From nobody Thu Nov 1 14:50:09 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7595912D4E8; Thu, 1 Nov 2018 14:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkAexZJgTivr; Thu, 1 Nov 2018 14:50:05 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 AD02812D4E9; Thu, 1 Nov 2018 14:50:04 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id z21-v6so19448756ljz.0; Thu, 01 Nov 2018 14:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4jDaGfl++i7ZTS7eoEXBnpGItcuO6DBXFTxVQTkrloU=; b=mnmNLgdYQXN54kdAJIpLZ/6YNoRFaXtKQEabphXYna72J9l1BCNgFMINZ8jBI+kTq+ pPiSEOgS4bjBGKYaHNe6y+HWwNUZe7uzUIWuYz3JAvoHn1KtjELjrBDdjKPWXILPmTL8 8fnHmIFP2XA0/bAjd2OQWvbOOyUwxieDxJ6MnHXo17jQRnFOLqtCHHwvS/UwmZEv1SgO SUG0BCkZEHtRcrTlSOHLtBRNpSTHPbEgI6m/ugfG9BSHQT/7pinGQEI3wpAMEfS9AObQ ik/UXLfbUVyWDWox7+2bjTBIwVW8vj7dGp3O1M/RkmxFKuF8pUf+LjnCJoc+iPJs/yPv YDcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4jDaGfl++i7ZTS7eoEXBnpGItcuO6DBXFTxVQTkrloU=; b=pk3JHbELVheUQLGjnQk4qDgkrdi8i7V19C09fBJ2jYQQZKtLb5ZNn9D/OaG1Rayitl N7Oj9rkEbU4x6QEywFwwZJHUPOKy5om5EsQL5E2RUkMtIqlldxVOBGrMA3GuJ97AsioD oBb1E5LxUQPs9xpn+4pXP57+QAJkixBK7iiUOW58IiMe+g2boK9N5qZargFYO3H9188I 1rLO/kVq1PuaQNKt6YEMbyAloIpYn/2Wi+OYoE8a+FVn3cUlQUxAiJm6gSKj2+O35XBz cqmr0gzHQSgET6oY5KyRq+kfVQ9PsNzSeRnGF38HcnjkASik2MDlvFdJ90uCkysOETaU TYxg== X-Gm-Message-State: AGRZ1gIpVERFEL43z1AH8UTnUYzcK5OBqmqYRP3tmXXx47L7jmhZU3Pc GbN719KvEqZPnP4AbN7zSRP4GglNP5Ma+DwDciaGFyv75Mg= X-Google-Smtp-Source: AJdET5d/m0ETWrTFUXBb7SlLzwk6tJUjWhoyoj4H5YVdT4E/Vm9zAmdLDSrNST2f0lKx4+8/56eERaFRZMv3GxG7a2Q= X-Received: by 2002:a2e:117:: with SMTP id 23-v6mr5851032ljb.131.1541109002653; Thu, 01 Nov 2018 14:50:02 -0700 (PDT) MIME-Version: 1.0 References: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net> In-Reply-To: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net> From: Spencer Dawkins at IETF Date: Thu, 1 Nov 2018 16:49:49 -0500 Message-ID: To: Mirja Kuehlewind Cc: draft-ietf-ippm-port-twamp-test.all@ietf.org, ippm@ietf.org Content-Type: multipart/alternative; boundary="000000000000a9dee40579a16660" Archived-At: Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 21:50:08 -0000 --000000000000a9dee40579a16660 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As long as TSV ADs are apologizing about this draft ... https://datatracker.ietf.org/doc/draft-ietf-ippm-port-twamp-test/history/ shows pretty clearly that Some Guy Who's Not The AD For IPPM changed the state from Publication Requested to AD Evaluation, which was no doubt a surprise to at least some people who were more awake than Some Guy was, that day Your AD was, and remains, Mirja! I can only offer as an excuse that what I did was once the right thing to do for IPPM drafts, and I'll try to stop doing it now :-) Spencer, as a participant, but one with AD privileges in the datatracker (oh, my!) On Mon, Oct 29, 2018 at 1:06 PM Mirja Kuehlewind (IETF) wrote: > Hi authors, > > first of all sorry for the rather long delay for this short draft. The ba= d > news it that I probably have to delay the processing even further as I wi= ll > not be able to join the next telechat on Nov 21 and we have to wait for t= he > telechat on Dec 6. The good news is that gives us plenty of time for the > IETF last call :-) > > I reviewed this document and I don=E2=80=99t think there are any issues t= hat would > not allow me to start the IETF last cal, but given we have time I would > like to ask a few questions/comments: > > 1) The document gives plenty of background information and talks about > impacts, however, it says very little about why it is good to have a fixe= d > port, beside this: > "It may simplify some operations to have a well- > known port available for the Test protocols, or for future > specifications involving TWAMP-Test to use this port as a default > port.=E2=80=9C > Is there any chance to say more than this? > > 2) Also, I agree with the shepherd that I don=E2=80=99t think it is neces= sary to > detail the history as much as done in section 4, e.g. rather discuss the > why than the actually comments by Lars and Tim. Also this section is call= ed > =E2=80=9Edefinition=E2=80=9C but this background information seems to go = beyond just > defining something. > > Btw. Tianran, it would be nice if you could update your comments in the > shepherd write-up accordingly if they have been addressed or are obsolete= . > Thanks! > > 3) I don=E2=80=99t think there is any normative language require in this = doc. As > you are =E2=80=9Ejust=E2=80=9C stating what has been normatively defined = in other > documents, it is actually preferred to not re-state normatively. > > 4) An update in the registry does not necessary mean an =E2=80=9Eupdate= =E2=80=9C of the > RFCs that registered that ports in the first place, especially as rfc4656 > doesn=E2=80=99t even mention the UDP port at all. Of course the use of = =E2=80=9Eupdate=E2=80=9C is > very loosely defined and can be used if that is preferred but it is not > strictly necessary. Or is there another reason to update these RFCs? If s= o, > it should be clearly spelled out in the draft. > > 5) Given that these entries are updates it would be nice to also fill the > missing information about contact information and assignee in the registr= y. > Instruction for IANA would need to be added to the IANA section in this > case. Assignee should be the IESG and contact the IETF chair. I assume th= e > modification date will be filled by IANA respectively. > > Thanks! > Mirja > > > > > > > --000000000000a9dee40579a16660 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As long as TSV ADs are apologizing about = this draft ...=C2=A0

https://datatracker.ietf= .org/doc/draft-ietf-ippm-port-twamp-test/history/ shows pretty clearly = that Some Guy Who's Not The AD For IPPM changed the state from Publicat= ion Requested to AD Evaluation, which was no doubt a surprise to at least s= ome people who were more awake than Some Guy was, that day=C2=A0
<= div>
Your AD was, and remains, Mirja!

I can only offer as an excuse that what I did was once the right thing to= do for IPPM drafts, and I'll try to stop doing it now :-)
Spencer, as a participant, but one with AD privileges in the d= atatracker (oh, my!)

On Mon, Oct 29, 2018 at 1:06 PM Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
Hi authors,

first of all sorry for the rather long delay for this short draft. The bad = news it that I probably have to delay the processing even further as I will= not be able to join the next telechat on Nov 21 and we have to wait for th= e telechat on Dec 6. The good news is that gives us plenty of time for the = IETF last call :-)

I reviewed this document and I don=E2=80=99t think there are any issues tha= t would not allow me to start the IETF last cal, but given we have time I w= ould like to ask a few questions/comments:

1) The document gives plenty of background information and talks about impa= cts, however, it says very little about why it is good to have a fixed port= , beside this:
"It may simplify some operations to have a well-
=C2=A0 =C2=A0known port available for the Test protocols, or for future
=C2=A0 =C2=A0specifications involving TWAMP-Test to use this port as a defa= ult
=C2=A0 =C2=A0port.=E2=80=9C
Is there any chance to say more than this?

2) Also, I agree with the shepherd that I don=E2=80=99t think it is necessa= ry to detail the history as much as done in section 4, e.g. rather discuss = the why than the actually comments by Lars and Tim. Also this section is ca= lled =E2=80=9Edefinition=E2=80=9C but this background information seems to = go beyond just defining something.

Btw. Tianran, it would be nice if you could update your comments in the she= pherd write-up accordingly if they have been addressed or are obsolete. Tha= nks!

3) I don=E2=80=99t think there is any normative language require in this do= c. As you are =E2=80=9Ejust=E2=80=9C stating what has been normatively defi= ned in other documents, it is actually preferred to not re-state normativel= y.

4) An update in the registry does not necessary mean an =E2=80=9Eupdate=E2= =80=9C of the RFCs that registered that ports in the first place, especiall= y as rfc4656 doesn=E2=80=99t even mention the UDP port at all. Of course th= e use of =E2=80=9Eupdate=E2=80=9C is very loosely defined and can be used i= f that is preferred but it is not strictly necessary. Or is there another r= eason to update these RFCs? If so, it should be clearly spelled out in the = draft.

5) Given that these entries are updates it would be nice to also fill the m= issing information about contact information and assignee in the registry. = Instruction for IANA would need to be added to the IANA section in this cas= e. Assignee should be the IESG and contact the IETF chair. I assume the mod= ification date will be filled by IANA respectively.

Thanks!
Mirja






--000000000000a9dee40579a16660-- From nobody Fri Nov 2 09:21:42 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C05A130DD6 for ; Fri, 2 Nov 2018 09:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 igJhZBRslzmd for ; Fri, 2 Nov 2018 09:21:38 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010048.outbound.protection.outlook.com [40.92.10.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7B5130DC5 for ; Fri, 2 Nov 2018 09:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zY/YewMEtNVDvt4Es4OSk5BsDACVJSKnHlDz5pUBaVM=; b=XB+oCb8p9WDtiHrH10cmD6qeKD/MI/zm06/I55bDVlxTFhisffKOojmYROet+uqBI8tk8AyHVFdGJATNT9/5T2KryKIUQfR68lRfE5dST2o+lmt0SMvKWZb+9mj2axkshN+LFxs0PQ8vhbEZ5DPeUdgVWxL4qIwazxfmbT5yN/jdj5lk+gff9T6758w1V5oxtA9EAineJ3qlBHPLrx3stHUtkxxZ0BILxR8reTcpPtWSrVgyrPBzjLGOAFDDKKEKjfFPyYM0KbT7efqHQLiifzXGkM2aK72cAVuLEC8eL+sOr0pYW5fseARIi4GfWYAD+pc7kviG7CUiz+JdCuxTQQ== Received: from CO1NAM04FT023.eop-NAM04.prod.protection.outlook.com (10.152.90.59) by CO1NAM04HT223.eop-NAM04.prod.protection.outlook.com (10.152.91.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1294.14; Fri, 2 Nov 2018 16:21:36 +0000 Received: from DM6PR15MB2217.namprd15.prod.outlook.com (10.152.90.51) by CO1NAM04FT023.mail.protection.outlook.com (10.152.90.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1294.14 via Frontend Transport; Fri, 2 Nov 2018 16:21:36 +0000 Received: from DM6PR15MB2217.namprd15.prod.outlook.com ([fe80::d01b:843d:920a:cc87]) by DM6PR15MB2217.namprd15.prod.outlook.com ([fe80::d01b:843d:920a:cc87%2]) with mapi id 15.20.1294.024; Fri, 2 Nov 2018 16:21:36 +0000 From: Wenfei Wu To: ippm Thread-Topic: SOSR 2019 Call For Papers (due in 2 weeks) Thread-Index: AQHUcsggfzmgsy6nI0Sjy3fAa8VkgA== Date: Fri, 2 Nov 2018 16:21:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: PU1PR01CA0041.apcprd01.prod.exchangelabs.com (2603:1096:803:16::29) To DM6PR15MB2217.namprd15.prod.outlook.com (2603:10b6:5:8b::31) x-incomingtopheadermarker: OriginalChecksum:D15476C6F19A0BED12C834DBBA325A4185E408900549EE2614C4F8AEE556DE87; UpperCasedChecksum:953C18636E869353970876E57E8815ABB20557FC634EC069C3C0F1A5B549179B; SizeAsReceived:7207; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [iBvpk6FMoaOnxVX7yyuIjbC9y75c1ymA] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM04HT223; 6:psuMhDnrFcbmVYvurIDlyw5rrv3om1RRdiLQDHfsaAxYGT3G7DZT7A39+JJUzE9lnfvrObF8co8pRFQp4Jth6SrQ70a3Nxh48cVo55oDh26O8E8pc5eynBRbCbyal1+oQGTSYUE4C4Uu14YBBIpN/vv7bHJQXEPWgIJvk3JYzZNTAFt/s9sgHGxKbku7Vn6XDAll9c1cmUu0SXYhV3g/hU+zuiP1r4hUW0ILCjhcmeof0iX7sPfvxNMzmg8o0BD0ymw9ooLX3t0VaJZ3AkW0pufLPO64vZfoBNpUnmQCVCpRXI+xAkIzBLR6QQuC90qw+Aj1cewMEt23lJ0wYTZU7TFO1a91swkyPdIpyiLcUvvqMl1adHKjPnqqoN9tCvLIIyMmygyY8RukTDBSX7xoJr5HqtY4RvAjKXDvlQkoFnNFGLPG30X+Z5FCgBlrD2Nux/4WURQG4+MmNqAvQClnGA==; 5:zkkbbs97hDdGzcmYljrxg4mlsHTxEeNSbn6lg1AK+L+J81SZvbwYEqkJwL9NlsF7bEzYnGizQ5cGYCaq1B5u5oS/tiHQU6zqKU5jmhogFMxi4cSIpQXRxagB6Fzqs3kDxPa8JziQ6Mg06sGhY6Sm4w8Feb5+poPBjn/yEUIzzfU=; 7:1c3vMytx1DAIYsOX4X7xIJUIXpfvp+2KRTr2yH78x69oack6rPlvot0JAAtTYC9WcZCtIGshEZpYTxTvWUysAXH4CdYAVt90dDg63JU5xxRwgFQrxxgIyGTaNMF7sLW6wq5qy4iiFn7hR0adlNeP2Q== x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:CO1NAM04HT223; x-ms-traffictypediagnostic: CO1NAM04HT223: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:CO1NAM04HT223; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM04HT223; x-microsoft-antispam-message-info: u3Eb1Pqk/Z7GExPloFIlOi7BwxhlITMVOmthR3DmPaYL/uupQzzgrz5SgVO4YB+b Content-Type: multipart/alternative; boundary="_000_DM6PR15MB22172A3718733A21A4E62665C8CF0DM6PR15MB2217namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: b6587b75-6f1a-4db7-b0b6-5cad10ef59a7 X-MS-Exchange-CrossTenant-Network-Message-Id: ad136efc-e367-4d2a-ada0-08d640df42cb X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: b6587b75-6f1a-4db7-b0b6-5cad10ef59a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2018 16:21:36.7506 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT223 Archived-At: Subject: [ippm] SOSR 2019 Call For Papers (due in 2 weeks) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 16:21:41 -0000 --_000_DM6PR15MB22172A3718733A21A4E62665C8CF0DM6PR15MB2217namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Symposium on SDN Research (SOSR) is the premiere venue for research pub= lications on SDN, building on past years' successful SOSR and HotSDN worksh= ops. The ACM SOSR 2019 will be held in San Jose, CA in April of 2019. Like = previous years, SOSR will be held at same time as the Open Networking Summi= t (ONS). We will again be giving out the SOSR Software Systems Award, which= recognizes software that has significantly impacted SDN. We invite researchers and practitioners to submit both long and short previ= ously unpublished papers, choosing the length appropriate to the level of c= ompleteness and detail in the work. We particularly encourage position pape= rs, radical ideas, and papers on real applications and experiences of SDN. Web: https://conferences.sigcomm.org/sosr/2019/ Abstracts due: November 8, 2018 (5pm PT) Paper submission: November 15, 2018 (5pm PT) Notification: January 15, 2019 Camera-ready due: February 28, 2019 Conference: April 3-5, 2019 in San Jose, CA (tentative dates; will be final= ized soon) --_000_DM6PR15MB22172A3718733A21A4E62665C8CF0DM6PR15MB2217namp_ Content-Type: text/html; charset="us-ascii" Content-ID: <56DA921387D30443B0CA0136ED343EE1@namprd15.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
The Symposium on SDN Research (SOSR) is the premiere venue for researc= h publications on SDN, building on past years' successful SOSR and HotSDN w= orkshops. The ACM SOSR 2019 will be held in San Jose, CA in April of 2019. = Like previous years, SOSR will be held at same time as the Open Networking Summit (ONS). We will again be gi= ving out the SOSR Software Systems Award, which recognizes software that ha= s significantly impacted SDN.

We invite researchers and practitioners to submit both long and short = previously unpublished papers, choosing the length appropriate to the level= of completeness and detail in the work. We particularly encourage position= papers, radical ideas, and papers on real applications and experiences of SDN.


Web: https://conferences.sigcomm.org/sosr/2019/

Abstracts due: November 8, 2018 (5pm PT)
Paper submission: November 15, 2018 (5pm PT)
Notification: January 15, 2019
Camera-ready due: February 28, 2019
Conference: April 3-5, 2019 in San Jose, CA (tentative dates; will be = finalized soon)
--_000_DM6PR15MB22172A3718733A21A4E62665C8CF0DM6PR15MB2217namp_-- From nobody Fri Nov 2 15:35:43 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105B2130DFC; Fri, 2 Nov 2018 15:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=apple.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 ceHSmhzvRyH6; Fri, 2 Nov 2018 15:35:40 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 59926130DFA; Fri, 2 Nov 2018 15:35:40 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id wA2MQWdc064821; Fri, 2 Nov 2018 15:35:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=phmBTy1Nrjc2bv1SldbUlEU57MZRzRCQVPoJdchYrZA=; b=k1ym/Ain3sTvWnEQHdJXAlqFPl5IMuhVtRYRixBEE5s5wnGZ0F9ZmxmwKkHTDHH96r79 so22OzwGqBtwEj2nz5Qy5d6SGF422XyZnUClNP0PuDvFwdySjOXbctXKhfA6MN2RGqlQ Wqht2kW8z84svPdxk2oyb7mZWBGKCij7UwjaMiauruPXX0TCNq/VIR5w3N4mNW1kwuAC ZaLLMUruO36zq8swwnJFguXZAmIoW4YJVhlVLPenfv8mDvVBvUbe4IlS0/QKE5e9BDfQ CPK2SrEabyOrBQuNJtmwx7pgUtOACpdxL7uU0+km01Z5XB6q3b/fPD6soi+7KdIANJJe Xw== Received: from sng-mtap-sz01.asia.apple.com (sng-mtap-sz01.asia.apple.com [17.84.80.20]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2ncmjd0qjd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 02 Nov 2018 15:35:36 -0700 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from sng-mmpp-sz02.asia.apple.com (sng-mmpp-sz02.asia.apple.com [17.84.80.27]) by sng-mtap-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PHL00C0P83BFH00@sng-mtap-sz01.asia.apple.com>; Sat, 03 Nov 2018 06:35:35 +0800 (SGT) Received: from process_viserion-daemon.sng-mmpp-sz02.asia.apple.com by sng-mmpp-sz02.asia.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHL001005R8SE00@sng-mmpp-sz02.asia.apple.com>; Sat, 03 Nov 2018 06:35:34 +0800 (SGT) X-Va-A: X-Va-T-CD: e65fcd9c4ae82fe548d4d21de6e0a66b X-Va-E-CD: cb1ae5a352ae44319ec1ee1950d2504d X-Va-R-CD: cf299964720e53c35c16b2eefc7c88db X-Va-CD: 0 X-Va-ID: ccbdc8ef-eb78-44b0-85af-887374563091 X-V-A: X-V-T-CD: ae1982d74d6d2b03b8f4d093c804888d X-V-E-CD: cb1ae5a352ae44319ec1ee1950d2504d X-V-R-CD: cf299964720e53c35c16b2eefc7c88db X-V-CD: 0 X-V-ID: eda4e219-df0b-4da7-a194-6b051b1bea6c Received: from process_milters-daemon.sng-mmpp-sz02.asia.apple.com by sng-mmpp-sz02.asia.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHL000005HVDD00@sng-mmpp-sz02.asia.apple.com>; Sat, 03 Nov 2018 06:35:32 +0800 (SGT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-02_13:,, signatures=0 Received: from [17.235.143.61] (unknown [17.235.143.61]) by sng-mmpp-sz02.asia.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PHL009IC82ZEN30@sng-mmpp-sz02.asia.apple.com>; Sat, 03 Nov 2018 06:35:30 +0800 (SGT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <43C2B245-408B-4043-A78F-A4295DAFFC6A@cisco.com> Date: Sat, 03 Nov 2018 06:35:20 +0800 Content-transfer-encoding: quoted-printable Message-id: <83BF63ED-EE91-4359-8F6B-94095D5D4E74@apple.com> References: <43C2B245-408B-4043-A78F-A4295DAFFC6A@cisco.com> To: "ippm@ietf.org" , "draft-fioccola-ippm-multipoint-alt-mark@ietf.org" X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-02_13:, , signatures=0 Archived-At: Subject: Re: [ippm] Adoption call for draft-fioccola-ippm-multipoint-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 22:35:42 -0000 I've marked draft-fioccola-ippm-multipoint-alt-mark as Adopted. Thanks = to everyone who sent their input! Authors, please submit a -ietf version of the document when ready. Best, Tommy >=20 > -----Messaggio originale----- > Da: tpauly@apple.com [mailto:tpauly@apple.com]=20 > Inviato: marted=C3=AC 9 ottobre 2018 01:03 > A: ippm@ietf.org > Cc: draft-fioccola-ippm-multipoint-alt-mark@ietf.org > Oggetto: Adoption call for draft-fioccola-ippm-multipoint-alt-mark >=20 > Hello IPPM, >=20 > In Montreal we decided to call for working group adoption of = draft-fioccola-ippm-multipoint-alt-mark prior to our IETF 103 meeting. >=20 > This email begins the call-for-adoption period, which will end at = the start of the IETF 103 meeting (November 5, 2018), to avoid getting = too close to the draft submission deadline. Please reply to this email = if you support adoption or have any objections to the WG adopting this = document. >=20 > The current status and text of the document can be found here: >=20 > = https://datatracker.ietf.org/doc/draft-fioccola-ippm-multipoint-alt-mark/ > = https://tools.ietf.org/html/draft-fioccola-ippm-multipoint-alt-mark-04 > = https://www.ietf.org/id/draft-fioccola-ippm-multipoint-alt-mark-04.txt >=20 > Best, > Tommy (as IPPM co-chair) >=20 >=20 >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie.=20 >=20 > This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks.=20 >=20 > Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 = necessario. >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >=20 >=20 From nobody Sat Nov 3 22:22:43 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453C8130DE9 for ; Sat, 3 Nov 2018 22:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 mHA-WHHDlCl2 for ; Sat, 3 Nov 2018 22:22:40 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 03447130DE4 for ; Sat, 3 Nov 2018 22:22:40 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 76E8F9D03B55C for ; Sun, 4 Nov 2018 05:22:36 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 4 Nov 2018 05:22:37 +0000 Received: from DGGEMM532-MBX.china.huawei.com ([169.254.7.205]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0415.000; Sun, 4 Nov 2018 13:22:34 +0800 From: Lizhenbin To: "ippm@ietf.org" Thread-Topic: Comments on draft-ietf-ippm-ioam-data-04 Thread-Index: AdRz/mPgYI8IvVkaQ8KInrqa6akAtA== Date: Sun, 4 Nov 2018 05:22:33 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D8F4BFDCC@DGGEMM532-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.168.247] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8F4BFDCCDGGEMM532MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [ippm] Comments on draft-ietf-ippm-ioam-data-04 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 05:22:42 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8F4BFDCCDGGEMM532MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQXV0aG9ycywNCldoZW4gaGF2ZSB0aGUgSGFja2F0aG9uIG9uIElPQU0gaW4gSUVURjEwMywg SSByZWFkIHRoZSBkcmFmdHMgYW5kIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSBmb2xsb3dpbmcgY29t bWVudHMgYW5kIHNvbWUgZG91YnRzIGZvciB5b3VyIHJlZmVyZW5jZS4NCjEuDQoiTm90ZSB0aGF0 IG5vdCBldmVyeQ0KICAgbm9kZSBpbiBhbiBJT0FNIGRvbWFpbiBuZWVkcyB0byBiZSBhbiBJT0FN IHRyYW5zaXQgbm9kZS4gIEZvcg0KICAgZXhhbXBsZSwgYSBTZWdtZW50IFJvdXRpbmcgZGVwbG95 bWVudCBtaWdodCByZXF1aXJlIHRoZSBzZWdtZW50DQogICByb3V0aW5nIHBhdGggdG8gYmUgdmVy aWZpZWQuICBJbiB0aGF0IGNhc2UsIG9ubHkgdGhlIFNSIG5vZGVzIHdvdWxkDQogICBhbHNvIGJl IElPQU0gdHJhbnNpdCBub2RlcyByYXRoZXIgdGhhbiBhbGwgbm9kZXMgLg0KIg0KMSkgSG93IHRv IGRpc3Rpbmd1aXNoIGlmIGFsbCBub2RlcyBvciBTUiBub2RlcyB3aWxsIHJlY29yZCBJT0FNIGlu Zm8/IElmIHRoZSBib3RoIGlzIG5lY2Vzc2FyeSwgaG93IHRvIHByb2Nlc3M/DQoyKSBGb3IgU1J2 NiB0aGUgU0lEIGxpc3QgY2FuIGJlIGtlcHQgaW4gdGhlIFNSSC4gQnV0IGZvciBTUi1NUExTLCB0 aGUgTGFiZWwvU0lEIHdpbGwgYmUgcG9wcGVkIGFuZCB0aGUgU0lEIGxpc3QgY2Fubm90IGJlIGtl cHQuIFdvdWxkIHRoZXJlIGJlIGRpZmZlcmVudCBwcm9jZXNzIGZvciBTUi1NU1BMIGFuZCBTUnY2 Lg0KMykgSW4gb3JkZXIgdG8gcmVkdWNlIHRoZSBjb21wbGV4aXR5LCBjb3VsZCB0aGUgcGFydCBi ZSBkaXNjdXNzZWQgaW4gc29tZSBTUiBpT0FNIGRyYWZ0IGluc3RlYWQgb2YgdGhpcyBkcmFmdD8N Cg0KDQoNCjIuDQoiV2hpbGUsIGZvciBleGFtcGxlLCB0aGUNCiAgICAgIElPQU0gbm9kZSBpZGVu dGlmaWVyIChOb2RlLUlEKSBkb2VzIG5vdCBoYXZlIHRvIGJlIHVuaXF1ZSBpbiBhDQogICAgICBk ZXBsb3ltZW50ICwgdGhlIGNvbWJpbmF0aW9uIG9mIE5vZGUtSUQgYW5kIE5hbWVzcGFjZS1JRCB3 aWxsDQogICAgICBhbHdheXMgYmUgdW5pcXVlLg0KIg0KV2h5IGFzc3VtZSB0aGF0IHRoZSBub2Rl IGlkIHdpbGwgbm90IGJlIHVuaXF1ZT8gSXQgaXMgb25seSB0byBpbmNyZWFzZSBjb21wbGV4aXR5 LlRoZSB1bmlxdWVuZXNzIHNob3VsZCBiZSBndWFyYW50ZWVkIHdoaWNoIGlzIGNvbW1vbiBpbiBv dGhlciBwcm90b2NvbHMgZGVzaWduIHN1Y2ggYXMgTFNSIElEIGluIE1QTFMgc2lnbmFsbGluZywg Um91dGVyIElEIGluIElHUCwgZXRjLg0KDQoNCg0KMy4NCiJBbiBJT0FNIGVuY2Fwc3VsYXRpbmcg bm9kZSBtdXN0ICBzZXQgTm9kZUxlbi4iDQpJbiBtYW55IHBsYWNlcyAibXVzdCIgc2hvdWxkIGJl IGNoYW5nZWQgdG8gIk1QTFMiLg0KDQoNCg0KNC4NCiIgICAgICBBIG5vZGUgcmVjZWl2aW5nIGFu IElPQU0gUHJlLWFsbG9jYXRlZCBvciBJbmNyZW1lbnRhbCBUcmFjZSBPcHRpb24NCiAgICAgIG1h eSAgIHJlbHkgb24gdGhlIE5vZGVMZW4gdmFsdWUsIG9yIGl0IG1heSBpZ25vcmUgdGhlIE5vZGVM ZW4gdmFsdWUNCiAgICAgIGFuZCBjYWxjdWxhdGUgdGhlIG5vZGUgbGVuZ3RoIGZyb20gdGhlIElP QU0tVHJhY2UtVHlwZSBiaXRzLg0KIg0KU2hvdWxkICJtYXkiIGJlIGNoYW5nZWQgdG8gIk1BWSI/ DQoNCg0KDQo1Lg0KIg0KICAgSU9BTS1UcmFjZS1UeXBlOiAgQSAxNi1iaXQgaWRlbnRpZmllciAg d2hpY2ggc3BlY2lmaWVzIHdoaWNoIGRhdGENCiAgICAgIHR5cGVzIGFyZSB1c2VkIGluIHRoaXMg bm9kZSBkYXRhIGxpc3QuDQoiDQoxNi1iaXQgc2hvdWxkIGJlIGNoYW5nZWQgdG8gMjQtYml0IGJh c2VkIHRoZSBuZXcgZGVzaWduLg0KDQoNCg0KNi4NCiINCiAgICAgIEJpdCAxMi0yMiAgVW5kZWZp bmVkLiAgQW4gSU9BTSBlbmNhcHN1bGF0aW5nIG5vZGUgbXVzdCAgc2V0IHRoZQ0KICAgICAgICAg ICAgICAgdmFsdWUgb2YgZWFjaCBvZiB0aGVzZSBiaXRzIHRvIDAuICBJZiBhbiBJT0FNIHRyYW5z aXQNCiAgICAgICAgICAgICAgIG5vZGUgcmVjZWl2ZXMgYSBwYWNrZXQgd2l0aCBvbmUgb3IgbW9y ZSBvZiB0aGVzZSBiaXRzIHNldA0KICAgICAgICAgICAgICAgdG8gMSwgaXQgbXVzdCAgZWl0aGVy Og0KIg0KV2h5IG5vdCBkaXJlY3RseSBpZ25vcmUgdGhlc2UgYml0cyB3aGljaCBhcmUgbm90IHNl dCBhcyAwPw0KDQoNCg0KNy4NCiINClRoZSBmaXJzdCBlbGVtZW50DQogICAgICBvZiB0aGUgbm9k ZSBkYXRhIGxpc3QgKG5vZGUgZGF0YSBsaXN0IFswXSkgY29udGFpbnMgdGhlIGxhc3Qgbm9kZQ0K ICAgICAgb2YgdGhlIHBhdGggd2hpbGUgdGhlIGxhc3Qgbm9kZSBkYXRhIG9mIHRoZSBub2RlIGRh dGEgbGlzdCAobm9kZQ0KICAgICAgZGF0YSBsaXN0W25dKSBjb250YWlucyB0aGUgZmlyc3Qgbm9k ZSBkYXRhIG9mIHRoZSBwYXRoIHRyYWNlZC4NCiINCklzIHRoaXMgZm9yIEluY3JlbWVudGFsIFRy YWNlIG9wdGlvbiBvciBmb3IgYm90aCBJbmNyZW1hbnRhbCBUcmFjZSBvcHRpb24gYW5kIFByZS1h bGxvY2F0ZWQgb3B0aW9uPw0KDQoNCg0KOC4NCiINCnRoZSBmaWVsZCB2YWx1ZSBNVVNUDQogICBi ZSBzZXQgdG8gMHhGRkZGRkZGRiBmb3IgNC1vY3RldCBmaWVsZHMgb3IgMHhGRkZGRkZGRkZGRkZG RkZGIGZvcg0KICAgOC1vY3RldCBmaWVsZHMNCiINClNpbmNlIHNvbWUgY3VzdG9taXplZCBkYXRh IG1heWJlIGVuY2Fwc3VsYXRlZCBpbiB0aGUgSU9BTSBoZWFkZXIsIG1heWJlIGl0IGlzIG5vdCBh bHdheXMgYWxpZ25lZCB3aXRoIDQtb2N0ZXQgb3IgOC1vY3RldC4gSXMgaXQgbmVjZXNzYXJ5IHRv IGludHJvZHVjZSBzb21lIHBhZGRpbmcgbWFjaGFuaXNtcz8NCg0KDQoNCjkuDQoiDQogICAgICBu b2RlX2lkOiAgMy1vY3RldCB1bnNpZ25lZCBpbnRlZ2VyLiAgTm9kZSBpZGVudGlmaWVyIGZpZWxk IHRvDQogICAgICAgICB1bmlxdWVseSBpZGVudGlmeSBhIG5vZGUgd2l0aGluIGluLXNpdHUgT0FN IGRvbWFpbiAuDQoiDQpUaG91Z2ggaXQgaXMgbmVjY2Vzc2FyeSB0byBzYXZlIHNwYWNlLCBpdCBp cyBhIGxpdHRsZSBzdHJhbmdlIGZvciAzLW9jdGV0IG5vZGUtaWQgY29tcGFyaW5nIHBvcHVsYXIg NC1vY3RldCBhbmQgMTYtb2N0ZXQgbm9kZSBpZCBpbiBvdGhlciBwcm90b2NvbHMuIFRoZSAzLW9j dGV0IG5vZGUgaWQgcmVtb3ZlIHRoZSBwb3NzaWJpbGl0eSBvZiByZXVzZSBhbmQgY29uc2lzdGVu Y3kuIEl0IG1heSBpbnRyb2R1Y2UgdGhlIHVubmVjZXNzYXJ5IGNvbmZ1c2lvbi4NCg0KDQoNCjEw Lg0KIg0KICAgcXVldWUgZGVwdGg6ICA0LW9jdGV0IHVuc2lnbmVkIGludGVnZXIgZmllbGQuICBU aGlzIGZpZWxkIGluZGljYXRlcw0KICAgICAgdGhlIGN1cnJlbnQgbGVuZ3RoIG9mIHRoZSBlZ3Jl c3MgaW50ZXJmYWNlIHF1ZXVlIG9mIHRoZSBpbnRlcmZhY2UNCiAgICAgIGZyb20gd2hlcmUgdGhl IHBhY2tldCBpcyBmb3J3YXJkZWQgb3V0Lg0KIg0KVGhlIHF1ZXVlIGxlbmd0aCBpcyBub3QgZW5v dWdoIHNpbmNlIHRoZXJlIG1heSBiZSBtdWx0aXBsZSBxdWV1ZXMgZm9yIGEgc3BlY2lmaWMgb3V0 Z29pbmcgaW50ZXJmYWNlLiBJZiB0aGVyZSBpcyBILVFvUywgaXQgd2lsbCBiZSBtb3JlIGNvbXBs ZXguDQoNCg0KDQoxMS4NCiINCiAgIGJ1ZmZlciBvY2N1cGFuY3k6ICA0LW9jdGV0IHVuc2lnbmVk IGludGVnZXIgZmllbGQuICBUaGlzIGZpZWxkDQogICAgICBpbmRpY2F0ZXMgdGhlIGN1cnJlbnQg c3RhdHVzIG9mIHRoZSBidWZmZXIgb2NjdXBhbmN5LiAgVGhlIGJ1ZmZlcg0KICAgICAgb2NjdXBh bmN5IGlzIGV4cHJlc3NlZCBhcyB0aGUgY3VycmVudCBudW1iZXIgb2YgbWVtb3J5IGJ1ZmZlcnMN CiAgICAgIHVzZWQgYnkgdGhlIHNldCBvZiBxdWV1ZXMgdGhhdCBzaGFyZSBhIGNvbW1vbiBidWZm ZXIgcG9vbCAuDQoiDQpXaGF0IGlzIHRoZSB1bml0c29mIHRoZSBidWZmZXIgb2NjdXBhbmN5PyBJ dCBpcyB0aGUgbnVtYmVyIG9mIGJ5dGVzIG9yIHRoZSBwZXJjZW50YWdlPw0KDQoNCg0KMTIuDQoi DQogICAweEQ0MDA6ICAgSU9BTS1UcmFjZS1UeXBlIGlzIDB4RDQwMCB0aGVuIHRoZSBmb3JtYXQg b2Ygbm9kZSBkYXRhIGlzOg0KIg0KRm9yICIweEQ0MDAiOg0KMSkgVGhlIHRyYWNlIHR5cGUgdmFs dWUgYWxyZWFkeSBjaGFuZ2VzIHRvIDI0LWJpdC4NCjIpIEJhc2VkIG9uIHRoZSBiaXQgZGVmaW5p dGlvbiBpbiB0aGUgZHJhZnQsIHRoZSB2YWx1ZSBpcyB3cm9uZy4gVGhlcmUgYXJlIHNpbWlsYXIg ZXJyb3JzIGZvciB2YWx1ZXMgaW4gdGhlIGV4YW1wbGVzIG9mIHRoZSBzZWN0aW9uLiBQbGVhc2Ug dXBkYXRlLg0KDQoNCg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KWmhlbmJpbiAoUm9iaW4pDQo= --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8F4BFDCCDGGEMM532MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Authors,
When have the Hackathon on IOAM in IETF103, I read the drafts and would lik= e to propose following comments and some doubts for your reference.
1.
"Note that not every
   node in an IOAM domain needs to be an IOAM transit node. = For
   example, a Segment Routing deployment might require the segmen= t
   routing path to be verified.  In that case, only the SR n= odes would
   also be IOAM transit nodes rather than all nodes .
"
1) How to distinguish if all nodes or SR nodes will record IOAM info? If th= e both is necessary, how to process?
2) For SRv6 the SID list can be kept in the SRH. But for SR-MPLS, the Label= /SID will be popped and the SID list cannot be kept. Would there be differe= nt process for SR-MSPL and SRv6.
3) In order to reduce the complexity, could the part be discussed in some S= R iOAM draft instead of this draft?

 

2.
"While, for example, the
      IOAM node identifier (Node-ID) does not have= to be unique in a
      deployment , the combination of Node-ID and = Namespace-ID will
      always be unique.
"
Why assume that the node id will not be unique? It is only to increase comp= lexity.The uniqueness should be guaranteed which is common in other protoco= ls design such as LSR ID in MPLS signalling, Router ID in IGP, etc.

 

3.
"An IOAM encapsulating node must  set NodeLen."
In many places "must" should be changed to "MPLS".

 

4.
"      A node receiving an IOAM Pre-allocated= or Incremental Trace Option
      may   rely on the NodeLen value, o= r it may ignore the NodeLen value
      and calculate the node length from the IOAM-= Trace-Type bits.
"
Should "may" be changed to "MAY"?

 

5.
"
   IOAM-Trace-Type:  A 16-bit identifier  which specifi= es which data
      types are used in this node data list.
"
16-bit should be changed to 24-bit based the new design.

 

6.
"
      Bit 12-22  Undefined.  An IOAM enc= apsulating node must  set the
            &nb= sp;  value of each of these bits to 0.  If an IOAM transit
            &nb= sp;  node receives a packet with one or more of these bits set
            &nb= sp;  to 1, it must  either:
"
Why not directly ignore these bits which are not set as 0?

 

7.
"
The first element
      of the node data list (node data list [0]) c= ontains the last node
      of the path while the last node data of the = node data list (node
      data list[n]) contains the first node data o= f the path traced.
"
Is this for Incremental Trace option or for both Incremantal Trace option a= nd Pre-allocated option?

 

8.
"
the field value MUST
   be set to 0xFFFFFFFF for 4-octet fields or 0xFFFFFFFFFFFFFFFF = for
   8-octet fields
"
Since some customized data maybe encapsulated in the IOAM header, maybe it = is not always aligned with 4-octet or 8-octet. Is it necessary to introduce= some padding machanisms?

 

9.
"
      node_id:  3-octet unsigned integer.&nbs= p; Node identifier field to
         uniquely identify a node w= ithin in-situ OAM domain .
"
Though it is neccessary to save space, it is a little strange for 3-octet n= ode-id comparing popular 4-octet and 16-octet node id in other protocols. T= he 3-octet node id remove the possibility of reuse and consistency. It may = introduce the unnecessary confusion.

 

10.
"
   queue depth:  4-octet unsigned integer field.  This = field indicates
      the current length of the egress interface q= ueue of the interface
      from where the packet is forwarded out.
"
The queue length is not enough since there may be multiple queues for a spe= cific outgoing interface. If there is H-QoS, it will be more complex.

 

11.
"
   buffer occupancy:  4-octet unsigned integer field.  = This field
      indicates the current status of the buffer o= ccupancy.  The buffer
      occupancy is expressed as the current number= of memory buffers
      used by the set of queues that share a commo= n buffer pool .
"
What is the unitsof the buffer occupancy? It is the number of bytes or the = percentage?

 

12.
"
   0xD400:   IOAM-Trace-Type is 0xD400 then the format = of node data is:
"
For "0xD400":
1) The trace type value already changes to 24-bit.
2) Based on the bit definition in the draft, the value is wrong. There are = similar errors for values in the examples of the section. Please update.

 

 

Best Regards,

Zhenbin (Robin)

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D8F4BFDCCDGGEMM532MBXchi_-- From nobody Sun Nov 4 13:58:37 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61956128CB7; Sun, 4 Nov 2018 13:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 s_JeLYQ5a6a8; Sun, 4 Nov 2018 13:58:34 -0800 (PST) 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 3591212872C; Sun, 4 Nov 2018 13:58:34 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wA4LtKUH042780; Sun, 4 Nov 2018 16:58:33 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049462.ppops.net-00191d01. with ESMTP id 2nj1552h01-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 04 Nov 2018 16:58:32 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA4LwVdS046086; Sun, 4 Nov 2018 15:58:32 -0600 Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [135.46.181.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA4LwOcL045957; Sun, 4 Nov 2018 15:58:25 -0600 Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [127.0.0.1]) by zlp30494.vci.att.com (Service) with ESMTP id A0A0D40004A2; Sun, 4 Nov 2018 21:58:24 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30494.vci.att.com (Service) with ESMTP id 827EC4000491; Sun, 4 Nov 2018 21:58:24 +0000 (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 wA4LwOwt012416; Sun, 4 Nov 2018 15:58:24 -0600 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 wA4LwIh3012244; Sun, 4 Nov 2018 15:58:18 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-blue.research.att.com (Postfix) with ESMTP id 3A364F1946; Sun, 4 Nov 2018 16:58:18 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Sun, 4 Nov 2018 16:57:30 -0500 From: "MORTON, ALFRED C (AL)" To: "Mirja Kuehlewind (IETF)" , "draft-ietf-ippm-port-twamp-test.all@ietf.org" CC: "ippm@ietf.org" Thread-Topic: [ippm] AD review of draft-ietf-ippm-port-twamp-test Thread-Index: AQHUb7IS2QGrObPQyUeFS1fWuZHhsKVAJHPw Date: Sun, 4 Nov 2018 21:57:29 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557D896F@njmtexg5.research.att.com> References: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net> In-Reply-To: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-04_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811040209 Archived-At: Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 21:58:37 -0000 SGkgTWlyamEsDQpwbGVhc2Ugc2VlIHJlcGxpZXMgaW4tbGluZS4NCkFsDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIE1pcmphIEt1ZWhsZXdpbmQNCj4gKElFVEYpDQo+IFNlbnQ6IE1v bmRheSwgT2N0b2JlciAyOSwgMjAxOCAyOjA2IFBNDQo+IFRvOiBkcmFmdC1pZXRmLWlwcG0tcG9y dC10d2FtcC10ZXN0LmFsbEBpZXRmLm9yZw0KPiBDYzogaXBwbUBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBbaXBwbV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBwbS1wb3J0LXR3YW1wLXRlc3QNCj4g DQo+IEhpIGF1dGhvcnMsDQo+IA0KPiBmaXJzdCBvZiBhbGwgc29ycnkgZm9yIHRoZSByYXRoZXIg bG9uZyBkZWxheSBmb3IgdGhpcyBzaG9ydCBkcmFmdC4gVGhlIGJhZA0KPiBuZXdzIGl0IHRoYXQg SSBwcm9iYWJseSBoYXZlIHRvIGRlbGF5IHRoZSBwcm9jZXNzaW5nIGV2ZW4gZnVydGhlciBhcyBJ DQo+IHdpbGwgbm90IGJlIGFibGUgdG8gam9pbiB0aGUgbmV4dCB0ZWxlY2hhdCBvbiBOb3YgMjEg YW5kIHdlIGhhdmUgdG8gd2FpdA0KPiBmb3IgdGhlIHRlbGVjaGF0IG9uIERlYyA2LiBUaGUgZ29v ZCBuZXdzIGlzIHRoYXQgZ2l2ZXMgdXMgcGxlbnR5IG9mIHRpbWUNCj4gZm9yIHRoZSBJRVRGIGxh c3QgY2FsbCA6LSkNCj4gDQo+IEkgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhbmQgSSBkb27igJl0 IHRoaW5rIHRoZXJlIGFyZSBhbnkgaXNzdWVzIHRoYXQgd291bGQNCj4gbm90IGFsbG93IG1lIHRv IHN0YXJ0IHRoZSBJRVRGIGxhc3QgY2FsLCBidXQgZ2l2ZW4gd2UgaGF2ZSB0aW1lIEkgd291bGQN Cj4gbGlrZSB0byBhc2sgYSBmZXcgcXVlc3Rpb25zL2NvbW1lbnRzOg0KPiANCj4gMSkgVGhlIGRv Y3VtZW50IGdpdmVzIHBsZW50eSBvZiBiYWNrZ3JvdW5kIGluZm9ybWF0aW9uIGFuZCB0YWxrcyBh Ym91dA0KPiBpbXBhY3RzLCBob3dldmVyLCBpdCBzYXlzIHZlcnkgbGl0dGxlIGFib3V0IHdoeSBp dCBpcyBnb29kIHRvIGhhdmUgYSBmaXhlZA0KPiBwb3J0LCBiZXNpZGUgdGhpczoNCj4gIkl0IG1h eSBzaW1wbGlmeSBzb21lIG9wZXJhdGlvbnMgdG8gaGF2ZSBhIHdlbGwtDQo+ICAgIGtub3duIHBv cnQgYXZhaWxhYmxlIGZvciB0aGUgVGVzdCBwcm90b2NvbHMsIG9yIGZvciBmdXR1cmUNCj4gICAg c3BlY2lmaWNhdGlvbnMgaW52b2x2aW5nIFRXQU1QLVRlc3QgdG8gdXNlIHRoaXMgcG9ydCBhcyBh IGRlZmF1bHQNCj4gICAgcG9ydC7igJwNCj4gSXMgdGhlcmUgYW55IGNoYW5jZSB0byBzYXkgbW9y ZSB0aGFuIHRoaXM/DQpbYWNtXSANCnllcywgbWVudGlvbmVkIEJCRiBUUi0zOTAgaW1wbGVtZW50 YXRpb25zIGFzIGJlbmVmYWN0b3JzLiANCj4gDQo+IDIpIEFsc28sIEkgYWdyZWUgd2l0aCB0aGUg c2hlcGhlcmQgdGhhdCBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgbmVjZXNzYXJ5IHRvDQo+IGRldGFp bCB0aGUgaGlzdG9yeSBhcyBtdWNoIGFzIGRvbmUgaW4gc2VjdGlvbiA0LCBlLmcuIHJhdGhlciBk aXNjdXNzIHRoZQ0KPiB3aHkgdGhhbiB0aGUgYWN0dWFsbHkgY29tbWVudHMgYnkgTGFycyBhbmQg VGltLiBBbHNvIHRoaXMgc2VjdGlvbiBpcw0KPiBjYWxsZWQg4oCeZGVmaW5pdGlvbuKAnCBidXQg dGhpcyBiYWNrZ3JvdW5kIGluZm9ybWF0aW9uIHNlZW1zIHRvIGdvIGJleW9uZA0KPiBqdXN0IGRl ZmluaW5nIHNvbWV0aGluZy4NClthY21dIA0KT2sgdGhlIHNlY3Rpb24gaXMgbm93IHRpdGxlZCwg RGVmaW5pdGlvbnMgYW5kIEJhY2tncm91bmQsDQphbmQgbW9zdCBvZiB0aGUgZGV0YWlscyBkZXNj cmliaW5nIGNvbW1lbnRzIGZyb20gTGFycyBhbmQgVGltDQphcmUgbW92ZWQgdG8gYW4gQXBwZW5k aXggQS4NCg0KPiANCj4gQnR3LiBUaWFucmFuLCBpdCB3b3VsZCBiZSBuaWNlIGlmIHlvdSBjb3Vs ZCB1cGRhdGUgeW91ciBjb21tZW50cyBpbiB0aGUNCj4gc2hlcGhlcmQgd3JpdGUtdXAgYWNjb3Jk aW5nbHkgaWYgdGhleSBoYXZlIGJlZW4gYWRkcmVzc2VkIG9yIGFyZSBvYnNvbGV0ZS4NCj4gVGhh bmtzIQ0KW2FjbV0gDQpZZXMsIHBsZWFzZSBjb25zaWRlciBpbmNvcnBvcmF0aW5nIHNvbWUgb2Yg dGhlIGRldGFpbHMgZnJvbQ0KbXkgZS1tYWlsIGxhc3QgQXVndXN0LCB0aGFua3MhDQoNCj4gDQo+ IDMpIEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhbnkgbm9ybWF0aXZlIGxhbmd1YWdlIHJlcXVp cmUgaW4gdGhpcyBkb2MuIEFzDQo+IHlvdSBhcmUg4oCeanVzdOKAnCBzdGF0aW5nIHdoYXQgaGFz IGJlZW4gbm9ybWF0aXZlbHkgZGVmaW5lZCBpbiBvdGhlcg0KPiBkb2N1bWVudHMsIGl0IGlzIGFj dHVhbGx5IHByZWZlcnJlZCB0byBub3QgcmUtc3RhdGUgbm9ybWF0aXZlbHkuDQpbYWNtXSANClRo ZSBTY29wZSBzYXlzOiANCglUaGUgc2NvcGUgb2YgdGhpcyBtZW1vIGlzIHRvIHJlLWFsbG9jYXRl IHdlbGwta25vd24gcG9ydHMgZm9yIHRoZSBVRFAgDQoJVGVzdCBwcm90b2NvbHMgdGhhdCBjb21w b3NlIG5lY2Vzc2FyeSBwYXJ0cyBvZiB0aGVpciByZXNwZWN0aXZlIA0KCXN0YW5kYXJkcyB0cmFj ayBwcm90b2NvbHMsIE9XQU1QIGFuZCBUV0FNUCwgYWxvbmcgd2l0aCBjbGFyaWZpY2F0aW9ucyAN CglvZiB0aGUgY29tcGxldGUgcHJvdG9jb2wgY29tcG9zaXRpb24gZm9yIHRoZSBpbmR1c3RyeS4N Cg0KVGhlIGNvbnRyb3ZlcnN5IGFib3V0IFRXQU1QIGNvbXBvc2l0aW9uIGlzIHBhcnRseSB3aGF0 IGJyb3VnaHQgdXMgaGVyZSENCldlIHVzZWQgdGhlIHRlcm0gUkVRVUlSRUQgaW4gdGhlIERlZmlu aXRpb25zIHRvIHJlc29sdmUgdGhlIHNtYWxsIGFtYmlndWl0eQ0KY3JlYXRlZCB3aGVuIE9XQU1Q IGF1dGhvcnMgZGlkIG5vdCB1c2Ugbm9ybWF0aXZlIGxhbmd1YWdlIHdoZW4gZGVzY3JpYmluZw0K dGhlIHByb3RvY29scyB0aGF0IGNvbXByaXNlIE9XQU1QLCBhbmQgVFdBTVAgYXV0aG9ycyBmb2xs b3dlZCB0aGF0IGNob2ljZSBvZg0Kd29yZGluZyAodW5mb3J0dW5hdGVseSkuDQogIA0KPiANCj4g NCkgQW4gdXBkYXRlIGluIHRoZSByZWdpc3RyeSBkb2VzIG5vdCBuZWNlc3NhcnkgbWVhbiBhbiDi gJ51cGRhdGXigJwgb2YgdGhlDQo+IFJGQ3MgdGhhdCByZWdpc3RlcmVkIHRoYXQgcG9ydHMgaW4g dGhlIGZpcnN0IHBsYWNlLCBlc3BlY2lhbGx5IGFzIHJmYzQ2NTYNCj4gZG9lc27igJl0IGV2ZW4g bWVudGlvbiB0aGUgVURQIHBvcnQgYXQgYWxsLiBPZiBjb3Vyc2UgdGhlIHVzZSBvZiDigJ51cGRh dGXigJwgaXMNCj4gdmVyeSBsb29zZWx5IGRlZmluZWQgYW5kIGNhbiBiZSB1c2VkIGlmIHRoYXQg aXMgcHJlZmVycmVkIGJ1dCBpdCBpcyBub3QNCj4gc3RyaWN0bHkgbmVjZXNzYXJ5LiBPciBpcyB0 aGVyZSBhbm90aGVyIHJlYXNvbiB0byB1cGRhdGUgdGhlc2UgUkZDcz8gSWYNCj4gc28sIGl0IHNo b3VsZCBiZSBjbGVhcmx5IHNwZWxsZWQgb3V0IGluIHRoZSBkcmFmdC4NClthY21dIA0KT2ssIGRy YXdpbmcgb24gdGhlIHBvaW50IGZyb20gdGhlIFNjb3BlLCBhbmQgcmVxdWlyZW1lbnQgTGFuZ3Vh Z2UgYWJvdmUsDQp0aGUgQWJzdHJhY3Qgbm93IGVuZHMgd2l0aDoNCg0KVGhlIG1lbW8gdXBkYXRl cyBSRkMgNDY1NiBhbmQgUkZDIDUzNTcsIGluIHRlcm1zIG9mIHRoZSBVRFAgd2VsbC1rbm93biBw b3J0IA0KYXNzaWdubWVudHMsIGFuZCBjbGFyaWZpZXMgdGhlIGNvbXBsZXRlIE9XQU1QIGFuZCBU V0FNUCBwcm90b2NvbCBjb21wb3NpdGlvbiANCmZvciB0aGUgaW5kdXN0cnkuDQoNCj4gDQo+IDUp IEdpdmVuIHRoYXQgdGhlc2UgZW50cmllcyBhcmUgdXBkYXRlcyBpdCB3b3VsZCBiZSBuaWNlIHRv IGFsc28gZmlsbCB0aGUNCj4gbWlzc2luZyBpbmZvcm1hdGlvbiBhYm91dCBjb250YWN0IGluZm9y bWF0aW9uIGFuZCBhc3NpZ25lZSBpbiB0aGUNCj4gcmVnaXN0cnkuIEluc3RydWN0aW9uIGZvciBJ QU5BIHdvdWxkIG5lZWQgdG8gYmUgYWRkZWQgdG8gdGhlIElBTkEgc2VjdGlvbg0KPiBpbiB0aGlz IGNhc2UuIEFzc2lnbmVlIHNob3VsZCBiZSB0aGUgSUVTRyBhbmQgY29udGFjdCB0aGUgSUVURiBj aGFpci4gSQ0KPiBhc3N1bWUgdGhlIG1vZGlmaWNhdGlvbiBkYXRlIHdpbGwgYmUgZmlsbGVkIGJ5 IElBTkEgcmVzcGVjdGl2ZWx5Lg0KW2FjbV0gDQpvaw0KDQo+IA0KPiBUaGFua3MhDQo+IE1pcmph DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IGlwcG0gbWFpbGluZyBsaXN0DQo+IGlwcG1AaWV0Zi5vcmcN Cj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAz QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faXBwbSZkPUR3SUdhUSZjPUxGWVotDQo+ IG85X0hVTWVNVFNRaWN2aklnJnI9T2ZzU3U4a1RJbHRWeUQxb0w3MmNCdyZtPWZjelJ2WWNmRmN1 d2Z0QUxQbDNpZGR4QnFyT0NwDQo+IFVUTGEycWZQc2hQbVJZJnM9RC1ENDJQdTNERnI3VEFJYjRy YXM4N3QyY054eUR0NFVVUnRGR2tQWkRPbyZlPQ0K From nobody Sun Nov 4 15:10:39 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97311130E01 for ; Sun, 4 Nov 2018 15:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 kstHyJj4Mbmr for ; Sun, 4 Nov 2018 15:10:35 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF5F1293FB for ; Sun, 4 Nov 2018 15:10:35 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wA4M5cLM013345 for ; Sun, 4 Nov 2018 17:14:30 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0048589.ppops.net-00191d01. with ESMTP id 2nhvbmrr49-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 04 Nov 2018 17:14:29 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA4MES1d075288 for ; Sun, 4 Nov 2018 16:14:28 -0600 Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [135.46.181.157]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA4MELeb075156 for ; Sun, 4 Nov 2018 16:14:21 -0600 Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [127.0.0.1]) by zlp30496.vci.att.com (Service) with ESMTP id AEF75410EC21 for ; Sun, 4 Nov 2018 22:14:21 +0000 (GMT) Received: from tlpd252.dadc.sbc.com (unknown [135.31.184.157]) by zlp30496.vci.att.com (Service) with ESMTP id 92095410EC20 for ; Sun, 4 Nov 2018 22:14:21 +0000 (GMT) Received: from dadc.sbc.com (localhost [127.0.0.1]) by tlpd252.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA4MELw6016477 for ; Sun, 4 Nov 2018 16:14:21 -0600 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by tlpd252.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA4MEETd016364 for ; Sun, 4 Nov 2018 16:14:14 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-green.research.att.com (Postfix) with ESMTP id DEE3BE2388 for ; Sun, 4 Nov 2018 17:10:41 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Sun, 4 Nov 2018 17:13:25 -0500 From: "MORTON, ALFRED C (AL)" To: "ippm@ietf.org" Thread-Topic: New Liaison Statement, "LS/r on current status of the draft Recommendation ITU-T Q.3961 (reply to SG11-LS52)" Thread-Index: AQHUbV0uU2LFQCZScEWqaKtbTePPYaVAO4pg Date: Sun, 4 Nov 2018 22:13:24 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557D89BC@njmtexg5.research.att.com> References: <154058001764.8778.9430328426745323258.idtracker@ietfa.amsl.com> In-Reply-To: <154058001764.8778.9430328426745323258.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-04_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811040211 Archived-At: Subject: [ippm] FW: New Liaison Statement, "LS/r on current status of the draft Recommendation ITU-T Q.3961 (reply to SG11-LS52)" X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 04 Nov 2018 23:10:38 -0000 SVBQTSwNCg0KVGhlIExpYWlzb24gU3RhdGVtZW50IG9uIElQIHBlcmZvcm1hbmNlIG1lYXN1cmVt ZW50cyBmcm9tIG1hbnkgU0RPcw0KKGJ1dCBwcmltYXJpbHkgSVRVLVQgU0cgMTIgYW5kIEVUU0kg VEMgU1RRKSBpcyBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE2 MDIvDQoNCkknbGwgYmUgZGlzY3Vzc2luZyB0aGlzIExpYWlzb24gYW5kIElQUE0ncyBwb3NzaWJs ZQ0KcmVwbHkgZHVyaW5nIHRoZSBJUFBNIFNlc3Npb24gYXQgSUVURi0xMDMuDQoNCnJlZ2FyZHMs DQpBbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTGlhaXNvbiBTdGF0ZW1l bnQgTWFuYWdlbWVudCBUb29sIFttYWlsdG86bHNtdEBpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXks IE9jdG9iZXIgMjYsIDIwMTggMjo1NCBQTQ0KVG86IFRoZSBJRVRGIENoYWlyIDxjaGFpckBpZXRm Lm9yZz4NCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IFRoZSBJRVRGIENoYWlyIDxjaGFp ckBpZXRmLm9yZz47IGl0dS10LWxpYWlzb25AaWFiLm9yZzsgTU9SVE9OLCBBTEZSRUQgQyAoQUwp IDxhY21AcmVzZWFyY2guYXR0LmNvbT47IFNjb3R0IE1hbnNmaWVsZCA8U2NvdHQuTWFuc2ZpZWxk QEVyaWNzc29uLmNvbT4NClN1YmplY3Q6IE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIkxTL3Igb24g Y3VycmVudCBzdGF0dXMgb2YgdGhlIGRyYWZ0IFJlY29tbWVuZGF0aW9uIElUVS1UIFEuMzk2MSAo cmVwbHkgdG8gU0cxMS1MUzUyKSINCg0KVGl0bGU6IExTL3Igb24gY3VycmVudCBzdGF0dXMgb2Yg dGhlIGRyYWZ0IFJlY29tbWVuZGF0aW9uIElUVS1UIFEuMzk2MSAocmVwbHkgdG8gU0cxMS1MUzUy KQ0KU3VibWlzc2lvbiBEYXRlOiAyMDE4LTEwLTI2DQpVUkwgb2YgdGhlIElFVEYgV2ViIHBhZ2U6 IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0 YXRyYWNrZXIuaWV0Zi5vcmdfbGlhaXNvbl8xNjAyXyZkPUR3SURhUSZjPUxGWVotbzlfSFVNZU1U U1FpY3ZqSWcmcj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3Jm09VlgzR05Dc3BWeTI1RFowWnZtMGkw SGhyU0NOekpCT0hraE1ydmpxY3FsdyZzPUhDd1FWWDFvTmo2ekZkaU5RM2ZqMU9uYy1IVzFnQzda SU9PZHhxT3JCWWcmZT0NCg0KRnJvbTogQWwgTW9ydG9uIDxhY21vcnRvbkBhdHQuY29tPg0KVG86 IFRoZSBJRVRGIENoYWlyIDxjaGFpckBpZXRmLm9yZz4NCkNjOiBTY290dCBNYW5zZmllbGQgPFNj b3R0Lk1hbnNmaWVsZEBFcmljc3Nvbi5jb20+LFRoZSBJRVRGIENoYWlyIDxjaGFpckBpZXRmLm9y Zz4saXR1LXQtbGlhaXNvbkBpYWIub3JnLFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KUmVzcG9u c2UgQ29udGFjdHM6IEEuIEMuIE1vcnRvbiA8YWNtb3J0b25AYXR0LmNvbT4NClRlY2huaWNhbCBD b250YWN0czogDQpQdXJwb3NlOiBGb3IgaW5mb3JtYXRpb24NCg0KQm9keTogSVRVLVQgU3R1ZHkg R3JvdXAgMTIgdGhhbmtzIHlvdSBmb3IgeW91ciBsaWFpc29uLCBzaGFyaW5nIHlvdXIgcGxhbiB0 byBkaXNjdXNzIERyYWZ0IFEuMzk2MSwg4oCcVGVzdGluZyBtZXRob2RvbG9naWVzIG9mIEludGVy bmV0IHJlbGF0ZWQgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnRzIGluY2x1ZGluZyBlMmUgYml0IHJh dGUgd2l0aGluIHRoZSBmaXhlZCBhbmQgbW9iaWxlIG9wZXJhdG9y4oCZcyBuZXR3b3Jrc+KAnSwg ZHVyaW5nIGZ1dHVyZSB3b3Jrc2hvcHMgYW5kIEpvaW50IG1lZXRpbmdzLiBXZSBhcmUgYXdhcmUg dGhhdCB0ZXh0IHNpbWlsYXIgdG8gZHJhZnQgcmVxdWlyZW1lbnRzIGluIFEuMzk2MSB3YXMgY29t cGxldGVseSBkZWxldGVkIGZyb20gdGhlIGNvcnJlc3BvbmRpbmcgRVRTSSBJTlQgc3BlY2lmaWNh dGlvbiBhcyBhIHJlc3VsdCBvZiBleHRlbnNpdmUgY29tbWVudHMgZHVyaW5nIHRoZSBhcHByb3Zh bCBwcm9jZXNzLCBhbmQgdGhlcmUgYXJlIGFkZGl0aW9uYWwgY29tbWVudHMgcG9zdC1hcHByb3Zh bCB3aGljaCByZW1haW4gdW4tYWRkcmVzc2VkIGFuZCB1bnJlc29sdmVkIGFmdGVyIHNldmVyYWwg bW9udGhzLiBXZSBoYXZlIGJlZW4gbm90aWZpZWQgb2YgbmV3IGFuZCB1cmdlbnQgd29yayBpbiBF VFNJIFNUUSB0byByZXZpc2UgY2xhdXNlIDYgb2YgVFMgMTAzIDIyMi0xICh0aGUgcmVmZXJlbmNl IHJlcGxhY2luZyBhbG1vc3QgYWxsIHJlcXVpcmVtZW50cyBpbiB0aGUgRVRTSSBJTlQgc3BlY2lm aWNhdGlvbikuIFRoZSBjdXJyZW50IHRleHQgb2YgVFMgMTAzIDIyMi0xICgzLTIwMTgpIHNwZWNp ZmljYXRpb24gcmV0YWlucyBhIGNvbXBsZXRlbHkgbm9uLWNvbXBhdGlibGUgc2NvcGUgdG8gZHJh ZnQgUS4zOTYxLCBhbmQgc3VmZmVycyBmcm9tIHRoZSBzYW1lIHNob3J0Y29taW5ncyByYWlzZWQg aW4gdGhlIEVUU0kgSU5UIHJldmlldyBwcm9jZXNzLiBBcyBwYXJ0IG9mIHRoZSBIYXJtb25pemF0 aW9uIGVmZm9ydHMNCiAgZm9yIElQLW5ldHdvcmsgcGVyZm9ybWFuY2Ugc3BlY2lmaWNhdGlvbnMg YmV0d2VlbiBFVFNJIFNUUSBhbmQgUTE3LzEyLCB3ZSBoYXZlIHJldmlld2VkIHRoZSByZXZpc2Vk IHRleHQgb2YgY2xhdXNlIDYvMTAzIDIyMi0xLCBhbmQgZmluZCBpdCBzYXRpc2ZhY3RvcnkuIE91 ciBjb25jbHVzaW9uIG9uIHRoaXMgdG9waWMgaXMgdGhhdCB3ZSBhZ3JlZSBhbmQgc3VwcG9ydCB0 aGUgcmVxdWVzdCBvZiBFVFNJIFNUUSwgdG8gYXZvaWQgcmVmZXJlbmNpbmcgdGhlIChjdXJyZW50 KSB0ZXh0IG9mIFRTIDEwMyAyMjItMSAoMy0yMDE4KSB3aGlsZSB0aGlzIHdvcmsgaXMgaW4tcHJv Z3Jlc3MuIFRoZSB3b3JrIGlzIHByb2NlZWRpbmcgdG93YXJkIGEgcHJvbXB0IHJlc29sdXRpb24u DQoNClN0dWR5IEdyb3VwIDEy4oCZcyBwbGFuIGlzIHRvIHByZXBhcmUgcmVsZXZhbnQgbm9ybWF0 aXZlIHNwZWNpZmljYXRpb25zIGZvciBJUC1sYXllciBDYXBhY2l0eSBhbmQgRmxvdy1yZWxhdGVk IFBhcmFtZXRlcnMgKHRocm91Z2hwdXQpLCBhbmQgdGhhdCBTRyAxMSBtYWtlIHVzZSBvZiB0aGUg bmV3IHNwZWNpZmljYXRpb25zIHdoZW4gYXZhaWxhYmxlLCBhcyBjb21tdW5pY2F0ZWQgaW4gTWF5 IDIwMTguICBXZSBhcmUgcGxlYXNlZCBTRzEx4oCZcyByZWNlbnQgbGlhaXNvbiBkaWQgbm90IG9i amVjdCB0byB0aGlzIHBsYW4sIGFuZCB3ZSBob3BlIFNHMTEgd2lsbCBwYXJ0aWNpcGF0ZSBpbiBI YXJtb25pemF0aW9uIGVmZm9ydHMsIGFzIEVUU0kgU1RRIGhhcyBhZ3JlZWQuDQoNCkFzIHN0YXRl ZCBpbiB5b3VyIGxpYWlzb24sIElUVS1UIFNHMTEgZW52aXNhZ2VzIHRoYXQgYmVuY2htYXJraW5n IHRlc3RpbmcgaXMgb25lIG9mIHRoZSBjb21wb25lbnRzIG9mIGRyYWZ0IFJlY29tbWVuZGF0aW9u IElUVS1UIFEuMzk2MS4gU2luY2UgdGhlIHRlcm0g4oCcYmVuY2htYXJraW5n4oCdIGlzIG5vdCBk ZWZpbmVkIGluIHRoZSBsaWFpc29uLCBhbmQgaGFzIG1hbnkgdXNlcyB0aHJvdWdob3V0IHRoZSBp bmR1c3RyeSwgd2Ugd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHdoYXQgdGhpcyBmb3JtIG9mIGJl bmNobWFya2luZyBpcyBpbnRlbmRlZCBjb21wYXJlLiANCg0KV2UgYXJlIGFsc28gYXdhcmUgb2Yg YSBsaXN0IG9mIG1ldGhvZHMgdXNlZCBieSBSZWd1bGF0b3JzIHRvICpzdXJ2ZXkqIEludGVybmV0 IHBlcmZvcm1hbmNlLCBwdWJsaXNoZWQgYnkgdGhlIE9FQ0QgaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5vZWNkLm9yZ19pbnRlcm5ldF9zcGVl ZC0yRHRlc3RzLmh0bSZkPUR3SURhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNTdThr VElsdFZ5RDFvTDcyY0J3Jm09VlgzR05Dc3BWeTI1RFowWnZtMGkwSGhyU0NOekpCT0hraE1ydmpx Y3FsdyZzPS0wTy1sam1pdTg3QkQ2WGU3dFd0VEZ1all4VGtsVUlYemZtQXc4djB6ZTgmZT0gLiBT b21lIFJlZ3VsYXRvcnMgaGF2ZSBtYWRlIGRpc2NsYWltZXJzIGFib3V0IHRoZSBhY2N1cmFjeSBv ZiB0aGVpciBzdXJ2ZXkgcmVzdWx0cy4gRm9yIGV4YW1wbGU6DQoNCiAgICAgICAgVGhlIGxvY2F0 aW9ucyBhbmQgdGVjaG5pY2FsIGZlYXR1cmVzIG9mIHRoZSBicm9hZGJhbmQgY29ubmVjdGlvbnMg aGF2ZSBiZWVuIHByb3ZpZGVkIGJ5IHRoZSBzZXJ2aWNlIHVzZXJzIHRoZW1zZWx2ZXMsIHdobyBh cmUgZW50aXJlbHkgYW5kIGV4Y2x1c2l2ZWx5IGxpYWJsZSBmb3IgdGhlaXIgDQogICAgICAgIGFj Y3VyYWN5LiBUaGUgc3BlZWQgcmVzdWx0aW5nIGZyb20gdGhlIG1lYXN1cmVtZW50IGFzIHRoZSBm aW5hbCBzcGVlZCBvZiB0aGUgY29ubmVjdGlvbiBpcyBhbHNvIGFmZmVjdGVkIGJ5IGEgc2VyaWVz IG9mIGZhY3RvcnMsIHN1Y2ggYXMgdGhlIHF1YWxpdHkgb2YgY2FibGVzLCBjb25uZWN0aW9ucyAN CiAgICAgICAgYW5kIGVxdWlwbWVudCBvciBlbGVjdHJvbWFnbmV0aWMgaW50ZXJmZXJlbmNlLg0K DQpUaGlzIHdlbGwtZXhwcmVzc2VzIG91ciBjb25jZXJucyB3aXRoIHRoZSBtZXRob2RzIGRlc2Ny aWJlZCBpbiBjdXJyZW50IFNHIDExIGRyYWZ0IG9mIFEuMzk2MS4NCg0KQXQgdGhpcyB0aW1lLCB3 ZSB3b3VsZCBsaWtlIHRvIGluZm9ybSB5b3Ugb2Ygb3VyIHByb2dyZXNzIHRvIGRldmVsb3AgdGhl IGFmb3JlbWVudGlvbmVkIG5vcm1hdGl2ZSBzcGVjaWZpY2F0aW9ucyBpbiBTdHVkeSBHcm91cCAx MiwgZXNwZWNpYWxseSBvdXIgcHJvZ3Jlc3MgYXQgdGhlIE9jdG9iZXIgMjAxOCBRMTcgSW50ZXJp bSBtZWV0aW5nIGluIERhcm1zdGFkdC4NCg0K4oCiCUFUJlTigJlzIGNvbnRyaWJ1dGlvbiBkZXNj cmliaW5nIGhvdyBuZXR3b3JrIGFjY2VzcywgdXNhZ2UgcGF0dGVybnMsIHVzZXIgYXBwbGljYXRp b24gcmVxdWlyZW1lbnRzLCBhbmQgZnV0dXJlIG1lYXN1cmVtZW50IHBhdGhzIGhhdmUgY2hhbmdl ZCBpbiB0aGUgcGFzdCBmaXZlIHllYXJzIHNldCB0aGUgdG9uZSBmb3IgdGhlIG1lZXRpbmcuIFRo ZXJlIGFyZSBsaWtlbHkgdG8gYmUg4oCcR2lnYWJpdCBpc2xhbmRz4oCdIGF0IHRoZSBlZGdlIG9m IGZ1dHVyZSBuZXR3b3Jrcy4gDQrigKIJRVRTSSBUUjEwMzUwMSBoYXMgYmVlbiBwcmVzZW50ZWQg YW5kIGRpc2N1c3NlZC4gRXNzZW50aWFsIHBvaW50cyB3ZXJlIHRoZSByZXF1aXJlbWVudCBmb3Ig ZnVsbCB0cmFuc3BhcmVuY3kgb2YgdGhlIG1lYXN1cmVtZW50IGFuZCBkYXRhIHByb2Nlc3Npbmcg bWV0aG9kb2xvZ3kuIFRoZSBUUiBhdHRlbXB0cyB0byBwcm92aWRlIGEgZnVsbCB2aWV3IG9mIHRv ZGF54oCZcyBtZXRob2RzIGZvciBhcHBsaWNhdGlvbiBsZXZlbCBtZWFzdXJlbWVudCBpbmNsdWRp bmcgbXVsdGkgc29ja2V0IGFuZCBjcm93ZCBzb3VyY2luZyBhcHByb2FjaGVzLg0K4oCiCVkuMTU0 MCBJUCBjYXBhY2l0eSBhbmQgZmxvdyByZWxhdGVkIHBhcmFtZXRlciBjbGF1c2VzIHdlcmUgZWRp dGVkIGJ5IHRoZSBncm91cC4NCuKAoglZLjE1NDAgYW5uZXggQSB3YXMgZXhwYW5kZWQgdG8gaW5j bHVkZSB0d28gcGhhc2VzIG9mIHRlc3RpbmcuIFRoZSBmaXJzdCBwaGFzZSBpcyBhIHRlc3QgdXNp bmcgc2hhcGVyL3BvbGljZXIgY2FwYWJpbGl0aWVzIG9mIGEgZ2VuZXJhbCBwdXJwb3NlIGNvbXB1 dGluZyBzeXN0ZW0sIGJhc2VkIG9uIEFUJlTigJlzIGNvbnRyaWJ1dGlvbiBhbmQgcHJlbGltaW5h cnkgdGVzdCByZXN1bHRzLiBUaGlzIHBoYXNlIGlzIHBhcmFsbGVsIHRvIHRoZSBCRVJFQyBldmFs dWF0aW9uIG9mIEludGVybmV0IGFjY2VzcyBtZWFzdXJlbWVudHMsIGFuZCBhZGRpbmcgY3JpdGlj YWwgdGVzdCBwYXRoIHBhcmFtZXRlcnMuDQrigKIJWS4xNTQwIGFubmV4IEEgd2FzIGV4cGFuZGVk IHRvIGluY2x1ZGUgaW5mb3JtYXRpb24gb24gZXZhbHVhdGlvbiBvZiBkaWZmZXJlbnQgYWNjZXNz IHNwZWVkIG1lYXN1cmVtZW50IG1ldGhvZHMsIGNvbmR1Y3RlZCBpbiAyMDEyIGJ5IEdvZ2EgYW5k IFRlaXhlaXJhLiBUaGlzIHdvcmsgcGFyYWxsZWxzIG91ciBwbGFuIGZvciBwaGFzZSAyLg0K4oCi CVRoZXJlIGlzIGEgY2xlYXIgbmVlZCB0byBlbmxpc3QgYWN0aXZlIHBhcnRpY2lwYW50cyBpbiB0 aGUgdGVzdGluZyBwcm9ncmFtLCB3aG8gYXJlIHdpbGxpbmcgdG8gY29udHJpYnV0ZSBib3RoIHJl c291cmNlcyBhbmQgcGVyc29ubmVsIGNvbnNpc3RlbnQgd2l0aCB0aGUgcGxhbnMgdW5kZXIgZGV2 ZWxvcG1lbnQuIFRob3NlIHdobyBjaG9vc2Ugbm90IHRvIHBhcnRpY2lwYXRlIHdpbGwgaGF2ZSBu byBpbmZsdWVuY2Ugb24gdGhlIG91dGNvbWUsIG9yIHRoZSBzY2hlZHVsZSBmb3IgY29tcGxldGlv biwgc28gdGhleSBhcmUgZW5jb3VyYWdlZCB0byBwYXJ0aWNpcGF0ZSBvciB3YWl0IHBhdGllbnRs eS4gIA0K4oCiCUEgbGlzdCBvZiByZWd1bGF0b3IgSW50ZXJuZXQgYWNjZXNzIHN1cnZleSBtZXRo b2RzIHdhcyBjb21waWxlZCBieSBBVCZUIGFuZCBkaXNjdXNzZWQgZHVyaW5nIHRoZSBtZWV0aW5n LiBUaGlzIGxpc3QgaXMgbW9yZSB1cCB0byBkYXRlIHRoYW4gdGhlIDIwMTUgT0VDRCBsaXN0LCBh bmQgY29uY2x1ZGVzIHRoYXQgdGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50IG1ldGhvZHMgY3VycmVu dGx5IGluIHVzZSwgYW5kIG5vIEludGVybmF0aW9uYWwgY29uc2Vuc3VzIGNhbiBiZSBkZXJpdmVk IHRvIHN1cHBvcnQgc3RhbmRhcmQgZGV2ZWxvcG1lbnQgZnJvbSByZWFkaW5nIHN1Y2ggbGlzdHMu DQrigKIJQVQmVCBjb250cmlidXRlZCBhIGNvbXBhcmlzb24gb2YgdHdvIG1ldGhvZHMgb2YgTFRF IEludGVybmV0IGFjY2VzcyBzcGVlZCBhc3Nlc3NtZW50LiBUaGUgcmVzdWx0cyBzaG93IHdpZGUg dmFyaWF0aW9uIGFuZCBzdHJvbmcgZGVwZW5kZW5jZSBvbiBtb2JpbGUgZGV2aWNlIHR5cGUuIExh cmdlciBzYW1wbGUgc2l6ZXMgYXJlIG5lZWRlZCB0byBhY2hpZXZlIHRoZSBjb21wYXJpc29uIGdv YWxzLg0K4oCiCVExNyByZXZpZXdlZCB0aGUgRVRTSS1TVFHigJlzIHJldmlzZWQgY2xhdXNlIDYg b2YgVFMtMTAzIDIyMi0xLCBmcm9tIHRoZSByYXBwb3J0ZXVyIG9mIHRoaXMgbmV3IHdvcmsgaXRl bS4gVGhlIHRleHQgd2FzIGZvdW5kIHRvIGJlIGFncmVlYWJsZSwgd2l0aCB0aGUgc3VnZ2VzdGlv biB0byB1cGRhdGUgdGhlIGludHJvZHVjdGlvbiB0byBpbmRpY2F0ZSB0aGVzZSBjaGFuZ2VzLg0K DQpTdHVkeSBHcm91cCAxMiBoYXMgcHJvdmlkZWQgYSBkZXRhaWxlZCBleHBsYW5hdGlvbiBvZiB0 aGUgY2xhdXNlIDYuMTIgcmVxdWlyZW1lbnRzIGluIEFwcGVuZGl4IElYIG9mIFJlYy4gWS4xNTQw LCB0aXRsZWQg4oCcRXhwbGFuYXRpb24gb2YgVENQLWJhc2VkIG1lYXN1cmVtZW50IGluYWRlcXVh Y3kgdG8gbWVldCBub3JtYXRpdmUgcmVxdWlyZW1lbnRz4oCdLiAgSG93ZXZlciwgd2UgaGF2ZSBj b25jbHVkZWQgdGhhdCBDYXBhY2l0eSBtZWFzdXJlbWVudHMgZGVzY3JpYmVkIGluIFJGQyA4MzM3 IG1lZXQgdGhlIHJlcXVpcmVtZW50cyBpbiBjbGF1c2UgNi4xMiBvZiBJVFUtVCBSZWNvbW1lbmRh dGlvbiBZLjE1NDAuIA0KDQpXZSBpbnZpdGUgYWxsIGV4cGVydHMgdG8gcGFydGljaXBhdGUgaW4g dGhlIGV2YWx1YXRpb24gcGxhbuKAmXMgZGV2ZWxvcG1lbnQgYW5kIHRvIHN1YnNlcXVlbnRseSBw YXJ0aWNpcGF0ZSBpbiB0aGUgZXZhbHVhdGlvbnMuIFNHIDEx4oCZcyBwbGFucyB0byBkZXZlbG9w IHRoZSB0ZXh0IG9mIHRoZSBkcmFmdCBRLjM5NjEgc2hvdWxkIG5vdyBtb3ZlIGZvcndhcmQgYWZ0 ZXIgdGhlIGV2YWx1YXRpb24gYW5kIGFwcHJvdmFsIG9mIFN0dWR5IEdyb3VwIDEy4oCZcyBub3Jt YXRpdmUgc3BlY2lmaWNhdGlvbnMgYXJlIGNvbXBsZXRlLCBhY2NvcmRpbmcgdG8gdGhlIGNvbnRy aWJ1dGlvbi1kcml2ZW4gc2NoZWR1bGUuICBDZXJ0YWlubHksIFNHIDExIGV4cGVydHMgd2lsbCBi ZSB3aWxsaW5nIHRvIGNvbnRyaWJ1dGUgdGhlaXIgZXhwZXJ0aXNlIGFuZCByZXNvdXJjZXMgdG8g dGhpcyBwbGFuLCBjb25zaXN0ZW50IHdpdGggdGhlaXIgZGVzaXJlIHRvIGNvbXBsZXRlIHdvcmsg b24gdGhpcyB0b3BpYyBhcyBxdWlja2x5IGFzIHBvc3NpYmxlLg0KDQpUaGUgY3VycmVudCBkcmFm dCBvZiByZXZpc2lvbnMgdG8gWS4xNTQwLCBhbmQgYSBuZXcgQW5uZXggQSBmb3IgdGhlIG5ldyBw YXJhbWV0ZXIgZGVmaW5pdGlvbnMgbm93IGNvbnRhaW5zIHRoZSBjdXJyZW50IHRleHQgb2YgdGhl IGV2YWx1YXRpb24gcGxhbiBmb3IgY2FuZGlkYXRlIGRlZmluaXRpb25zIGZvciB0aGUgbmV3IG5v cm1hdGl2ZSBwYXJhbWV0ZXJzIGZvciBJUC1sYXllciBDYXBhY2l0eSBhbmQgRmxvdy1yZWxhdGVk IFBhcmFtZXRlcnMgKHRocm91Z2hwdXQpLiBBbm5leCBBIGNvbnRhaW5zIHRoZSBsYXRlc3QgdmVy c2lvbiBvZiB0aGUgZXZhbHVhdGlvbiBwbGFuLCB3aXRoIGtleSByZWZlcmVuY2VzIHRvIGV4aXN0 aW5nIGNvbXBhcmlzb25zIG9mIG1ldGhvZHMuDQoNClN0dWR5IEdyb3VwIDEyIHdvdWxkIGxpa2Ug dG8gaW52aXRlIFN0dWR5IEdyb3VwIDExIHRvIHNjaGVkdWxlIGNvLWxvY2F0ZWQgbWVldGluZ3Mg aW4gR2VuZXZhLCBOb3ZlbWJlciAyMDE4LCBhbmQgdG8gcGFydGljaXBhdGUgaW4gdGhlIFNHMTIg d29ya3Nob3AgYWRqYWNlbnQgdG8gdGhlIG1lZXRpbmcgZGF0ZXMsIG9uIE5vdmVtYmVyIDI2LCAy MDE4LiBXZSB3b3VsZCBsaWtlIHRvIHVzZSB0aGUgd29ya3Nob3AgdG8gc2hhcmUgb3VyIGV4cGVy aWVuY2UsIHRvIG1ha2UgdGhlIHdvcmsgb2Ygb3ZlcnNlZWluZyBJVFUtVCBTRyAxMuKAmXMgbWFu ZGF0ZSBhbmQgb3VyIGNvb3JkaW5hdGlvbiByb2xlcyBtb3JlIGVmZmljaWVudCBhbmQgZWZmZWN0 aXZlLiANCg0KQXR0YWNobWVudHM6DQpURDYxOS0gQ3VycmVudCB0ZXh0IG9mIEFubmV4IEEgYW5k IFkuMTU0MCBjbGF1c2VzLg0KDQpVUkwgdG8gdGhlIFdvcmtzaG9wOiANCmh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lml0dS5pbnRfZW5fSVRV LTJEVF9Xb3Jrc2hvcHMtMkRhbmQtMkRTZW1pbmFyc19xb3NfMjAxODExX1BhZ2VzX2RlZmF1bHQu YXNweCZkPUR3SURhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNTdThrVElsdFZ5RDFv TDcyY0J3Jm09VlgzR05Dc3BWeTI1RFowWnZtMGkwSGhyU0NOekpCT0hraE1ydmpxY3FsdyZzPVND LVlITkVFSVVkQ1c0YTduVzNIWjl3NklSSmRoMmx6Snk5Vzc2REpmcG8mZT0NCkF0dGFjaG1lbnRz Og0KDQogICAgb0xTNTlhdHQNCiAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19saWJfZHRfZG9jdW1lbnRzX0xJQUlTT05f bGlhaXNvbi0yRDIwMTgtMkQxMC0yRDI2LTJEaXR1LTJEdC0yRHNnLTJEMTItMkRpZXRmLTJEbHNy LTJEb24tMkRjdXJyZW50LTJEc3RhdHVzLTJEb2YtMkR0aGUtMkRkcmFmdC0yRHJlY29tbWVuZGF0 aW9uLTJEaXR1LTJEdC0yRHEzOTYxLTJEcmVwbHktMkR0by0yRHNnMTEtMkRsczUyLTJEYXR0YWNo bWVudC0yRDEuZG9jeCZkPUR3SURhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNTdThr VElsdFZ5RDFvTDcyY0J3Jm09VlgzR05Dc3BWeTI1RFowWnZtMGkwSGhyU0NOekpCT0hraE1ydmpx Y3FsdyZzPUVFQ2Y2clZ1VkpVVC12dWE3RlNYU05YY2J3enEySjlYRTJCU0d6WmxGek0mZT0NCg0K From nobody Sun Nov 4 18:30:07 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E01128CF2; Sun, 4 Nov 2018 18:30:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <154138500463.31952.15529407397997714685@ietfa.amsl.com> Date: Sun, 04 Nov 2018 18:30:04 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-port-twamp-test-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 02:30:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : OWAMP and TWAMP Well-Known Port Assignments Authors : Al Morton Greg Mirsky Filename : draft-ietf-ippm-port-twamp-test-03.txt Pages : 9 Date : 2018-11-04 Abstract: This memo explains the motivation and describes the re-assignment of well-known ports for the OWAMP and TWAMP protocols for control and measurement, and clarifies the meaning and composition of these standards track protocol names for the industry. The memo updates RFC 4656 and RFC 5357, in terms of the UDP well- known port assignments, and clarifies the complete OWAMP and TWAMP protocol composition for the industry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-port-twamp-test/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-port-twamp-test-03 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-port-twamp-test-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-port-twamp-test-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 5 01:09:52 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF81130DC2; Mon, 5 Nov 2018 01:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 VxhrhG_F_aZP; Mon, 5 Nov 2018 01:09:47 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 7E43612D4EB; Mon, 5 Nov 2018 01:09:47 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1E0ECF42DF3BC; Mon, 5 Nov 2018 09:09:44 +0000 (GMT) Received: from lhreml507-mbb.china.huawei.com ([10.201.109.48]) by LHREML712-CAH.china.huawei.com ([10.201.108.35]) with mapi id 14.03.0415.000; Mon, 5 Nov 2018 09:09:44 +0000 From: Giuseppe Fioccola To: "tpauly@apple.com" , "ippm@ietf.org" , "draft-fioccola-ippm-multipoint-alt-mark@ietf.org" Thread-Topic: [ippm] Adoption call for draft-fioccola-ippm-multipoint-alt-mark Thread-Index: AQHUZFiX/eIwJznPbUiOHmmXWfA2d6U9L/oAgAPUitA= Date: Mon, 5 Nov 2018 09:09:43 +0000 Message-ID: References: <43C2B245-408B-4043-A78F-A4295DAFFC6A@cisco.com> <83BF63ED-EE91-4359-8F6B-94095D5D4E74@apple.com> In-Reply-To: <83BF63ED-EE91-4359-8F6B-94095D5D4E74@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.204.62.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] Adoption call for draft-fioccola-ippm-multipoint-alt-mark X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 09:09:50 -0000 SGkgVG9tbXksDQpUaGFuayB5b3UhDQpJIGhhdmUganVzdCBzdWJtaXR0ZWQgdGhlIC1pZXRmIHZl cnNpb24gKC0wMCkgb2YgdGhlIGRvY3VtZW50Lg0KSW4gYWRkaXRpb24sIEkgdG9vayB0aGUgb3Bw b3J0dW5pdHkgdG8gdXBkYXRlIG15IGNvbnRhY3QgaW5mb3JtYXRpb24uDQoNCkJlc3QgUmVnYXJk cywNCg0KR2l1c2VwcGUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRwYXVs eUBhcHBsZS5jb20gW21haWx0bzp0cGF1bHlAYXBwbGUuY29tXSANClNlbnQ6IEZyaWRheSwgMiBO b3ZlbWJlciAyMDE4IDIzOjM1DQpUbzogaXBwbUBpZXRmLm9yZzsgZHJhZnQtZmlvY2NvbGEtaXBw bS1tdWx0aXBvaW50LWFsdC1tYXJrQGlldGYub3JnDQpDYzogR2l1c2VwcGUgRmlvY2NvbGEgPGdp dXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5jb20+DQpTdWJqZWN0OiBSZTogW2lwcG1dIEFkb3B0aW9u IGNhbGwgZm9yIGRyYWZ0LWZpb2Njb2xhLWlwcG0tbXVsdGlwb2ludC1hbHQtbWFyaw0KDQpJJ3Zl IG1hcmtlZCBkcmFmdC1maW9jY29sYS1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmsgYXMgQWRvcHRl ZC4gVGhhbmtzIHRvIGV2ZXJ5b25lIHdobyBzZW50IHRoZWlyIGlucHV0IQ0KDQpBdXRob3JzLCBw bGVhc2Ugc3VibWl0IGEgLWlldGYgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgd2hlbiByZWFkeS4N Cg0KQmVzdCwNClRvbW15DQoNCj4gDQo+ICAgIC0tLS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0t DQo+ICAgIERhOiB0cGF1bHlAYXBwbGUuY29tIFttYWlsdG86dHBhdWx5QGFwcGxlLmNvbV0gDQo+ ICAgIEludmlhdG86IG1hcnRlZMOsIDkgb3R0b2JyZSAyMDE4IDAxOjAzDQo+ICAgIEE6IGlwcG1A aWV0Zi5vcmcNCj4gICAgQ2M6IGRyYWZ0LWZpb2Njb2xhLWlwcG0tbXVsdGlwb2ludC1hbHQtbWFy a0BpZXRmLm9yZw0KPiAgICBPZ2dldHRvOiBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1maW9jY29s YS1pcHBtLW11bHRpcG9pbnQtYWx0LW1hcmsNCj4gDQo+ICAgIEhlbGxvIElQUE0sDQo+IA0KPiAg ICBJbiBNb250cmVhbCB3ZSBkZWNpZGVkIHRvIGNhbGwgZm9yIHdvcmtpbmcgZ3JvdXAgYWRvcHRp b24gb2YgZHJhZnQtZmlvY2NvbGEtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrIHByaW9yIHRvIG91 ciBJRVRGIDEwMyBtZWV0aW5nLg0KPiANCj4gICAgVGhpcyBlbWFpbCBiZWdpbnMgdGhlIGNhbGwt Zm9yLWFkb3B0aW9uIHBlcmlvZCwgd2hpY2ggd2lsbCBlbmQgYXQgdGhlIHN0YXJ0IG9mIHRoZSBJ RVRGIDEwMyBtZWV0aW5nIChOb3ZlbWJlciA1LCAyMDE4KSwgdG8gYXZvaWQgZ2V0dGluZyB0b28g Y2xvc2UgdG8gdGhlIGRyYWZ0IHN1Ym1pc3Npb24gZGVhZGxpbmUuIFBsZWFzZSByZXBseSB0byB0 aGlzIGVtYWlsIGlmIHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9yIGhhdmUgYW55IG9iamVjdGlvbnMg dG8gdGhlIFdHIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiAgICBUaGUgY3VycmVudCBz dGF0dXMgYW5kIHRleHQgb2YgdGhlIGRvY3VtZW50IGNhbiBiZSBmb3VuZCBoZXJlOg0KPiANCj4g ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlvY2NvbGEtaXBwbS1t dWx0aXBvaW50LWFsdC1tYXJrLw0KPiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZmlvY2NvbGEtaXBwbS1tdWx0aXBvaW50LWFsdC1tYXJrLTA0DQo+ICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2lkL2RyYWZ0LWZpb2Njb2xhLWlwcG0tbXVsdGlwb2ludC1hbHQtbWFyay0wNC50 eHQNCj4gDQo+ICAgIEJlc3QsDQo+ICAgIFRvbW15IChhcyBJUFBNIGNvLWNoYWlyKQ0KPiANCj4g DQo+IA0KPiAgICBRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJp enphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25l LCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2Vu emEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVh bG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBj b3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBt aXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXppZS4gDQo+ IA0KPiAgICBUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBh bmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFk ZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2Ug YnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2ht ZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLiANCj4g DQo+ICAgIFJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBu b24gw6ggbmVjZXNzYXJpby4NCj4gDQo+ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ICAgIGlwcG0gbWFpbGluZyBsaXN0DQo+ICAgIGlwcG1AaWV0 Zi5vcmcNCj4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQo+ ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAg IGlwcG0gbWFpbGluZyBsaXN0DQo+ICAgIGlwcG1AaWV0Zi5vcmcNCj4gICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQo+IA0KPiANCg0K From nobody Mon Nov 5 01:26:12 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CA612F1AC; Mon, 5 Nov 2018 01:26:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <154140996497.9218.151035607737104897@ietfa.amsl.com> Date: Mon, 05 Nov 2018 01:26:04 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-multipoint-alt-mark-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 09:26:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Multipoint Alternate Marking method for passive and hybrid performance monitoring Authors : Giuseppe Fioccola Mauro Cociglio Amedeo Sapio Riccardo Sisto Filename : draft-ietf-ippm-multipoint-alt-mark-00.txt Pages : 20 Date : 2018-11-05 Abstract: The Alternate Marking method, as presented in RFC 8321 [RFC8321], can be applied only to point-to-point flows because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document aims to generalize and expand this methodology to measure any kind of unicast flows, whose packets can follow several different paths in the network, in wider terms a multipoint-to-multipoint network. For this reason the technique here described is called Multipoint Alternate Marking. Some definitions here introduced extend the scope of RFC 5644 [RFC5644] in the context of alternate marking schema. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-multipoint-alt-mark/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-multipoint-alt-mark-00 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-multipoint-alt-mark-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 5 17:58:35 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED66C130F72 for ; Mon, 5 Nov 2018 17:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 3UgOR-6N8fgY for ; Mon, 5 Nov 2018 17:58:24 -0800 (PST) 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 304CA130F61 for ; Mon, 5 Nov 2018 17:58:19 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wA61thoH040854 for ; Mon, 5 Nov 2018 20:58:18 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049459.ppops.net-00191d01. with ESMTP id 2nk1gp0c90-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 05 Nov 2018 20:58:17 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA61wHh5009601 for ; Mon, 5 Nov 2018 19:58:17 -0600 Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [135.46.181.158]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA61wDuK009478 for ; Mon, 5 Nov 2018 19:58:13 -0600 Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [127.0.0.1]) by zlp30495.vci.att.com (Service) with ESMTP id 42B9340D3C41 for ; Tue, 6 Nov 2018 01:58:13 +0000 (GMT) Received: from tlpd252.dadc.sbc.com (unknown [135.31.184.157]) by zlp30495.vci.att.com (Service) with ESMTP id 32B1D40D3C40 for ; Tue, 6 Nov 2018 01:58:13 +0000 (GMT) Received: from dadc.sbc.com (localhost [127.0.0.1]) by tlpd252.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA61wD5e101364 for ; Mon, 5 Nov 2018 19:58:13 -0600 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by tlpd252.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA61w8ii101254 for ; Mon, 5 Nov 2018 19:58:08 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-blue.research.att.com (Postfix) with ESMTP id 2F1D9F1CA6 for ; Mon, 5 Nov 2018 20:58:08 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Mon, 5 Nov 2018 20:57:19 -0500 From: "MORTON, ALFRED C (AL)" To: "ippm@ietf.org" Thread-Topic: Comment on draft-kumar-ippm-ifa-00 Thread-Index: AdR1c4O5PmvUdZTcSliKG4UOj7Rzcw== Date: Tue, 6 Nov 2018 01:57:19 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557DA250@njmtexg5.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.148.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=615 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811060013 Archived-At: Subject: [ippm] Comment on draft-kumar-ippm-ifa-00 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 01:58:33 -0000 IFA Authors, IPPM, I read p/o https://tools.ietf.org/html/draft-kumar-ippm-ifa-00 As someone working on the Route Metrics draft, this point=20 interested me: 2.2 Operational Requirements IFA MUST preserve the flow path across the network. This is a useful and interesting requirement. Care to say more (or point me to a section of the=20 draft) where you say how this will be accomplished? thanks, Al From nobody Mon Nov 5 21:11:20 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A0E130F6D for ; Mon, 5 Nov 2018 21:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 GPxxNy9rWpZx for ; Mon, 5 Nov 2018 21:11:16 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 9D8AF130E9E for ; Mon, 5 Nov 2018 21:11:14 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id w22-v6so2261014plk.0 for ; Mon, 05 Nov 2018 21:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=pKODa5eTNEpDXBuJMwuy08XPcdgQPPKPa2RWK5btQSE=; b=eBRsa2yYgRO10FcPbMvT0i8YjLoMP2fXsGkY9wb1h/Y9Sux7H5qAFbThETYioWP+Wb 5OS3iuXAU3oZz/7zbdRG6/2LFHS9LGAUuIKeA4UO0CbtGHkYV1Jc/HGhNxwVRuKirYZL FHxQ1oAV2lzg3pidSrPahebUfppEckKgMiaUY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=pKODa5eTNEpDXBuJMwuy08XPcdgQPPKPa2RWK5btQSE=; b=fcVVDbUYSQrjZqLp2So6LNJ9awcT/MIqYvPPo43S6zhJ3JhqHvTe9IhaVBIkldUKUw It0w5lPYPUgmRaCgg9K7vj5wpU/+3YuutEVWwrT8f05vVMYIhVmKvCZ4Te/5H7SFMUt+ 44t5Wgr+rEWQDWDgJHloUGo85eAqm+qmrLWXTcYwi6h4r7Vb+NPAqEYia8o0nIrjl2I+ 2jRz9rs7wbDBZJGGjiCF57vqXCq1EJCZHryBXaj7QV73UDRrSQ+36WFI+7Am1hnX91aS vN5whQJ1fR+aH2t+3x9wiUiQWB+XnEg+swc03/AHg2lHI9S1hoaWbu76LeX8MQKMey8W skEA== X-Gm-Message-State: AGRZ1gKWDijFxTIsVkSOdWPYZgbHTJFYV33V1xIXPVzGXNPW/j6VUxDH dOLWtr1OWihFJ7MdSfGBL2Uc5G2Oask= X-Google-Smtp-Source: AJdET5fKSdB3yyfupYnGkERSAACdJaRT9SrfCgg/btUPy84n1Gup7WGirJ1UiXoQHQaWAFIA+xhpQw== X-Received: by 2002:a17:902:30f:: with SMTP id 15-v6mr24962027pld.155.1541481074125; Mon, 05 Nov 2018 21:11:14 -0800 (PST) Received: from [172.20.28.201] (110-170-235-6.static.asianet.co.th. [110.170.235.6]) by smtp.gmail.com with ESMTPSA id g27-v6sm14335642pfj.162.2018.11.05.21.11.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 21:11:13 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.11.0.180909 Date: Tue, 06 Nov 2018 12:11:06 +0700 From: Jai Kumar To: "MORTON, ALFRED C (AL)" , "ippm@ietf.org" Message-ID: <69225916-34D4-4CB1-A5AA-31F39D729B91@broadcom.com> Thread-Topic: [ippm] Comment on draft-kumar-ippm-ifa-00 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [ippm] Comment on draft-kumar-ippm-ifa-00 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 05:11:19 -0000 Hi Al, Thanks for reviewing the draft. Idea is to preserve the L3 and L4 fields which are typically looked in the = data plane for load balancing. This essentially means following - Do not tunnel IPv4 packets as load balancing will start using the tunnel = header fields - Preserve the L4 information and making sure its within a reachable distan= ce(parse depth of silicon) for the data plane - e.g. inserting metadata on top of L4 header will push the L4 header too = deep for data plane to access - this will also be indeterministic behavior depending the length of metad= ata stack in the ingress packet on a hop in the network path Regards, -Jai =EF=BB=BFOn 11/6/18, 8:58 AM, "ippm on behalf of MORTON, ALFRED C (AL)" wrote: IFA Authors, IPPM, =20 I read p/o https://tools.ietf.org/html/draft-kumar-ippm-ifa-00 =20 As someone working on the Route Metrics draft, this point=20 interested me: =20 2.2 Operational Requirements =20 IFA MUST preserve the flow path across the network. =20 This is a useful and interesting requirement. Care to say more (or point me to a section of the=20 draft) where you say how this will be accomplished? =20 thanks, Al =20 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm =20 From nobody Mon Nov 5 22:05:38 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BCD130E39; Mon, 5 Nov 2018 22:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A8uS5-aeVYX; Mon, 5 Nov 2018 22:05:27 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 078FA130E25; Mon, 5 Nov 2018 22:05:24 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id k19-v6so10294906lji.11; Mon, 05 Nov 2018 22:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/4n/WeEBaQIP6b57g75A+50fRgesYVDRP+FtUiV+oko=; b=VJokdis2VKMKuULP+h78obxvFGzS5RFR+Mm4vrcLeaLPThFx7q+bS2imvfhPTPb5zD EoHspTEXR+h6uWhgP6j1pYMN56f9awxo+Qf6ZHMuxHFHJEV35W2ABRsPUO63zbrIE/SN YG9yUBkqgotEgm3jkGUbsIT4zFmlOyEaL/Vz92TJHQYYVex4RPWnnnjnswesEv7Vg4QS 3UxAW6foS3+i1mN1jTJAMJlKRwMbHxfNoRZiqeq8LGGYskcsYPDpHxtW7XMCFRgxdpwM FTlVWneU04mS+QXpcyhSIegYkCyNPPQvbvTpPPEbwGaAfxQLnQDnkr6CDqGOzUBqdAQR hjCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/4n/WeEBaQIP6b57g75A+50fRgesYVDRP+FtUiV+oko=; b=dc93XQQqnVVM8JvJSXRFMnwjrnX1BB6jZ9sx/qvau4ngLZe6jvDIpCjE1HxvWu8XFq asHCTYyhY7RCDdCepXKIiPZr+dP3VFCHAuj79Yq+eEZRYr6PcxV/D0AjSyx/mSc6gVDt jQhICN0cJA8oEiUaN9ywIKRBdTqCz2cYp4ctqxTT66Dtgf67ru+40svH/U8vxcxnCTjN nHA+VQVdNQ8ShDw/j695e9YWugdEhmiXVJr8vNOVl7TbWjf3hFfIrz1F5DSiqNmpeyZk tqOORAoiXJJKObT19N4bWUG4hhbUr3Tuli3WwHQWNrM9TESFlTxLjUz+uLZU8xmAss0e 09vA== X-Gm-Message-State: AGRZ1gLuu9sbY1vGpH0CJz3Ekii2AAC82A3GarjF2LpB+DQ8A6K7ZlRt DDDKjwhbHxdBdy50Iz2PVyR2H23PyUA0MJ6HDEMpGGqCQl8= X-Google-Smtp-Source: AJdET5d9JKVUaa5XCsXMjJHINrL5KVpEGpie/prRNQicdsNuhnpkz/0oK55FxNcX3s7ZJV5HYQR2eS93QWYBz/xtzVE= X-Received: by 2002:a2e:94ce:: with SMTP id r14-v6mr14443527ljh.34.1541484320421; Mon, 05 Nov 2018 22:05:20 -0800 (PST) MIME-Version: 1.0 From: Greg Mirsky Date: Tue, 6 Nov 2018 13:05:10 +0700 Message-ID: To: draft-gandhi-spring-udp-pm@ietf.org, spring , IETF IPPM WG , 6man WG Content-Type: multipart/alternative; boundary="000000000000587baa0579f8c9ae" Archived-At: Subject: [ippm] Sequence Number in RFC 6374 and Synthetic Loss Measurement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 06:05:29 -0000 --000000000000587baa0579f8c9ae Content-Type: text/plain; charset="UTF-8" Dear Authors, in your presentation of this draft at IPPM WG meeting I've pointed that assertion in Section 6 of the draft: The message formats for DM and LM [RFC6374] do not contain sequence number for probe query packets. is not accurate. RFC 6374 allows interpretation of the Timestamp field as a sequence number. Section 3.4 explains that QTF and RTF values could be 0, 1, 2, or 3, with 1 identifying the sequence number: 1: Sequence number. This value indicates that the timestamp field is to be viewed as a simple 64-bit sequence number. This provides a simple solution for applications that do not require a real absolute timestamp, but only an indication of message ordering; an example is LM exception detection. Regards, Greg --000000000000587baa0579f8c9ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors,
in you= r presentation of this draft at IPPM WG meeting I've pointed that asser= tion in Section 6 of the draft:
=C2=A0 =C2=A0The message for= mats for DM and LM [RFC6374] do not contain sequence
=C2=A0 =C2= =A0number for probe query packets.
is not accurate. RFC 637= 4 allows interpretation of the Timestamp field as a sequence number. Sectio= n 3.4 explains that QTF and RTF values could be 0, 1, 2, or 3, with 1 ident= ifying the sequence number:
=C2=A0 =C2=A0 =C2=A0 1: Sequence= number.=C2=A0 This value indicates that the timestamp field
=C2= =A0 =C2=A0 =C2=A0 is to be viewed as a simple 64-bit sequence number.=C2=A0= This provides
=C2=A0 =C2=A0 =C2=A0 a simple solution for applica= tions that do not require a real
=C2=A0 =C2=A0 =C2=A0 absolute ti= mestamp, but only an indication of message ordering; an
=C2=A0 = =C2=A0 =C2=A0 example is LM exception detection.

=
Regards,
Greg

--000000000000587baa0579f8c9ae-- From nobody Tue Nov 6 02:17:09 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69322130DFF for ; Tue, 6 Nov 2018 02:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 IZ8sGHCFhqoc for ; Tue, 6 Nov 2018 02:17:06 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B7A1277C8 for ; Tue, 6 Nov 2018 02:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1326; q=dns/txt; s=iport; t=1541499426; x=1542709026; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=e0DnC1S9GYRAXBvQGYH9h40uzjOhhPUnamU8BL+dlsU=; b=TcGzoouguRPD+K4/8XiKvA8vtEjJf+KvRoSSZDWJfm2hI0UVBeZmZlmo ujGzSoYDis/rtb11+RitZswAOuHHQ+jKua/mnpU66D3vhg9lgjliHslcX 7otWoqVzLj/4PMMXZeCYJyf/DYYUll4tK8IpmxEISYU2iHdqgKDYmY61r k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADQaeFb/5RdJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGCA2aBAjGDbIgYjgCXVYF6CwEBI4RJGYNBIjQ?= =?us-ascii?q?NDQEDAQECAQECbRwBC4VkEUUSASICJgIEMBUSBA6DJgGCAQ+oM4EuhDECgQm?= =?us-ascii?q?EcQWBC4prF4IAgREnDBODdBkBgVkBAQOEYjGCJgKJN5V/CQKBX4UOiiMYkGG?= =?us-ascii?q?NDIoXAhEUgSYdOIFVcBVlAYJCgjKIaIU+QY1BgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,471,1534809600"; d="scan'208";a="196415408" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 10:17:02 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id wA6AH2pS030904 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Nov 2018 10:17:02 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 6 Nov 2018 05:17:01 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1395.000; Tue, 6 Nov 2018 05:17:01 -0500 From: "Brian Weis (bew)" To: "spencerdawkins.ietf@gmail.com" CC: "ippm@ietf.org" Thread-Topic: Upcoming request for EtherType allocation Thread-Index: AQHUdbnb9xE1zSKOQ0mdu4N0E/TwhQ== Date: Tue, 6 Nov 2018 10:17:01 +0000 Message-ID: <09C43D84-A5CC-4400-9FDD-814E33D2B3AC@cisco.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.24.45.182] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.144, xch-rtp-004.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: [ippm] Upcoming request for EtherType allocation X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 10:17:08 -0000 SGkgU3BlbmNlciwNCg0KQXMgZGlzY3Vzc2VkIGluIHRvZGF54oCZcyBJUFBNIFdHIG1lZXRpbmcs IHdlIGFyZSBleHBlY3RpbmcgaW4gdGhlIGZ1dHVyZSB0byByZXF1ZXN0IHB1YmxpY2F0aW9uIG9m IGFuIEludGVybmV0LURyYWZ0IHRoYXQgcmVxdWlyZXMgYSBuZXcgRXRoZXJUeXBlIHRvIHRvIGJl IGFsbG9jYXRlZC4gWW91IG1lbnRpb25lZCB0aGF0IHRoaXMgbWlnaHQgYmUgYW4gaW50ZXJlc3Rp bmcgdG9waWMgZm9yIHRoaXMgd2Vla+KAmXMgSUVURi9JRUVFIDgwMiBtZWV0aW5nLCBhbmQgc28g SeKAmW0gcGFzc2luZyBvbiB0aGUgZm9sbG93aW5nIG5vdGVzLg0KDQpXZSB3b3VsZCByZXF1ZXN0 IGFuIEV0aGVyVHlwZSBmb3IgaXQgIkluLXNpdHUgT0FNIChJT0FNKeKAnSAoc2VlIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13ZWlzLWlwcG0taW9hbS1ldGgtMDApLiBXZSB1bmRl cnN0YW5kIHRoYXQgdGhlcmUgaXMgYSBwcm9jZXNzIGZvciBJQU5BIHRvIHJlcXVlc3QgdGhpcyBm cm9tIHRoZSBJRUVFIDgwMiwgYW5kIGhhdmUgcHV0IHRoaXMgaW50byBvdXIgSUFOQSBDb25zaWRl cmF0aW9ucyBzZWN0aW9uLiAgQWRkaXRpb25hbGx5LCB3ZSBoYWQgYW4gZWFybHkgcHJpdmF0ZSBl eGNoYW5nZSB3aXRoIHNvbWUgbWVtYmVycyBvZiB0aGUgSUVFRSA4MDIgUkFDICh0aGUgZW50aXR5 IHRoYXQgcGVyZm9ybXMgdGhlIGFsbG9jYXRpb24pLCB3aG8gZ2F2ZSBhZHZpY2UgdG8gbWFrZSBz dXJlIHdlIG9ubHkgYXNrIGZvciBvbmUgRXRoZXJUeXBlIG9mIHRoaXMgcHVycG9zZSwgYW5kIHdl 4oCZdmUgZm9sbG93ZWQgdGhhdCBhZHZpY2UuIEkgZG9u4oCZdCBleHBlY3QgYW55IGlzc3VlcyB3 aXRoIGRlZmluaW5nIHRoZSBFdGhlclR5cGUgd2UgbmVlZCwgYnV0IGlmIHlvdeKAmWQgbGlrZSB0 byBjaGVjayB3aXRoIHRoZW0gdGhhdCB3b3VsZCBiZSBncmVhdC4NCg0KVGhhbmtzLA0KQnJpYW4= From nobody Tue Nov 6 11:26:52 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018C1130DEF for ; Tue, 6 Nov 2018 11:26:51 -0800 (PST) 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 t90VLmbbsOdx for ; Tue, 6 Nov 2018 11:26:48 -0800 (PST) Received: from cnet.fi.uba.ar (cnet.fi.uba.ar [157.92.58.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA12D129385 for ; Tue, 6 Nov 2018 11:26:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by cnet.fi.uba.ar (Postfix) with ESMTP id DAE0014006C; Tue, 6 Nov 2018 15:55:55 -0300 (ART) X-Virus-Scanned: Debian amavisd-new at cnet.fi.uba.ar Received: from cnet.fi.uba.ar ([127.0.0.1]) by localhost (cnet.fi.uba.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-z9PqjS06xc; Tue, 6 Nov 2018 15:55:49 -0300 (ART) Received: from [192.168.1.136] (unknown [157.92.51.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by cnet.fi.uba.ar (Postfix) with ESMTPSA id AD4E2140068; Tue, 6 Nov 2018 15:55:49 -0300 (ART) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: J Ignacio Alvarez-Hamelin In-Reply-To: <730E50FA-3318-43FE-9C1E-60D29B748BE0@trammell.ch> Date: Tue, 6 Nov 2018 16:26:22 -0300 Cc: IETF IPPM WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <153635740444.28980.6908501775124770245@ietfa.amsl.com> <0861E2EE-9403-4F71-AFD7-1C89D73C773C@trammell.ch> <730E50FA-3318-43FE-9C1E-60D29B748BE0@trammell.ch> To: Greg Mirsky X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 19:26:51 -0000 Hi Greg,=20 Today at the IPPM meeting I said that you could consider using SHA1 256 = with bits for authentication, to respect some security standards. Your = comment that is expensive, and I agree with that.=20 I propose another alternative, is the one that I used in = draft-alavarez-hamelin-tictoc-sic-02, the Elliptic Curve Digital = Signature Algorithm (ECDSA), which yields in few bits and has some = securities form de cryptographic point of view.=20 Best withes, J. Ignacio _______________________________________________________________ Dr. Ing. Jos=C3=A9 Ignacio Alvarez-Hamelin CONICET and Facultad de Ingenier=C3=ADa, Universidad de Buenos Aires Av. Paseo Col=C3=B3n 850 - C1063ACV - Buenos Aires - Argentina +54 (11) 5285 0716 / 5285 0705 e-mail: ihameli@cnet.fi.uba.ar web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ _______________________________________________________________ > On 16 Oct 2018, at 05:24, Brian Trammell (IETF) = wrote: >=20 > hi Greg, >=20 > We'll put this and a tentative start of WGLC on the Bangkok agenda. >=20 > Thanks, cheers, >=20 > Brian >=20 >> On 16 Oct 2018, at 01:00, Greg Mirsky wrote: >>=20 >> Hi Brian, >> my apologies for the delayed response. The new version of the draft = has been just uploaded. The updates include the new section that = describes authentication and encryption operations on STAMP packets. I'd = request the presentation slot at the meeting and, if there are no = significant concerns, would ask to consider starting the WG LC on the = base specification. The work on the STAMP YANG data model still on-going = and we're addressing the comments from the early YANG Doctors review by = Mahesh. I expect we'll have the new version by the end of November. >>=20 >> Regards, >> Greg >>=20 >> On Thu, Oct 4, 2018 at 8:12 AM Brian Trammell (IETF) = wrote: >> hi Greg, >>=20 >> following up a bit late, perhaps... when do you think this will be = ready for LC? >>=20 >> Cheers, >>=20 >> Brian (as WG co-chair) >>=20 >>> On 8 Sep 2018, at 00:53, Greg Mirsky wrote: >>>=20 >>> Dear All, >>> minor editorial improvements to the document.. >>> Your comments, questions, and suggestions always welcome and much = appreciated. >>>=20 >>> Regards, >>> Greg >>>=20 >>> ---------- Forwarded message ---------- >>> From: >>> Date: Fri, Sep 7, 2018 at 2:56 PM >>> Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt >>> To: i-d-announce@ietf.org >>> Cc: ippm@ietf.org >>>=20 >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the IP Performance Measurement WG of = the IETF. >>>=20 >>> Title : Simple Two-way Active Measurement Protocol >>> Authors : Greg Mirsky >>> Guo Jun >>> Henrik Nydell >>> Richard Foote >>> Filename : draft-ietf-ippm-stamp-02.txt >>> Pages : 14 >>> Date : 2018-09-07 >>>=20 >>> Abstract: >>> This document describes a Simple Two-way Active Measurement = Protocol >>> which enables measurement of both one-way and round-trip = performance >>> metrics like delay, delay variation, and packet loss. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-ippm-stamp-02 >>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-02 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-stamp-02 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> 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 >>=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Tue Nov 6 18:15:40 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA6E126DBF for ; Tue, 6 Nov 2018 18:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGbm1vwszz0P for ; Tue, 6 Nov 2018 18:15:37 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 6FDB6126CB6 for ; Tue, 6 Nov 2018 18:15:36 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id f23so5814901lfc.13 for ; Tue, 06 Nov 2018 18:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GEAR+2qLiCAKkRAoFFwPtf3n2jJZzeZ5wt9KS1VkBd0=; b=D/anKIpCmp4C1CCW9LVc3l5ZWIoOctSyyupwhccQPF6dm+ujO2XdoL2zHdfXBJiIuT mIj+GcGdPAHT3QP1z9kG+MDxNehE3UzNgoFQ+MOhRcQ3tJYZbjpPabMJWZ90ZTUKMDlI cwuYE7Jg9HeTHLEqiu3+4JmVlFHFaU6rJZ4tATPF2nUim8C3FYtTwWpoQtrFfmTlZ7yR hoaLCDsv4Lbe1i0j6gqV8DF7HeqUrqotPVvbrZ0L58p1gWl9A7Ce0zWKe1o7xdniNVF5 saX0v1FtkmQEnLqz1ZeM4OqcAqMJmiR81NPf8nKrmKAdWB+HArSRBb6wxJ/INGJdY0vO YKYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GEAR+2qLiCAKkRAoFFwPtf3n2jJZzeZ5wt9KS1VkBd0=; b=YtAppizwL3eVQN2CLFIUoNEYBGL7nyQmw+6zyhbiezDhRYdthUoJQga8wtTICuznKq QdvSPHImE7b38GOf45X8ts4dmYuDDIZN4f/IPRA6PkjhOHZf+Evvjsu7EL4rwobEmRA8 aGBSPZyvKdfQoIqZZuC0ax9wDsakeLLB/0kNLOMYkTO6KRkL288M5/4ekhIRzA5tMANq SUidpd/Nbpdo1liFqWThYNH6teTVdBzIOMFaQDi1NbmCsahHN6x0ww3r3yo7EkpC3lVY 67NO+FSLBmUijP23e8JR2JfG3mXnht14Cq2uyJnvwJct7Z7GuFDQqWrm8I4xa4qJPlS8 zKIg== X-Gm-Message-State: AGRZ1gKDcYKeajRrIxRHvf9OvG156T1Jxxt5itP8xKyxtSt43na4Jrnd +DAc1J86LIivQ73HvN8U2wlfxWRQqgLfnLVfrZKnThd7 X-Google-Smtp-Source: AJdET5ejY5T/hBjNfbf28WLL1uQRg87sB2ak8g67B4+N98S5qGL3Vpm0qQveuoCAvOwZBOStAD7O3fyHzrpn3McoswA= X-Received: by 2002:a19:ae03:: with SMTP id f3mr13383lfc.86.1541556934455; Tue, 06 Nov 2018 18:15:34 -0800 (PST) MIME-Version: 1.0 References: <153635740444.28980.6908501775124770245@ietfa.amsl.com> <0861E2EE-9403-4F71-AFD7-1C89D73C773C@trammell.ch> <730E50FA-3318-43FE-9C1E-60D29B748BE0@trammell.ch> In-Reply-To: From: Greg Mirsky Date: Wed, 7 Nov 2018 09:15:25 +0700 Message-ID: To: "J. Ignacio Alvarez-Hamelin" Cc: IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000007abeba057a09b117" Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 02:15:39 -0000 --0000000000007abeba057a09b117 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ho J.Ignacio, thank you for the comment and helpful suggestion. Will read the draft-alavarez-hamelin-tictoc-sic and respond accordingly in a short time. >From the quick run through the draft, I agree with you that ECDSA offers advantages over the SHA1 of the same length. Just need to check for possible impact on YANG data model. Regards, Greg On Wed, Nov 7, 2018 at 2:26 AM J Ignacio Alvarez-Hamelin < ihameli@cnet.fi.uba.ar> wrote: > Hi Greg, > > Today at the IPPM meeting I said that you could consider using SHA1 256 > with bits for authentication, to respect some security standards. Your > comment that is expensive, and I agree with that. > I propose another alternative, is the one that I used in > draft-alavarez-hamelin-tictoc-sic-02, the Elliptic Curve Digital Signatur= e > Algorithm (ECDSA), which yields in few bits and has some securities form = de > cryptographic point of view. > > > Best withes, > > J. Ignacio > _______________________________________________________________ > > Dr. Ing. Jos=C3=A9 Ignacio Alvarez-Hamelin > CONICET and Facultad de Ingenier=C3=ADa, Universidad de Buenos Aires > Av. Paseo Col=C3=B3n 850 - C1063ACV - Buenos Aires - Argentina > +54 (11) 5285 0716 / 5285 0705 > e-mail: ihameli@cnet.fi.uba.ar > web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ > _______________________________________________________________ > > > > > On 16 Oct 2018, at 05:24, Brian Trammell (IETF) > wrote: > > > > hi Greg, > > > > We'll put this and a tentative start of WGLC on the Bangkok agenda. > > > > Thanks, cheers, > > > > Brian > > > >> On 16 Oct 2018, at 01:00, Greg Mirsky wrote: > >> > >> Hi Brian, > >> my apologies for the delayed response. The new version of the draft ha= s > been just uploaded. The updates include the new section that describes > authentication and encryption operations on STAMP packets. I'd request th= e > presentation slot at the meeting and, if there are no significant concern= s, > would ask to consider starting the WG LC on the base specification. The > work on the STAMP YANG data model still on-going and we're addressing the > comments from the early YANG Doctors review by Mahesh. I expect we'll hav= e > the new version by the end of November. > >> > >> Regards, > >> Greg > >> > >> On Thu, Oct 4, 2018 at 8:12 AM Brian Trammell (IETF) > wrote: > >> hi Greg, > >> > >> following up a bit late, perhaps... when do you think this will be > ready for LC? > >> > >> Cheers, > >> > >> Brian (as WG co-chair) > >> > >>> On 8 Sep 2018, at 00:53, Greg Mirsky wrote: > >>> > >>> Dear All, > >>> minor editorial improvements to the document.. > >>> Your comments, questions, and suggestions always welcome and much > appreciated. > >>> > >>> Regards, > >>> Greg > >>> > >>> ---------- Forwarded message ---------- > >>> From: > >>> Date: Fri, Sep 7, 2018 at 2:56 PM > >>> Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt > >>> To: i-d-announce@ietf.org > >>> Cc: ippm@ietf.org > >>> > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >>> This draft is a work item of the IP Performance Measurement WG of the > IETF. > >>> > >>> Title : Simple Two-way Active Measurement Protocol > >>> Authors : Greg Mirsky > >>> Guo Jun > >>> Henrik Nydell > >>> Richard Foote > >>> Filename : draft-ietf-ippm-stamp-02.txt > >>> Pages : 14 > >>> Date : 2018-09-07 > >>> > >>> Abstract: > >>> This document describes a Simple Two-way Active Measurement Protoco= l > >>> which enables measurement of both one-way and round-trip performanc= e > >>> metrics like delay, delay variation, and packet loss. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ > >>> > >>> There are also htmlized versions available at: > >>> https://tools.ietf.org/html/draft-ietf-ippm-stamp-02 > >>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-02 > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-stamp-02 > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of > submission > >>> until the htmlized version and diff are available at tools.ietf.org. > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> ippm mailing list > >>> ippm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ippm > >>> > >>> _______________________________________________ > >>> ippm mailing list > >>> ippm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ippm > >> > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > > --0000000000007abeba057a09b117 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ho J.Ignacio,
thank you for the comment and helpful=C2= =A0suggestion. Will read the draft-alavarez-hamelin-tictoc-sic and respond= =C2=A0accordingly in a short time. From the quick run through the draft, I = agree with you that ECDSA offers advantages over the SHA1 of the=C2=A0same = length. Just need to check for possible impact on YANG data model.

Regards,
Greg

On Wed, Nov 7, 2018 at 2:26 AM J Ignacio Alvarez-H= amelin <ihameli@cnet.fi.uba.ar= > wrote:
Hi Greg,

Today at the IPPM meeting I said that you could consider using SHA1 256 wit= h bits for authentication, to respect some security standards. Your comment= that is expensive, and I agree with that.
I propose another alternative, is the one that I used in draft-alavarez-ham= elin-tictoc-sic-02, the Elliptic Curve Digital Signature Algorithm (ECDSA),= which yields in few bits and has some securities form de cryptographic poi= nt of view.


Best withes,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 J. Ignacio
_______________________________________________________________

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



> On 16 Oct 2018, at 05:24, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>
> hi Greg,
>
> We'll put this and a tentative start of WGLC on the Bangkok agenda= .
>
> Thanks, cheers,
>
> Brian
>
>> On 16 Oct 2018, at 01:00, Greg Mirsky <gregimirsky@gmail.com> wrote:
>>
>> Hi Brian,
>> my apologies for the delayed response. The new version of the draf= t has been just uploaded. The updates include the new section that describe= s authentication and encryption operations on STAMP packets. I'd reques= t the presentation slot at the meeting and, if there are no significant con= cerns, would ask to consider starting the WG LC on the base specification. = The work on the STAMP YANG data model still on-going and we're addressi= ng the comments from the early YANG Doctors review by Mahesh. I expect we&#= 39;ll have the new version by the end of November.
>>
>> Regards,
>> Greg
>>
>> On Thu, Oct 4, 2018 at 8:12 AM Brian Trammell (IETF) <ietf@trammell.ch> wro= te:
>> hi Greg,
>>
>> following up a bit late, perhaps... when do you think this will be= ready for LC?
>>
>> Cheers,
>>
>> Brian (as WG co-chair)
>>
>>> On 8 Sep 2018, at 00:53, Greg Mirsky <gregimirsky@gmail.com> wrote:<= br> >>>
>>> Dear All,
>>> minor editorial improvements to the document..
>>> Your comments, questions, and suggestions always welcome and m= uch appreciated.
>>>
>>> Regards,
>>> Greg
>>>
>>> ---------- Forwarded message ----------
>>> From: <internet-drafts@ietf.org>
>>> Date: Fri, Sep 7, 2018 at 2:56 PM
>>> Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt
>>> To: i-d-announce@ietf.org
>>> Cc: ippm@ie= tf.org
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts directories.
>>> This draft is a work item of the IP Performance Measurement WG= of the IETF.
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Simple Two-way Active Measurement Protocol
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Greg Mirsky
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Guo Jun
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik Nydell
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Richard Foote
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0= : draft-ietf-ippm-stamp-02.txt
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: 14
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2018-09-07
>>>
>>> Abstract:
>>>=C2=A0 =C2=A0This document describes a Simple Two-way Active Me= asurement Protocol
>>>=C2=A0 =C2=A0which enables measurement of both one-way and roun= d-trip performance
>>>=C2=A0 =C2=A0metrics like delay, delay variation, and packet lo= ss.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc= /draft-ietf-ippm-stamp/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-i= etf-ippm-stamp-02
>>> https://datatracker.ietf.= org/doc/html/draft-ietf-ippm-stamp-02
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdif= f?url2=3Ddraft-ietf-ippm-stamp-02
>>>
>>>
>>> Please note that it may take a couple of minutes from the time= of submission
>>> until the htmlized version and diff are available at tools.ietf.= org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/ippm
>>>
>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/ippm
>>
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm

--0000000000007abeba057a09b117-- From nobody Tue Nov 6 19:50:19 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CD7130DC7 for ; Tue, 6 Nov 2018 19:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.97 X-Spam-Level: X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 YhETzSuQsAWx for ; Tue, 6 Nov 2018 19:50:10 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD96D12785F for ; Tue, 6 Nov 2018 19:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31594; q=dns/txt; s=iport; t=1541562609; x=1542772209; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6lUY1KgsJ+nE4j1/LNUgGDvvevG9anwcNeK60fkhZRY=; b=FGCNz5mYXB8kd0eottapuoO5LAGrwpKJGdhedN8c7jDQqqNVDF8g2Un3 1wEBfF2oneH/pxG/R2G+kdwm+hgT/4FT+l1WrN259MQLMgLBJF8h0WNnX wFuX0NJ1Zhj2WsH33d2fVD44Vsu/7+iuqfJVvutQb+/wJnjkNNRp4OOg+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADpX+Jb/5RdJa1hAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIDZoECJwqDbIgYjBaBaCWHWoEpji0?= =?us-ascii?q?UgWYLAQEYAQyERwIXg0EiNA0NAQMBAQIBAQJtHAyFOgEBAQECAQEBIUsLBQs?= =?us-ascii?q?CAQgRAwECAScDAgICHwYLFAkIAgQOBYMhAYEdTAMNCA+pLoEuhDECDEA9gkk?= =?us-ascii?q?NghmLWx0XggCBEScME4JMglZFAQECAQEWgQ8FARIBNgkBHQmCPTGCJgKJDCy?= =?us-ascii?q?FKoUEgSiJfS4JAoZtgySDVYMqGIFWTIQ0gyKGbI0NgQSJFQIRFIEmDRA4ZHF?= =?us-ascii?q?wFRohKgGCQQmCHQEXgXWGaYU+QTEBixaBH4EfAQE?= X-IronPort-AV: E=Sophos;i="5.54,474,1534809600"; d="scan'208,217";a="474573643" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2018 03:50:07 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id wA73o7hG004165 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Nov 2018 03:50:07 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 6 Nov 2018 22:50:06 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1395.000; Tue, 6 Nov 2018 22:50:06 -0500 From: "Brian Weis (bew)" To: Greg Mirsky CC: "J. Ignacio Alvarez-Hamelin" , IETF IPPM WG Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt Thread-Index: AQHUdga0j7BtTkXoqE2P+bPcfo/CEqVD50GAgAAabwA= Date: Wed, 7 Nov 2018 03:50:06 +0000 Message-ID: References: <153635740444.28980.6908501775124770245@ietfa.amsl.com> <0861E2EE-9403-4F71-AFD7-1C89D73C773C@trammell.ch> <730E50FA-3318-43FE-9C1E-60D29B748BE0@trammell.ch> 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.24.122.89] Content-Type: multipart/alternative; boundary="_000_F77B6597C36C483B8325AE69DE393E86ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.142, xch-rtp-002.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 03:50:15 -0000 --_000_F77B6597C36C483B8325AE69DE393E86ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSWduYWNpbyBhbmQgR3JlZywNCg0KRUNEU0EgaXMgYSBkaWdpdGFsIHNpZ25hdHVyZSBhbGdv cml0aG0sIHdoaWNoIGlzIHZlcnkgZXhwZW5zaXZlIGFuZCBiZWNhdXNlIG9mIHRoaXMgaXQgaXMg bm90IHRyYWRpdGlvbmFsbHkgdXNlZCB0byBwcm90ZWN0IG5ldHdvcmsgZGF0YSBwYWNrZXRzLiAg SSBkb27igJl0IHJlY29tbWVuZCBzcGVjaWZ5aW5nIGl0LiBVbmxlc3MgdGhpcyBpcyBhIHJhcmVs eSBzZW50IGRhdGEgcGFja2V0IHNlbnQsIHlvdSB3b3VsZCBiZSBjb25zdW1pbmcgYSBzdWJzdGFu dGlhbCBhbW91bnQgb2YgdGhlIENQVSBieSBhcHBseWluZyBhIGRpZ2l0YWwgc2lnbmF0dXJlIHRv IGV2ZXJ5IHBhY2tldCBzZW50IHdpdGggU1RBTVAuIEFsc28sIGluIG9yZGVyIHRvIGdldCB0aGUg dmFsdWUgIHlvdSB3YW50LCB5b3UgYWN0dWFsbHkgaGF2ZSB0byBjcmVhdGUgYSBoYXNoIG9mIHRo ZSBwYWNrZXQgKGUuZy4sIHVzaW5nIFNIQTEvU0hBMjU2KSBhbmQgdGhlbiBzaWduIHRoZSBoYXNo LCB3aGVyZSB0aGUgcmVzdWx0IHdpbGwgYmUgYXQgbGVhc3QgdGhlIGxlbmd0aCBvZiBhIGZ1bGwg SE1BQyBvdXRwdXQuIFNvIHlvdeKAmXJlIG5vdCBzYXZpbmcgYW55IHNwYWNlLg0KDQpVc2luZyBI TUFDLVNIQTEgb3IgU0hBMjU2IG9uIG5ldHdvcmsgZGF0YSBwYWNrZXRzIGFzIHNob3duIGluIEZp Z3VyZSA0IGlzIHZlcnkgcmVhc29uYWJsZS4gIFNlY3Rpb24gNSBvZiBSRkMgMjEwNCAoSE1BQykg c2F5cyBob3cgaXTigJlzIGFjY2VwdGFibGUgdG8gdHJ1bmNhdGUgdGhlIGhhc2ggb3V0cHV0LCBh bmQgc2VjdXJpdHkgcHJvdG9jb2xzIHVzdWFsbHkgZG8gdGhpcy4gIElQU2VjIHRydW5jYXRlcyBI TUFDLVNIQS0xIG91dHB1dCB0byA5NiBiaXRzIChSRkMgMjQwNCksIGFuZCBITUFDLVNIQS0yNTYg aXMgdHJ1bmNhdGVkIHRvIDEyOCBiaXRzIChSRkMgNDg2OCkuICBTaW5jZSAtMDMgd2FzIHdpbGxp bmcgdG8gYXBwbHkgYSAxMjgtYml0IHRydW5jYXRlZCBoYXNoLCBJIHRoaW5rIHlvdSBjb3VsZCBz YWZlbHkgc3BlY2lmeSB1c2luZyBITUFDLVNIQS0yNTYgd2l0aCBhIDEyOCBiaXQgdHJ1bmNhdGlv bi4gTm90ZSB0aGF0IGlmIHlvdSBzcGVjaWZ5IHRoZSB1c2Ugb2YgSE1BQy1TSEExLCB5b3Ugd2ls bCB2ZXJ5IGxpa2VseSBydW4gaW50byBTZWNEaXIgY29tcGxhaW50cyB3aGVuIHlvdSBnZXQgdG8g SUVURiBsYXN0IGNhbGwuDQoNCkkgZGlkIG1lbnRpb24gaW4gdGhlIElQUE0gbWVldGluZyB0aGF0 IGFkZGluZyBBRVMgc3VwcG9ydCBpcyBiaXQgbW9yZSBwcm9ibGVtYXRpYy4gSSB3b3VsZCByZWNv bW1lbmQgc3BlY2lmeWluZyB0aGF0IHdoZW4gY29uZmlkZW50aWFsaXR5IGlzIG5lZWRlZCB0aGF0 IGl0IGJlIGRvbmUgYSBoaWdoZXIgbGF5ZXIuIElmIHlvdSBkbyBkZWNpZGUgdG8ga2VlcCBpdCBp biB0aGlzIGRyYWZ0LCB5b3Ugc2hvdWxkIGRlc2NyaWJlIHdoYXQgaXMgdGhlIHZhbHVlIG9mIHBy b3RlY3Rpbmcgb25seSB0aGUgZmlyc3QgMTYgb2N0ZXRzLiBBbHNvLCB5b3Ugc2hvdWxkIGtub3cg dGhhdCBjcnlwdG9ncmFwaGVycyBkbyBub3QgcmVjb21tZW5kIHVzaW5nIEVCQy4gQSBXaWtpcGVk aWEgcGFnZSBkZXNjcmliZXMgdGhpcyBwbGFpbmx5OiAiVGhlIGRpc2FkdmFudGFnZSBvZiB0aGlz IG1ldGhvZCBpcyBhIGxhY2sgb2YgZGlmZnVzaW9uLiBCZWNhdXNlIEVDQiBlbmNyeXB0cyBpZGVu dGljYWwgcGxhaW50ZXh0IGJsb2NrcyBpbnRvIGlkZW50aWNhbCBjaXBoZXJ0ZXh0IGJsb2Nrcywg aXQgZG9lcyBub3QgaGlkZSBkYXRhIHBhdHRlcm5zIHdlbGwuIEluIHNvbWUgc2Vuc2VzLCBpdCBk b2Vzbid0IHByb3ZpZGUgc2VyaW91cyBtZXNzYWdlIGNvbmZpZGVudGlhbGl0eSwgYW5kIGl0IGlz IG5vdCByZWNvbW1lbmRlZCBmb3IgdXNlIGluIGNyeXB0b2dyYXBoaWMgcHJvdG9jb2xzIGF0IGFs bC7igJ0gKGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0Jsb2NrX2NpcGhlcl9tb2RlX29m X29wZXJhdGlvbiNFbGVjdHJvbmljX0NvZGVib29rXyhFQ0IpKS4NCg0KVGhlIG90aGVyIG1vZGUg LTAzIG1lbnRpb25lZCBpcyB1c2luZyBBRVMtQ0JDIHRvIHByb3RlY3QgdGhlIGVudGlyZSBtZXNz YWdlLiBUaGF04oCZcyBhIGNvbnZlbnRpb25hbCB1c2Ugb2YgQUVTLCBidXQgd2hlbiBBRVMtQ0JD IGlzIHVzZWQsIGJvdGggdGhlIGVuY3J5cHRvciBhbmQgZGVjcnlwdCBuZWVkIHRoZSBzYW1lIElu aXRpYWxpemF0aW9uIFZlY3RvciAoSVYpIHVzZWQgd2l0aCB0aGUgbWV0aG9kLiBUcmFkaXRpb25h bGx5IGl0IGlzIGluY2x1ZGVkIGluIHRoZSBwYWNrZXQsIHNvIHRoYXTigJlzIGFub3RoZXIgMTYg b2N0ZXRzIHlvdSBwcm9iYWJseSBuZWVkIHRvIGFkZCB0byB0aGUgcGFja2V0IGZvcm1hdC4gVGhp cyBzaG91bGQgTk9UIHJlcGxhY2UgdGhlIEhNQUMgZmllbGQsIGJlY2F1c2UgY3J5cHRvZ3JhcGhl cnMgc3Ryb25nbHkgc3RhdGUgdGhhdCBpdCBpcyBiYWQgcHJhY3RpY2UgdG8gc2VuZCBhbiB1bmF1 dGhlbnRpY2F0ZWQgZW5jcnlwdGVkIHBhY2tldC4NCg0KSSBkb27igJl0IHNlZSB0aGUgcmF0aW9u YWxlIGluIC0wMyBmb3IgbmVlZGluZyBjb25maWRlbnRpYWxpdHkuIFNvIGl0IG1pZ2h0IGJlIGJl c3QgdG8gc3RpY2sgd2l0aCBhbiBITUFDLVNIQTI1NiBoYXNoLCBhbmQgaWYgY29uZmlkZW50aWFs aXR5IGlzIHJlcXVpcmVkIHRvIHVzZSBhIGhpZ2hlciBsYXllciBlbmNyeXB0aW9uLiBPdGhlcndp c2UsIHlvdeKAmWxsIG5lZWQgdG8gZG8gYSBsb3QgbW9yZSBzcGVjaWZpY2F0aW9uIG9mIGhvdyB0 aGUgY29uZmlkZW50aWFsbHkgaXMgZG9uZSBpbiB0aGlzIGRyYWZ0Lg0KDQpJIGhvcGUgdGhhdCBo ZWxwcy4NCg0KQnJpYW4NCg0KT24gTm92IDcsIDIwMTgsIGF0IDk6MTUgQU0sIEdyZWcgTWlyc2t5 IDxncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+IHdy b3RlOg0KDQpIbyBKLklnbmFjaW8sDQp0aGFuayB5b3UgZm9yIHRoZSBjb21tZW50IGFuZCBoZWxw ZnVsIHN1Z2dlc3Rpb24uIFdpbGwgcmVhZCB0aGUgZHJhZnQtYWxhdmFyZXotaGFtZWxpbi10aWN0 b2Mtc2ljIGFuZCByZXNwb25kIGFjY29yZGluZ2x5IGluIGEgc2hvcnQgdGltZS4gRnJvbSB0aGUg cXVpY2sgcnVuIHRocm91Z2ggdGhlIGRyYWZ0LCBJIGFncmVlIHdpdGggeW91IHRoYXQgRUNEU0Eg b2ZmZXJzIGFkdmFudGFnZXMgb3ZlciB0aGUgU0hBMSBvZiB0aGUgc2FtZSBsZW5ndGguIEp1c3Qg bmVlZCB0byBjaGVjayBmb3IgcG9zc2libGUgaW1wYWN0IG9uIFlBTkcgZGF0YSBtb2RlbC4NCg0K UmVnYXJkcywNCkdyZWcNCg0KT24gV2VkLCBOb3YgNywgMjAxOCBhdCAyOjI2IEFNIEogSWduYWNp byBBbHZhcmV6LUhhbWVsaW4gPGloYW1lbGlAY25ldC5maS51YmEuYXI8bWFpbHRvOmloYW1lbGlA Y25ldC5maS51YmEuYXI+PiB3cm90ZToNCkhpIEdyZWcsDQoNClRvZGF5IGF0IHRoZSBJUFBNIG1l ZXRpbmcgSSBzYWlkIHRoYXQgeW91IGNvdWxkIGNvbnNpZGVyIHVzaW5nIFNIQTEgMjU2IHdpdGgg Yml0cyBmb3IgYXV0aGVudGljYXRpb24sIHRvIHJlc3BlY3Qgc29tZSBzZWN1cml0eSBzdGFuZGFy ZHMuIFlvdXIgY29tbWVudCB0aGF0IGlzIGV4cGVuc2l2ZSwgYW5kIEkgYWdyZWUgd2l0aCB0aGF0 Lg0KSSBwcm9wb3NlIGFub3RoZXIgYWx0ZXJuYXRpdmUsIGlzIHRoZSBvbmUgdGhhdCBJIHVzZWQg aW4gZHJhZnQtYWxhdmFyZXotaGFtZWxpbi10aWN0b2Mtc2ljLTAyLCB0aGUgRWxsaXB0aWMgQ3Vy dmUgRGlnaXRhbCBTaWduYXR1cmUgQWxnb3JpdGhtIChFQ0RTQSksIHdoaWNoIHlpZWxkcyBpbiBm ZXcgYml0cyBhbmQgaGFzIHNvbWUgc2VjdXJpdGllcyBmb3JtIGRlIGNyeXB0b2dyYXBoaWMgcG9p bnQgb2Ygdmlldy4NCg0KDQpCZXN0IHdpdGhlcywNCg0KICAgICAgICBKLiBJZ25hY2lvDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KRHIuIEluZy4gSm9zw6kgSWduYWNpbyBBbHZhcmV6LUhhbWVsaW4NCkNPTklDRVQgYW5k IEZhY3VsdGFkIGRlIEluZ2VuaWVyw61hLCBVbml2ZXJzaWRhZCBkZSBCdWVub3MgQWlyZXMNCkF2 LiBQYXNlbyBDb2zDs24gODUwIC0gQzEwNjNBQ1YgLSBCdWVub3MgQWlyZXMgLSBBcmdlbnRpbmEN Cis1NCAoMTEpIDUyODUgMDcxNiAvIDUyODUgMDcwNQ0KZS1tYWlsOiBpaGFtZWxpQGNuZXQuZmku dWJhLmFyPG1haWx0bzppaGFtZWxpQGNuZXQuZmkudWJhLmFyPg0Kd2ViOiBodHRwOi8vY25ldC5m aS51YmEuYXIvaWduYWNpby5hbHZhcmV6LWhhbWVsaW4vDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCj4gT24gMTYg T2N0IDIwMTgsIGF0IDA1OjI0LCBCcmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwu Y2g8bWFpbHRvOmlldGZAdHJhbW1lbGwuY2g+PiB3cm90ZToNCj4NCj4gaGkgR3JlZywNCj4NCj4g V2UnbGwgcHV0IHRoaXMgYW5kIGEgdGVudGF0aXZlIHN0YXJ0IG9mIFdHTEMgb24gdGhlIEJhbmdr b2sgYWdlbmRhLi4NCj4NCj4gVGhhbmtzLCBjaGVlcnMsDQo+DQo+IEJyaWFuDQo+DQo+PiBPbiAx NiBPY3QgMjAxOCwgYXQgMDE6MDAsIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208 bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4NCj4+IEhpIEJyaWFuLA0K Pj4gbXkgYXBvbG9naWVzIGZvciB0aGUgZGVsYXllZCByZXNwb25zZS4gVGhlIG5ldyB2ZXJzaW9u IG9mIHRoZSBkcmFmdCBoYXMgYmVlbiBqdXN0IHVwbG9hZGVkLiBUaGUgdXBkYXRlcyBpbmNsdWRl IHRoZSBuZXcgc2VjdGlvbiB0aGF0IGRlc2NyaWJlcyBhdXRoZW50aWNhdGlvbiBhbmQgZW5jcnlw dGlvbiBvcGVyYXRpb25zIG9uIFNUQU1QIHBhY2tldHMuIEknZCByZXF1ZXN0IHRoZSBwcmVzZW50 YXRpb24gc2xvdCBhdCB0aGUgbWVldGluZyBhbmQsIGlmIHRoZXJlIGFyZSBubyBzaWduaWZpY2Fu dCBjb25jZXJucywgd291bGQgYXNrIHRvIGNvbnNpZGVyIHN0YXJ0aW5nIHRoZSBXRyBMQyBvbiB0 aGUgYmFzZSBzcGVjaWZpY2F0aW9uLiBUaGUgd29yayBvbiB0aGUgU1RBTVAgWUFORyBkYXRhIG1v ZGVsIHN0aWxsIG9uLWdvaW5nIGFuZCB3ZSdyZSBhZGRyZXNzaW5nIHRoZSBjb21tZW50cyBmcm9t IHRoZSBlYXJseSBZQU5HIERvY3RvcnMgcmV2aWV3IGJ5IE1haGVzaC4gSSBleHBlY3Qgd2UnbGwg aGF2ZSB0aGUgbmV3IHZlcnNpb24gYnkgdGhlIGVuZCBvZiBOb3ZlbWJlci4NCj4+DQo+PiBSZWdh cmRzLA0KPj4gR3JlZw0KPj4NCj4+IE9uIFRodSwgT2N0IDQsIDIwMTggYXQgODoxMiBBTSBCcmlh biBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g8bWFpbHRvOmlldGZAdHJhbW1lbGwu Y2g+PiB3cm90ZToNCj4+IGhpIEdyZWcsDQo+Pg0KPj4gZm9sbG93aW5nIHVwIGEgYml0IGxhdGUs IHBlcmhhcHMuLi4gd2hlbiBkbyB5b3UgdGhpbmsgdGhpcyB3aWxsIGJlIHJlYWR5IGZvciBMQz8N Cj4+DQo+PiBDaGVlcnMsDQo+Pg0KPj4gQnJpYW4gKGFzIFdHIGNvLWNoYWlyKQ0KPj4NCj4+PiBP biA4IFNlcCAyMDE4LCBhdCAwMDo1MywgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNv bTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4gd3JvdGU6DQo+Pj4NCj4+PiBEZWFyIEFs bCwNCj4+PiBtaW5vciBlZGl0b3JpYWwgaW1wcm92ZW1lbnRzIHRvIHRoZSBkb2N1bWVudC4uDQo+ Pj4gWW91ciBjb21tZW50cywgcXVlc3Rpb25zLCBhbmQgc3VnZ2VzdGlvbnMgYWx3YXlzIHdlbGNv bWUgYW5kIG11Y2ggYXBwcmVjaWF0ZWQuDQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+IEdyZWcNCj4+ Pg0KPj4+IC0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KPj4+IEZyb206 IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4+DQo+Pj4gRGF0ZTogRnJpLCBTZXAgNywgMjAxOCBhdCAyOjU2IFBNDQo+Pj4gU3ViamVjdDog W2lwcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wMi50eHQNCj4+PiBUbzog aS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+Pj4g Q2M6IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQo+Pj4NCj4+Pg0KPj4+DQo+ Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIElQIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IFdHIG9mIHRoZSBJRVRGLg0KPj4+DQo+ Pj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFNpbXBsZSBUd28td2F5IEFjdGl2ZSBNZWFzdXJl bWVudCBQcm90b2NvbA0KPj4+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBHcmVnIE1pcnNreQ0K Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBHdW8gSnVuDQo+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgIEhlbnJpayBOeWRlbGwNCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgUmlj aGFyZCBGb290ZQ0KPj4+ICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWlwcG0t c3RhbXAtMDIudHh0DQo+Pj4gICAgICAgIFBhZ2VzICAgICAgICAgICA6IDE0DQo+Pj4gICAgICAg IERhdGUgICAgICAgICAgICA6IDIwMTgtMDktMDcNCj4+Pg0KPj4+IEFic3RyYWN0Og0KPj4+ICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBTaW1wbGUgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1l bnQgUHJvdG9jb2wNCj4+PiAgIHdoaWNoIGVuYWJsZXMgbWVhc3VyZW1lbnQgb2YgYm90aCBvbmUt d2F5IGFuZCByb3VuZC10cmlwIHBlcmZvcm1hbmNlDQo+Pj4gICBtZXRyaWNzIGxpa2UgZGVsYXks IGRlbGF5IHZhcmlhdGlvbiwgYW5kIHBhY2tldCBsb3NzLg0KPj4+DQo+Pj4NCj4+PiBUaGUgSUVU RiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+PiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlwcG0tc3RhbXAvDQo+Pj4NCj4+ PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+Pj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1zdGFtcC0wMg0KPj4+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLXN0YW1w LTAyDQo+Pj4NCj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFi bGUgYXQ6DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt aXBwbS1zdGFtcC0wMg0KPj4+DQo+Pj4NCj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+Pj4gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCj4+Pg0KPj4+IEludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+PiBmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBpcHBtIG1haWxpbmcgbGlzdA0KPj4+IGlw cG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IGlwcG0gbWFpbGluZyBsaXN0DQo+Pj4gaXBw bUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IGlwcG0gbWFpbGluZyBsaXN0DQo+IGlwcG1AaWV0 Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXBwbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1A aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCg0K LS0NCkJyaWFuIFdlaXMNClNlY3VyaXR5LCBDU0csIENpc2NvIFN5c3RlbXMNClRlbGVwaG9uZTog KzEgNDA4IDUyNiA0Nzk2DQpFbWFpbDogYmV3QGNpc2NvLmNvbTxtYWlsdG86YmV3QGNpc2NvLmNv bT4NCg0K --_000_F77B6597C36C483B8325AE69DE393E86ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgSWduYWNpbyBhbmQgR3JlZywN CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVDRFNB IGlzIGEgZGlnaXRhbCBzaWduYXR1cmUgYWxnb3JpdGhtLCB3aGljaCBpcyB2ZXJ5IGV4cGVuc2l2 ZSBhbmQgYmVjYXVzZSBvZiB0aGlzIGl0IGlzIG5vdCB0cmFkaXRpb25hbGx5IHVzZWQgdG8gcHJv dGVjdCBuZXR3b3JrIGRhdGEgcGFja2V0cy4gJm5ic3A7SSBkb27igJl0IHJlY29tbWVuZCBzcGVj aWZ5aW5nIGl0LiBVbmxlc3MgdGhpcyBpcyBhIHJhcmVseSBzZW50IGRhdGEgcGFja2V0IHNlbnQs IHlvdSB3b3VsZCBiZSBjb25zdW1pbmcNCiBhIHN1YnN0YW50aWFsIGFtb3VudCBvZiB0aGUgQ1BV IGJ5IGFwcGx5aW5nIGEgZGlnaXRhbCBzaWduYXR1cmUgdG8gZXZlcnkgcGFja2V0IHNlbnQgd2l0 aCBTVEFNUC4gQWxzbywgaW4gb3JkZXIgdG8gZ2V0IHRoZSB2YWx1ZSAmbmJzcDt5b3Ugd2FudCwg eW91IGFjdHVhbGx5IGhhdmUgdG8gY3JlYXRlIGEgaGFzaCBvZiB0aGUgcGFja2V0IChlLmcuLCB1 c2luZyBTSEExL1NIQTI1NikgYW5kIHRoZW4gc2lnbiB0aGUgaGFzaCwgd2hlcmUgdGhlIHJlc3Vs dA0KIHdpbGwgYmUgYXQgbGVhc3QgdGhlIGxlbmd0aCBvZiBhIGZ1bGwgSE1BQyBvdXRwdXQuIFNv IHlvdeKAmXJlIG5vdCBzYXZpbmcgYW55IHNwYWNlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VXNpbmcgSE1BQy1TSEExIG9yIFNIQTI1 NiBvbiBuZXR3b3JrIGRhdGEgcGFja2V0cyBhcyBzaG93biBpbiBGaWd1cmUgNCBpcyB2ZXJ5IHJl YXNvbmFibGUuICZuYnNwO1NlY3Rpb24gNSBvZiBSRkMgMjEwNCAoSE1BQykgc2F5cyBob3cgaXTi gJlzIGFjY2VwdGFibGUgdG8gdHJ1bmNhdGUgdGhlIGhhc2ggb3V0cHV0LCBhbmQgc2VjdXJpdHkg cHJvdG9jb2xzIHVzdWFsbHkgZG8gdGhpcy4gJm5ic3A7SVBTZWMgdHJ1bmNhdGVzIEhNQUMtU0hB LTENCiBvdXRwdXQgdG8gOTYgYml0cyAoUkZDIDI0MDQpLCBhbmQgSE1BQy1TSEEtMjU2IGlzIHRy dW5jYXRlZCB0byAxMjggYml0cyAoUkZDIDQ4NjgpLiAmbmJzcDtTaW5jZSAtMDMgd2FzIHdpbGxp bmcgdG8gYXBwbHkgYSAxMjgtYml0IHRydW5jYXRlZCBoYXNoLCBJIHRoaW5rIHlvdSBjb3VsZCBz YWZlbHkgc3BlY2lmeSB1c2luZyBITUFDLVNIQS0yNTYgd2l0aCBhIDEyOCBiaXQgdHJ1bmNhdGlv bi4gTm90ZSB0aGF0IGlmIHlvdSBzcGVjaWZ5IHRoZSB1c2Ugb2YNCiBITUFDLVNIQTEsIHlvdSB3 aWxsIHZlcnkgbGlrZWx5IHJ1biBpbnRvIFNlY0RpciBjb21wbGFpbnRzIHdoZW4geW91IGdldCB0 byBJRVRGIGxhc3QgY2FsbC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkkgZGlkIG1lbnRpb24gaW4gdGhlIElQUE0gbWVldGluZyB0aGF0 IGFkZGluZyBBRVMgc3VwcG9ydCBpcyBiaXQgbW9yZSBwcm9ibGVtYXRpYy4gSSB3b3VsZCByZWNv bW1lbmQgc3BlY2lmeWluZyB0aGF0IHdoZW4gY29uZmlkZW50aWFsaXR5IGlzIG5lZWRlZCB0aGF0 IGl0IGJlIGRvbmUgYSBoaWdoZXIgbGF5ZXIuIElmIHlvdSBkbyBkZWNpZGUgdG8ga2VlcCBpdCBp biB0aGlzIGRyYWZ0LCB5b3Ugc2hvdWxkIGRlc2NyaWJlDQogd2hhdCBpcyB0aGUgdmFsdWUgb2Yg cHJvdGVjdGluZyBvbmx5IHRoZSBmaXJzdCAxNiBvY3RldHMuIEFsc28sIHlvdSBzaG91bGQga25v dyB0aGF0IGNyeXB0b2dyYXBoZXJzIGRvIG5vdCByZWNvbW1lbmQgdXNpbmcgRUJDLiBBIFdpa2lw ZWRpYSBwYWdlIGRlc2NyaWJlcyB0aGlzIHBsYWlubHk6ICZxdW90O1RoZSBkaXNhZHZhbnRhZ2Ug b2YgdGhpcyBtZXRob2QgaXMgYSBsYWNrIG9mJm5ic3A7ZGlmZnVzaW9uLiBCZWNhdXNlIEVDQiBl bmNyeXB0cyBpZGVudGljYWwmbmJzcDtwbGFpbnRleHQmbmJzcDtibG9ja3MNCiBpbnRvIGlkZW50 aWNhbCZuYnNwO2NpcGhlcnRleHQmbmJzcDtibG9ja3MsIGl0Jm5ic3A7ZG9lcyBub3QgaGlkZSBk YXRhIHBhdHRlcm5zIHdlbGwuIEluIHNvbWUgc2Vuc2VzLCBpdCBkb2Vzbid0IHByb3ZpZGUgc2Vy aW91cyBtZXNzYWdlIGNvbmZpZGVudGlhbGl0eSwgYW5kIGl0IGlzIG5vdCByZWNvbW1lbmRlZCBm b3IgdXNlIGluJm5ic3A7Y3J5cHRvZ3JhcGhpYyBwcm90b2NvbHMgYXQgYWxsLuKAnSAoPGEgaHJl Zj0iaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvQmxvY2tfY2lwaGVyX21vZGVfb2Zfb3Bl cmF0aW9uI0VsZWN0cm9uaWNfQ29kZWJvb2tfKEVDQikpIiBjbGFzcz0iIj5odHRwczovL2VuLndp a2lwZWRpYS5vcmcvd2lraS9CbG9ja19jaXBoZXJfbW9kZV9vZl9vcGVyYXRpb24jRWxlY3Ryb25p Y19Db2RlYm9va18oRUNCKSk8L2E+LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIG90aGVyIG1vZGUgLTAzIG1lbnRpb25lZCBpcyB1 c2luZyBBRVMtQ0JDIHRvIHByb3RlY3QgdGhlIGVudGlyZSBtZXNzYWdlLiBUaGF04oCZcyBhIGNv bnZlbnRpb25hbCB1c2Ugb2YgQUVTLCBidXQgd2hlbiBBRVMtQ0JDIGlzIHVzZWQsIGJvdGggdGhl IGVuY3J5cHRvciBhbmQgZGVjcnlwdCBuZWVkIHRoZSBzYW1lIEluaXRpYWxpemF0aW9uIFZlY3Rv ciAoSVYpIHVzZWQgd2l0aCB0aGUgbWV0aG9kLiBUcmFkaXRpb25hbGx5DQogaXQgaXMgaW5jbHVk ZWQgaW4gdGhlIHBhY2tldCwgc28gdGhhdOKAmXMgYW5vdGhlciAxNiBvY3RldHMgeW91IHByb2Jh Ymx5IG5lZWQgdG8gYWRkIHRvIHRoZSBwYWNrZXQgZm9ybWF0LiBUaGlzIHNob3VsZCBOT1QgcmVw bGFjZSB0aGUgSE1BQyBmaWVsZCwgYmVjYXVzZSBjcnlwdG9ncmFwaGVycyBzdHJvbmdseSBzdGF0 ZSB0aGF0IGl0IGlzIGJhZCBwcmFjdGljZSB0byBzZW5kIGFuIHVuYXV0aGVudGljYXRlZCBlbmNy eXB0ZWQgcGFja2V0LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBkb27igJl0IHNlZSB0aGUgcmF0aW9uYWxlIGluIC0wMyBm b3IgbmVlZGluZyBjb25maWRlbnRpYWxpdHkuIFNvIGl0IG1pZ2h0IGJlIGJlc3QgdG8gc3RpY2sg d2l0aCBhbiBITUFDLVNIQTI1NiBoYXNoLCBhbmQgaWYgY29uZmlkZW50aWFsaXR5IGlzIHJlcXVp cmVkIHRvIHVzZSBhIGhpZ2hlciBsYXllciBlbmNyeXB0aW9uLiBPdGhlcndpc2UsIHlvdeKAmWxs IG5lZWQgdG8gZG8gYSBsb3QgbW9yZSBzcGVjaWZpY2F0aW9uIG9mDQogaG93IHRoZSBjb25maWRl bnRpYWxseSBpcyBkb25lIGluIHRoaXMgZHJhZnQuPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPkkgaG9wZSB0aGF0IGhlbHBzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QnJpYW48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5PbiBOb3YgNywgMjAxOCwgYXQgOToxNSBBTSwgR3JlZyBNaXJza3kgJmx0 OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIGNsYXNzPSIiPmdyZWdpbWly c2t5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0i Ij5IbyBKLklnbmFjaW8sDQo8ZGl2IGNsYXNzPSIiPnRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnQg YW5kIGhlbHBmdWwmbmJzcDtzdWdnZXN0aW9uLiBXaWxsIHJlYWQgdGhlIGRyYWZ0LWFsYXZhcmV6 LWhhbWVsaW4tdGljdG9jLXNpYyBhbmQgcmVzcG9uZCZuYnNwO2FjY29yZGluZ2x5IGluIGEgc2hv cnQgdGltZS4gRnJvbSB0aGUgcXVpY2sgcnVuIHRocm91Z2ggdGhlIGRyYWZ0LCBJIGFncmVlIHdp dGggeW91IHRoYXQgRUNEU0Egb2ZmZXJzIGFkdmFudGFnZXMgb3ZlciB0aGUgU0hBMSBvZiB0aGUm bmJzcDtzYW1lDQogbGVuZ3RoLiBKdXN0IG5lZWQgdG8gY2hlY2sgZm9yIHBvc3NpYmxlIGltcGFj dCBvbiBZQU5HIGRhdGEgbW9kZWwuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5HcmVn PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4N CjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPk9uIFdlZCwgTm92IDcsIDIwMTggYXQgMjoyNiBBTSBK IElnbmFjaW8gQWx2YXJlei1IYW1lbGluICZsdDs8YSBocmVmPSJtYWlsdG86aWhhbWVsaUBjbmV0 LmZpLnViYS5hciIgY2xhc3M9IiI+aWhhbWVsaUBjbmV0LmZpLnViYS5hcjwvYT4mZ3Q7IHdyb3Rl OjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGlu Zy1sZWZ0OjFleCI+DQpIaSBHcmVnLCA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUb2Rh eSBhdCB0aGUgSVBQTSBtZWV0aW5nIEkgc2FpZCB0aGF0IHlvdSBjb3VsZCBjb25zaWRlciB1c2lu ZyBTSEExIDI1NiB3aXRoIGJpdHMgZm9yIGF1dGhlbnRpY2F0aW9uLCB0byByZXNwZWN0IHNvbWUg c2VjdXJpdHkgc3RhbmRhcmRzLiBZb3VyIGNvbW1lbnQgdGhhdCBpcyBleHBlbnNpdmUsIGFuZCBJ IGFncmVlIHdpdGggdGhhdC4NCjxiciBjbGFzcz0iIj4NCkkgcHJvcG9zZSBhbm90aGVyIGFsdGVy bmF0aXZlLCBpcyB0aGUgb25lIHRoYXQgSSB1c2VkIGluIGRyYWZ0LWFsYXZhcmV6LWhhbWVsaW4t dGljdG9jLXNpYy0wMiwgdGhlIEVsbGlwdGljIEN1cnZlIERpZ2l0YWwgU2lnbmF0dXJlIEFsZ29y aXRobSAoRUNEU0EpLCB3aGljaCB5aWVsZHMgaW4gZmV3IGJpdHMgYW5kIGhhcyBzb21lIHNlY3Vy aXRpZXMgZm9ybSBkZSBjcnlwdG9ncmFwaGljIHBvaW50IG9mIHZpZXcuDQo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCZXN0IHdpdGhlcyw8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSi4gSWduYWNpbzxi ciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkRyLiBJbmcu IEpvc8OpIElnbmFjaW8gQWx2YXJlei1IYW1lbGluPGJyIGNsYXNzPSIiPg0KQ09OSUNFVCBhbmQg RmFjdWx0YWQgZGUgSW5nZW5pZXLDrWEsIFVuaXZlcnNpZGFkIGRlIEJ1ZW5vcyBBaXJlczxiciBj bGFzcz0iIj4NCkF2LiBQYXNlbyBDb2zDs24gODUwIC0gQzEwNjNBQ1YgLSBCdWVub3MgQWlyZXMg LSBBcmdlbnRpbmE8YnIgY2xhc3M9IiI+DQomIzQzOzU0ICgxMSkgNTI4NSAwNzE2IC8gNTI4NSAw NzA1PGJyIGNsYXNzPSIiPg0KZS1tYWlsOiA8YSBocmVmPSJtYWlsdG86aWhhbWVsaUBjbmV0LmZp LnViYS5hciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmloYW1lbGlAY25ldC5maS51YmEuYXI8 L2E+PGJyIGNsYXNzPSIiPg0Kd2ViOiA8YSBocmVmPSJodHRwOi8vY25ldC5maS51YmEuYXIvaWdu YWNpby5hbHZhcmV6LWhhbWVsaW4vIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBj bGFzcz0iIj4NCmh0dHA6Ly9jbmV0LmZpLnViYS5hci9pZ25hY2lvLmFsdmFyZXotaGFtZWxpbi88 L2E+PGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmd0OyBPbiAxNiBPY3QgMjAxOCwgYXQgMDU6MjQs IEJyaWFuIFRyYW1tZWxsIChJRVRGKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdHJhbW1lbGwu Y2giIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pZXRmQHRyYW1tZWxsLmNoPC9hPiZndDsgd3Jv dGU6PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IGhpIEdyZWcsPGJyIGNs YXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IFdlJ2xsIHB1dCB0aGlzIGFuZCBhIHRl bnRhdGl2ZSBzdGFydCBvZiBXR0xDIG9uIHRoZSBCYW5na29rIGFnZW5kYS4uPGJyIGNsYXNzPSIi Pg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IFRoYW5rcywgY2hlZXJzLDxiciBjbGFzcz0iIj4N CiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBCcmlhbjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgT24gMTYgT2N0IDIwMTgsIGF0IDAxOjAwLCBHcmVnIE1pcnNreSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEhpIEJyaWFuLDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7IG15IGFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5ZWQgcmVzcG9uc2UuIFRoZSBu ZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaGFzIGJlZW4ganVzdCB1cGxvYWRlZC4gVGhlIHVwZGF0 ZXMgaW5jbHVkZSB0aGUgbmV3IHNlY3Rpb24gdGhhdCBkZXNjcmliZXMgYXV0aGVudGljYXRpb24g YW5kIGVuY3J5cHRpb24gb3BlcmF0aW9ucyBvbiBTVEFNUCBwYWNrZXRzLiBJJ2QgcmVxdWVzdCB0 aGUgcHJlc2VudGF0aW9uIHNsb3QgYXQgdGhlIG1lZXRpbmcgYW5kLA0KIGlmIHRoZXJlIGFyZSBu byBzaWduaWZpY2FudCBjb25jZXJucywgd291bGQgYXNrIHRvIGNvbnNpZGVyIHN0YXJ0aW5nIHRo ZSBXRyBMQyBvbiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9uLiBUaGUgd29yayBvbiB0aGUgU1RBTVAg WUFORyBkYXRhIG1vZGVsIHN0aWxsIG9uLWdvaW5nIGFuZCB3ZSdyZSBhZGRyZXNzaW5nIHRoZSBj b21tZW50cyBmcm9tIHRoZSBlYXJseSBZQU5HIERvY3RvcnMgcmV2aWV3IGJ5IE1haGVzaC4gSSBl eHBlY3Qgd2UnbGwgaGF2ZQ0KIHRoZSBuZXcgdmVyc2lvbiBieSB0aGUgZW5kIG9mIE5vdmVtYmVy LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFJlZ2FyZHMs PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgR3JlZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7IE9uIFRodSwgT2N0IDQsIDIwMTggYXQgODoxMiBBTSBCcmlhbiBU cmFtbWVsbCAoSUVURikgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQHRyYW1tZWxsLmNoIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+aWV0ZkB0cmFtbWVsbC5jaDwvYT4mZ3Q7IHdyb3RlOjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7IGhpIEdyZWcsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgZm9sbG93aW5nIHVwIGEgYml0IGxhdGUsIHBlcmhhcHMuLi4gd2hl biBkbyB5b3UgdGhpbmsgdGhpcyB3aWxsIGJlIHJlYWR5IGZvciBMQz88YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBDaGVlcnMsPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgQnJpYW4gKGFzIFdHIGNvLWNoYWlyKTxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBPbiA4IFNlcCAy MDE4LCBhdCAwMDo1MywgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNr eUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsmZ3Q7IERlYXIgQWxsLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBtaW5v ciBlZGl0b3JpYWwgaW1wcm92ZW1lbnRzIHRvIHRoZSBkb2N1bWVudC4uPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsmZ3Q7IFlvdXIgY29tbWVudHMsIHF1ZXN0aW9ucywgYW5kIHN1Z2dlc3Rpb25zIGFs d2F5cyB3ZWxjb21lIGFuZCBtdWNoIGFwcHJlY2lhdGVkLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgUmVnYXJkcyw8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyZndDsgR3JlZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IEZyb206ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgRGF0ZTogRnJp LCBTZXAgNywgMjAxOCBhdCAyOjU2IFBNPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IFN1Ympl Y3Q6IFtpcHBtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDIudHh0PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aS1kLWFubm91bmNlQGlldGYub3JnPC9h PjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pcHBtQGlldGYub3JnPC9hPjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIElQIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IFdHIG9mIHRoZSBJRVRG LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzogU2ltcGxlIFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3Rv Y29sPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IEF1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBHcmVnIE1pcnNreTxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBHdW8gSnVuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IEhlbnJpayBOeWRlbGw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUmljaGFyZCBGb290ZTxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wMi50eHQ8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMTQ8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAxOC0wOS0wNzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgQWJzdHJhY3Q6PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEg U2ltcGxlIFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwO3doaWNoIGVuYWJsZXMgbWVhc3VyZW1lbnQgb2YgYm90 aCBvbmUtd2F5IGFuZCByb3VuZC10cmlwIHBlcmZvcm1hbmNlPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsmZ3Q7Jm5ic3A7ICZuYnNwO21ldHJpY3MgbGlrZSBkZWxheSwgZGVsYXkgdmFyaWF0aW9uLCBh bmQgcGFja2V0IGxvc3MuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgVGhlIElFVEYgZGF0YXRy YWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtaXBwbS1zdGFtcC8iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi Pg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHBtLXN0YW1w LzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsm Z3Q7IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtaXBwbS1zdGFtcC0wMiIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9IiI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBt LXN0YW1wLTAyPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtaXBwbS1zdGFtcC0wMiIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtaXBwbS1zdGFtcC0wMjwvYT48YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IEEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wMiIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1pcHBtLXN0YW1wLTAyPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IFBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb248YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCnRvb2xz LmlldGYub3JnPC9hPi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsmZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt b3VzIEZUUCBhdDo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7Jmd0OyBpcHBtIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0 OyA8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi PmlwcG1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbSIgcmVsPSJub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwcG08L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBpcHBtIG1haWxpbmcgbGlzdDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiIGNsYXNzPSIiPmlwcG1AaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXBwbSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG08L2E+PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyBp cHBtIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmlwcG1A aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pcHBtQGlldGYub3JnPC9hPjxiciBj bGFzcz0iIj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHBtIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbTwvYT48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KaXBwbSBtYWlsaW5n IGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgY2xhc3M9 IiI+aXBwbUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lwcG08YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4tLSZuYnNwOzxiciBjbGFzcz0i Ij4NCkJyaWFuIFdlaXM8YnIgY2xhc3M9IiI+DQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1z PGJyIGNsYXNzPSIiPg0KVGVsZXBob25lOiAmIzQzOzEgNDA4IDUyNiA0Nzk2PGJyIGNsYXNzPSIi Pg0KRW1haWw6IDxhIGhyZWY9Im1haWx0bzpiZXdAY2lzY28uY29tIiBjbGFzcz0iIj5iZXdAY2lz Y28uY29tPC9hPiA8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_F77B6597C36C483B8325AE69DE393E86ciscocom_-- From nobody Tue Nov 6 22:51:57 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2164130F29 for ; Tue, 6 Nov 2018 22:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7flBOBZ5DbD for ; Tue, 6 Nov 2018 22:51:46 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 2151D130E19 for ; Tue, 6 Nov 2018 22:51:46 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id h192so10694052lfg.3 for ; Tue, 06 Nov 2018 22:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ywaOUV8I+6+QE1S1tXMmmZjerQklqoaeOIXcumud3t4=; b=ZRpy6w5YEqQW9RC9HCuPsC7fI1TlHXNxK0l7+SldTjeyf6MkKBpdWLzjsw7b1I9mvF EAk/7cBIPhiGGz5pBSUp1RT4LmuC/qOc54B6qokwT8bElF/+irx68RUlWSPl+g7ijmRz VjZmxPQYYqvQXgP4i7zcQh6e3qsFkv1yaKk9ZVLhAyf1viLeMA6VpLP+ploHM+Orw0LO 4kci7juyHWKW5pW+FyAvhLaVUp+ZX2nA5s+uClPtJu9h2I0JRDEcFeTJQ4/Ilv7cHXxD b3YbCykL2jheo5q6D0AcUUDeBJ7Vp2/XxcYv65QgQH4TMn0czK4L8PRphtGY+7jCKWgw pPSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ywaOUV8I+6+QE1S1tXMmmZjerQklqoaeOIXcumud3t4=; b=nPfgnHE9f3XsjEVNt5B4ZIPvx9S9RTQn7xxKduoQyqJ3qTah6Oeq5d/z7mRgQ5Xv6o cS7oH7I5JoNaN0Mnmuy4XK70YVt6k84OnUCIaz5zSAELoE6PCVVqPxY4cCrVLj11QVwc 0I+qvqTrU0cX9FmlLUCGhejj3RCUGdUNgRnWK3Yf+n/doeBaAWb1gkBQjHn3QMGDM50X D3h/PffjcG0CHFagXUEWJ35+UckRHcM9HlIP2ZuIEA8NZbQhFz+DRu3RFtbZS99drrXD RQKvIXh2b1E9e9O+SeADH+quW5xmZPnm3gT+bRoWlVI50OzEJM6sMj2IcgTMkieHeYSx O/rg== X-Gm-Message-State: AGRZ1gLLyoShLwLnePxQRKxZygVKb6Jkdq4GFJ5XvI/wcpyTNZQVMKcd UlIMwaOPL0xvtwDX0hapVhwu9Cd/pFMVE8r3gQc= X-Google-Smtp-Source: AJdET5f4gTUOB53HpL5SCBp4ZhiLm1WJKEiDRaXENhPzFcTRKhSzj8Uv/J8MjjwxrozAF2Vun29watbtpHuhvv59Pxw= X-Received: by 2002:a19:e601:: with SMTP id d1mr405226lfh.71.1541573503775; Tue, 06 Nov 2018 22:51:43 -0800 (PST) MIME-Version: 1.0 References: <153635740444.28980.6908501775124770245@ietfa.amsl.com> <0861E2EE-9403-4F71-AFD7-1C89D73C773C@trammell.ch> <730E50FA-3318-43FE-9C1E-60D29B748BE0@trammell.ch> In-Reply-To: From: Greg Mirsky Date: Wed, 7 Nov 2018 13:51:34 +0700 Message-ID: To: bew@cisco.com Cc: "J. Ignacio Alvarez-Hamelin" , IETF IPPM WG Content-Type: multipart/alternative; boundary="00000000000016782e057a0d8dec" Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 06:51:55 -0000 --00000000000016782e057a0d8dec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Brian, thank you for helpful insights. As this is the WG document, we'll follow the decision of the experts that participate in the WG discussion. I like the proposal to move encryption out of the STAMP base specification as it helps in keeping timing measurements more accurate by reading the wall clock closer to the packet transmission. Dear All, please consider stating your support/no support for the following options: - for the integrity protection: - use HMAC-SHA256 truncated to 128 bits - use ECDSA truncated to 128 bits - for the confidentiality protection: - keep the current text - remove, stating it is by higher layer(s). Regards, Greg On Wed, Nov 7, 2018 at 10:50 AM Brian Weis (bew) wrote: > Hi Ignacio and Greg, > > ECDSA is a digital signature algorithm, which is very expensive and > because of this it is not traditionally used to protect network data > packets. I don=E2=80=99t recommend specifying it. Unless this is a rarel= y sent > data packet sent, you would be consuming a substantial amount of the CPU = by > applying a digital signature to every packet sent with STAMP. Also, in > order to get the value you want, you actually have to create a hash of t= he > packet (e.g., using SHA1/SHA256) and then sign the hash, where the result > will be at least the length of a full HMAC output. So you=E2=80=99re not = saving any > space. > > Using HMAC-SHA1 or SHA256 on network data packets as shown in Figure 4 is > very reasonable. Section 5 of RFC 2104 (HMAC) says how it=E2=80=99s acce= ptable to > truncate the hash output, and security protocols usually do this. IPSec > truncates HMAC-SHA-1 output to 96 bits (RFC 2404), and HMAC-SHA-256 is > truncated to 128 bits (RFC 4868). Since -03 was willing to apply a 128-b= it > truncated hash, I think you could safely specify using HMAC-SHA-256 with = a > 128 bit truncation. Note that if you specify the use of HMAC-SHA1, you wi= ll > very likely run into SecDir complaints when you get to IETF last call. > > I did mention in the IPPM meeting that adding AES support is bit more > problematic. I would recommend specifying that when confidentiality is > needed that it be done a higher layer. If you do decide to keep it in thi= s > draft, you should describe what is the value of protecting only the first > 16 octets. Also, you should know that cryptographers do not recommend usi= ng > EBC. A Wikipedia page describes this plainly: "The disadvantage of this > method is a lack of diffusion. Because ECB encrypts > identical plaintext blocks into identical ciphertext blocks, it does not > hide data patterns well. In some senses, it doesn't provide serious messa= ge > confidentiality, and it is not recommended for use in cryptographic > protocols at all.=E2=80=9D ( > https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_C= odebook_(ECB)) > . > > The other mode -03 mentioned is using AES-CBC to protect the entire > message. That=E2=80=99s a conventional use of AES, but when AES-CBC is us= ed, both > the encryptor and decrypt need the same Initialization Vector (IV) used > with the method. Traditionally it is included in the packet, so that=E2= =80=99s > another 16 octets you probably need to add to the packet format. This > should NOT replace the HMAC field, because cryptographers strongly state > that it is bad practice to send an unauthenticated encrypted packet. > > I don=E2=80=99t see the rationale in -03 for needing confidentiality. So = it might > be best to stick with an HMAC-SHA256 hash, and if confidentiality is > required to use a higher layer encryption. Otherwise, you=E2=80=99ll need= to do a > lot more specification of how the confidentially is done in this draft. > > I hope that helps. > > Brian > > On Nov 7, 2018, at 9:15 AM, Greg Mirsky wrote: > > Ho J.Ignacio, > thank you for the comment and helpful suggestion. Will read the > draft-alavarez-hamelin-tictoc-sic and respond accordingly in a short time= . > From the quick run through the draft, I agree with you that ECDSA offers > advantages over the SHA1 of the same length. Just need to check for > possible impact on YANG data model. > > Regards, > Greg > > On Wed, Nov 7, 2018 at 2:26 AM J Ignacio Alvarez-Hamelin < > ihameli@cnet.fi.uba.ar> wrote: > >> Hi Greg, >> >> Today at the IPPM meeting I said that you could consider using SHA1 256 >> with bits for authentication, to respect some security standards. Your >> comment that is expensive, and I agree with that. >> I propose another alternative, is the one that I used in >> draft-alavarez-hamelin-tictoc-sic-02, the Elliptic Curve Digital Signatu= re >> Algorithm (ECDSA), which yields in few bits and has some securities form= de >> cryptographic point of view. >> >> >> Best withes, >> >> J. Ignacio >> _______________________________________________________________ >> >> Dr. Ing. Jos=C3=A9 Ignacio Alvarez-Hamelin >> CONICET and Facultad de Ingenier=C3=ADa, Universidad de Buenos Aires >> Av. Paseo Col=C3=B3n 850 - C1063ACV - Buenos Aires - Argentina >> +54 (11) 5285 0716 / 5285 0705 >> e-mail: ihameli@cnet.fi.uba.ar >> web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ >> _______________________________________________________________ >> >> >> >> > On 16 Oct 2018, at 05:24, Brian Trammell (IETF) >> wrote: >> > >> > hi Greg, >> > >> > We'll put this and a tentative start of WGLC on the Bangkok agenda.. >> > >> > Thanks, cheers, >> > >> > Brian >> > >> >> On 16 Oct 2018, at 01:00, Greg Mirsky wrote: >> >> >> >> Hi Brian, >> >> my apologies for the delayed response. The new version of the draft >> has been just uploaded. The updates include the new section that describ= es >> authentication and encryption operations on STAMP packets. I'd request t= he >> presentation slot at the meeting and, if there are no significant concer= ns, >> would ask to consider starting the WG LC on the base specification. The >> work on the STAMP YANG data model still on-going and we're addressing th= e >> comments from the early YANG Doctors review by Mahesh. I expect we'll ha= ve >> the new version by the end of November. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Thu, Oct 4, 2018 at 8:12 AM Brian Trammell (IETF) >> wrote: >> >> hi Greg, >> >> >> >> following up a bit late, perhaps... when do you think this will be >> ready for LC? >> >> >> >> Cheers, >> >> >> >> Brian (as WG co-chair) >> >> >> >>> On 8 Sep 2018, at 00:53, Greg Mirsky wrote: >> >>> >> >>> Dear All, >> >>> minor editorial improvements to the document.. >> >>> Your comments, questions, and suggestions always welcome and much >> appreciated. >> >>> >> >>> Regards, >> >>> Greg >> >>> >> >>> ---------- Forwarded message ---------- >> >>> From: >> >>> Date: Fri, Sep 7, 2018 at 2:56 PM >> >>> Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt >> >>> To: i-d-announce@ietf.org >> >>> Cc: ippm@ietf.org >> >>> >> >>> >> >>> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >>> This draft is a work item of the IP Performance Measurement WG of th= e >> IETF. >> >>> >> >>> Title : Simple Two-way Active Measurement Protocol >> >>> Authors : Greg Mirsky >> >>> Guo Jun >> >>> Henrik Nydell >> >>> Richard Foote >> >>> Filename : draft-ietf-ippm-stamp-02.txt >> >>> Pages : 14 >> >>> Date : 2018-09-07 >> >>> >> >>> Abstract: >> >>> This document describes a Simple Two-way Active Measurement Protoc= ol >> >>> which enables measurement of both one-way and round-trip performan= ce >> >>> metrics like delay, delay variation, and packet loss. >> >>> >> >>> >> >>> The IETF datatracker status page for this draft is: >> >>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ >> >>> >> >>> There are also htmlized versions available at: >> >>> https://tools.ietf.org/html/draft-ietf-ippm-stamp-02 >> >>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-02 >> >>> >> >>> A diff from the previous version is available at: >> >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-stamp-02 >> >>> >> >>> >> >>> Please note that it may take a couple of minutes from the time of >> submission >> >>> until the htmlized version and diff are available at tools.ietf.org. >> >>> >> >>> Internet-Drafts are also available by anonymous FTP at: >> >>> ftp://ftp.ietf.org/internet-drafts/ >> >>> >> >>> _______________________________________________ >> >>> ippm mailing list >> >>> ippm@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ippm >> >>> >> >>> _______________________________________________ >> >>> ippm mailing list >> >>> ippm@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ippm >> >> >> > >> > _______________________________________________ >> > ippm mailing list >> > ippm@ietf.org >> > https://www.ietf.org/mailman/listinfo/ippm >> >> _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > -- > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > --00000000000016782e057a0d8dec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,
thank you for helpful insights. As this is t= he WG document, we'll follow the decision of the experts that participa= te in the WG discussion. I like the proposal to move encryption out of the = STAMP base specification as it helps in keeping timing measurements more ac= curate by reading the wall clock closer to the packet transmission.

Dear All,
please consider stating your support/= no support for the following options:
  • for the integrity p= rotection:
    • use HMAC-SHA256 truncated to 128 bits=C2=A0
      • =
    • use=C2=A0 ECDSA=C2=A0 truncated to 128 bits
  • for the confidentiality protection:
    • =
    • keep the current text
    • remove, stating it is by higher layer= (s).
Regards,
Greg

On Wed, Nov 7, 2018 at 10:50 AM Brian= Weis (bew) <bew@cisc= o.com> wrote:
Hi Ignacio and Greg,

ECDSA is a digital signature algorithm, which is very expensive and be= cause of this it is not traditionally used to protect network data packets.= =C2=A0 I don=E2=80=99t recommend specifying it. Unless this is a rarely sen= t data packet sent, you would be consuming a substantial amount of the CPU by applying a digital signature to every p= acket sent with STAMP. Also, in order to get the value =C2=A0you want, you = actually have to create a hash of the packet (e.g., using SHA1/SHA256) and = then sign the hash, where the result will be at least the length of a full HMAC output. So you=E2=80=99re not s= aving any space.

Using HMAC-SHA1 or SHA256 on network data packets as shown in Figure 4= is very reasonable.=C2=A0 Section 5 of RFC 2104 (HMAC) says how it=E2=80= =99s acceptable to truncate the hash output, and security protocols usually= do this.=C2=A0 IPSec truncates HMAC-SHA-1 output to 96 bits (RFC 2404), and HMAC-SHA-256 is truncated to 128 bits (R= FC 4868).=C2=A0 Since -03 was willing to apply a 128-bit truncated hash, I = think you could safely specify using HMAC-SHA-256 with a 128 bit truncation= . Note that if you specify the use of HMAC-SHA1, you will very likely run into SecDir complaints when you get to= IETF last call.

I did mention in the IPPM meeting that adding AES support is bit more = problematic. I would recommend specifying that when confidentiality is need= ed that it be done a higher layer. If you do decide to keep it in this draf= t, you should describe what is the value of protecting only the first 16 octets. Also, you should= know that cryptographers do not recommend using EBC. A Wikipedia page desc= ribes this plainly: "The disadvantage of this method is a lack of=C2= =A0diffusion. Because ECB encrypts identical=C2=A0plaintext=C2=A0blocks into identical=C2=A0ciphertext=C2=A0blocks, it=C2=A0does not hide data pat= terns well. In some senses, it doesn't provide serious message confiden= tiality, and it is not recommended for use in=C2=A0cryptographic protocols = at all.=E2=80=9D (https://en.wik= ipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_(ECB)).

The other mode -03 mentioned is using AES-CBC to protect the entire me= ssage. That=E2=80=99s a conventional use of AES, but when AES-CBC is used, = both the encryptor and decrypt need the same Initialization Vector (IV) use= d with the method. Traditionally it is included in the packet, so that=E2=80=99s another 16 octets you prob= ably need to add to the packet format. This should NOT replace the HMAC fie= ld, because cryptographers strongly state that it is bad practice to send a= n unauthenticated encrypted packet.=C2=A0

I don=E2=80=99t see the rationale in -03 for needing confidentiality. = So it might be best to stick with an HMAC-SHA256 hash, and if confidentiali= ty is required to use a higher layer encryption. Otherwise, you=E2=80=99ll = need to do a lot more specification of how the confidentially is done in this draft.

I hope that helps.

Brian


Ho J.Ignacio,
thank you for the comment and helpful=C2=A0suggestion. Will read the d= raft-alavarez-hamelin-tictoc-sic and respond=C2=A0accordingly in a short ti= me. From the quick run through the draft, I agree with you that ECDSA offer= s advantages over the SHA1 of the=C2=A0same length. Just need to check for possible impact on YANG data model.

Regards,
Greg

On Wed, Nov 7, 2018 at 2:26 AM J Ignacio Alvarez-Hamelin &= lt;ihameli@cnet= .fi.uba.ar> wrote:
Hi Greg,

Today at the IPPM meeting I said that you could consider using SHA1 256 wit= h bits for authentication, to respect some security standards. Your comment= that is expensive, and I agree with that.
I propose another alternative, is the one that I used in draft-alavarez-ham= elin-tictoc-sic-02, the Elliptic Curve Digital Signature Algorithm (ECDSA),= which yields in few bits and has some securities form de cryptographic poi= nt of view.


Best withes,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 J. Ignacio
_______________________________________________________________

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



> On 16 Oct 2018, at 05:24, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>
> hi Greg,
>
> We'll put this and a tentative start of WGLC on the Bangkok agenda= ..
>
> Thanks, cheers,
>
> Brian
>
>> On 16 Oct 2018, at 01:00, Greg Mirsky <gregimirsky@gmail.com> wrote:
>>
>> Hi Brian,
>> my apologies for the delayed response. The new version of the draf= t has been just uploaded. The updates include the new section that describe= s authentication and encryption operations on STAMP packets. I'd reques= t the presentation slot at the meeting and, if there are no significant concerns, would ask to consider starting the W= G LC on the base specification. The work on the STAMP YANG data model still= on-going and we're addressing the comments from the early YANG Doctors= review by Mahesh. I expect we'll have the new version by the end of November.
>>
>> Regards,
>> Greg
>>
>> On Thu, Oct 4, 2018 at 8:12 AM Brian Trammell (IETF) <ietf@trammell.ch> wro= te:
>> hi Greg,
>>
>> following up a bit late, perhaps... when do you think this will be= ready for LC?
>>
>> Cheers,
>>
>> Brian (as WG co-chair)
>>
>>> On 8 Sep 2018, at 00:53, Greg Mirsky <gregimirsky@gmail.com> wrote:<= br> >>>
>>> Dear All,
>>> minor editorial improvements to the document..
>>> Your comments, questions, and suggestions always welcome and m= uch appreciated.
>>>
>>> Regards,
>>> Greg
>>>
>>> ---------- Forwarded message ----------
>>> From: <internet-drafts@ietf.org>
>>> Date: Fri, Sep 7, 2018 at 2:56 PM
>>> Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt
>>> To: i-d-announce@ietf.org
>>> Cc: ippm@ie= tf.org
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts directories.
>>> This draft is a work item of the IP Performance Measurement WG= of the IETF.
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Simple Two-way Active Measurement Protocol
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Greg Mirsky
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Guo Jun
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik Nydell
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Richard Foote
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0= : draft-ietf-ippm-stamp-02.txt
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: 14
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2018-09-07
>>>
>>> Abstract:
>>>=C2=A0 =C2=A0This document describes a Simple Two-way Active Me= asurement Protocol
>>>=C2=A0 =C2=A0which enables measurement of both one-way and roun= d-trip performance
>>>=C2=A0 =C2=A0metrics like delay, delay variation, and packet lo= ss.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-ippm-stamp-02
>>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-02
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-stamp-02
>>>
>>>
>>> Please note that it may take a couple of minutes from the time= of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/ippm
>>>
>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/ippm
>>
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm

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

--=C2=A0
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com=

--00000000000016782e057a0d8dec-- From nobody Wed Nov 7 05:37:19 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B85128CF2 for ; Wed, 7 Nov 2018 05:37:17 -0800 (PST) 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 g82EzZsXddDd for ; Wed, 7 Nov 2018 05:37:14 -0800 (PST) Received: from cnet.fi.uba.ar (cnet.fi.uba.ar [157.92.58.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0991274D0 for ; Wed, 7 Nov 2018 05:37:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by cnet.fi.uba.ar (Postfix) with ESMTP id 471CD14006C; Wed, 7 Nov 2018 10:06:21 -0300 (ART) X-Virus-Scanned: Debian amavisd-new at cnet.fi.uba.ar Received: from cnet.fi.uba.ar ([127.0.0.1]) by localhost (cnet.fi.uba.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJmByZ8EEs8L; Wed, 7 Nov 2018 10:06:13 -0300 (ART) Received: from [192.168.1.136] (unknown [157.92.51.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by cnet.fi.uba.ar (Postfix) with ESMTPSA id B69C9140068; Wed, 7 Nov 2018 10:06:13 -0300 (ART) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: J Ignacio Alvarez-Hamelin In-Reply-To: Date: Wed, 7 Nov 2018 10:36:50 -0300 Cc: IETF IPPM WG Content-Transfer-Encoding: quoted-printable Message-Id: <63C8B8A4-8C46-438A-BCA8-F0E10E76D53B@cnet.fi.uba.ar> References: <153635740444.28980.6908501775124770245@ietfa.amsl.com> <0861E2EE-9403-4F71-AFD7-1C89D73C773C@trammell.ch> <730E50FA-3318-43FE-9C1E-60D29B748BE0@trammell.ch> To: Greg Mirsky , "Brian Weis (bew)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Nov 2018 13:37:17 -0000 Thanks Brian for your useful comments about ECDSA used on some type of = hardware (in my case it doesn=E2=80=99t matter because they are = endpoints and the signature is done in a deferred mode to not interfere = with the clock synchronization process). Thanks Greg for your solution.=20 Best, J. Ignacio _______________________________________________________________ Dr. Ing. Jos=C3=A9 Ignacio Alvarez-Hamelin CONICET and Facultad de Ingenier=C3=ADa, Universidad de Buenos Aires Av. Paseo Col=C3=B3n 850 - C1063ACV - Buenos Aires - Argentina +54 (11) 5285 0716 / 5285 0705 e-mail: ihameli@cnet.fi.uba.ar web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ _______________________________________________________________ > On 7 Nov 2018, at 03:51, Greg Mirsky wrote: >=20 > Hi Brian, > thank you for helpful insights. As this is the WG document, we'll = follow the decision of the experts that participate in the WG = discussion. I like the proposal to move encryption out of the STAMP base = specification as it helps in keeping timing measurements more accurate = by reading the wall clock closer to the packet transmission. >=20 > Dear All, > please consider stating your support/no support for the following = options: > =E2=80=A2 for the integrity protection: > =E2=80=A2 use HMAC-SHA256 truncated to 128 bits=20 > =E2=80=A2 use ECDSA truncated to 128 bits > =E2=80=A2 for the confidentiality protection: > =E2=80=A2 keep the current text > =E2=80=A2 remove, stating it is by higher layer(s). > Regards, > Greg >=20 > On Wed, Nov 7, 2018 at 10:50 AM Brian Weis (bew) = wrote: > Hi Ignacio and Greg, >=20 > ECDSA is a digital signature algorithm, which is very expensive and = because of this it is not traditionally used to protect network data = packets. I don=E2=80=99t recommend specifying it. Unless this is a = rarely sent data packet sent, you would be consuming a substantial = amount of the CPU by applying a digital signature to every packet sent = with STAMP. Also, in order to get the value you want, you actually have = to create a hash of the packet (e.g., using SHA1/SHA256) and then sign = the hash, where the result will be at least the length of a full HMAC = output. So you=E2=80=99re not saving any space. >=20 > Using HMAC-SHA1 or SHA256 on network data packets as shown in Figure 4 = is very reasonable. Section 5 of RFC 2104 (HMAC) says how it=E2=80=99s = acceptable to truncate the hash output, and security protocols usually = do this. IPSec truncates HMAC-SHA-1 output to 96 bits (RFC 2404), and = HMAC-SHA-256 is truncated to 128 bits (RFC 4868). Since -03 was willing = to apply a 128-bit truncated hash, I think you could safely specify = using HMAC-SHA-256 with a 128 bit truncation. Note that if you specify = the use of HMAC-SHA1, you will very likely run into SecDir complaints = when you get to IETF last call. >=20 > I did mention in the IPPM meeting that adding AES support is bit more = problematic. I would recommend specifying that when confidentiality is = needed that it be done a higher layer. If you do decide to keep it in = this draft, you should describe what is the value of protecting only the = first 16 octets. Also, you should know that cryptographers do not = recommend using EBC. A Wikipedia page describes this plainly: "The = disadvantage of this method is a lack of diffusion. Because ECB encrypts = identical plaintext blocks into identical ciphertext blocks, it does not = hide data patterns well. In some senses, it doesn't provide serious = message confidentiality, and it is not recommended for use in = cryptographic protocols at all.=E2=80=9D = (https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_C= odebook_(ECB)). >=20 > The other mode -03 mentioned is using AES-CBC to protect the entire = message. That=E2=80=99s a conventional use of AES, but when AES-CBC is = used, both the encryptor and decrypt need the same Initialization Vector = (IV) used with the method. Traditionally it is included in the packet, = so that=E2=80=99s another 16 octets you probably need to add to the = packet format. This should NOT replace the HMAC field, because = cryptographers strongly state that it is bad practice to send an = unauthenticated encrypted packet.=20 >=20 > I don=E2=80=99t see the rationale in -03 for needing confidentiality. = So it might be best to stick with an HMAC-SHA256 hash, and if = confidentiality is required to use a higher layer encryption. Otherwise, = you=E2=80=99ll need to do a lot more specification of how the = confidentially is done in this draft. >=20 > I hope that helps. >=20 > Brian >=20 >> On Nov 7, 2018, at 9:15 AM, Greg Mirsky = wrote: >>=20 >> Ho J.Ignacio, >> thank you for the comment and helpful suggestion. Will read the = draft-alavarez-hamelin-tictoc-sic and respond accordingly in a short = time. =46rom the quick run through the draft, I agree with you that = ECDSA offers advantages over the SHA1 of the same length. Just need to = check for possible impact on YANG data model. >>=20 >> Regards, >> Greg >>=20 >> On Wed, Nov 7, 2018 at 2:26 AM J Ignacio Alvarez-Hamelin = wrote: >> Hi Greg,=20 >>=20 >> Today at the IPPM meeting I said that you could consider using SHA1 = 256 with bits for authentication, to respect some security standards. = Your comment that is expensive, and I agree with that.=20 >> I propose another alternative, is the one that I used in = draft-alavarez-hamelin-tictoc-sic-02, the Elliptic Curve Digital = Signature Algorithm (ECDSA), which yields in few bits and has some = securities form de cryptographic point of view.=20 >>=20 >>=20 >> Best withes, >>=20 >> J. Ignacio >> _______________________________________________________________ >>=20 >> Dr. Ing. Jos=C3=A9 Ignacio Alvarez-Hamelin >> CONICET and Facultad de Ingenier=C3=ADa, Universidad de Buenos Aires >> Av. Paseo Col=C3=B3n 850 - C1063ACV - Buenos Aires - Argentina >> +54 (11) 5285 0716 / 5285 0705 >> e-mail: ihameli@cnet.fi.uba.ar >> web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ >> _______________________________________________________________ >>=20 >>=20 >>=20 >> > On 16 Oct 2018, at 05:24, Brian Trammell (IETF) = wrote: >> >=20 >> > hi Greg, >> >=20 >> > We'll put this and a tentative start of WGLC on the Bangkok = agenda.. >> >=20 >> > Thanks, cheers, >> >=20 >> > Brian >> >=20 >> >> On 16 Oct 2018, at 01:00, Greg Mirsky = wrote: >> >>=20 >> >> Hi Brian, >> >> my apologies for the delayed response. The new version of the = draft has been just uploaded. The updates include the new section that = describes authentication and encryption operations on STAMP packets. I'd = request the presentation slot at the meeting and, if there are no = significant concerns, would ask to consider starting the WG LC on the = base specification. The work on the STAMP YANG data model still on-going = and we're addressing the comments from the early YANG Doctors review by = Mahesh. I expect we'll have the new version by the end of November. >> >>=20 >> >> Regards, >> >> Greg >> >>=20 >> >> On Thu, Oct 4, 2018 at 8:12 AM Brian Trammell (IETF) = wrote: >> >> hi Greg, >> >>=20 >> >> following up a bit late, perhaps... when do you think this will be = ready for LC? >> >>=20 >> >> Cheers, >> >>=20 >> >> Brian (as WG co-chair) >> >>=20 >> >>> On 8 Sep 2018, at 00:53, Greg Mirsky = wrote: >> >>>=20 >> >>> Dear All, >> >>> minor editorial improvements to the document.. >> >>> Your comments, questions, and suggestions always welcome and much = appreciated. >> >>>=20 >> >>> Regards, >> >>> Greg >> >>>=20 >> >>> ---------- Forwarded message ---------- >> >>> From: >> >>> Date: Fri, Sep 7, 2018 at 2:56 PM >> >>> Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt >> >>> To: i-d-announce@ietf.org >> >>> Cc: ippm@ietf.org >> >>>=20 >> >>>=20 >> >>>=20 >> >>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >> >>> This draft is a work item of the IP Performance Measurement WG of = the IETF. >> >>>=20 >> >>> Title : Simple Two-way Active Measurement = Protocol >> >>> Authors : Greg Mirsky >> >>> Guo Jun >> >>> Henrik Nydell >> >>> Richard Foote >> >>> Filename : draft-ietf-ippm-stamp-02.txt >> >>> Pages : 14 >> >>> Date : 2018-09-07 >> >>>=20 >> >>> Abstract: >> >>> This document describes a Simple Two-way Active Measurement = Protocol >> >>> which enables measurement of both one-way and round-trip = performance >> >>> metrics like delay, delay variation, and packet loss. >> >>>=20 >> >>>=20 >> >>> The IETF datatracker status page for this draft is: >> >>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ >> >>>=20 >> >>> There are also htmlized versions available at: >> >>> https://tools.ietf.org/html/draft-ietf-ippm-stamp-02 >> >>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-02 >> >>>=20 >> >>> A diff from the previous version is available at: >> >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-stamp-02 >> >>>=20 >> >>>=20 >> >>> Please note that it may take a couple of minutes from the time of = submission >> >>> until the htmlized version and diff are available at = tools.ietf.org. >> >>>=20 >> >>> Internet-Drafts are also available by anonymous FTP at: >> >>> ftp://ftp.ietf.org/internet-drafts/ >> >>>=20 >> >>> _______________________________________________ >> >>> 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 >> >>=20 >> >=20 >> > _______________________________________________ >> > 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 >=20 > --=20 > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com >=20 From nobody Thu Nov 8 00:37:11 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BC3130DCC; Thu, 8 Nov 2018 00:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 x6O_soDG8QMN; Thu, 8 Nov 2018 00:36:57 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D41F1293FB; Thu, 8 Nov 2018 00:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67502; q=dns/txt; s=iport; t=1541666217; x=1542875817; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bvTgFSUFdKaApoHnHvvJxIGFtoWbdkgkoGneL0o94ps=; b=gBD4LX2nlT2VTpYMww4mfNF7F8r4zT9aXPkZVds1SUQEaylWYQg0YIYZ IOrYUErk4YjDLWYm0geTwTN0YQ/T/ZxCuZGhjJgr8LJD3s87d3Cj5x4RV X4vW/MNZ8shep+au2ufABFS63fB9Kd5qAlZQplbHodAIzGZA84udSAurZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADj9ONb/4QNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ12ZoECJwqDbogYjgiJBI4uFIFmCwE?= =?us-ascii?q?BGAEMhEcCF4J4IjQNDQEDAQECAQECbRwMhToBAQEBAwEBIQocHgcLDAQCAQg?= =?us-ascii?q?RBAEBASABBgMCAgIfBgsUCQgCBA4FCBODB4EdTAMVD6d1gS6ELQEDAgINGIM?= =?us-ascii?q?0DYIZikaBMxeBQT+BEYMSglYhJAEBA4E3Dy8fCIJGglcCiQUKLAOFKoFbhFK?= =?us-ascii?q?JWicuCQKGbYZ5gyIggiOORo0fgQSJJQIRFIEmHTiBVXAVO4JsCYIeF4gjO4U?= =?us-ascii?q?+QTGLFIEugR8BAQ?= X-IronPort-AV: E=Sophos;i="5.54,478,1534809600"; d="scan'208,217";a="198175056" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2018 08:36:56 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id wA88auSK021133 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Nov 2018 08:36:56 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 8 Nov 2018 02:36:55 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1395.000; Thu, 8 Nov 2018 02:36:55 -0600 From: "Frank Brockners (fbrockne)" To: Mark Smith CC: "C. M. Heard" , 6man WG , "ippm@ietf.org" Thread-Topic: v6 option types for IOAM data fields Thread-Index: AQHUb5iXbX4MUs3YyEqKVf0LZIK86aU2jG5ggACUzgCADm05gA== Date: Thu, 8 Nov 2018 08:36:55 +0000 Message-ID: References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> In-Reply-To: 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.68.220.1] Content-Type: multipart/alternative; boundary="_000_f50040ab52d04867b9a5cefa1c3131c3XCHRCD008ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [ippm] v6 option types for IOAM data fields X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 08:37:03 -0000 --_000_f50040ab52d04867b9a5cefa1c3131c3XCHRCD008ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyaywgTWlrZSwNCg0KdGhhbmtzIGZvciBzdW1tYXJpemluZyB0aGUgY29uY2VybnMgYXJv dW5kIGxlYWtlZCBwYWNrZXRzIOKAkyBhbmQgb3V0bGluaW5nIGFuIGFwcHJvYWNoIHRvIG1pdGln YXRlIHRob3NlLiBUaGVyZSBhcmUgYSBjb3VwbGUgb2Ygb3RoZXIgY2hhbGxlbmdlcyB3ZSBmYWNl LiBVbmZvcnR1bmF0ZWx5IHdlIGRpZCBub3QgZ2V0IHRvIGEgZGlzY3Vzc2lvbiBpbiB0aGUgNm1h biBXRyBtZWV0aW5nIHRoaXMgdGltZSBkdWUgdG8gdGhlIGxpbWl0ZWQgdGltZSB3ZSBoYWQuIFRo ZSBtZWV0aW5nIHNsaWRlcyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAz L21hdGVyaWFscy9zbGlkZXMtMTAzLTZtYW4taW4tc2l0dS1vYW0taXB2Ni1vcHRpb25zLTAwIHBy b3ZpZGUgYSBzdW1tYXJ5IG9mIGNvbmNlcm5zLg0KDQpJbiBhIG51dHNoZWxsOg0KDQoxLiAgICAg ICBQb3RlbnRpYWwgSGJIIGV4dCBoZWFkZXIgYW5kIElPQU0gb3B0aW9uIGluc2VydGlvbiBhbmQg cmVtb3ZhbCBieSB0cmFuc2l0IG5vZGVzIChpLmUuIOKAnGVuIHJvdXRl4oCdKSBpbiBhIHJlc3Ry aWN0ZWQgYWRtaW5pc3RyYXRpdmUgZG9tYWluLg0KDQphKSAgICAgICBIb3cgZG8geW91IGRlYWwg d2l0aCBQTVRVPyDigJMgUGFja2V0IHNpemUgY2hhbmdlcyBtaWdodCBleGNlZWQgUE1UVS4NCg0K YikgICAgICBNaXNsZWFkaW5nIElDTVAgZXJyb3JzIGNvbmZ1c2luZyB0aGUgc291cmNlDQoNCmMp ICAgICAgIFBvc3NpYmxlIGxlYWtzIHRoYXQgYWZmZWN0IHRoZSBmb3J3YXJkaW5nIGJlaGF2aW9y IGFuZCBzdGF0ZSBvZiBuZXR3b3JrIGVsZW1lbnRzIG91dHNpZGUgdGhlIGRvbWFpbi4NCg0KMi4g ICAgICAgSW5jcmVtZW50YWwgVHJhY2UgSU9BTSBIYkggT3B0aW9uIOKAkyB3aGljaCBpcyB0byBz dXBwb3J0IGEgaGFyZHdhcmUtZnJpZW5kbHkgaW1wbGVtZW50YXRpb246IENoYW5nZXMgT3B0aW9u IERhdGEgTGVuIGVuLXJvdXRlLg0KDQphKSAgICAgICBEZWFsaW5nIHdpdGggUE1UVeKAkyBQYWNr ZXQgc2l6ZSBjaGFuZ2VzIGNhbiBleGNlZWQgUE1UVTsgc2VlIGFib3ZlDQoNCjMuICAgICAgIENs YXJpZnkgYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgYW5kIHNjb3BlDQoNCldoaWxlIDMuIGlzIHNv bWV0aGluZyB0aGF0IGlzIGluIHRoZSB3b3JrcywgdGhlcmUgYXJlIG5vIGVhc3kgYW5zd2VycyB0 byAxLiBhbmQgMi4gQ29uc2lkZXJhdGlvbnM6DQoNCk9uIDEuIFN1cHBvcnRpbmcgSGJIIGV4dCBo ZWFkZXIgYW5kIG9wdGlvbiBpbnNlcnRpb24vcmVtb3ZhbCBpbiB0cmFuc2l0LiBBIGNvdXBsZSBv ZiBzb2x1dGlvbiBhcHByb2FjaGVz4oCmDQoNCjEuICAgICAgIEZpeCBQTVRVIGFuZCBvZmZzZXQg Zm9yIHBhY2tldCBzaXplIGNoYW5nZSBpbiBQTVRVIGRpc2NvdmVyeSAtIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC10cm9hbi02bWFuLXBtdHUtc29sdXRpb24tc3BhY2UtMDANCkhv cGUgdGhhdCB3ZSBjYW4gbWFrZSBwcm9ncmVzcyB0b3dhcmRzIGEgc29sdXRpb24gdG9tb3Jyb3fi gKYNCg0KMi4gICAgICAgSVAtaW4tSVAgd2l0aCBJT0FNIGV4dGVuc2lvbiBoZWFkZXIgaW4gdGhl ICppbm5lciogcGFja2V0Lg0KTmV3IElQdjYgcGFja2V0IGlzIGNyZWF0ZWQgd2l0aCBlbmNhcHN1 bGF0aW5nIG5vZGUgYXMgc291cmNlIGFuZCB0aGUgb3JpZ2luYWwgZGVzdGluYXRpb24gYXMgdGhl IGRlc3RpbmF0aW9uDQoodGhpcyBpcyBzbGlnaHRseSBkaWZmZXJlbnQgdGhhbiB3aGF0IHlvdSwg TWFyaywgc3VnZ2VzdCDigJMgYmVjYXVzZSB3ZeKAmWQgbGlrZSB0byBrZWVwIHRoZSBmb3J3YXJk aW5nIHBhdGggdGhlIHNhbWUuIFR1bm5lbGluZyB3aXRoIFVMQSB3b3VsZCBub3QgZ2V0IHVzIHRo ZXJlOyB0aGUgc2xpZGVzIGFib3ZlIGhhdmUgYSBkaWFncmFtIHRoYXQgZGVwaWN0cyB0aGUgcG90 ZW50aWFsIGVuY2FwKToNCg0KYSkgICAgICAgUGF5bG9hZCBvZiB0aGlzIHBhY2tldCBpcyB0aGUg b3JpZ2luYWwgSVB2NiBwYWNrZXQgYWxvbmcgd2l0aCBhbiBleHRlbnNpb24gaGVhZGVyIGluc2Vy dGVkIGluc2lkZS4NCg0KYikgICAgICBUaGUgb3JpZ2luYWwgcGFja2V0IGlzIHJlc3RvcmVkIGJ5 IHJlbW92aW5nIHRoZSBvdXRlciBJUHY2IGhlYWRlciBhbmQgdGhlIGlubmVyIGV4dGVuc2lvbiBo ZWFkZXIgYnkgYSBub2RlIGF0IHRoZSBkb21haW4gYm91bmRhcnkuDQoNCmMpICAgICAgIENhdmVh dHM6DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGkuICAgICAgTW9kaWZpZWQgcGFja2V0IG1heSBzdGlsbCBsZWFrIOKAkyBi dXQgd2lsbCBvbmx5IGNvbmZ1c2UgdGhlIGRlc3RpbmF0aW9uIG5vZGUuIFRoZSBkZXN0IG5vZGUg d2lsbCBsaWtlbHkgc2VuZCBhbiBJQ01QIGJhY2sgdG8gdGhlIGVuY2FwIG5vZGUsIHdoaWNoIGdl dHMgdGhlIGVuY2FwIG5vZGUgYW4gdW5kZXJzdGFuZGluZyB0aGF0IHNvbWV0aGluZyBpcyBnb2lu ZyB3cm9uZy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGlpLiAgICAgIEVDTVAgY29tcHV0YXRpb24gbmVlZHMgdG8gYmUgcmV3 b3JrZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaWlpLiAgICAgIENvbXBsZXgvY29zdGx5IGltcGxlbWVudGF0aW9uIGluIEhX ICYgU1cg4oCTIElPQU0tY2FwYWJsZSBub2RlcyBuZWVkIHRvIGh1bnQgZm9yIHRoZSBJT0FNIGRh dGEgZmllbGRzIGluIHRoZSBpbm5lciBwYWNrZXQuDQoNCjMuICAgICAgIE5vIHN1cHBvcnQgb2Yg SU9BTSBpbiB0cmFuc2l0IG5ldHdvcmsuIFN1cHBvcnQgb25seSBzb3VyY2UgaW5pdGlhdGVkIElP QU0gdHJhY2luZywgcHJvb2Ygb2YgdHJhbnNpdC4uDQpDYXZlYXQ6IExpbWl0cyB1c2FnZSBvZiBJ T0FNIHNpZ25pZmljYW50bHkuDQoNCk9uIDIuIEluY3JlbWVudGFsIFRyYWNlIElPQU0gSGJIIE9w dGlvbg0KDQoxLiAgICAgICBVc2UgUE1UVSB0byBkZXRlcm1pbmUgbWF4IHBvc3NpYmxlIEluY3Jl bWVudGFsIFRyYWNlIElPQU0gT3B0aW9uIGxlbmd0aA0KDQoyLiAgICAgICBEbyBub3Qgc3VwcG9y dCBJbmNyZW1lbnRhbCBUcmFjZSBJT0FNIE9wdGlvbiBpbiBJUHY2Lg0KDQpXaGlsZSB0aGVyZSBp c27igJl0IGFuIGVhc3kgYW5zd2VyLCBJTUhPIHdlIHNob3VsZCBzdGlsbCB0cnkgdG8gZmluZCBh IHdvcmthYmxlIGFuZCBpbXBsZW1lbnRhYmxlIHNvbHV0aW9uLiBJIHNvbWV0aW1lcyBjb21wYXJl IHRoZSBzaXR1YXRpb24gd2l0aCB0aGUgcm9hZCBuZXR3b3JrOiBXaGF0IHdlIGhhdmUgdG9kYXkg aXMgYSBuZXR3b3JrIG9mIGdyYXZlbCByb2FkcyAoSW50ZXJuZXQgd2l0aCBvZnRlbiBwb29yIGV4 dCBoZWFkZXIgcHJvY2Vzc2luZykgYW5kIGNhcnMgYXJlIGJ1aWx0IHRvIGNvcGUgd2l0aCBncmF2 ZWwgcm9hZHMuIE5vdyBmYXN0ZXIgYW5kIGNvbWZ5IGNhcnMgYmVjb21lIGF2YWlsYWJsZSwgdGhv dWdoIHRoZXkgb25seSB3b3JrIG9uIHRhcmVkL2NvbmNyZXRlIHJvYWRzIChzcGVjaWZpYyBhZG1p bmlzdHJhdGl2ZSBkb21haW5zKS4gSWYgeW91IHRyeSB0byBkcml2ZSB0aGVzZSBuZXcgY2FycyBv biBncmF2ZWwgcm9hZHMgdGhleSBicmVhayBhbmQgdGhlIHdyZWNrcyBqYW0gdGhlIHJvYWRz4oCm LCBzdGlsbCB3ZSBwcm9iYWJseSB3YW50IHRvIGFsbG93IGZvbGtzIHRvIGJ1eSBhbmQgdXNlIHRo ZSBmYXN0ICYgY29tZnkgY2FycywgYmVjYXVzZSB0aGV5IHdpbGwgYWxzbyBwdXNoIGZvciBiZXR0 ZXIgcm9hZHMgIGFzIHdlbGwgKGRvIHByb3BlciBleHQgaGVhZGVyIHByb2Nlc3NpbmcpLg0KDQpU aG91Z2h0cz8NCg0KVGhhbmtzLCBGcmFuaw0KDQoNCkZyb206IE1hcmsgU21pdGggPG1hcmt6enpz bWl0aEBnbWFpbC5jb20+DQpTZW50OiBEaWVuc3RhZywgMzAuIE9rdG9iZXIgMjAxOCAwNToyNg0K VG86IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxmYnJvY2tuZUBjaXNjby5jb20+DQpDYzog Qy4gTS4gSGVhcmQgPGhlYXJkQHBvYm94LmNvbT47IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+OyBp cHBtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogdjYgb3B0aW9uIHR5cGVzIGZvciBJT0FNIGRhdGEg ZmllbGRzDQoNCg0KSGkgRnJhbmssDQoNCk9uIFR1ZS4sIDMwIE9jdC4gMjAxOCwgMDU6MzYgRnJh bmsgQnJvY2tuZXJzIChmYnJvY2tuZSksIDxmYnJvY2tuZUBjaXNjby5jb208bWFpbHRvOmZicm9j a25lQGNpc2NvLmNvbT4+IHdyb3RlOg0KVGhhbmtzIE1pa2UuIE9uIHRoZSBzY29wZSBvZiBhbiBJ T0FNIGRlcGxveW1lbnQ6DQpkcmFmdC1pZXRmLWlwcG0taW9hbS1kYXRhLTA0IGNsYXJpZmllcyBp biBzZWN0aW9uIDMgdGhhdCBJT0FNIGlzIGEgZG9tYWluIGZvY3VzZWQgZmVhdHVyZSwgaS5lLiBu b3QgZXhwZWN0ZWQgdG8gYmUgZGVwbG95ZWQgb24gdGhlIG9wZW4gSW50ZXJuZXQuDQoNClRoYXQg c3RpbGwgdmlvbGF0ZXMgUkZDIDgyMDAsIHRoZXJlIGFyZSBubyBleGNlcHRpb25zIGZvciAiY2xv c2VkIiBkb21haW5zLg0KDQpGcm9tIHNlY3Rpb24gMzoNCg0KIkRlc2lnbmVycyBvZg0KICAgY2Fy cmllciBwcm90b2NvbHMgZm9yIElPQU0gbXVzdCBzcGVjaWZ5IG1lY2hhbmlzbXMgdG8gZW5zdXJl IHRoYXQNCiAgIElPQU0gZGF0YSBzdGF5cyB3aXRoaW4gYW4gSU9BTSBkb21haW4uICBJbiBhZGRp dGlvbiwgdGhlIG9wZXJhdG9yIG9mDQogICBzdWNoIGEgZG9tYWluIGlzIGV4cGVjdGVkIHRvIHB1 dCBwcm92aXNpb25zIGluIHBsYWNlIHRvIGVuc3VyZSB0aGF0DQogICBJT0FNIGRhdGEgZG9lcyBu b3QgbGVhayBiZXlvbmQgdGhlIGVkZ2Ugb2YgYW4gSU9BTSBkb21haW4sIGUuZy4gdXNpbmcNCiAg IGZvciBleGFtcGxlIHBhY2tldCBmaWx0ZXJpbmcgbWV0aG9kcy4iDQoNCk5laXRoZXIgdGhlIGRl c2lnbmVycyBvciB0aGUgb3BlcmF0b3JzIGNhbiBlbnN1cmUgdGhpcyBJT0FNIGluZm9ybWF0aW9u IHdvbid0IGxlYWsuDQoNClBvc3NpYmxlIHJlYXNvbnMgaXQgY2FuIGxlYWs6DQoNCi0gb3BlcmF0 b3IgY29uZmlndXJhdGlvbiBlcnJvciAtIGUuZy4gZm9yZ2V0dGluZyB0byBjb25maWd1cmUgdGhl IGRvbWFpbiBib3VuZGFyeSAoZS5nLiByb3V0ZXIgd2l0aCBtdWx0aXBsZSBkb21haW4gZXhpdCBp bnRlcmZhY2VzLCBmb3JnZXR0aW5nIHRvIGFkZCB0aGF0IG9wdGlvbiBvbiBvbmUgb2YgdGhlbSks IG9yIG1pc2NvbmZpZ3VyaW5nIGl0Lg0KDQotIHBhcnRpYWwgZGV2aWNlIGZhaWx1cmUgLSB0aGUg ZGV2aWNlIHN0aWxsIGZvcndhcmRzIHBhY2tldHMsIGJ1dCBjZWFzZXMgdG8gcmVtb3ZlIHRoaXMg aW5mb3JtYXRpb24gZHVlIHRvIGEgaGFyZHdhcmUgZmF1bHQgdGhhdCBoYXMgYXBwZWFyZWQNCg0K LSB2ZW5kb3IgaW1wbGVtZW50YXRpb24gYnVncyB0aGF0IGZhaWxzIHRvIHJlbW92ZSB0aGUgaW5m b3JtYXRpb24uDQoNCkFueSBvciBhbGwgb2YgdGhlc2UgY2FuIG9jY3VyLCBhbmQgYXMgaXQgaXMg b24gZWdyZXNzLCB0aGUgY29uc2VxdWVuY2VzIG1heSBub3QgYmUgdmlzaWJsZSB0byB0aGUgZG9t YWluIG5ldHdvcmsgb3BlcmF0b3IsIGJlY2F1c2UgbmV0d29yayBvcGVyYXRvcnMgcmFyZWx5IGlu c3BlY3QgcGFja2V0cyBhZnRlciB0aGV5J3ZlIGxlZnQgdGhlaXIgbmV0d29yay4gT25jZSBhIHBh Y2tldCBpcyBzZW50IG9udG8gc29tZWJvZHkgZWxzZSwgaXQgaXMgYXNzdW1lZCB0byBoYXZlIGJl ZW4gc2VudCB3aXRob3V0IGZhdWx0cy4NCg0KVGhlcmUgYXJlIG1hbnkgaW5zdGFuY2VzIG9mIGxl YWtzIGF0IHRoZSBib3VuZGFyeSBvZiB3aGF0IGFyZSBzdXBwb3NlZCB0byBiZSBjbG9zZWQgZG9t YWlucywgc3VjaCBhcyBwYWNrZXRzIGNvbnRhaW5pbmcgUkZDMTkxOCBwcml2YXRlIGFkZHJlc3Nl cyAoaW4gcGFja2V0IGhlYWRlcnMgdGhlbXNlbHZlcywgb3IgaW4gRE5TIHBhY2tldHMgLSBzdWNo IGEgYmlnIHByb2JsZW0gdGhhdCB3d3cuYXMxMTIubmV0PGh0dHA6Ly9hczExMi5uZXQ+IHdhcyBj cmVhdGVkKSwgYW5kIHJvdXRlIGxlYWtzIGUuZy4gaHR0cHM6Ly9iZ3Btb24ubmV0L2hvdy10aGUt aW50ZXJuZXQtaW4tYXVzdHJhbGlhLXdlbnQtZG93bi11bmRlci8NCg0KQXMgb3BlcmF0b3JzIHVz dWFsbHkgaGF2ZSBvbmx5IG9uZSBkZXZpY2UgYXQgdGhlIGVkZ2Ugb2YgdGhlIGRvbWFpbiwgdGhh dCB3b3VsZCBiZSBwZXJmb3JtaW5nIHRoZSBkb21haW4gYm91bmRhcnkgZnVuY3Rpb24sIHRoYXQg ZGV2aWNlIGJlY29tZXMgYSBzaW5nbGUgcG9pbnQgb2YgZmFpbHVyZS4gRW5mb3JjZW1lbnQgaXMg dGhlcmVmb3JlIHF1aXRlIGZyYWdpbGUuIEEgZG9tYWluIGJvdW5kYXJ5IGVuZm9yY2VkIGJ5IHR3 byBkb21haW4gZWRnZSBkZXZpY2VzIGluLWxpbmUgd291bGQgaW5jcmVhc2Ugcm9idXN0bmVzcywg aG93ZXZlciBJJ2QgdGhpbmsgdGhhdCB3b3VsZCBiZSByYXJlbHkgZGVwbG95ZWQsIGJlY2F1c2Ug d2UgaGF2ZW4ndCBzZWVuIHRoYXQgY29tbW9ubHkgd2l0aCBJUHY0IE5BVC4NCg0KVGhlIG9ubHkg d2F5IGZvciBhbiBvcGVyYXRvciB0byBlbnN1cmUgdGhlc2UgbGVha3MgZG9uJ3QgYW5kIG5ldmVy IG9jY3VyIGlzIGZvciB0aGUgZG9tYWluIHRvIGxpdGVyYWxseSBub3QgYmUgcGh5c2ljYWxseSBj b25uZWN0ZWQgdG8gdGhlIEludGVybmV0IGkuZS4gdGhlIGRvbWFpbiBpcyBhaXIgZ2FwcGVkIGZy b20gdGhlIEludGVybmV0LiBJZiB0aGVyZSBpcyBhIGxpbmsgYmV0d2VlbiB0aGUgZG9tYWluIGFu ZCB0aGUgSW50ZXJuZXQgdGhhdCBjYW4gY2FycnkgSVAgcGFja2V0cywgdGhlbiB0aGVyZSBpcyBh bHdheXMgYSBwb3NzaWJpbGl0eSB0aGF0IGluZm9ybWF0aW9uIGNhbiBsZWFrIGZyb20gdGhlIGRv bWFpbi4NCg0KU28gYWNjZXB0aW5nIHRoYXQgbGVha3MgY2FuIGFsd2F5cyBvY2N1ciwgYSBmYXIg bW9yZSByb2J1c3Qgb3B0aW9uIGlzIHRvIGxlYXZlIHRoZSBvcmlnaW5hbCBwYWNrZXQgYWxvbmUg ZW50aXJlbHksIGFuZCBlbmNhcHN1bGF0ZSBpdCBpbiBhIGRvbWFpbiBsb2NhbCBJUHY2IGhlYWRl ciAoaS5lIFJGQzI0NzMsIHNlY3Rpb24gMy4xKSB3aXRoIGRvbWFpbiBsb2NhbCBsaW1pdGVkIGFk ZHJlc3NlcyAoaS5lLiBVTEEgYWRkcmVzc2VzKSBhbmQgdGhlIGFkZGl0aW9uYWwgRUguDQoNClRo YXQgc3RpbGwgZG9lc24ndCBlbnN1cmUgdGhhdCBwYWNrZXQgd29uJ3QgbGVhayBvdXRzaWRlIHRo ZSBkb21haW4sIGJlY2F1c2UgdGhvc2UgcGFja2V0cyB3aWxsIGZvbGxvdyBhIGRlZmF1bHQgcm91 dGUsIGhvd2V2ZXIgYXMgdGhlIHBhY2tldCdzIGFkZHJlc3NpbmcgaXMgaW52YWxpZCBvdXRzaWRl IG9mIHRoZSBkb21haW4sIHRoYXQgcGFja2V0IHdpbGwgYmUgZHJvcHBlZCBvbmNlIGl0IHJlYWNo ZXMgZWl0aGVyIGFuIGludmFsaWQgSW50ZXJuZXQgYWRkcmVzcyBmaWx0ZXIsIG9yIGEgZGVmYXVs dCBmcmVlIEludGVybmV0IHJvdXRlci4gVGhlIHBhY2tldCB3aXRoIHRoZSBmYWlsZWQtdG8tYmUt cmVtb3ZlZCBvdXRlciBVTEEgSVB2NiBoZWFkZXIgd2lsbCBuZXZlciByZWFjaCB0aGUgZGVzdGlu YXRpb24gYWRkcmVzcyBvZiB0aGUgaW5uZXIgcGFja2V0LCBiZWNhdXNlIHRoZSBEQSBvZiB0aGUg aW5uZXIgcGFja2V0IGlzIGluIHRoZSBVTEEgSVB2NiBwYWNrZXQncyBwYXlsb2FkLg0KDQpGYWls dXJlIG9mIHRoZSBtZWNoYW5pc20gd291bGQgYmUgbXVjaCBtb3JlIG9idmlvdXMsIGxvY2FsaXNl ZCB0byB0aGUgZG9tYWluIGltcGxlbWVudGluZyB0aGUgbWVjaGFuaXNtIChyYXRoZXIgdGhhbiBi ZWluZyBleHRlcm5hbGlzZWQgdG8gc29tZWJvZHkgZWxzZSdzIGRvbWFpbi9uZXR3b3JrKSwgYW5k IGFic29sdXRlLCBiZWNhdXNlIHRoZSBmYWlsdXJlIG1vZGUgaXMgcGFja2V0cyBiZWluZyBlbnRp cmVseSBkaXNjYXJkZWQuDQoNClJlZ2FyZHMsDQpNYXJrLg0KDQoNCg0KRnJhbmsNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb208 bWFpbHRvOmhlYXJkQHBvYm94LmNvbT4+DQpTZW50OiBNb250YWcsIDI5LiBPa3RvYmVyIDIwMTgg MTY6MDMNClRvOiA2bWFuIDxpcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPj47IElQ UE0gPGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+Pg0KQ2M6IEZyYW5rIEJyb2Nr bmVycyAoZmJyb2NrbmUpIDxmYnJvY2tuZUBjaXNjby5jb208bWFpbHRvOmZicm9ja25lQGNpc2Nv LmNvbT4+DQpTdWJqZWN0OiBSZTogdjYgb3B0aW9uIHR5cGVzIGZvciBJT0FNIGRhdGEgZmllbGRz DQoNCk9uIFRodSwgMjUgT2N0IDIwMTggMTU6MDY6NTcgKzAwMDAgRnJhbmsgQnJvY2tuZXJzIChm YnJvY2tuZSkgd3JvdGU6DQo+IFF1aWNrIGhlYWRzIHVwOiBJbiB0aGUgNk1BTiBtZWV0aW5nIGlu IEJLSywgd2XigJlsbCByZXZpZXcNCj4gZHJhZnQtaW9hbWV0YWwtaXBwbS02bWFuLWlvYW0taXB2 Ni1vcHRpb25zLTAxIOKAkyB3aGljaCByZXF1ZXN0cyAyDQo+IG9wdGlvbiB0eXBlcyBmcm9tIHRo ZSBETy9IYnlIIG9wdGlvbnMgc3ViLXJlZ2lzdHJ5Lg0KPg0KPiBXaGlsZSB0aGUgYnVsayBvZiB0 aGUgSU9BTSB3b3JrIGlzIHByb2dyZXNzZWQgaW4gdGhlIElQUE0gV0csIHdl4oCZZA0KPiBncmVh dGx5IGFwcHJlY2lhdGUgeW91ciBmZWVkYmFjayBvbg0KPiBkcmFmdC1pb2FtZXRhbC1pcHBtLTZt YW4taW9hbS1pcHY2LW9wdGlvbnMtMDEsDQo+IHdoaWNoIGRlZmluZXMgaG93IElPQU0gZGF0YSBm aWVsZHMgYXJlIGNhcnJpZWQgdXNpbmcgdjYgZXh0ZW5zaW9uIGhlYWRlcnMuDQo+IENj4oCZaW5n IHRoZSBJUFBNIFdHIGFzIHdlbGwsIHRvIGtlZXAgZXZlcnlvbmUgb24gdGhlIHNhbWUgcGFnZS4N Cg0KSSBoYXZlIHR3byBicmllZiBjb21tZW50cyBvbiB0aGlzIHdvcmsuDQoNCkZpcnN0LCBJIHNl ZSB0aGF0IHRoZSBJbmNyZW1lbnRhbCBUcmFjaW5nIE9wdGlvbiBjaGFuZ2VzIGxlbmd0aCBpbiB0 cmFuc2l0Lg0KSXQgaXMgbm90IGFwcHJvcHJpYXRlIGZvciBpdCB0byBiZSBjYXJyaWVkIGluIGFu IElQdjYgb3B0aW9uIGludGVuZGVkIGZvciB1c2Ugb24gdGhlIG9wZW4gSW50ZXJuZXQsIGZvciBl eGFjdGx5IHRoZSBzYW1lIHJlYXNvbiB0aGF0IGluc2VydGlvbiBvZiBleHRlbnNpb24gaGVhZGVy cyBieSBpbnRlcm1lZGlhdGUgbm9kZXMgaXMgbm90IGFsbG93ZWQgb24gdGhlIG9wZW4gSW50ZXJu ZXQuDQoNClNlY29uZCwgSSBzZWUgdGhhdCB0d28gSVB2NiBvcHRpb24gY29kZSBwb2ludHMgYXJl IHJlcXVlc3RlZCwgb25lIHdpdGggdGhlICJjaGciIGZsYWcgc2V0LCB0aGUgb3RoZXIgd2l0aCB0 aGUgImNoZyIgZmxhZyBjbGVhci4gV2hpbGUgdGhlcmUgaXMgbm8gaGFybSBpbiB0aGlzLCBpdCBp cyBub3Qgc3RyaWN0bHkgbmVjZXNzYXJ5OyB0aGUgb25seSByZWFsIHB1cnBvc2Ugb2YgdGhpcyBm bGFnIGlzIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZSBvcHRpb24gZGF0YSBpcyBvciBpcyBub3Qg aW5jbHVkZWQgaW4gdGhlIEF1dGhlbnRpY2F0aW9uIEhlYWRlciBJbnRlZ3JpdHkgQ2hlY2sgVmFs dWUgY29tcHV0YXRpb24uDQoNCk1pa2UgSGVhcmQNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5v cmc+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K --_000_f50040ab52d04867b9a5cefa1c3131c3XCHRCD008ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1z b25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3 MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzAxMDg1NDA3Ow0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTgyMzk1ODI4OCA2 NzU2NzYzMSA2NzU2NzY0MSA2NzU2NzY0MyA2NzU2NzYzMSA2NzU2NzY0MSA2NzU2NzY0MyA2NzU2 NzYzMSA2NzU2NzY0MSA2NzU2NzY0Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0K CXttc28tbGlzdC1pZDozNTEyMjU1ODE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjEzMjAwOTA2NzggNjc1Njc2MzEgNjc1Njc2NDEgNjc1Njc2NDMgNjc1 Njc2MzEgNjc1Njc2NDEgNjc1Njc2NDMgNjc1Njc2MzEgNjc1Njc2NDEgNjc1Njc2NDM7fQ0KQGxp c3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0 DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6Nzg4NjIwNzMyOw0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozMTQ2MTYxNzIgNjc1 Njc2MzEgNTQ5ODk0MzA0IDY3NTY3NjQzIDY3NTY3NjMxIDY3NTY3NjQxIDY3NTY3NjQzIDY3NTY3 NjMxIDY3NTY3NjQxIDY3NTY3NjQzO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUyXCkiOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxMDkzODE4ODM1Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTkzNTY0NzI5OCA2NzU2 NzYzMSA2NzU2NzY0MSA2NzU2NzY0MyA2NzU2NzYzMSA2NzU2NzY0MSA2NzU2NzY0MyA2NzU2NzYz MSA2NzU2NzY0MSA2NzU2NzY0Mzt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsNA0KCXtt c28tbGlzdC1pZDoxNDk2NjA2Mzk0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczo3MjgxMzM2NDQgNjc1Njc2MzEgNjc1Njc2NDEgNjc1Njc2NDMgNjc1Njc2 MzEgNjc1Njc2NDEgNjc1Njc2NDMgNjc1Njc2MzEgNjc1Njc2NDEgNjc1Njc2NDM7fQ0KQGxpc3Qg bDQ6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw0OmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsNDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MTY1NzM0MzcxNzsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1ODQzNTg0MDYgNDgz MTQyNTk4IDY3NTY3NjE5IDY3NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5IDY3NTY3NjIxIDY3NTY3 NjE3IDY3NTY3NjE5IDY3NTY3NjIxO30NCkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6MzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw1OmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs NTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDU6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDU6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsNTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5IaSBNYXJrLCBNaWtlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPnRoYW5rcyBmb3Igc3VtbWFyaXppbmcgdGhlIGNvbmNlcm5zIGFyb3VuZCBs ZWFrZWQgcGFja2V0cyDigJMgYW5kIG91dGxpbmluZyBhbiBhcHByb2FjaCB0byBtaXRpZ2F0ZSB0 aG9zZS4gVGhlcmUgYXJlIGEgY291cGxlDQogb2Ygb3RoZXIgY2hhbGxlbmdlcyB3ZSBmYWNlLiBV bmZvcnR1bmF0ZWx5IHdlIGRpZCBub3QgZ2V0IHRvIGEgZGlzY3Vzc2lvbiBpbiB0aGUgNm1hbiBX RyBtZWV0aW5nIHRoaXMgdGltZSBkdWUgdG8gdGhlIGxpbWl0ZWQgdGltZSB3ZSBoYWQuIFRoZSBt ZWV0aW5nIHNsaWRlcw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL21lZXRpbmcvMTAzL21hdGVyaWFscy9zbGlkZXMtMTAzLTZtYW4taW4tc2l0dS1vYW0taXB2 Ni1vcHRpb25zLTAwIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy02bWFuLWluLXNpdHUtb2FtLWlw djYtb3B0aW9ucy0wMDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5wcm92 aWRlIGEgc3VtbWFyeSBvZiBjb25jZXJucy4gPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JbiBhIG51dHNoZWxs OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4x LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Qb3RlbnRpYWwgSGJIIGV4dCBoZWFkZXIgYW5kIElPQU0g b3B0aW9uIGluc2VydGlvbiBhbmQgcmVtb3ZhbCBieSB0cmFuc2l0IG5vZGVzIChpLmUuIOKAnGVu IHJvdXRl4oCdKSBpbiBhIHJlc3RyaWN0ZWQNCiBhZG1pbmlzdHJhdGl2ZSBkb21haW4uIDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwyIGxm bzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj5hKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Ib3cgZG8geW91IGRlYWwgd2l0 aCBQTVRVPyDigJMgUGFja2V0IHNpemUgY2hhbmdlcyBtaWdodCBleGNlZWQgUE1UVS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMiBsZm8y Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Yik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWlzbGVhZGluZyBJQ01QIGVycm9ycyBjb25m dXNpbmcgdGhlIHNvdXJjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5jKTxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5Qb3NzaWJsZSBsZWFrcyB0aGF0IGFmZmVjdCB0aGUgZm9yd2FyZGluZyBiZWhhdmlvciBhbmQg c3RhdGUgb2YgbmV0d29yayBlbGVtZW50cyBvdXRzaWRlIHRoZSBkb21haW4uDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+SW5jcmVtZW50YWwgVHJhY2UgSU9BTSBIYkggT3B0aW9uIOKAkyB3aGljaCBp cyB0byBzdXBwb3J0IGEgaGFyZHdhcmUtZnJpZW5kbHkgaW1wbGVtZW50YXRpb246IENoYW5nZXMg T3B0aW9uIERhdGENCiBMZW4gZW4tcm91dGUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hKTxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5EZWFsaW5nIHdpdGggUE1UVeKAkyBQYWNrZXQgc2l6ZSBjaGFuZ2VzIGNh biBleGNlZWQgUE1UVTsgc2VlIGFib3ZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omwy IGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNsYXJpZnkgYXBw bGljYWJpbGl0eSBzdGF0ZW1lbnQgYW5kIHNjb3BlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldoaWxlIDMuIGlzIHNvbWV0 aGluZyB0aGF0IGlzIGluIHRoZSB3b3JrcywgdGhlcmUgYXJlIG5vIGVhc3kgYW5zd2VycyB0byAx LiBhbmQgMi4gQ29uc2lkZXJhdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk9uIDEuIFN1cHBvcnRpbmcgSGJIIGV4 dCBoZWFkZXIgYW5kIG9wdGlvbiBpbnNlcnRpb24vcmVtb3ZhbCBpbiB0cmFuc2l0LiBBIGNvdXBs ZSBvZiBzb2x1dGlvbiBhcHByb2FjaGVz4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 Omw0IGxldmVsMSBsZm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkZpeCBQTVRV IGFuZCBvZmZzZXQgZm9yIHBhY2tldCBzaXplIGNoYW5nZSBpbiBQTVRVIGRpc2NvdmVyeSAtDQo8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHJvYW4tNm1hbi1wbXR1 LXNvbHV0aW9uLXNwYWNlLTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHJv YW4tNm1hbi1wbXR1LXNvbHV0aW9uLXNwYWNlLTAwPC9hPjxicj4NCkhvcGUgdGhhdCB3ZSBjYW4g bWFrZSBwcm9ncmVzcyB0b3dhcmRzIGEgc29sdXRpb24gdG9tb3Jyb3figKY8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+SVAtaW4tSVAgd2l0aCBJT0FNIGV4dGVuc2lvbiBoZWFkZXIgaW4gdGhlICo8Yj5p bm5lcjwvYj4qIHBhY2tldC48YnI+DQpOZXcgSVB2NiBwYWNrZXQgaXMgY3JlYXRlZCB3aXRoIGVu Y2Fwc3VsYXRpbmcgbm9kZSBhcyBzb3VyY2UgYW5kIHRoZSBvcmlnaW5hbCBkZXN0aW5hdGlvbiBh cyB0aGUgZGVzdGluYXRpb24NCjxicj4NCih0aGlzIGlzIHNsaWdodGx5IGRpZmZlcmVudCB0aGFu IHdoYXQgeW91LCBNYXJrLCBzdWdnZXN0IOKAkyBiZWNhdXNlIHdl4oCZZCBsaWtlIHRvIGtlZXAg dGhlIGZvcndhcmRpbmcgcGF0aCB0aGUgc2FtZS4gVHVubmVsaW5nIHdpdGggVUxBIHdvdWxkIG5v dCBnZXQgdXMgdGhlcmU7IHRoZSBzbGlkZXMgYWJvdmUgaGF2ZSBhIGRpYWdyYW0gdGhhdCBkZXBp Y3RzIHRoZSBwb3RlbnRpYWwgZW5jYXApOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hKTxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5QYXlsb2FkIG9mIHRoaXMgcGFja2V0IGlzIHRoZSBvcmlnaW5hbCBJUHY2IHBh Y2tldCBhbG9uZyB3aXRoIGFuIGV4dGVuc2lvbiBoZWFkZXIgaW5zZXJ0ZWQgaW5zaWRlLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDIg bGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPmIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSBvcmlnaW5hbCBwYWNrZXQgaXMg cmVzdG9yZWQgYnkgcmVtb3ZpbmcgdGhlIG91dGVyIElQdjYgaGVhZGVyIGFuZCB0aGUgaW5uZXIg ZXh0ZW5zaW9uIGhlYWRlciBieSBhIG5vZGUgYXQNCiB0aGUgZG9tYWluIGJvdW5kYXJ5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwyIGxm bzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj5jKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DYXZlYXRzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTA4LjBwdDt0ZXh0LWluZGVudDotMTA4LjBwdDttc28tdGV4dC1pbmRlbnQtYWx0Oi05LjBw dDttc28tbGlzdDpsMiBsZXZlbDMgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+aS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Nb2RpZmllZCBwYWNrZXQgbWF5IHN0aWxs IGxlYWsg4oCTIGJ1dCB3aWxsIG9ubHkgY29uZnVzZQ0KIHRoZSBkZXN0aW5hdGlvbiBub2RlLiBU aGUgZGVzdCBub2RlIHdpbGwgbGlrZWx5IHNlbmQgYW4gSUNNUCBiYWNrIHRvIHRoZSBlbmNhcCBu b2RlLCB3aGljaCBnZXRzIHRoZSBlbmNhcCBub2RlIGFuIHVuZGVyc3RhbmRpbmcgdGhhdCBzb21l dGhpbmcgaXMgZ29pbmcgd3JvbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O3RleHQtaW5kZW50Oi0x MDguMHB0O21zby10ZXh0LWluZGVudC1hbHQ6LTkuMHB0O21zby1saXN0OmwyIGxldmVsMyBsZm8y Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5paS48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5FQ01Q IGNvbXB1dGF0aW9uIG5lZWRzIHRvIGJlIHJld29ya2VkLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0 O3RleHQtaW5kZW50Oi0xMDguMHB0O21zby10ZXh0LWluZGVudC1hbHQ6LTkuMHB0O21zby1saXN0 OmwyIGxldmVsMyBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5paWkuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Q29tcGxleC9jb3N0bHkgaW1wbGVtZW50YXRpb24gaW4gSFcgJmFtcDsgU1cg4oCTIElPQU0tY2Fw YWJsZQ0KIG5vZGVzIG5lZWQgdG8gaHVudCBmb3IgdGhlIElPQU0gZGF0YSBmaWVsZHMgaW4gdGhl IGlubmVyIHBhY2tldC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omw0IGxldmVsMSBs Zm80Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk5vIHN1cHBvcnQgb2YgSU9BTSBp biB0cmFuc2l0IG5ldHdvcmsuIFN1cHBvcnQgb25seSBzb3VyY2UgaW5pdGlhdGVkIElPQU0gdHJh Y2luZywgcHJvb2Ygb2YgdHJhbnNpdC4uDQo8YnI+DQpDYXZlYXQ6IExpbWl0cyB1c2FnZSBvZiBJ T0FNIHNpZ25pZmljYW50bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk9uIDIuIEluY3JlbWVudGFsIFRyYWNlIElPQU0g SGJIIE9wdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvNiI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Vc2UgUE1UVSB0byBkZXRlcm1pbmUgbWF4 IHBvc3NpYmxlIEluY3JlbWVudGFsIFRyYWNlIElPQU0gT3B0aW9uIGxlbmd0aDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvNiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5EbyBub3Qgc3VwcG9ydCBJbmNyZW1lbnRhbCBUcmFjZSBJT0FNIE9wdGlvbiBp biBJUHY2Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPldoaWxlIHRoZXJlIGlzbuKAmXQgYW4gZWFzeSBhbnN3ZXIsIElN SE8gd2Ugc2hvdWxkIHN0aWxsIHRyeSB0byBmaW5kIGEgd29ya2FibGUgYW5kIGltcGxlbWVudGFi bGUgc29sdXRpb24uIEkgc29tZXRpbWVzDQogY29tcGFyZSB0aGUgc2l0dWF0aW9uIHdpdGggdGhl IHJvYWQgbmV0d29yazogV2hhdCB3ZSBoYXZlIHRvZGF5IGlzIGEgbmV0d29yayBvZiBncmF2ZWwg cm9hZHMgKEludGVybmV0IHdpdGggb2Z0ZW4gcG9vciBleHQgaGVhZGVyIHByb2Nlc3NpbmcpIGFu ZCBjYXJzIGFyZSBidWlsdCB0byBjb3BlIHdpdGggZ3JhdmVsIHJvYWRzLiBOb3cgZmFzdGVyIGFu ZCBjb21meSBjYXJzIGJlY29tZSBhdmFpbGFibGUsIHRob3VnaCB0aGV5IG9ubHkgd29yayBvbg0K IHRhcmVkL2NvbmNyZXRlIHJvYWRzIChzcGVjaWZpYyBhZG1pbmlzdHJhdGl2ZSBkb21haW5zKS4g SWYgeW91IHRyeSB0byBkcml2ZSB0aGVzZSBuZXcgY2FycyBvbiBncmF2ZWwgcm9hZHMgdGhleSBi cmVhayBhbmQgdGhlIHdyZWNrcyBqYW0gdGhlIHJvYWRz4oCmLCBzdGlsbCB3ZSBwcm9iYWJseSB3 YW50IHRvIGFsbG93IGZvbGtzIHRvIGJ1eSBhbmQgdXNlIHRoZSBmYXN0ICZhbXA7IGNvbWZ5IGNh cnMsIGJlY2F1c2UgdGhleSB3aWxsIGFsc28gcHVzaCBmb3INCiBiZXR0ZXIgcm9hZHMgJm5ic3A7 YXMgd2VsbCAoZG8gcHJvcGVyIGV4dCBoZWFkZXIgcHJvY2Vzc2luZykuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRob3Vn aHRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5UaGFua3MsIEZyYW5rPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWFy ayBTbWl0aCAmbHQ7bWFya3p6enNtaXRoQGdtYWlsLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9i PiBEaWVuc3RhZywgMzAuIE9rdG9iZXIgMjAxOCAwNToyNjxicj4NCjxiPlRvOjwvYj4gRnJhbmsg QnJvY2tuZXJzIChmYnJvY2tuZSkgJmx0O2Zicm9ja25lQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IEMuIE0uIEhlYXJkICZsdDtoZWFyZEBwb2JveC5jb20mZ3Q7OyA2bWFuIFdHICZsdDtp cHY2QGlldGYub3JnJmd0OzsgaXBwbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog djYgb3B0aW9uIHR5cGVzIGZvciBJT0FNIGRhdGEgZmllbGRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkhpIEZy YW5rLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFR1ZS4sIDMwIE9jdC4gMjAxOCwgMDU6MzYgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSks ICZsdDs8YSBocmVmPSJtYWlsdG86ZmJyb2NrbmVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZmJyb2NrbmVAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgTWlrZS4gT24gdGhlIHNj b3BlIG9mIGFuIElPQU0gZGVwbG95bWVudDogPGJyPg0KZHJhZnQtaWV0Zi1pcHBtLWlvYW0tZGF0 YS0wNCBjbGFyaWZpZXMgaW4gc2VjdGlvbiAzIHRoYXQgSU9BTSBpcyBhIGRvbWFpbiBmb2N1c2Vk IGZlYXR1cmUsIGkuZS4gbm90IGV4cGVjdGVkIHRvIGJlIGRlcGxveWVkIG9uIHRoZSBvcGVuIElu dGVybmV0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgc3RpbGwgdmlvbGF0ZXMgUkZDIDgyMDAs IHRoZXJlIGFyZSBubyBleGNlcHRpb25zIGZvciAmcXVvdDtjbG9zZWQmcXVvdDsgZG9tYWlucy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJv bSBzZWN0aW9uIDM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZxdW90O0Rlc2lnbmVycyBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtjYXJyaWVyIHByb3Rv Y29scyBmb3IgSU9BTSBtdXN0IHNwZWNpZnkgbWVjaGFuaXNtcyB0byBlbnN1cmUgdGhhdDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwO0lPQU0gZGF0YSBzdGF5cyB3aXRoaW4gYW4gSU9BTSBkb21haW4uJm5ic3A7IEluIGFkZGl0 aW9uLCB0aGUgb3BlcmF0b3Igb2Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtzdWNoIGEgZG9tYWluIGlzIGV4cGVjdGVkIHRv IHB1dCBwcm92aXNpb25zIGluIHBsYWNlIHRvIGVuc3VyZSB0aGF0PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7SU9BTSBkYXRh IGRvZXMgbm90IGxlYWsgYmV5b25kIHRoZSBlZGdlIG9mIGFuIElPQU0gZG9tYWluLCBlLmcuIHVz aW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7Zm9yIGV4YW1wbGUgcGFja2V0IGZpbHRlcmluZyBtZXRob2RzLiZxdW90Ozxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OZWl0 aGVyIHRoZSBkZXNpZ25lcnMgb3IgdGhlIG9wZXJhdG9ycyBjYW4gZW5zdXJlIHRoaXMgSU9BTSBp bmZvcm1hdGlvbiB3b24ndCBsZWFrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBvc3NpYmxlIHJlYXNvbnMgaXQgY2FuIGxlYWs6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g b3BlcmF0b3IgY29uZmlndXJhdGlvbiBlcnJvciAtIGUuZy4gZm9yZ2V0dGluZyB0byBjb25maWd1 cmUgdGhlIGRvbWFpbiBib3VuZGFyeSAoZS5nLiByb3V0ZXIgd2l0aCBtdWx0aXBsZSBkb21haW4g ZXhpdCBpbnRlcmZhY2VzLCBmb3JnZXR0aW5nIHRvIGFkZCB0aGF0IG9wdGlvbiBvbiBvbmUgb2Yg dGhlbSksIG9yIG1pc2NvbmZpZ3VyaW5nIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHBhcnRpYWwgZGV2aWNlIGZhaWx1cmUgLSB0aGUg ZGV2aWNlIHN0aWxsIGZvcndhcmRzIHBhY2tldHMsIGJ1dCBjZWFzZXMgdG8gcmVtb3ZlIHRoaXMg aW5mb3JtYXRpb24gZHVlIHRvIGEgaGFyZHdhcmUgZmF1bHQgdGhhdCBoYXMgYXBwZWFyZWQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSB2ZW5k b3IgaW1wbGVtZW50YXRpb24gYnVncyB0aGF0IGZhaWxzIHRvIHJlbW92ZSB0aGUgaW5mb3JtYXRp b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFueSBvciBhbGwgb2YgdGhlc2UgY2FuIG9jY3VyLCBhbmQgYXMgaXQgaXMgb24gZWdyZXNzLCB0 aGUgY29uc2VxdWVuY2VzIG1heSBub3QgYmUgdmlzaWJsZSB0byB0aGUgZG9tYWluIG5ldHdvcmsg b3BlcmF0b3IsIGJlY2F1c2UgbmV0d29yayBvcGVyYXRvcnMgcmFyZWx5IGluc3BlY3QgcGFja2V0 cyBhZnRlciB0aGV5J3ZlIGxlZnQgdGhlaXIgbmV0d29yay4gT25jZSBhIHBhY2tldCBpcyBzZW50 IG9udG8gc29tZWJvZHkNCiBlbHNlLCBpdCBpcyBhc3N1bWVkIHRvIGhhdmUgYmVlbiBzZW50IHdp dGhvdXQgZmF1bHRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGVyZSBhcmUgbWFueSBpbnN0YW5jZXMgb2YgbGVha3MgYXQgdGhlIGJvdW5k YXJ5IG9mIHdoYXQgYXJlIHN1cHBvc2VkIHRvIGJlIGNsb3NlZCBkb21haW5zLCBzdWNoIGFzIHBh Y2tldHMgY29udGFpbmluZyBSRkMxOTE4IHByaXZhdGUgYWRkcmVzc2VzIChpbiBwYWNrZXQgaGVh ZGVycyB0aGVtc2VsdmVzLCBvciBpbiBETlMgcGFja2V0cyAtIHN1Y2ggYSBiaWcgcHJvYmxlbSB0 aGF0IHd3dy5hPGEgaHJlZj0iaHR0cDovL2FzMTEyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnMxMTIu bmV0PC9hPiZuYnNwO3dhcw0KIGNyZWF0ZWQpLCBhbmQgcm91dGUgbGVha3MgZS5nLiA8YSBocmVm PSJodHRwczovL2JncG1vbi5uZXQvaG93LXRoZS1pbnRlcm5ldC1pbi1hdXN0cmFsaWEtd2VudC1k b3duLXVuZGVyLyI+DQpodHRwczovL2JncG1vbi5uZXQvaG93LXRoZS1pbnRlcm5ldC1pbi1hdXN0 cmFsaWEtd2VudC1kb3duLXVuZGVyLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgb3BlcmF0b3JzIHVzdWFsbHkgaGF2ZSBvbmx5IG9u ZSBkZXZpY2UgYXQgdGhlIGVkZ2Ugb2YgdGhlIGRvbWFpbiwgdGhhdCB3b3VsZCBiZSBwZXJmb3Jt aW5nIHRoZSBkb21haW4gYm91bmRhcnkgZnVuY3Rpb24sIHRoYXQgZGV2aWNlIGJlY29tZXMgYSBz aW5nbGUgcG9pbnQgb2YgZmFpbHVyZS4gRW5mb3JjZW1lbnQgaXMgdGhlcmVmb3JlIHF1aXRlIGZy YWdpbGUuIEEgZG9tYWluIGJvdW5kYXJ5IGVuZm9yY2VkDQogYnkgdHdvIGRvbWFpbiBlZGdlIGRl dmljZXMgaW4tbGluZSB3b3VsZCBpbmNyZWFzZSByb2J1c3RuZXNzLCBob3dldmVyIEknZCB0aGlu ayB0aGF0IHdvdWxkIGJlIHJhcmVseSBkZXBsb3llZCwgYmVjYXVzZSB3ZSBoYXZlbid0IHNlZW4g dGhhdCBjb21tb25seSB3aXRoIElQdjQgTkFULjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb25seSB3YXkgZm9yIGFuIG9wZXJhdG9yIHRv IGVuc3VyZSB0aGVzZSBsZWFrcyBkb24ndCBhbmQgbmV2ZXIgb2NjdXIgaXMgZm9yIHRoZSBkb21h aW4gdG8gbGl0ZXJhbGx5IG5vdCBiZSBwaHlzaWNhbGx5IGNvbm5lY3RlZCB0byB0aGUgSW50ZXJu ZXQgaS5lLiB0aGUgZG9tYWluIGlzIGFpciBnYXBwZWQgZnJvbSB0aGUgSW50ZXJuZXQuIElmIHRo ZXJlIGlzIGEgbGluayBiZXR3ZWVuIHRoZSBkb21haW4gYW5kDQogdGhlIEludGVybmV0IHRoYXQg Y2FuIGNhcnJ5IElQIHBhY2tldHMsIHRoZW4gdGhlcmUgaXMgYWx3YXlzIGEgcG9zc2liaWxpdHkg dGhhdCBpbmZvcm1hdGlvbiBjYW4gbGVhayBmcm9tIHRoZSBkb21haW4uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGFjY2VwdGluZyB0aGF0 IGxlYWtzIGNhbiBhbHdheXMgb2NjdXIsIGEgZmFyIG1vcmUgcm9idXN0IG9wdGlvbiBpcyB0byBs ZWF2ZSB0aGUgb3JpZ2luYWwgcGFja2V0IGFsb25lIGVudGlyZWx5LCBhbmQgZW5jYXBzdWxhdGUg aXQgaW4gYSBkb21haW4gbG9jYWwgSVB2NiBoZWFkZXIgKGkuZSBSRkMyNDczLCBzZWN0aW9uIDMu MSkgd2l0aCBkb21haW4gbG9jYWwgbGltaXRlZCBhZGRyZXNzZXMgKGkuZS4gVUxBDQogYWRkcmVz c2VzKSBhbmQgdGhlIGFkZGl0aW9uYWwgRUguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgc3RpbGwgZG9lc24ndCBlbnN1cmUgdGhhdCBw YWNrZXQgd29uJ3QgbGVhayBvdXRzaWRlIHRoZSBkb21haW4sIGJlY2F1c2UgdGhvc2UgcGFja2V0 cyB3aWxsIGZvbGxvdyBhIGRlZmF1bHQgcm91dGUsIGhvd2V2ZXIgYXMgdGhlIHBhY2tldCdzIGFk ZHJlc3NpbmcgaXMgaW52YWxpZCBvdXRzaWRlIG9mIHRoZSBkb21haW4sIHRoYXQgcGFja2V0IHdp bGwgYmUgZHJvcHBlZCBvbmNlIGl0IHJlYWNoZXMgZWl0aGVyDQogYW4gaW52YWxpZCBJbnRlcm5l dCBhZGRyZXNzIGZpbHRlciwgb3IgYSBkZWZhdWx0IGZyZWUgSW50ZXJuZXQgcm91dGVyLiBUaGUg cGFja2V0IHdpdGggdGhlIGZhaWxlZC10by1iZS1yZW1vdmVkIG91dGVyIFVMQSBJUHY2IGhlYWRl ciB3aWxsIG5ldmVyIHJlYWNoIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIG9mIHRoZSBpbm5lciBw YWNrZXQsIGJlY2F1c2UgdGhlIERBIG9mIHRoZSBpbm5lciBwYWNrZXQgaXMgaW4gdGhlIFVMQSBJ UHY2IHBhY2tldCdzDQogcGF5bG9hZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RmFpbHVyZSBvZiB0aGUgbWVjaGFuaXNtIHdvdWxkIGJlIG11 Y2ggbW9yZSBvYnZpb3VzLCBsb2NhbGlzZWQgdG8gdGhlIGRvbWFpbiBpbXBsZW1lbnRpbmcgdGhl IG1lY2hhbmlzbSAocmF0aGVyIHRoYW4gYmVpbmcgZXh0ZXJuYWxpc2VkIHRvIHNvbWVib2R5IGVs c2UncyBkb21haW4vbmV0d29yayksIGFuZCBhYnNvbHV0ZSwgYmVjYXVzZSB0aGUgZmFpbHVyZSBt b2RlIGlzIHBhY2tldHMgYmVpbmcgZW50aXJlbHkNCiBkaXNjYXJkZWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJrLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KRnJhbms8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCkZyb206IEMuIE0uIEhlYXJkICZsdDs8YSBocmVmPSJtYWlsdG86aGVhcmRAcG9i b3guY29tIiB0YXJnZXQ9Il9ibGFuayI+aGVhcmRAcG9ib3guY29tPC9hPiZndDsNCjxicj4NClNl bnQ6IE1vbnRhZywgMjkuIE9rdG9iZXIgMjAxOCAxNjowMzxicj4NClRvOiA2bWFuICZsdDs8YSBo cmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwdjZAaWV0Zi5vcmc8 L2E+Jmd0OzsgSVBQTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5pcHBtQGlldGYub3JnPC9hPiZndDs8YnI+DQpDYzogRnJhbmsgQnJvY2tuZXJzIChm YnJvY2tuZSkgJmx0OzxhIGhyZWY9Im1haWx0bzpmYnJvY2tuZUBjaXNjby5jb20iIHRhcmdldD0i X2JsYW5rIj5mYnJvY2tuZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFJlOiB2NiBv cHRpb24gdHlwZXMgZm9yIElPQU0gZGF0YSBmaWVsZHM8YnI+DQo8YnI+DQpPbiBUaHUsIDI1IE9j dCAyMDE4IDE1OjA2OjU3ICYjNDM7MDAwMCBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKSB3cm90 ZTo8YnI+DQomZ3Q7IFF1aWNrIGhlYWRzIHVwOiBJbiB0aGUgNk1BTiBtZWV0aW5nIGluIEJLSywg d2XigJlsbCByZXZpZXc8YnI+DQomZ3Q7IGRyYWZ0LWlvYW1ldGFsLWlwcG0tNm1hbi1pb2FtLWlw djYtb3B0aW9ucy0wMSDigJMgd2hpY2ggcmVxdWVzdHMgMiA8YnI+DQomZ3Q7IG9wdGlvbiB0eXBl cyBmcm9tIHRoZSBETy9IYnlIIG9wdGlvbnMgc3ViLXJlZ2lzdHJ5Ljxicj4NCiZndDs8YnI+DQom Z3Q7IFdoaWxlIHRoZSBidWxrIG9mIHRoZSBJT0FNIHdvcmsgaXMgcHJvZ3Jlc3NlZCBpbiB0aGUg SVBQTSBXRywgd2XigJlkIDxicj4NCiZndDsgZ3JlYXRseSBhcHByZWNpYXRlIHlvdXIgZmVlZGJh Y2sgb24gPGJyPg0KJmd0OyBkcmFmdC1pb2FtZXRhbC1pcHBtLTZtYW4taW9hbS1pcHY2LW9wdGlv bnMtMDEsPGJyPg0KJmd0OyB3aGljaCBkZWZpbmVzIGhvdyBJT0FNIGRhdGEgZmllbGRzIGFyZSBj YXJyaWVkIHVzaW5nIHY2IGV4dGVuc2lvbiBoZWFkZXJzLjxicj4NCiZndDsgQ2PigJlpbmcgdGhl IElQUE0gV0cgYXMgd2VsbCwgdG8ga2VlcCBldmVyeW9uZSBvbiB0aGUgc2FtZSBwYWdlLjxicj4N Cjxicj4NCkkgaGF2ZSB0d28gYnJpZWYgY29tbWVudHMgb24gdGhpcyB3b3JrLjxicj4NCjxicj4N CkZpcnN0LCBJIHNlZSB0aGF0IHRoZSBJbmNyZW1lbnRhbCBUcmFjaW5nIE9wdGlvbiBjaGFuZ2Vz IGxlbmd0aCBpbiB0cmFuc2l0Ljxicj4NCkl0IGlzIG5vdCBhcHByb3ByaWF0ZSBmb3IgaXQgdG8g YmUgY2FycmllZCBpbiBhbiBJUHY2IG9wdGlvbiBpbnRlbmRlZCBmb3IgdXNlIG9uIHRoZSBvcGVu IEludGVybmV0LCBmb3IgZXhhY3RseSB0aGUgc2FtZSByZWFzb24gdGhhdCBpbnNlcnRpb24gb2Yg ZXh0ZW5zaW9uIGhlYWRlcnMgYnkgaW50ZXJtZWRpYXRlIG5vZGVzIGlzIG5vdCBhbGxvd2VkIG9u IHRoZSBvcGVuIEludGVybmV0Ljxicj4NCjxicj4NClNlY29uZCwgSSBzZWUgdGhhdCB0d28gSVB2 NiBvcHRpb24gY29kZSBwb2ludHMgYXJlIHJlcXVlc3RlZCwgb25lIHdpdGggdGhlICZxdW90O2No ZyZxdW90OyBmbGFnIHNldCwgdGhlIG90aGVyIHdpdGggdGhlICZxdW90O2NoZyZxdW90OyBmbGFn IGNsZWFyLiBXaGlsZSB0aGVyZSBpcyBubyBoYXJtIGluIHRoaXMsIGl0IGlzIG5vdCBzdHJpY3Rs eSBuZWNlc3Nhcnk7IHRoZSBvbmx5IHJlYWwgcHVycG9zZSBvZiB0aGlzIGZsYWcgaXMgdG8gZGV0 ZXJtaW5lIHdoZXRoZXIgdGhlIG9wdGlvbg0KIGRhdGEgaXMgb3IgaXMgbm90IGluY2x1ZGVkIGlu IHRoZSBBdXRoZW50aWNhdGlvbiBIZWFkZXIgSW50ZWdyaXR5IENoZWNrIFZhbHVlIGNvbXB1dGF0 aW9uLjxicj4NCjxicj4NCk1pa2UgSGVhcmQ8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCklFVEYgSVB2 NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppcHY2QGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXB2NkBpZXRmLm9yZzwvYT48YnI+DQpBZG1pbmlzdHJh dGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHY2IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwdjY8L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_f50040ab52d04867b9a5cefa1c3131c3XCHRCD008ciscocom_-- From nobody Thu Nov 8 03:41:01 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763F6130E6C; Thu, 8 Nov 2018 03:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wKl8zXJ0vOYF; Thu, 8 Nov 2018 03:40:56 -0800 (PST) Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A30128CB7; Thu, 8 Nov 2018 03:40:56 -0800 (PST) Received: by mail-oi1-x241.google.com with SMTP id x204-v6so1172951oia.0; Thu, 08 Nov 2018 03:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EKwvSQqhxeNm2jTsVNjvfHczeAou0iB9ktyY1+ME4WQ=; b=I5DBP8QrLRtBdeHuq31jcdRXiH2hVK5lFn9FFF9fZHiSB+4x3fYo3lIfmIUup/HPHj q4aW+aEHtBljvTiFeLwYLAmjyBABKuBElF/UhTYALehlGNSS8arp/8T6YDT2Fqpr8ybU VDn3IjBKOLJjhrpj+WPV2XfIBlqcBOGT8C4MoVY1EUiVTPX2FZLSW2RK5kwi7USNjfG1 EpttycfJNUpKmUG2IcCgM/Jz9nyzJBmtT1gSn6e0Oe9OfhUPuvl+SoTdfGklGNiZYMue osWpsY0/X68um1nI4mVG8EVUtMNhCaX21YE4U9jNB1jmspdiv6TNz24CYPIxS9MoQ5/X mY9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EKwvSQqhxeNm2jTsVNjvfHczeAou0iB9ktyY1+ME4WQ=; b=R2/ILERWK82/vYLgxLbeX3ROlAImoNQpk07ShpR27g0bDt3OJxQ7RzWNM+iVVTAPzh QW4iXvifzYWpKONe/WeEBfl/6PHbLL3fJAr1fDPIiCBTMe06QUmERpPPNnCijiWXi2t3 uLOj5qKk4zNqdWQ4rw9AxiLMDq0rtIEDwgcClEO6Z9mYhcterMb0Ipd6kP2rOcdXOenJ LaYCsdscl6BgPVcjoST5pmA78nL4khpLPqYSnf2VAFYKIw/DkvjWjNCSC/1pKx9Bg7XR PmAlwXk4cLzkO7pZle1AOohgVTSAaKdfF1fOQoje8m9jpeoqr/saVxaniiWGGBdPcKvh K6LA== X-Gm-Message-State: AGRZ1gIc50u2ymbN6fxBheGlt/aQHAjlOdoRCnb+bCK+LavxpLgUEfLS xLtQXdBtbrCLH3lHtDWvR8UhmoinnRWgBSI90mw= X-Google-Smtp-Source: AJdET5c7rKq2qoc8RkkYooS3/wba8fZFOPKbRQJPS4f1mirkaDR1sDvWcl6f0b9jGFcTtuRG1SfeeRH/bNMvjMbygDg= X-Received: by 2002:aca:e5d4:: with SMTP id c203-v6mr2440943oih.1.1541677255234; Thu, 08 Nov 2018 03:40:55 -0800 (PST) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> In-Reply-To: From: Mark Smith Date: Thu, 8 Nov 2018 22:40:29 +1100 Message-ID: To: Frank Brockners Cc: "C. M. Heard" , 6man WG , ippm@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] v6 option types for IOAM data fields X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 11:40:59 -0000 Hi Frank, On Thu, 8 Nov 2018 at 19:36, Frank Brockners (fbrockne) wrote: > > Hi Mark, Mike, > > > > thanks for summarizing the concerns around leaked packets =E2=80=93 and o= utlining an approach to mitigate those. There are a couple of other challen= ges we face. Unfortunately we did not get to a discussion in the 6man WG me= eting this time due to the limited time we had. The meeting slides https://= datatracker.ietf.org/meeting/103/materials/slides-103-6man-in-situ-oam-ipv6= -options-00 provide a summary of concerns. > > > > In a nutshell: > > 1. Potential HbH ext header and IOAM option insertion and removal b= y transit nodes (i.e. =E2=80=9Cen route=E2=80=9D) in a restricted administr= ative domain. > > a) How do you deal with PMTU? =E2=80=93 Packet size changes might e= xceed PMTU. > > b) Misleading ICMP errors confusing the source > > c) Possible leaks that affect the forwarding behavior and state of = network elements outside the domain. > Yes, all of the above, good summary. An additional one is that if you were are receiver of this outside of the domain because it as leaked, at the destination, after the packet as traversed a number of ASes over the Internet, there is nothing to identify the device/AS that inserted the EH. Very time consuming to troubleshoot who inserted the EH but didn't remove it (you have to walk the AS path, contacting each operator, asking them to verify their config, get packet captures etc.), and all the while you may have a number of angry customers/end-users. > 2. Incremental Trace IOAM HbH Option =E2=80=93 which is to support = a hardware-friendly implementation: Changes Option Data Len en-route. > > a) Dealing with PMTU=E2=80=93 Packet size changes can exceed PMTU; = see above > > 3. Clarify applicability statement and scope > > > > While 3. is something that is in the works, there are no easy answers to = 1. and 2. Considerations: > > > > On 1. Supporting HbH ext header and option insertion/removal in transit. = A couple of solution approaches=E2=80=A6 > > 1. Fix PMTU and offset for packet size change in PMTU discovery - h= ttps://tools.ietf.org/html/draft-troan-6man-pmtu-solution-space-00 > Hope that we can make progress towards a solution tomorrow=E2=80=A6 > > 2. IP-in-IP with IOAM extension header in the *inner* packet. > New IPv6 packet is created with encapsulating node as source and the orig= inal destination as the destination > (this is slightly different than what you, Mark, suggest =E2=80=93 becaus= e we=E2=80=99d like to keep the forwarding path the same. Tunneling with UL= A would not get us there; the slides above have a diagram that depicts the = potential encap): > > a) Payload of this packet is the original IPv6 packet along with an= extension header inserted inside. > > b) The original packet is restored by removing the outer IPv6 header= and the inner extension header by a node at the domain boundary. > > c) Caveats: > > i. Mo= dified packet may still leak =E2=80=93 but will only confuse the destinatio= n node. The dest node will likely send an ICMP back to the encap node, whic= h gets the encap node an understanding that something is going wrong. > This is certainly better, because the source address identifies the device that inserted the EH of the packet that leaked to where ever it leaked to. What the source address should be is an interesting question. If it is a global/public source address, then anybody who receives the packet leaked with the EH can identify who inserted it and therefore who didn't remove it. OTOH, if it is a private/local ULA Source Address, then BCP38 source address filters would cause the invalid leaked packet to be dropped sooner, rather than being forwarded onto the final destination. Total packet loss of OAM encapsulated packets would make the failure obvious to the OAM domain operator. Slight drawback is BCP38 filters haven't been universally implemented across the Internet. I think I like the latter better because commonly it would localise the symptoms of the failure to remove the EH to the domain that inserted it, rather than having to have an external party get involved in troubleshooting. > ii. ECM= P computation needs to be reworked. > > iii. Comp= lex/costly implementation in HW & SW =E2=80=93 IOAM-capable nodes need to h= unt for the IOAM data fields in the inner packet. > Yes, the implementation complexity of insertion is another concern - encapsulation is the most common and simplest cross layer forwarding function performed and there's decades of history in optimising it. The root cause of both the possible leak and the risk that the inserted EH will reach the final packet destination is that the Dest. Addr. of the packet with the inserted EH is both valid outside of the domain, and valid all the way across the Internet to the final and actual original packet destination. That creates a "default permit" if a packet leaks with the inserted EH rather than a far better "default deny" in this failure situation. In this OAM case, it seems to me the ideal and the requirements would be: - have the packet with the added OAM information follow the same path within the domain that the same packet without the OAM information would follow within the domain - have the Dest. Addr. of the packet with the added OAM information only be valid within the OAM domain i.e. an "interior DA", so that if through failure the packet leaks, it isn't a valid DA on the Internet and will be dropped by, if nothing else earlier, an Internet router with a default free route table. - encapsulate rather than insert, because encapsulation would be simpler, and is the traditional way of adding information to PDUs across many decades and many protocols (I can only think of VLAN ID insertion as the only existing counter example, and according to Radia Perlman in her book, that is only because at the time they weren't sure if all NICs commonly available could successfully encapsulate a full sized ethernet frame inside another one). In other words, preserve the original IPv6 packet, add an OAM header in front of it, then encapsulate it in another header to forward within and across the OAM domain. Bog standard IGP/LDP MPLS could achieve those requirements, with the OAM header inserted after the final MPLS tag and before the IPv6 header. The MPLS/OAM/IPv6 packet follows an LSP across the domain that matches the path that the IPv6 packet without MPLS would follow across the domain. In that scenario, the MPLS LSP across the domain is the "interior DA" that isn't valid outside of the OAM domain, because MPLS wouldn't (normally) be valid outside of the OAM domain (i.e. OAM domain is MPLS domain 1:1). If MPLS fails to be removed at the OAM domain egress edge, the packet is dropped immediately, so a fail safe, localised to the OAM domain. For an IPv6-in-IPv6 scenario: - for each OAM domain interior IPv6 routes/prefixes used by hosts (i.e. hosts have addresses from these prefixes), automatically create a matching interior OAM route/prefix (maybe just a /128), 1:1, with the interior OAM route/prefix originated by the same router(s) where the interior IPv6 routes/prefixes are created/originated. The interior OAM routes come from ULA space or perhaps a new designated and reserved private/local OAM address space for this purpose. When a end host originated packet ingresses the OAM domain edge, the DA address of the packet is looked up to find the 1:1 matching internal OAM route/prefix/address. This internal OAM route/prefix/address is used as the DA for the outer IPv6 header, outer header SA is the OAM address of the OAM ingress device, an OAM header follows, and then the original, inner IPv6 packet follows without modification. As the OAM route/prefix/address is originated at the same place as the OAM domain interior IPv6 route/prefix, the path the now IPv6-in-IPv6 packet follows through the OAM domain should be the same as that which the original, now inner packet would have followed with its DA. In a sense this OAM route/prefix/address is an internal routeable index or proxy for the inner packet destination prefix. - for exterior routes, IPv6-in-IPv6 tunnelling too between BGP border routers per RFC1772, "A.2.3 Encapsulation", with the addition of the OAM header between the new outer IPv6 header and the inner original IPv6 packet, and OAM local addresses for the tunnel end points. This avoids having to create 1:1 matching internal OAM route/prefix/address for each exterior route. (And perhaps a somewhat radical idea for reducing tunnelling overhead. All of this tunnelling stuff already exists for IPv4; and it is sunk cost. Would there be much harm in using IPv4 as the interior outer tunnelling protocol for this IPv6 traffic with the added OAM information? I'd much rather keep running an IPv4 OAM island to carry IPv6 than any splitting apart of IPv6 packets to insert EHs in them ...) > 3. No support of IOAM in transit network. Support only source initi= ated IOAM tracing, proof of transit.. > Caveat: Limits usage of IOAM significantly. > > > On 2. Incremental Trace IOAM HbH Option > > 1. Use PMTU to determine max possible Incremental Trace IOAM Option= length > > 2. Do not support Incremental Trace IOAM Option in IPv6. > > Could what I've suggested above solve those? I think the use of tunnelling/encapsulation supports a transit OAM scenario. Regards, Mark. > > While there isn=E2=80=99t an easy answer, IMHO we should still try to fin= d a workable and implementable solution. I sometimes compare the situation = with the road network: What we have today is a network of gravel roads (Int= ernet with often poor ext header processing) and cars are built to cope wit= h gravel roads. Now faster and comfy cars become available, though they onl= y work on tared/concrete roads (specific administrative domains). If you tr= y to drive these new cars on gravel roads they break and the wrecks jam the= roads=E2=80=A6, still we probably want to allow folks to buy and use the f= ast & comfy cars, because they will also push for better roads as well (do= proper ext header processing). > > > > Thoughts? > > > > Thanks, Frank > > > > > > From: Mark Smith > Sent: Dienstag, 30. Oktober 2018 05:26 > To: Frank Brockners (fbrockne) > Cc: C. M. Heard ; 6man WG ; ippm@ietf.org > Subject: Re: v6 option types for IOAM data fields > > > > > Hi Frank, > > > > On Tue., 30 Oct. 2018, 05:36 Frank Brockners (fbrockne), wrote: > > Thanks Mike. On the scope of an IOAM deployment: > draft-ietf-ippm-ioam-data-04 clarifies in section 3 that IOAM is a domain= focused feature, i.e. not expected to be deployed on the open Internet. > > > > That still violates RFC 8200, there are no exceptions for "closed" domain= s. > > > > From section 3: > > > > "Designers of > > carrier protocols for IOAM must specify mechanisms to ensure that > > IOAM 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." > > > > Neither the designers or the operators can ensure this IOAM information w= on't leak. > > > > Possible reasons it can leak: > > > > - operator configuration error - e.g. forgetting to configure the domain = boundary (e.g. router with multiple domain exit interfaces, forgetting to a= dd that option on one of them), or misconfiguring it. > > > > - partial device failure - the device still forwards packets, but ceases = to remove this information due to a hardware fault that has appeared > > > > - vendor implementation bugs that fails to remove the information. > > > > Any or all of these can occur, and as it is on egress, the consequences m= ay not be visible to the domain network operator, because network operators= rarely inspect packets after they've left their network. Once a packet is = sent onto somebody else, it is assumed to have been sent without faults. > > > > There are many instances of leaks at the boundary of what are supposed to= be closed domains, such as packets containing RFC1918 private addresses (i= n packet headers themselves, or in DNS packets - such a big problem that ww= w.as112.net was created), and route leaks e.g. https://bgpmon.net/how-the-i= nternet-in-australia-went-down-under/ > > > > As operators usually have only one device at the edge of the domain, that= would be performing the domain boundary function, that device becomes a si= ngle point of failure. Enforcement is therefore quite fragile. A domain bou= ndary enforced by two domain edge devices in-line would increase robustness= , however I'd think that would be rarely deployed, because we haven't seen = that commonly with IPv4 NAT. > > > > The only way for an operator to ensure these leaks don't and never occur = is for the domain to literally not be physically connected to the Internet = i.e. the domain is air gapped from the Internet. If there is a link between= the domain and the Internet that can carry IP packets, then there is alway= s a possibility that information can leak from the domain. > > > > So accepting that leaks can always occur, a far more robust option is to = leave the original packet alone entirely, and encapsulate it in a domain lo= cal IPv6 header (i.e RFC2473, section 3.1) with domain local limited addres= ses (i.e. ULA addresses) and the additional EH. > > > > That still doesn't ensure that packet won't leak outside the domain, beca= use those packets will follow a default route, however as the packet's addr= essing is invalid outside of the domain, that packet will be dropped once i= t reaches either an invalid Internet address filter, or a default free Inte= rnet router. The packet with the failed-to-be-removed outer ULA IPv6 header= will never reach the destination address of the inner packet, because the = DA of the inner packet is in the ULA IPv6 packet's payload. > > > > Failure of the mechanism would be much more obvious, localised to the dom= ain implementing the mechanism (rather than being externalised to somebody = else's domain/network), and absolute, because the failure mode is packets b= eing entirely discarded. > > > > Regards, > > Mark. > > > > > > > Frank > > -----Original Message----- > From: C. M. Heard > Sent: Montag, 29. Oktober 2018 16:03 > To: 6man ; IPPM > Cc: Frank Brockners (fbrockne) > Subject: Re: v6 option types for IOAM data fields > > On Thu, 25 Oct 2018 15:06:57 +0000 Frank Brockners (fbrockne) wrote: > > Quick heads up: In the 6MAN meeting in BKK, we=E2=80=99ll review > > draft-ioametal-ippm-6man-ioam-ipv6-options-01 =E2=80=93 which requests = 2 > > option types from the DO/HbyH options sub-registry. > > > > While the bulk of the IOAM work is progressed in the IPPM WG, we=E2=80= =99d > > greatly appreciate your feedback on > > draft-ioametal-ippm-6man-ioam-ipv6-options-01, > > which defines how IOAM data fields are carried using v6 extension heade= rs. > > Cc=E2=80=99ing the IPPM WG as well, to keep everyone on the same page. > > I have two brief comments on this work. > > First, I see that the Incremental Tracing Option changes length in transi= t. > It is not appropriate for it to be carried in an IPv6 option intended for= use on the open Internet, for exactly the same reason that insertion of ex= tension headers by intermediate nodes is not allowed on the open Internet. > > Second, I see that two IPv6 option code points are requested, one with th= e "chg" flag set, the other with the "chg" flag clear. While there is no ha= rm in this, it is not strictly necessary; the only real purpose of this fla= g is to determine whether the option data is or is not included in the Auth= entication Header Integrity Check Value computation. > > Mike Heard > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Nov 8 13:52:48 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B0F130DBE for ; Thu, 8 Nov 2018 13:52:46 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 gX8bOyFKYHnl for ; Thu, 8 Nov 2018 13:52:42 -0800 (PST) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 F284C12D4E8 for ; Thu, 8 Nov 2018 13:52:41 -0800 (PST) Received: by mail-yb1-xb35.google.com with SMTP id i78-v6so9006648ybg.0 for ; Thu, 08 Nov 2018 13:52:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DqrJe7msw4lCWCxsLxd+g7Mw++YWCAsJdl9W7xSXzbs=; b=tQaw/MmbJ2TBVY71ukrI8SIPzLPcV+Jpyigu4UFzA+w32unWULS5HBYrXQq4tFSVx5 fDaHJjSefXPbtwzw4H8C4fXAVaQWWrpQhJtosBUfc+3zyXoiijCc25LgXKtMKU7jst6C Eb2FhQ3EdU5WCTOvEs0molm9qvCkFXPiAHGhdoDX9C/7zw0i3NFzq2xqBSUQNDrtalF6 ZEffqJKBhEyI5i+xzH9kw1LXcAQVawuHlT5XTTMmKMyYleVFEQUZXaFNNJzFcitoMfRo TBJLMy2aQUJEcRgTzLT2bnY/RJY/uQxBhDmp4zXiKiAoWP2rUcn4n3VieZ+GQElK6DOf 8BRQ== 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=DqrJe7msw4lCWCxsLxd+g7Mw++YWCAsJdl9W7xSXzbs=; b=GVNrdZV7wBBHm8yRKHxmPMeRdiuRrNrQqMJ3oo12FVJ8SPDrSLJrLxgcFSaU26oGSZ ct1UCzaR7xPknISs6HD/okot3baqqHoHAMstrHtnkyN3H3lNQSBJPGI2xOBe4wUYeF7G z4fnmp+e5aJdAI+dnJFzkRMtmIvmVDBf2AdacuiCDnVl+dkg7hShvAORbqJfEqJH57LT BX2Xe3Vo+y2A76Tl/0o8Iu0WplXe+xThEkLLjRdSvmprYWB0oSffC+pELYOJVO29XHmV QFcbXKjCrmGiQFdrsOAtc5E+DEZYYUtex9g0mCcOFVO/t1UvcxY+dDihrYimddJwSeZb ehUA== X-Gm-Message-State: AGRZ1gJKGFbMAqYPAVy2Ir/nLzru/Pa60OjIkpLz/t893C0hWg7cOk5T z2sMqM3Oil5mIOIOJNpTCpj5MfZjvNvhMnlG/Gxchw== X-Google-Smtp-Source: AJdET5dV0nnbDo5kmhocvjZq9MAZtpnk80/8nVCnmRo5m+Zol+1DBs6hMjBJ2hj5z6plKdIPxSSJvyXysNA77w94hSs= X-Received: by 2002:a0c:ec92:: with SMTP id u18mr6516223qvo.168.1541713960906; Thu, 08 Nov 2018 13:52:40 -0800 (PST) MIME-Version: 1.0 Received: by 2002:aed:2022:0:0:0:0:0 with HTTP; Thu, 8 Nov 2018 13:52:40 -0800 (PST) In-Reply-To: References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> From: Tom Herbert Date: Thu, 8 Nov 2018 13:52:40 -0800 Message-ID: To: "Frank Brockners (fbrockne)" Cc: Mark Smith , "C. M. Heard" , 6man WG , "ippm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fc4219057a2e4041" Archived-At: Subject: Re: [ippm] v6 option types for IOAM data fields X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 08 Nov 2018 21:52:47 -0000 --000000000000fc4219057a2e4041 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 8, 2018, 12:37 AM Frank Brockners (fbrockne) wrote: > Hi Mark, Mike, > > > > thanks for summarizing the concerns around leaked packets =E2=80=93 and o= utlining > an approach to mitigate those. There are a couple of other challenges we > face. Unfortunately we did not get to a discussion in the 6man WG meeting > this time due to the limited time we had. The meeting slides > https://datatracker.ietf.org/meeting/103/materials/slides- > 103-6man-in-situ-oam-ipv6-options-00 provide a summary of concerns. > > > > In a nutshell: > > 1. Potential HbH ext header and IOAM option insertion and removal > by transit nodes (i.e. =E2=80=9Cen route=E2=80=9D) in a restricted admini= strative domain. > > a) How do you deal with PMTU? =E2=80=93 Packet size changes might e= xceed > PMTU. > > b) Misleading ICMP errors confusing the source > > c) Possible leaks that affect the forwarding behavior and state of > network elements outside the domain. > There's already been significant discussion in 6man list about option insertion/removal. I believe the conclusion is that RFC8200 prohibits it exactly for the reasons listed above and maybe a few others. I don't think that restricting the use to a limited domain is sufficient rationale to create an exception. As mentioned previously, encapsulation can be used to achieve the proper effect. > 2. Incremental Trace IOAM HbH Option =E2=80=93 which is to support = a > hardware-friendly implementation: Changes Option Data Len en-route. > > a) Dealing with PMTU=E2=80=93 Packet size changes can exceed PMTU; = see above > This has basically the same problems as option insertion. RFC8200 only allow Option Data to be changeable en route, and that is only if the third bit of the option type is set. Here are two other issues for these: - No accountability as to who changed the packet in flight - They break authentication header > 3. Clarify applicability statement and scope > > > > While 3. is something that is in the works, there are no easy answers to > 1. and 2. Considerations: > > > > On 1. Supporting HbH ext header and option insertion/removal in transit. = A > couple of solution approaches=E2=80=A6 > > 1. Fix PMTU and offset for packet size change in PMTU discovery - > https://tools.ietf.org/html/draft-troan-6man-pmtu-solution-space-00 > Hope that we can make progress towards a solution tomorrow=E2=80=A6 > > 2. IP-in-IP with IOAM extension header in the **inner** packet. > New IPv6 packet is created with encapsulating node as source and the > original destination as the destination > (this is slightly different than what you, Mark, suggest =E2=80=93 becaus= e we=E2=80=99d > like to keep the forwarding path the same. Tunneling with ULA would not g= et > us there; the slides above have a diagram that depicts the potential enca= p): > > a) Payload of this packet is the original IPv6 packet along with an > extension header inserted inside. > > b) The original packet is restored by removing the outer IPv6 header > and the inner extension header by a node at the domain boundary. > > c) Caveats: > > i. Mo= dified > packet may still leak =E2=80=93 but will only confuse the destination nod= e. The > dest node will likely send an ICMP back to the encap node, which gets the > encap node an understanding that something is going wrong. > > ii. ECM= P > computation needs to be reworked. > > iii. Comp= lex/costly > implementation in HW & SW =E2=80=93 IOAM-capable nodes need to hunt for t= he IOAM > data fields in the inner packet. > > 3. No support of IOAM in transit network. Support only source > initiated IOAM tracing, proof of transit.. > Caveat: Limits usage of IOAM significantly. > > > > On 2. Incremental Trace IOAM HbH Option > > 1. Use PMTU to determine max possible Incremental Trace IOAM Option > length > > 2. Do not support Incremental Trace IOAM Option in IPv6. > > > > While there isn=E2=80=99t an easy answer, IMHO we should still try to fin= d a > workable and implementable solution. I sometimes compare the situation wi= th > the road network: What we have today is a network of gravel roads (Intern= et > with often poor ext header processing) and cars are built to cope with > gravel roads. Now faster and comfy cars become available, though they onl= y > work on tared/concrete roads (specific administrative domains). If you tr= y > to drive these new cars on gravel roads they break and the wrecks jam the > roads=E2=80=A6, still we probably want to allow folks to buy and use the = fast & > comfy cars, because they will also push for better roads as well (do > proper ext header processing). > > > > Thoughts? > > > > Thanks, Frank > > > > > > *From:* Mark Smith > *Sent:* Dienstag, 30. Oktober 2018 05:26 > *To:* Frank Brockners (fbrockne) > *Cc:* C. M. Heard ; 6man WG ; > ippm@ietf.org > *Subject:* Re: v6 option types for IOAM data fields > > > > > Hi Frank, > > > > On Tue., 30 Oct. 2018, 05:36 Frank Brockners (fbrockne), < > fbrockne@cisco.com> wrote: > > Thanks Mike. On the scope of an IOAM deployment: > draft-ietf-ippm-ioam-data-04 clarifies in section 3 that IOAM is a domain > focused feature, i.e. not expected to be deployed on the open Internet. > > > > That still violates RFC 8200, there are no exceptions for "closed" domain= s. > > > > From section 3: > > > > "Designers of > > carrier protocols for IOAM must specify mechanisms to ensure that > > IOAM 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." > > > > Neither the designers or the operators can ensure this IOAM information > won't leak. > > > > Possible reasons it can leak: > > > > - operator configuration error - e.g. forgetting to configure the domain > boundary (e.g. router with multiple domain exit interfaces, forgetting to > add that option on one of them), or misconfiguring it. > > > > - partial device failure - the device still forwards packets, but ceases > to remove this information due to a hardware fault that has appeared > > > > - vendor implementation bugs that fails to remove the information. > > > > Any or all of these can occur, and as it is on egress, the consequences > may not be visible to the domain network operator, because network > operators rarely inspect packets after they've left their network. Once a > packet is sent onto somebody else, it is assumed to have been sent withou= t > faults. > > > > There are many instances of leaks at the boundary of what are supposed to > be closed domains, such as packets containing RFC1918 private addresses (= in > packet headers themselves, or in DNS packets - such a big problem that ww= w.a > s112.net was created), and route leaks e.g. > https://bgpmon.net/how-the-internet-in-australia-went-down-under/ > > > > As operators usually have only one device at the edge of the domain, that > would be performing the domain boundary function, that device becomes a > single point of failure. Enforcement is therefore quite fragile. A domain > boundary enforced by two domain edge devices in-line would increase > robustness, however I'd think that would be rarely deployed, because we > haven't seen that commonly with IPv4 NAT. > > > > The only way for an operator to ensure these leaks don't and never occur > is for the domain to literally not be physically connected to the Interne= t > i.e. the domain is air gapped from the Internet. If there is a link betwe= en > the domain and the Internet that can carry IP packets, then there is alwa= ys > a possibility that information can leak from the domain. > > > > So accepting that leaks can always occur, a far more robust option is to > leave the original packet alone entirely, and encapsulate it in a domain > local IPv6 header (i.e RFC2473, section 3.1) with domain local limited > addresses (i.e. ULA addresses) and the additional EH. > > > > That still doesn't ensure that packet won't leak outside the domain, > because those packets will follow a default route, however as the packet'= s > addressing is invalid outside of the domain, that packet will be dropped > once it reaches either an invalid Internet address filter, or a default > free Internet router. The packet with the failed-to-be-removed outer ULA > IPv6 header will never reach the destination address of the inner packet, > because the DA of the inner packet is in the ULA IPv6 packet's payload. > > > > Failure of the mechanism would be much more obvious, localised to the > domain implementing the mechanism (rather than being externalised to > somebody else's domain/network), and absolute, because the failure mode i= s > packets being entirely discarded. > > > > Regards, > > Mark. > > > > > > > Frank > > -----Original Message----- > From: C. M. Heard > Sent: Montag, 29. Oktober 2018 16:03 > To: 6man ; IPPM > Cc: Frank Brockners (fbrockne) > Subject: Re: v6 option types for IOAM data fields > > On Thu, 25 Oct 2018 15:06:57 +0000 Frank Brockners (fbrockne) wrote: > > Quick heads up: In the 6MAN meeting in BKK, we=E2=80=99ll review > > draft-ioametal-ippm-6man-ioam-ipv6-options-01 =E2=80=93 which requests = 2 > > option types from the DO/HbyH options sub-registry. > > > > While the bulk of the IOAM work is progressed in the IPPM WG, we=E2=80= =99d > > greatly appreciate your feedback on > > draft-ioametal-ippm-6man-ioam-ipv6-options-01, > > which defines how IOAM data fields are carried using v6 extension > headers. > > Cc=E2=80=99ing the IPPM WG as well, to keep everyone on the same page. > > I have two brief comments on this work. > > First, I see that the Incremental Tracing Option changes length in transi= t. > It is not appropriate for it to be carried in an IPv6 option intended for > use on the open Internet, for exactly the same reason that insertion of > extension headers by intermediate nodes is not allowed on the open Intern= et. > > Second, I see that two IPv6 option code points are requested, one with th= e > "chg" flag set, the other with the "chg" flag clear. While there is no ha= rm > in this, it is not strictly necessary; the only real purpose of this flag > is to determine whether the option data is or is not included in the > Authentication Header Integrity Check Value computation. > > Mike Heard > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000fc4219057a2e4041 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 8, 2018, 12:37 AM Frank Brockners (fbrockne) &= lt;fbrockne@cisco.c= om> wrote:

Hi Mark, Mike,

=C2=A0

thanks for summarizing= the concerns around leaked packets =E2=80=93 and outlining an approach to = mitigate those. There are a couple of other challenges we face. Unfortunately we did not get to a discussion = in the 6man WG meeting this time due to the limited time we had. The meetin= g slides https://datatracker.ietf.org/meet= ing/103/materials/slides-103-6man-in-situ-oam-ipv6-options-00 provide a summary of concerns.

=C2=A0

In a nutshell:<= u>

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Potential HbH ext= header and IOAM option insertion and removal by transit nodes (i.e. =E2=80= =9Cen route=E2=80=9D) in a restricted administrative domain.

a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 How do you deal w= ith PMTU? =E2=80=93 Packet size changes might exceed PMTU.

b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Misleading ICMP e= rrors confusing the source

c)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Possible leaks th= at affect the forwarding behavior and state of network elements outside the= domain.

<= br>
There's already been significant discussion = in 6man list about option insertion/removal. I believe the conclusion is th= at RFC8200 prohibits it exactly for the reasons listed above and maybe a fe= w others. I don't think that restricting the use to a limited domain is= sufficient rationale to create an exception. As mentioned previously, enca= psulation can be used to achieve the proper effect.
=

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Incremental Trace= IOAM HbH Option =E2=80=93 which is to support a hardware-friendly implemen= tation: Changes Option Data Len en-route.

a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Dealing with PMTU= =E2=80=93 Packet size changes can exceed PMTU; see above


This has basically the same problems a= s option insertion. RFC8200 only allow Option Data to be changeable en rout= e, and that is only if the third bit of the option type is set.
<= br>
Here are two other issues for these:

- No accountability as to who changed the packet in flight
- The= y break authentication header

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Clarify applicabi= lity statement and scope

=C2=A0

While 3. is something = that is in the works, there are no easy answers to 1. and 2. Considerations= :

=C2=A0

On 1. Supporting HbH e= xt header and option insertion/removal in transit. A couple of solution app= roaches=E2=80=A6

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Fix PMTU and offs= et for packet size change in PMTU discovery - https://tools.ietf.org/html/= draft-troan-6man-pmtu-solution-space-00
Hope that we can make progress towards a solution tomorrow=E2=80=A6<= u>

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IP-in-IP with IOA= M extension header in the *inner* packet.
New IPv6 packet is created with encapsulating node as source and the origin= al destination as the destination
(this is slightly different than what you, Mark, suggest =E2=80=93 because = we=E2=80=99d like to keep the forwarding path the same. Tunneling with ULA = would not get us there; the slides above have a diagram that depicts the po= tential encap):

a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Payload of this p= acket is the original IPv6 packet along with an extension header inserted i= nside.

b)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The original pack= et is restored by removing the outer IPv6 header and the inner extension he= ader by a node at the domain boundary.

c)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Caveats:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 i.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Modified packet may still leak =E2=80=93 but will only confuse the destination node. The dest node will likely send an ICMP back to the e= ncap node, which gets the encap node an understanding that something is goi= ng wrong.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ii.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ECMP computation needs to be reworked.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 iii.=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Complex/costly implementation in HW & SW =E2=80=93 IOAM-capable nodes need to hunt for the IOAM data fields in the inner packet.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No support of IOA= M in transit network. Support only source initiated IOAM tracing, proof of = transit..
Caveat: Limits usage of IOAM significantly.

=C2=A0

On 2. Incremental Trac= e IOAM HbH Option

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Use PMTU to deter= mine max possible Incremental Trace IOAM Option length=

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do not support In= cremental Trace IOAM Option in IPv6.

=C2=A0

While there isn=E2=80= =99t an easy answer, IMHO we should still try to find a workable and implem= entable solution. I sometimes compare the situation with the road network: What we have today is a netwo= rk of gravel roads (Internet with often poor ext header processing) and car= s are built to cope with gravel roads. Now faster and comfy cars become ava= ilable, though they only work on tared/concrete roads (specific administrative domains). If you try to driv= e these new cars on gravel roads they break and the wrecks jam the roads=E2= =80=A6, still we probably want to allow folks to buy and use the fast &= comfy cars, because they will also push for better roads =C2=A0as well (do proper ext header processing).

=C2=A0

Thoughts?

=C2=A0

Thanks, Frank

=C2=A0

=C2=A0

From: = Mark Smith <markzzzsmith@gmail.com>
Sent: Dienstag, 30. Oktober 2018 05:26
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>
Cc: C. M. Heard <heard@pobox.com>; 6man WG <ipv6@ietf.org&g= t;; i= ppm@ietf.org
Subject: Re: v6 option types for IOAM data fields

=C2=A0


Hi Frank,

=C2=A0

On Tue., 30 Oct. 2018, 05:36 Frank Brockners (fbrock= ne), <fbrockne@cisco.com> wrote:

Thanks Mike. On the scope of an IOAM deployment: draft-ietf-ippm-ioam-data-04 clarifies in section 3 that IOAM is a domain f= ocused feature, i.e. not expected to be deployed on the open Internet.

=C2=A0

That still violates RFC 8200, there are no exception= s for "closed" domains.

=C2=A0

From section 3:

=C2=A0

"Designers of

=C2=A0 =C2=A0carrier protocols for IOAM must specify= mechanisms to ensure that

=C2=A0 =C2=A0IOAM data stays within an IOAM domain.= =C2=A0 In addition, the operator of

=C2=A0 =C2=A0such a domain is expected to put provis= ions in place to ensure that

=C2=A0 =C2=A0IOAM data does not leak beyond the edge= of an IOAM domain, e.g. using

=C2=A0 =C2=A0for example packet filtering methods.&q= uot;

=C2=A0

Neither the designers or the operators can ensure th= is IOAM information won't leak.

=C2=A0

Possible reasons it can leak:

=C2=A0

- operator configuration error - e.g. forgetting to = configure the domain boundary (e.g. router with multiple domain exit interf= aces, forgetting to add that option on one of them), or misconfiguring it.<= u>

=C2=A0

- partial device failure - the device still forwards= packets, but ceases to remove this information due to a hardware fault tha= t has appeared

=C2=A0

- vendor implementation bugs that fails to remove th= e information.

=C2=A0

Any or all of these can occur, and as it is on egres= s, the consequences may not be visible to the domain network operator, beca= use network operators rarely inspect packets after they've left their n= etwork. Once a packet is sent onto somebody else, it is assumed to have been sent without faults.

=C2=A0

There are many instances of leaks at the boundary of= what are supposed to be closed domains, such as packets containing RFC1918= private addresses (in packet headers themselves, or in DNS packets - such = a big problem that www.as112.net=C2=A0was created), and route leaks e.g. https://bgpmon.net/how-the-internet-in-australia-went-down-under/=

=C2=A0

As operators usually have only one device at the edg= e of the domain, that would be performing the domain boundary function, tha= t device becomes a single point of failure. Enforcement is therefore quite = fragile. A domain boundary enforced by two domain edge devices in-line would increase robustness, however I= 9;d think that would be rarely deployed, because we haven't seen that c= ommonly with IPv4 NAT.

=C2=A0

The only way for an operator to ensure these leaks d= on't and never occur is for the domain to literally not be physically c= onnected to the Internet i.e. the domain is air gapped from the Internet. I= f there is a link between the domain and the Internet that can carry IP packets, then there is always a possibility= that information can leak from the domain.

=C2=A0

So accepting that leaks can always occur, a far more= robust option is to leave the original packet alone entirely, and encapsul= ate it in a domain local IPv6 header (i.e RFC2473, section 3.1) with domain= local limited addresses (i.e. ULA addresses) and the additional EH.

=C2=A0

That still doesn't ensure that packet won't = leak outside the domain, because those packets will follow a default route,= however as the packet's addressing is invalid outside of the domain, t= hat packet will be dropped once it reaches either an invalid Internet address filter, or a default free Internet router. The= packet with the failed-to-be-removed outer ULA IPv6 header will never reac= h the destination address of the inner packet, because the DA of the inner = packet is in the ULA IPv6 packet's payload.

=C2=A0

Failure of the mechanism would be much more obvious,= localised to the domain implementing the mechanism (rather than being exte= rnalised to somebody else's domain/network), and absolute, because the = failure mode is packets being entirely discarded.

=C2=A0

Regards,

Mark.

=C2=A0

=C2=A0


Frank

-----Original Message-----
From: C. M. Heard <heard@pobox.com>
Sent: Montag, 29. Oktober 2018 16:03
To: 6man <ipv6@ietf.org>; IPPM <ippm@ietf.org>
Cc: Frank Brockners (fbrockne) <fbrockne@cisco.com>
Subject: Re: v6 option types for IOAM data fields

On Thu, 25 Oct 2018 15:06:57 +0000 Frank Brockners (fbrockne) wrote:
> Quick heads up: In the 6MAN meeting in BKK, we=E2=80=99ll review
> draft-ioametal-ippm-6man-ioam-ipv6-options-01 =E2=80=93 which req= uests 2
> option types from the DO/HbyH options sub-registry.
>
> While the bulk of the IOAM work is progressed in the IPPM WG, we=E2=80= =99d
> greatly appreciate your feedback on
> draft-ioametal-ippm-6man-ioam-ipv6-options-01,
> which defines how IOAM data fields are carried using v6 extension head= ers.
> Cc=E2=80=99ing the IPPM WG as well, to keep everyone on the same page.=

I have two brief comments on this work.

First, I see that the Incremental Tracing Option changes length in transit.=
It is not appropriate for it to be carried in an IPv6 option intended for u= se on the open Internet, for exactly the same reason that insertion of exte= nsion headers by intermediate nodes is not allowed on the open Internet.
Second, I see that two IPv6 option code points are requested, one with the = "chg" flag set, the other with the "chg" flag clear. Wh= ile there is no harm in this, it is not strictly necessary; the only real p= urpose of this flag is to determine whether the option data is or is not included in the Authentication Header Integrity Check Va= lue computation.

Mike Heard
-----------------------------------------------------------------= ---
IETF IPv6 working group mailing list
ipv6@= ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------= ---

-----------------------------------------------------------------= ---
IETF IPv6 working group mailing list
ipv6@= ietf.org
Administrative Requests: https://www.ietf.org/m= ailman/listinfo/ipv6
-----------------------------------------------------------------= ---
--000000000000fc4219057a2e4041-- From nobody Fri Nov 9 08:30:34 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C7F128CE4 for ; Fri, 9 Nov 2018 08:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, 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 bDuIKFAnVc7D for ; Fri, 9 Nov 2018 08:30:32 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4072912D4F0 for ; Fri, 9 Nov 2018 08:30:32 -0800 (PST) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wA9GQPB8037472; Fri, 9 Nov 2018 11:30:28 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by mx0a-00191d01.pphosted.com with ESMTP id 2nnaqd6hvg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Nov 2018 11:30:27 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA9GUO48051783; Fri, 9 Nov 2018 10:30:25 -0600 Received: from zlp30497.vci.att.com (zlp30497.vci.att.com [135.46.181.156]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wA9GUIge051501; Fri, 9 Nov 2018 10:30:18 -0600 Received: from zlp30497.vci.att.com (zlp30497.vci.att.com [127.0.0.1]) by zlp30497.vci.att.com (Service) with ESMTP id C41614014200; Fri, 9 Nov 2018 16:30:18 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30497.vci.att.com (Service) with ESMTP id 9EBF84014208; Fri, 9 Nov 2018 16:30:18 +0000 (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 wA9GUIfS028602; Fri, 9 Nov 2018 10:30:18 -0600 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 wA9GU3d3025550; Fri, 9 Nov 2018 10:30:03 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-blue.research.att.com (Postfix) with ESMTP id 85A4FF1D90; Fri, 9 Nov 2018 11:30:02 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Fri, 9 Nov 2018 11:29:12 -0500 From: "MORTON, ALFRED C (AL)" To: RFC Errata System , "CIAVATTONE, LEN" , "spencerdawkins.ietf@gmail.com" , "ietf@kuehlewind.net" , "ietf@wjcerveny.com" , "ietf@trammell.ch" , "tpauly@apple.com" CC: "prabhjot.sethi@gmail.com" , "ippm@ietf.org" Thread-Topic: [Technical Errata Reported] RFC6038 (5549) Thread-Index: AQHUdlKcvG1ZSaDbskuriHI+UlJysaVHpNAA Date: Fri, 9 Nov 2018 16:29:11 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557DDDB0@njmtexg5.research.att.com> References: <20181107043043.5854CB80EE3@rfc-editor.org> In-Reply-To: <20181107043043.5854CB80EE3@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.154.99] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-09_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811090150 Archived-At: Subject: Re: [ippm] [Technical Errata Reported] RFC6038 (5549) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 09 Nov 2018 16:30:33 -0000 SXQgbG9va3MgbGlrZSB0aGlzIEVycmF0YSBzaG91bGQgYmUgdmVyaWZpZWQuDQoNCkEgc2ltaWxh ciBwb2ludCB3YXMgdmVyaWZpZWQgaW4gUkZDIDUzNTcgKGxhc3QgeWVhcik6DQpodHRwczovL3d3 dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNTA0Ng0KDQpBbA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IFJGQyBFcnJhdGEgU3lzdGVtIFttYWlsdG86cmZjLWVkaXRv ckByZmMtZWRpdG9yLm9yZ10NCj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgNiwgMjAxOCAxMToz MSBQTQ0KPiBUbzogTU9SVE9OLCBBTEZSRUQgQyAoQUwpIDxhY21AcmVzZWFyY2guYXR0LmNvbT47 IENJQVZBVFRPTkUsIExFTg0KPiA8bGM5ODkyQGF0dC5jb20+OyBzcGVuY2VyZGF3a2lucy5pZXRm QGdtYWlsLmNvbTsgaWV0ZkBrdWVobGV3aW5kLm5ldDsNCj4gaWV0ZkB3amNlcnZlbnkuY29tOyBp ZXRmQHRyYW1tZWxsLmNoOyB0cGF1bHlAYXBwbGUuY29tDQo+IENjOiBwcmFiaGpvdC5zZXRoaUBn bWFpbC5jb207IGlwcG1AaWV0Zi5vcmc7IHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcNCj4gU3Vi amVjdDogW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzYwMzggKDU1NDkpDQo+IA0KPiBU aGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM2MDM4 LA0KPiAiVHdvLVdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgKFRXQU1QKSBSZWZsZWN0 IE9jdGV0cyBhbmQNCj4gU3ltbWV0cmljYWwgU2l6ZSBGZWF0dXJlcyIuDQo+IA0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBZb3UgbWF5IHJldmlldyB0aGUgcmVw b3J0IGJlbG93IGFuZCBhdDoNCj4gaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhL2Vp ZDU1NDkNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFR5 cGU6IFRlY2huaWNhbA0KPiBSZXBvcnRlZCBieTogUHJhYmhqb3QgU2luZ2ggU2V0aGkgPHByYWJo am90LnNldGhpQGdtYWlsLmNvbT4NCj4gDQo+IFNlY3Rpb246IDUuMS41DQo+IA0KPiBPcmlnaW5h bCBUZXh0DQo+IC0tLS0tLS0tLS0tLS0NCj4gSW4gdGhpcyBjb21iaW5lZCBtb2RlLCB0aGUgUGFj a2V0IFBhZGRpbmcgdG8gYmUgcmVmbGVjdGVkIGZvbGxvd3MgdGhlDQo+IDI3IE1CWiBvY3RldHMu ICBJbiBBdXRoZW50aWNhdGVkIG9yIEVuY3J5cHRlZCBtb2RlcywgdGhlIFBhY2tldA0KPiBQYWRk aW5nIHRvIGJlIHJlZmxlY3RlZCBmb2xsb3dzIHRoZSA1NiBNQlogb2N0ZXRzLg0KPiANCj4gQ29y cmVjdGVkIFRleHQNCj4gLS0tLS0tLS0tLS0tLS0NCj4gSW4gdGhpcyBjb21iaW5lZCBtb2RlLCB0 aGUgUGFja2V0IFBhZGRpbmcgdG8gYmUgcmVmbGVjdGVkIGZvbGxvd3MgdGhlDQo+IDI3IE1CWiBv Y3RldHMuICBJbiBBdXRoZW50aWNhdGVkIG9yIEVuY3J5cHRlZCBtb2RlcywgdGhlIFBhY2tldA0K PiBQYWRkaW5nIHRvIGJlIHJlZmxlY3RlZCBmb2xsb3dzIHRoZSA2NCBNQlogb2N0ZXRzLg0KPiAN Cj4gTm90ZXMNCj4gLS0tLS0NCj4gdG8gYWNoaWV2ZSBzeW1tZXRyaWNhbCBzaXplIGluIGF1dGhl bnRpY2F0ZWQgYW5kIGVuY3J5cHRlZCBtb2RlIGxlbmd0aCBvZg0KPiBtYnogZmllbGQgbmVlZHMg dG8gYmUgNjQgb2N0ZWN0cyBpbnN0ZWFkIG9mIDU2IG9jdGVjdHMNCj4gDQo+IEluc3RydWN0aW9u czoNCj4gLS0tLS0tLS0tLS0tLQ0KPiBUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBvc3RlZCBh cyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBsZWFzZQ0KPiB1c2UgIlJlcGx5IEFsbCIgdG8g ZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KPiByZWplY3RlZC4gV2hl biBhIGRlY2lzaW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkNCj4gY2FuIGxvZyBp biB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0LCBpZiBuZWNlc3Nhcnku DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBSRkM2MDM4 IChkcmFmdC1pZXRmLWlwcG0tdHdhbXAtcmVmbGVjdC1vY3RldHMtMDkpDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRpdGxlICAgICAgICAgICAgICAgOiBUd28t V2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCAoVFdBTVApIFJlZmxlY3QNCj4gT2N0ZXRz IGFuZCBTeW1tZXRyaWNhbCBTaXplIEZlYXR1cmVzDQo+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBP Y3RvYmVyIDIwMTANCj4gQXV0aG9yKHMpICAgICAgICAgICA6IEEuIE1vcnRvbiwgTC4gQ2lhdmF0 dG9uZQ0KPiBDYXRlZ29yeSAgICAgICAgICAgIDogUFJPUE9TRUQgU1RBTkRBUkQNCj4gU291cmNl ICAgICAgICAgICAgICA6IElQIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50DQo+IEFyZWEgICAgICAg ICAgICAgICAgOiBUcmFuc3BvcnQNCj4gU3RyZWFtICAgICAgICAgICAgICA6IElFVEYNCj4gVmVy aWZ5aW5nIFBhcnR5ICAgICA6IElFU0cNCg== From nobody Fri Nov 9 18:21:59 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3234130DF0; Fri, 9 Nov 2018 18:21:57 -0800 (PST) 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 Nn73VBEj7CBp; Fri, 9 Nov 2018 18:21:55 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 DFA70130DF6; Fri, 9 Nov 2018 18:21:54 -0800 (PST) Received: from [2001:67c:1232:144:2807:3e69:4d34:c6df]; authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gLIuF-00030k-Ui; Sat, 10 Nov 2018 03:21:52 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF557D896F@njmtexg5.research.att.com> Date: Sat, 10 Nov 2018 09:21:46 +0700 Cc: "ippm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7DAAE1B6-3F0C-472B-8185-9FACB35EF59E@kuehlewind.net> References: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557D896F@njmtexg5.research.att.com> To: "draft-ietf-ippm-port-twamp-test.all@ietf.org" X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1541816514;94cb5b3d; X-HE-SMSGID: 1gLIuF-00030k-Ui Archived-At: Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 02:21:58 -0000 Hi all, sorry one more question: RFC7594 would be a downref and I think it is = correct that this is a normative reference because it pointed to in the = security sec. On the other it seems a bit weird to point normatively to = the security section of an informational doc. So just double-checking if = that is all right (given downrefs need to be called out in the last = call, so we have to decide before I start last call)?=20 Also looking at the references again, I think RFC6335 does not need to = be a normative reference. @Tianran: a downref is a normative reference to a document with a lower = maturity level, so also a normative reference from a draft that is = intended for Proposed Standard to an informational RFC is a downref. In = the shepherd write-up you only say that there are normative reference to = RFCs, however, you would next time also need to check the status of = these RFCs. Thanks! Btw. could you please update the shepherd write-up? Mirja > Am 05.11.2018 um 04:57 schrieb MORTON, ALFRED C (AL) = : >=20 > Hi Mirja, > please see replies in-line. > Al >=20 >> -----Original Message----- >> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind >> (IETF) >> Sent: Monday, October 29, 2018 2:06 PM >> To: draft-ietf-ippm-port-twamp-test.all@ietf.org >> Cc: ippm@ietf.org >> Subject: [ippm] AD review of draft-ietf-ippm-port-twamp-test >>=20 >> Hi authors, >>=20 >> first of all sorry for the rather long delay for this short draft. = The bad >> news it that I probably have to delay the processing even further as = I >> will not be able to join the next telechat on Nov 21 and we have to = wait >> for the telechat on Dec 6. The good news is that gives us plenty of = time >> for the IETF last call :-) >>=20 >> I reviewed this document and I don=E2=80=99t think there are any = issues that would >> not allow me to start the IETF last cal, but given we have time I = would >> like to ask a few questions/comments: >>=20 >> 1) The document gives plenty of background information and talks = about >> impacts, however, it says very little about why it is good to have a = fixed >> port, beside this: >> "It may simplify some operations to have a well- >> known port available for the Test protocols, or for future >> specifications involving TWAMP-Test to use this port as a default >> port.=E2=80=9C >> Is there any chance to say more than this? > [acm]=20 > yes, mentioned BBF TR-390 implementations as benefactors.=20 >>=20 >> 2) Also, I agree with the shepherd that I don=E2=80=99t think it is = necessary to >> detail the history as much as done in section 4, e.g. rather discuss = the >> why than the actually comments by Lars and Tim. Also this section is >> called =E2=80=9Edefinition=E2=80=9C but this background information = seems to go beyond >> just defining something. > [acm]=20 > Ok the section is now titled, Definitions and Background, > and most of the details describing comments from Lars and Tim > are moved to an Appendix A. >=20 >>=20 >> Btw. Tianran, it would be nice if you could update your comments in = the >> shepherd write-up accordingly if they have been addressed or are = obsolete. >> Thanks! > [acm]=20 > Yes, please consider incorporating some of the details from > my e-mail last August, thanks! >=20 >>=20 >> 3) I don=E2=80=99t think there is any normative language require in = this doc. As >> you are =E2=80=9Ejust=E2=80=9C stating what has been normatively = defined in other >> documents, it is actually preferred to not re-state normatively. > [acm]=20 > The Scope says:=20 > The scope of this memo is to re-allocate well-known ports for = the UDP=20 > Test protocols that compose necessary parts of their respective=20= > standards track protocols, OWAMP and TWAMP, along with = clarifications=20 > of the complete protocol composition for the industry. >=20 > The controversy about TWAMP composition is partly what brought us = here! > We used the term REQUIRED in the Definitions to resolve the small = ambiguity > created when OWAMP authors did not use normative language when = describing > the protocols that comprise OWAMP, and TWAMP authors followed that = choice of > wording (unfortunately). >=20 >>=20 >> 4) An update in the registry does not necessary mean an =E2=80=9Eupdate= =E2=80=9C of the >> RFCs that registered that ports in the first place, especially as = rfc4656 >> doesn=E2=80=99t even mention the UDP port at all. Of course the use = of =E2=80=9Eupdate=E2=80=9C is >> very loosely defined and can be used if that is preferred but it is = not >> strictly necessary. Or is there another reason to update these RFCs? = If >> so, it should be clearly spelled out in the draft. > [acm]=20 > Ok, drawing on the point from the Scope, and requirement Language = above, > the Abstract now ends with: >=20 > The memo updates RFC 4656 and RFC 5357, in terms of the UDP well-known = port=20 > assignments, and clarifies the complete OWAMP and TWAMP protocol = composition=20 > for the industry. >=20 >>=20 >> 5) Given that these entries are updates it would be nice to also fill = the >> missing information about contact information and assignee in the >> registry. Instruction for IANA would need to be added to the IANA = section >> in this case. Assignee should be the IESG and contact the IETF chair. = I >> assume the modification date will be filled by IANA respectively. > [acm]=20 > ok >=20 >>=20 >> Thanks! >> Mirja >>=20 >>=20 >>=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=3DfczRvYcfFcuwftALPl3iddxBq= rOCp >> UTLa2qfPshPmRY&s=3DD-D42Pu3DFr7TAIb4ras87t2cNxyDt4UURtFGkPZDOo&e=3D From nobody Fri Nov 9 19:49:09 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3AD130DD5; Fri, 9 Nov 2018 19:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 mrcBnfLvaj4k; Fri, 9 Nov 2018 19:49:05 -0800 (PST) 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 368C1128D0C; Fri, 9 Nov 2018 19:49:05 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wAA3jMhq008103; Fri, 9 Nov 2018 22:49:01 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049459.ppops.net-00191d01. with ESMTP id 2nnm7pws02-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Nov 2018 22:49:00 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAA3mx78065805; Fri, 9 Nov 2018 21:48:59 -0600 Received: from zlp30493.vci.att.com (zlp30493.vci.att.com [135.46.181.176]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAA3mv1g065773; Fri, 9 Nov 2018 21:48:57 -0600 Received: from zlp30493.vci.att.com (zlp30493.vci.att.com [127.0.0.1]) by zlp30493.vci.att.com (Service) with ESMTP id 04C7240004AC; Sat, 10 Nov 2018 03:48:57 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30493.vci.att.com (Service) with ESMTP id D3C4C400048B; Sat, 10 Nov 2018 03:48:56 +0000 (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 wAA3mu2f026108; Fri, 9 Nov 2018 21:48:56 -0600 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 wAA3mkUP025530; Fri, 9 Nov 2018 21:48:46 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-blue.research.att.com (Postfix) with ESMTP id A652BF1E40; Fri, 9 Nov 2018 22:48:45 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Fri, 9 Nov 2018 22:47:55 -0500 From: "MORTON, ALFRED C (AL)" To: "Mirja Kuehlewind (IETF)" , "draft-ietf-ippm-port-twamp-test.all@ietf.org" , "spencerdawkins.ietf@gmail.com" CC: "ippm@ietf.org" Thread-Topic: [ippm] AD review of draft-ietf-ippm-port-twamp-test Thread-Index: AQHUb7IS2QGrObPQyUeFS1fWuZHhsKVAJHPwgAiIOwD//8EtMA== Date: Sat, 10 Nov 2018 03:47:54 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557DE051@njmtexg5.research.att.com> References: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557D896F@njmtexg5.research.att.com> <7DAAE1B6-3F0C-472B-8185-9FACB35EF59E@kuehlewind.net> In-Reply-To: <7DAAE1B6-3F0C-472B-8185-9FACB35EF59E@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [110.170.235.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-09_09:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811100030 Archived-At: Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 03:49:07 -0000 SGkgTWlyamEsIGFuZCBTcGVuY2VyLA0KDQpyZXBsaWVzIGJlbG93LCB3aXRoIGEgcXVlc3Rpb24g Zm9yIHRoZSAiT3V0Z29pbmcgQUQiDQpBbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpIFttYWlsdG86aWV0ZkBrdWVobGV3aW5k Lm5ldF0NCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciA5LCAyMDE4IDk6MjIgUE0NCj4gVG86IGRy YWZ0LWlldGYtaXBwbS1wb3J0LXR3YW1wLXRlc3QuYWxsQGlldGYub3JnDQo+IENjOiBpcHBtQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbaXBwbV0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBw bS1wb3J0LXR3YW1wLXRlc3QNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IHNvcnJ5IG9uZSBtb3JlIHF1 ZXN0aW9uOiBSRkM3NTk0IHdvdWxkIGJlIGEgZG93bnJlZiBhbmQgSSB0aGluayBpdCBpcw0KPiBj b3JyZWN0IHRoYXQgdGhpcyBpcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgYmVjYXVzZSBpdCBwb2lu dGVkIHRvIGluIHRoZQ0KPiBzZWN1cml0eSBzZWMuIE9uIHRoZSBvdGhlciBpdCBzZWVtcyBhIGJp dCB3ZWlyZCB0byBwb2ludCBub3JtYXRpdmVseSB0bw0KPiB0aGUgc2VjdXJpdHkgc2VjdGlvbiBv ZiBhbiBpbmZvcm1hdGlvbmFsIGRvYy4gU28ganVzdCBkb3VibGUtY2hlY2tpbmcgaWYNCj4gdGhh dCBpcyBhbGwgcmlnaHQgKGdpdmVuIGRvd25yZWZzIG5lZWQgdG8gYmUgY2FsbGVkIG91dCBpbiB0 aGUgbGFzdCBjYWxsLA0KPiBzbyB3ZSBoYXZlIHRvIGRlY2lkZSBiZWZvcmUgSSBzdGFydCBsYXN0 IGNhbGwpPw0KW2FjbV0gDQoNClllcywgSSdkIGxpa2UgdG8ga2VlcCB0aGUgRG93bnJlZiwgYW5k IGFsc28gYXNrIHRvIHBsYWNlIFJGQyA3NTk0DQpvbiB0aGUgInBlcm1hbmVudCBEb3ducmVmIGV4 Y2VwdGlvbiBsaXN0Ii4gSSBkb24ndCBrbm93IHRoZSBleGFjdA0KbmFtZSBvZiB0aGlzIGxpc3Qs IGJ1dCB0aGUgSVBQTSBGcmFtZXdvcmsgUkZDIDIzMzAgd2FzIHBsYWNlZCBvbiBpdC4NCg0KQFNw ZW5jZXI6ICJPdXRnb2luZyBBRCIgbWF5IGJlIGFibGUgdG8gaGVscCB1cyBmaW5kIHRoZSBsaXN0 IGFib3ZlLA0KYmVmb3JlIHlvdSBnbyBwbGVhc2UuIDotKQ0KDQo+IA0KPiBBbHNvIGxvb2tpbmcg YXQgdGhlIHJlZmVyZW5jZXMgYWdhaW4sIEkgdGhpbmsgUkZDNjMzNSBkb2VzIG5vdCBuZWVkIHRv IGJlDQo+IGEgbm9ybWF0aXZlIHJlZmVyZW5jZS4NClthY21dIA0KSWYgb3VyIGNvbGxlYWd1ZXMg aW4gSUFOQSBhcmUgb2sgd2l0aCB0aGF0LCBzbyBhbSBJLg0KDQo+IA0KPiBAVGlhbnJhbjogYSBk b3ducmVmIGlzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBhIGRvY3VtZW50IHdpdGggYSBsb3dl cg0KPiBtYXR1cml0eSBsZXZlbCwgc28gYWxzbyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgZnJvbSBh IGRyYWZ0IHRoYXQgaXMNCj4gaW50ZW5kZWQgZm9yIFByb3Bvc2VkIFN0YW5kYXJkIHRvIGFuIGlu Zm9ybWF0aW9uYWwgUkZDIGlzIGEgZG93bnJlZi4gSW4NCj4gdGhlIHNoZXBoZXJkIHdyaXRlLXVw IHlvdSBvbmx5IHNheSB0aGF0IHRoZXJlIGFyZSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvDQo+IFJG Q3MsIGhvd2V2ZXIsIHlvdSB3b3VsZCBuZXh0IHRpbWUgYWxzbyBuZWVkIHRvIGNoZWNrIHRoZSBz dGF0dXMgb2YgdGhlc2UNCj4gUkZDcy4gVGhhbmtzISBCdHcuIGNvdWxkIHlvdSBwbGVhc2UgdXBk YXRlIHRoZSBzaGVwaGVyZCB3cml0ZS11cD8NClthY21dIA0KKzEsIHRoYW5rcyBUaWFucmFuLg0K DQo+IA0KPiBNaXJqYQ0KPiANCj4gDQo+ID4gQW0gMDUuMTEuMjAxOCB1bSAwNDo1NyBzY2hyaWVi IE1PUlRPTiwgQUxGUkVEIEMgKEFMKQ0KPiA8YWNtQHJlc2VhcmNoLmF0dC5jb20+Og0KPiA+DQo+ ID4gSGkgTWlyamEsDQo+ID4gcGxlYXNlIHNlZSByZXBsaWVzIGluLWxpbmUuDQo+ID4gQWwNCj4g Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBpcHBtIFttYWls dG86aXBwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlyamEgS3VlaGxld2luZA0K PiA+PiAoSUVURikNCj4gPj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDI5LCAyMDE4IDI6MDYgUE0N Cj4gPj4gVG86IGRyYWZ0LWlldGYtaXBwbS1wb3J0LXR3YW1wLXRlc3QuYWxsQGlldGYub3JnDQo+ ID4+IENjOiBpcHBtQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFtpcHBtXSBBRCByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1pcHBtLXBvcnQtdHdhbXAtdGVzdA0KPiA+Pg0KPiA+PiBIaSBhdXRob3JzLA0K PiA+Pg0KPiA+PiBmaXJzdCBvZiBhbGwgc29ycnkgZm9yIHRoZSByYXRoZXIgbG9uZyBkZWxheSBm b3IgdGhpcyBzaG9ydCBkcmFmdC4gVGhlDQo+IGJhZA0KPiA+PiBuZXdzIGl0IHRoYXQgSSBwcm9i YWJseSBoYXZlIHRvIGRlbGF5IHRoZSBwcm9jZXNzaW5nIGV2ZW4gZnVydGhlciBhcyBJDQo+ID4+ IHdpbGwgbm90IGJlIGFibGUgdG8gam9pbiB0aGUgbmV4dCB0ZWxlY2hhdCBvbiBOb3YgMjEgYW5k IHdlIGhhdmUgdG8NCj4gd2FpdA0KPiA+PiBmb3IgdGhlIHRlbGVjaGF0IG9uIERlYyA2LiBUaGUg Z29vZCBuZXdzIGlzIHRoYXQgZ2l2ZXMgdXMgcGxlbnR5IG9mDQo+IHRpbWUNCj4gPj4gZm9yIHRo ZSBJRVRGIGxhc3QgY2FsbCA6LSkNCj4gPj4NCj4gPj4gSSByZXZpZXdlZCB0aGlzIGRvY3VtZW50 IGFuZCBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgYXJlIGFueSBpc3N1ZXMgdGhhdA0KPiB3b3VsZA0K PiA+PiBub3QgYWxsb3cgbWUgdG8gc3RhcnQgdGhlIElFVEYgbGFzdCBjYWwsIGJ1dCBnaXZlbiB3 ZSBoYXZlIHRpbWUgSSB3b3VsZA0KPiA+PiBsaWtlIHRvIGFzayBhIGZldyBxdWVzdGlvbnMvY29t bWVudHM6DQo+ID4+DQo+ID4+IDEpIFRoZSBkb2N1bWVudCBnaXZlcyBwbGVudHkgb2YgYmFja2dy b3VuZCBpbmZvcm1hdGlvbiBhbmQgdGFsa3MgYWJvdXQNCj4gPj4gaW1wYWN0cywgaG93ZXZlciwg aXQgc2F5cyB2ZXJ5IGxpdHRsZSBhYm91dCB3aHkgaXQgaXMgZ29vZCB0byBoYXZlIGENCj4gZml4 ZWQNCj4gPj4gcG9ydCwgYmVzaWRlIHRoaXM6DQo+ID4+ICJJdCBtYXkgc2ltcGxpZnkgc29tZSBv cGVyYXRpb25zIHRvIGhhdmUgYSB3ZWxsLQ0KPiA+PiAgIGtub3duIHBvcnQgYXZhaWxhYmxlIGZv ciB0aGUgVGVzdCBwcm90b2NvbHMsIG9yIGZvciBmdXR1cmUNCj4gPj4gICBzcGVjaWZpY2F0aW9u cyBpbnZvbHZpbmcgVFdBTVAtVGVzdCB0byB1c2UgdGhpcyBwb3J0IGFzIGEgZGVmYXVsdA0KPiA+ PiAgIHBvcnQu4oCcDQo+ID4+IElzIHRoZXJlIGFueSBjaGFuY2UgdG8gc2F5IG1vcmUgdGhhbiB0 aGlzPw0KPiA+IFthY21dDQo+ID4geWVzLCBtZW50aW9uZWQgQkJGIFRSLTM5MCBpbXBsZW1lbnRh dGlvbnMgYXMgYmVuZWZhY3RvcnMuDQo+ID4+DQo+ID4+IDIpIEFsc28sIEkgYWdyZWUgd2l0aCB0 aGUgc2hlcGhlcmQgdGhhdCBJIGRvbuKAmXQgdGhpbmsgaXQgaXMgbmVjZXNzYXJ5DQo+IHRvDQo+ ID4+IGRldGFpbCB0aGUgaGlzdG9yeSBhcyBtdWNoIGFzIGRvbmUgaW4gc2VjdGlvbiA0LCBlLmcu IHJhdGhlciBkaXNjdXNzDQo+IHRoZQ0KPiA+PiB3aHkgdGhhbiB0aGUgYWN0dWFsbHkgY29tbWVu dHMgYnkgTGFycyBhbmQgVGltLiBBbHNvIHRoaXMgc2VjdGlvbiBpcw0KPiA+PiBjYWxsZWQg4oCe ZGVmaW5pdGlvbuKAnCBidXQgdGhpcyBiYWNrZ3JvdW5kIGluZm9ybWF0aW9uIHNlZW1zIHRvIGdv IGJleW9uZA0KPiA+PiBqdXN0IGRlZmluaW5nIHNvbWV0aGluZy4NCj4gPiBbYWNtXQ0KPiA+IE9r IHRoZSBzZWN0aW9uIGlzIG5vdyB0aXRsZWQsIERlZmluaXRpb25zIGFuZCBCYWNrZ3JvdW5kLA0K PiA+IGFuZCBtb3N0IG9mIHRoZSBkZXRhaWxzIGRlc2NyaWJpbmcgY29tbWVudHMgZnJvbSBMYXJz IGFuZCBUaW0NCj4gPiBhcmUgbW92ZWQgdG8gYW4gQXBwZW5kaXggQS4NCj4gPg0KPiA+Pg0KPiA+ PiBCdHcuIFRpYW5yYW4sIGl0IHdvdWxkIGJlIG5pY2UgaWYgeW91IGNvdWxkIHVwZGF0ZSB5b3Vy IGNvbW1lbnRzIGluIHRoZQ0KPiA+PiBzaGVwaGVyZCB3cml0ZS11cCBhY2NvcmRpbmdseSBpZiB0 aGV5IGhhdmUgYmVlbiBhZGRyZXNzZWQgb3IgYXJlDQo+IG9ic29sZXRlLg0KPiA+PiBUaGFua3Mh DQo+ID4gW2FjbV0NCj4gPiBZZXMsIHBsZWFzZSBjb25zaWRlciBpbmNvcnBvcmF0aW5nIHNvbWUg b2YgdGhlIGRldGFpbHMgZnJvbQ0KPiA+IG15IGUtbWFpbCBsYXN0IEF1Z3VzdCwgdGhhbmtzIQ0K PiA+DQo+ID4+DQo+ID4+IDMpIEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhbnkgbm9ybWF0aXZl IGxhbmd1YWdlIHJlcXVpcmUgaW4gdGhpcyBkb2MuDQo+IEFzDQo+ID4+IHlvdSBhcmUg4oCeanVz dOKAnCBzdGF0aW5nIHdoYXQgaGFzIGJlZW4gbm9ybWF0aXZlbHkgZGVmaW5lZCBpbiBvdGhlcg0K PiA+PiBkb2N1bWVudHMsIGl0IGlzIGFjdHVhbGx5IHByZWZlcnJlZCB0byBub3QgcmUtc3RhdGUg bm9ybWF0aXZlbHkuDQo+ID4gW2FjbV0NCj4gPiBUaGUgU2NvcGUgc2F5czoNCj4gPiAJVGhlIHNj b3BlIG9mIHRoaXMgbWVtbyBpcyB0byByZS1hbGxvY2F0ZSB3ZWxsLWtub3duIHBvcnRzIGZvciB0 aGUNCj4gVURQDQo+ID4gCVRlc3QgcHJvdG9jb2xzIHRoYXQgY29tcG9zZSBuZWNlc3NhcnkgcGFy dHMgb2YgdGhlaXIgcmVzcGVjdGl2ZQ0KPiA+IAlzdGFuZGFyZHMgdHJhY2sgcHJvdG9jb2xzLCBP V0FNUCBhbmQgVFdBTVAsIGFsb25nIHdpdGgNCj4gY2xhcmlmaWNhdGlvbnMNCj4gPiAJb2YgdGhl IGNvbXBsZXRlIHByb3RvY29sIGNvbXBvc2l0aW9uIGZvciB0aGUgaW5kdXN0cnkuDQo+ID4NCj4g PiBUaGUgY29udHJvdmVyc3kgYWJvdXQgVFdBTVAgY29tcG9zaXRpb24gaXMgcGFydGx5IHdoYXQg YnJvdWdodCB1cyBoZXJlIQ0KPiA+IFdlIHVzZWQgdGhlIHRlcm0gUkVRVUlSRUQgaW4gdGhlIERl ZmluaXRpb25zIHRvIHJlc29sdmUgdGhlIHNtYWxsDQo+IGFtYmlndWl0eQ0KPiA+IGNyZWF0ZWQg d2hlbiBPV0FNUCBhdXRob3JzIGRpZCBub3QgdXNlIG5vcm1hdGl2ZSBsYW5ndWFnZSB3aGVuDQo+ IGRlc2NyaWJpbmcNCj4gPiB0aGUgcHJvdG9jb2xzIHRoYXQgY29tcHJpc2UgT1dBTVAsIGFuZCBU V0FNUCBhdXRob3JzIGZvbGxvd2VkIHRoYXQNCj4gY2hvaWNlIG9mDQo+ID4gd29yZGluZyAodW5m b3J0dW5hdGVseSkuDQo+ID4NCj4gPj4NCj4gPj4gNCkgQW4gdXBkYXRlIGluIHRoZSByZWdpc3Ry eSBkb2VzIG5vdCBuZWNlc3NhcnkgbWVhbiBhbiDigJ51cGRhdGXigJwgb2YgdGhlDQo+ID4+IFJG Q3MgdGhhdCByZWdpc3RlcmVkIHRoYXQgcG9ydHMgaW4gdGhlIGZpcnN0IHBsYWNlLCBlc3BlY2lh bGx5IGFzDQo+IHJmYzQ2NTYNCj4gPj4gZG9lc27igJl0IGV2ZW4gbWVudGlvbiB0aGUgVURQIHBv cnQgYXQgYWxsLiBPZiBjb3Vyc2UgdGhlIHVzZSBvZiDigJ51cGRhdGXigJwNCj4gaXMNCj4gPj4g dmVyeSBsb29zZWx5IGRlZmluZWQgYW5kIGNhbiBiZSB1c2VkIGlmIHRoYXQgaXMgcHJlZmVycmVk IGJ1dCBpdCBpcyBub3QNCj4gPj4gc3RyaWN0bHkgbmVjZXNzYXJ5LiBPciBpcyB0aGVyZSBhbm90 aGVyIHJlYXNvbiB0byB1cGRhdGUgdGhlc2UgUkZDcz8gSWYNCj4gPj4gc28sIGl0IHNob3VsZCBi ZSBjbGVhcmx5IHNwZWxsZWQgb3V0IGluIHRoZSBkcmFmdC4NCj4gPiBbYWNtXQ0KPiA+IE9rLCBk cmF3aW5nIG9uIHRoZSBwb2ludCBmcm9tIHRoZSBTY29wZSwgYW5kIHJlcXVpcmVtZW50IExhbmd1 YWdlIGFib3ZlLA0KPiA+IHRoZSBBYnN0cmFjdCBub3cgZW5kcyB3aXRoOg0KPiA+DQo+ID4gVGhl IG1lbW8gdXBkYXRlcyBSRkMgNDY1NiBhbmQgUkZDIDUzNTcsIGluIHRlcm1zIG9mIHRoZSBVRFAg d2VsbC1rbm93bg0KPiBwb3J0DQo+ID4gYXNzaWdubWVudHMsIGFuZCBjbGFyaWZpZXMgdGhlIGNv bXBsZXRlIE9XQU1QIGFuZCBUV0FNUCBwcm90b2NvbA0KPiBjb21wb3NpdGlvbg0KPiA+IGZvciB0 aGUgaW5kdXN0cnkuDQo+ID4NCj4gPj4NCj4gPj4gNSkgR2l2ZW4gdGhhdCB0aGVzZSBlbnRyaWVz IGFyZSB1cGRhdGVzIGl0IHdvdWxkIGJlIG5pY2UgdG8gYWxzbyBmaWxsDQo+IHRoZQ0KPiA+PiBt aXNzaW5nIGluZm9ybWF0aW9uIGFib3V0IGNvbnRhY3QgaW5mb3JtYXRpb24gYW5kIGFzc2lnbmVl IGluIHRoZQ0KPiA+PiByZWdpc3RyeS4gSW5zdHJ1Y3Rpb24gZm9yIElBTkEgd291bGQgbmVlZCB0 byBiZSBhZGRlZCB0byB0aGUgSUFOQQ0KPiBzZWN0aW9uDQo+ID4+IGluIHRoaXMgY2FzZS4gQXNz aWduZWUgc2hvdWxkIGJlIHRoZSBJRVNHIGFuZCBjb250YWN0IHRoZSBJRVRGIGNoYWlyLiBJDQo+ ID4+IGFzc3VtZSB0aGUgbW9kaWZpY2F0aW9uIGRhdGUgd2lsbCBiZSBmaWxsZWQgYnkgSUFOQSBy ZXNwZWN0aXZlbHkuDQo+ID4gW2FjbV0NCj4gPiBvaw0KPiA+DQo+ID4+DQo+ID4+IFRoYW5rcyEN Cj4gPj4gTWlyamENCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gaXBwbSBt YWlsaW5nIGxpc3QNCj4gPj4gaXBwbUBpZXRmLm9yZw0KPiA+PiBodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+ID4+IDNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19pcHBtJmQ9RHdJR2FRJmM9TEZZWi0NCj4gPj4NCj4gbzlfSFVNZU1UU1Fp Y3ZqSWcmcj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3Jm09ZmN6UnZZY2ZGY3V3ZnRBTFBsM2lkZHhC cXJPQ3ANCj4gPj4gVVRMYTJxZlBzaFBtUlkmcz1ELUQ0MlB1M0RGcjdUQUliNHJhczg3dDJjTnh5 RHQ0VVVSdEZHa1BaRE9vJmU9DQoNCg== From nobody Fri Nov 9 20:56:44 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889E2130E7F for ; Fri, 9 Nov 2018 20:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 X02ydr9BNVPl for ; Fri, 9 Nov 2018 20:56:38 -0800 (PST) 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 BD6F2130E3A for ; Fri, 9 Nov 2018 20:56:38 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wAA4scSW037046 for ; Fri, 9 Nov 2018 23:56:37 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049459.ppops.net-00191d01. with ESMTP id 2nnrabgj1c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 09 Nov 2018 23:56:37 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAA4uaN2050931 for ; Fri, 9 Nov 2018 22:56:36 -0600 Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [135.46.181.158]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAA4uTbD050795 for ; Fri, 9 Nov 2018 22:56:30 -0600 Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [127.0.0.1]) by zlp30495.vci.att.com (Service) with ESMTP id D089540002F7 for ; Sat, 10 Nov 2018 04:56:29 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30495.vci.att.com (Service) with ESMTP id A678B40002F2 for ; Sat, 10 Nov 2018 04:56:29 +0000 (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 wAA4uTl9023248 for ; Fri, 9 Nov 2018 22:56:29 -0600 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 wAA4uOOQ023073 for ; Fri, 9 Nov 2018 22:56:24 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTP id 9FC53E1BED for ; Fri, 9 Nov 2018 23:56:23 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Fri, 9 Nov 2018 23:55:33 -0500 From: "MORTON, ALFRED C (AL)" To: "ippm@ietf.org" Thread-Topic: Proposed Liaison Reply to ITU-T SG12 Thread-Index: AdR4rdv3vBY8O41eTV6k6fXa7o7Jzw== Date: Sat, 10 Nov 2018 04:55:32 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557DE0A8@njmtexg5.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [110.170.235.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-10_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811100042 Archived-At: Subject: [ippm] Proposed Liaison Reply to ITU-T SG12 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 04:56:41 -0000 IPPM, Following presentation and discussion of the Subject Liaison (description b= elow), and several individuals indicating interest (during and after=20 the IPPM session), I would like to propose the brief text of a Liaison reply. The WG will need to reach consensus on the text of the reply as a next step. Thanks to all who have expressed interest to participate in this work! regards, Al Proposed Body of Liaison Reply (to all recipients) -=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- IETF IPPM working group thanks you for your liaison describing plans to evaluate methods of measurement for IP network performance. The harmonizati= on of capacity measurements will be timely and useful to the industry. At the present time, about 3 individuals have expressed interest, and they= =20 will contact you directly for details of participation in the evaluation pl= an. IPPM WG is pleased to see that methods based on RFC8337, Model-Based Metric= s for Bulk Transport Capacity, are already under consideration. Please keep the IPPM WG informed of your progress, especially if there are ways in which IPPM WG participants assist further. Background -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- IPPM, The Liaison Statement on IP performance measurements from many SDOs (but primarily ITU-T SG 12 and ETSI TC STQ) is here: https://datatracker.ietf.org/liaison/1602/ I'll be discussing this Liaison and IPPM's possible reply during the IPPM Session at IETF-103. regards, Al -----Original Message----- From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 Sent: Friday, October 26, 2018 2:54 PM To: The IETF Chair Cc: The IESG ; The IETF Chair ; itu-t-liaiso= n@iab.org; MORTON, ALFRED C (AL) ; Scott Mansfield Subject: New Liaison Statement, "LS/r on current status of the draft Recomm= endation ITU-T Q.3961 (reply to SG11-LS52)" Title: LS/r on current status of the draft Recommendation ITU-T Q.3961 (rep= ly to SG11-LS52) Submission Date: 2018-10-26 URL of the IETF Web page: https://urldefense.proofpoint.com/v2/url?u=3Dhttp= s-3A__datatracker.ietf.org_liaison_1602_&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicv= jIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DVX3GNCspVy25DZ0Zvm0i0HhrSCNzJBOHkhMrvjqc= qlw&s=3DHCwQVX1oNj6zFdiNQ3fj1Onc-HW1gC7ZIOOdxqOrBYg&e=3D From: Al Morton To: The IETF Chair Cc: Scott Mansfield ,The IETF Chair ,itu-t-liaison@iab.org,The IESG Response Contacts: A. C. Morton Technical Contacts:=20 Purpose: For information Body: ITU-T Study Group 12 thanks you for your liaison, sharing your plan t= o discuss Draft Q.3961, "Testing methodologies of Internet related performa= nce measurements including e2e bit rate within the fixed and mobile operato= r's networks", during future workshops and Joint meetings. We are aware tha= t text similar to draft requirements in Q.3961 was completely deleted from = the corresponding ETSI INT specification as a result of extensive comments = during the approval process, and there are additional comments post-approva= l which remain un-addressed and unresolved after several months. We have be= en notified of new and urgent work in ETSI STQ to revise clause 6 of TS 103= 222-1 (the reference replacing almost all requirements in the ETSI INT spe= cification). The current text of TS 103 222-1 (3-2018) specification retain= s a completely non-compatible scope to draft Q.3961, and suffers from the s= ame shortcomings raised in the ETSI INT review process. As part of the Harm= onization efforts for IP-network performance specifications between ETSI STQ and Q17/12, we= have reviewed the revised text of clause 6/103 222-1, and find it satisfac= tory. Our conclusion on this topic is that we agree and support the request= of ETSI STQ, to avoid referencing the (current) text of TS 103 222-1 (3-20= 18) while this work is in-progress. The work is proceeding toward a prompt = resolution. Study Group 12's plan is to prepare relevant normative specifications for I= P-layer Capacity and Flow-related Parameters (throughput), and that SG 11 m= ake use of the new specifications when available, as communicated in May 20= 18. We are pleased SG11's recent liaison did not object to this plan, and = we hope SG11 will participate in Harmonization efforts, as ETSI STQ has agr= eed. As stated in your liaison, ITU-T SG11 envisages that benchmarking testing i= s one of the components of draft Recommendation ITU-T Q.3961. Since the ter= m "benchmarking" is not defined in the liaison, and has many uses throughou= t the industry, we would like to understand what this form of benchmarking = is intended compare.=20 We are also aware of a list of methods used by Regulators to *survey* Inter= net performance, published by the OECD https://urldefense.proofpoint.com/v2= /url?u=3Dhttp-3A__www.oecd.org_internet_speed-2Dtests.htm&d=3DDwIDaQ&c=3DLF= YZ-o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DVX3GNCspVy25DZ0Zvm0i0Hh= rSCNzJBOHkhMrvjqcqlw&s=3D-0O-ljmiu87BD6Xe7tWtTFujYxTklUIXzfmAw8v0ze8&e=3D .= Some Regulators have made disclaimers about the accuracy of their survey r= esults. For example: The locations and technical features of the broadband connections h= ave been provided by the service users themselves, who are entirely and exc= lusively liable for their=20 accuracy. The speed resulting from the measurement as the final spe= ed of the connection is also affected by a series of factors, such as the q= uality of cables, connections=20 and equipment or electromagnetic interference. This well-expresses our concerns with the methods described in current SG 1= 1 draft of Q.3961. At this time, we would like to inform you of our progress to develop the af= orementioned normative specifications in Study Group 12, especially our pro= gress at the October 2018 Q17 Interim meeting in Darmstadt. * AT&T's contribution describing how network access, usage patterns, user a= pplication requirements, and future measurement paths have changed in the p= ast five years set the tone for the meeting. There are likely to be "Gigabi= t islands" at the edge of future networks.=20 * ETSI TR103501 has been presented and discussed. Essential points were the= requirement for full transparency of the measurement and data processing m= ethodology. The TR attempts to provide a full view of today's methods for a= pplication level measurement including multi socket and crowd sourcing appr= oaches. * Y.1540 IP capacity and flow related parameter clauses were edited by the = group. * Y.1540 annex A was expanded to include two phases of testing. The first p= hase is a test using shaper/policer capabilities of a general purpose compu= ting system, based on AT&T's contribution and preliminary test results. Thi= s phase is parallel to the BEREC evaluation of Internet access measurements= , and adding critical test path parameters. * Y.1540 annex A was expanded to include information on evaluation of diffe= rent access speed measurement methods, conducted in 2012 by Goga and Teixei= ra. This work parallels our plan for phase 2. * There is a clear need to enlist active participants in the testing progra= m, who are willing to contribute both resources and personnel consistent wi= th the plans under development. Those who choose not to participate will ha= ve no influence on the outcome, or the schedule for completion, so they are= encouraged to participate or wait patiently. =20 * A list of regulator Internet access survey methods was compiled by AT&T a= nd discussed during the meeting. This list is more up to date than the 2015= OECD list, and concludes that there are many different methods currently i= n use, and no International consensus can be derived to support standard de= velopment from reading such lists. * AT&T contributed a comparison of two methods of LTE Internet access speed= assessment. The results show wide variation and strong dependence on mobil= e device type. Larger sample sizes are needed to achieve the comparison goa= ls. * Q17 reviewed the ETSI-STQ's revised clause 6 of TS-103 222-1, from the ra= pporteur of this new work item. The text was found to be agreeable, with th= e suggestion to update the introduction to indicate these changes. Study Group 12 has provided a detailed explanation of the clause 6.12 requi= rements in Appendix IX of Rec. Y.1540, titled "Explanation of TCP-based mea= surement inadequacy to meet normative requirements". However, we have conc= luded that Capacity measurements described in RFC 8337 meet the requirement= s in clause 6.12 of ITU-T Recommendation Y.1540.=20 We invite all experts to participate in the evaluation plan's development a= nd to subsequently participate in the evaluations. SG 11's plans to develop= the text of the draft Q.3961 should now move forward after the evaluation = and approval of Study Group 12's normative specifications are complete, acc= ording to the contribution-driven schedule. Certainly, SG 11 experts will = be willing to contribute their expertise and resources to this plan, consis= tent with their desire to complete work on this topic as quickly as possibl= e. The current draft of revisions to Y.1540, and a new Annex A for the new par= ameter definitions now contains the current text of the evaluation plan for= candidate definitions for the new normative parameters for IP-layer Capaci= ty and Flow-related Parameters (throughput). Annex A contains the latest ve= rsion of the evaluation plan, with key references to existing comparisons o= f methods. Study Group 12 would like to invite Study Group 11 to schedule co-located m= eetings in Geneva, November 2018, and to participate in the SG12 workshop a= djacent to the meeting dates, on November 26, 2018. We would like to use th= e workshop to share our experience, to make the work of overseeing ITU-T SG= 12's mandate and our coordination roles more efficient and effective.=20 Attachments: TD619- Current text of Annex A and Y.1540 clauses. URL to the Workshop:=20 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.itu.int_en_ITU-2= DT_Workshops-2Dand-2DSeminars_qos_201811_Pages_default.aspx&d=3DDwIDaQ&c=3D= LFYZ-o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DVX3GNCspVy25DZ0Zvm0i0= HhrSCNzJBOHkhMrvjqcqlw&s=3DSC-YHNEEIUdCW4a7nW3HZ9w6IRJdh2lzJy9W76DJfpo&e=3D Attachments: oLS59att https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_lib= _dt_documents_LIAISON_liaison-2D2018-2D10-2D26-2Ditu-2Dt-2Dsg-2D12-2Dietf-2= Dlsr-2Don-2Dcurrent-2Dstatus-2Dof-2Dthe-2Ddraft-2Drecommendation-2Ditu-2Dt-= 2Dq3961-2Dreply-2Dto-2Dsg11-2Dls52-2Dattachment-2D1.docx&d=3DDwIDaQ&c=3DLFY= Z-o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DVX3GNCspVy25DZ0Zvm0i0Hhr= SCNzJBOHkhMrvjqcqlw&s=3DEECf6rVuVJUT-vua7FSXSNXcbwzq2J9XE2BSGzZlFzM&e=3D From nobody Fri Nov 9 20:59:15 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50458131091; Fri, 9 Nov 2018 20:59:13 -0800 (PST) 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 DpCZQ-Tyjk71; Fri, 9 Nov 2018 20:59:11 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 E498E130E3A; Fri, 9 Nov 2018 20:59:10 -0800 (PST) Received: from static-146-88-49-66.violin.co.th ([146.88.49.66] helo=[172.27.14.52]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gLLMQ-0003lJ-NK; Sat, 10 Nov 2018 05:59:07 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF557DE051@njmtexg5.research.att.com> Date: Sat, 10 Nov 2018 11:59:01 +0700 Cc: "draft-ietf-ippm-port-twamp-test.all@ietf.org" , "spencerdawkins.ietf@gmail.com" , "ippm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <879BC912-692D-4C82-8591-3FA76EF9F66E@kuehlewind.net> References: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557D896F@njmtexg5.research.att.com> <7DAAE1B6-3F0C-472B-8185-9FACB35EF59E@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557DE051@njmtexg5.research.att.com> To: "MORTON, ALFRED C (AL)" X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1541825951;fe22dc42; X-HE-SMSGID: 1gLLMQ-0003lJ-NK Archived-At: Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 04:59:13 -0000 Hi Al, see inline. > Am 10.11.2018 um 10:47 schrieb MORTON, ALFRED C (AL) = : >=20 > Hi Mirja, and Spencer, >=20 > replies below, with a question for the "Outgoing AD" > Al >=20 >> -----Original Message----- >> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] >> Sent: Friday, November 9, 2018 9:22 PM >> To: draft-ietf-ippm-port-twamp-test.all@ietf.org >> Cc: ippm@ietf.org >> Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test >>=20 >> Hi all, >>=20 >> sorry one more question: RFC7594 would be a downref and I think it is >> correct that this is a normative reference because it pointed to in = the >> security sec. On the other it seems a bit weird to point normatively = to >> the security section of an informational doc. So just double-checking = if >> that is all right (given downrefs need to be called out in the last = call, >> so we have to decide before I start last call)? > [acm]=20 >=20 > Yes, I'd like to keep the Downref, and also ask to place RFC 7594 > on the "permanent Downref exception list". I don't know the exact > name of this list, but the IPPM Framework RFC 2330 was placed on it. >=20 > @Spencer: "Outgoing AD" may be able to help us find the list above, > before you go please. :-) It=E2=80=99s called Downref registry and it's here: https://datatracker.ietf.org/doc/downref/ My understanding is that it will go there automatically if once = referenced as a downref but I can double-check during the publication = process. >=20 >>=20 >> Also looking at the references again, I think RFC6335 does not need = to be >> a normative reference. > [acm]=20 > If our colleagues in IANA are ok with that, so am I. Okay. Actually we can do this later and don=E2=80=99t have to do it = before last call, which I will respectively start now. Thanks! Mirja >=20 >>=20 >> @Tianran: a downref is a normative reference to a document with a = lower >> maturity level, so also a normative reference from a draft that is >> intended for Proposed Standard to an informational RFC is a downref. = In >> the shepherd write-up you only say that there are normative reference = to >> RFCs, however, you would next time also need to check the status of = these >> RFCs. Thanks! Btw. could you please update the shepherd write-up? > [acm]=20 > +1, thanks Tianran. >=20 >>=20 >> Mirja >>=20 >>=20 >>> Am 05.11.2018 um 04:57 schrieb MORTON, ALFRED C (AL) >> : >>>=20 >>> Hi Mirja, >>> please see replies in-line. >>> Al >>>=20 >>>> -----Original Message----- >>>> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind >>>> (IETF) >>>> Sent: Monday, October 29, 2018 2:06 PM >>>> To: draft-ietf-ippm-port-twamp-test.all@ietf.org >>>> Cc: ippm@ietf.org >>>> Subject: [ippm] AD review of draft-ietf-ippm-port-twamp-test >>>>=20 >>>> Hi authors, >>>>=20 >>>> first of all sorry for the rather long delay for this short draft. = The >> bad >>>> news it that I probably have to delay the processing even further = as I >>>> will not be able to join the next telechat on Nov 21 and we have to >> wait >>>> for the telechat on Dec 6. The good news is that gives us plenty of >> time >>>> for the IETF last call :-) >>>>=20 >>>> I reviewed this document and I don=E2=80=99t think there are any = issues that >> would >>>> not allow me to start the IETF last cal, but given we have time I = would >>>> like to ask a few questions/comments: >>>>=20 >>>> 1) The document gives plenty of background information and talks = about >>>> impacts, however, it says very little about why it is good to have = a >> fixed >>>> port, beside this: >>>> "It may simplify some operations to have a well- >>>> known port available for the Test protocols, or for future >>>> specifications involving TWAMP-Test to use this port as a default >>>> port.=E2=80=9C >>>> Is there any chance to say more than this? >>> [acm] >>> yes, mentioned BBF TR-390 implementations as benefactors. >>>>=20 >>>> 2) Also, I agree with the shepherd that I don=E2=80=99t think it is = necessary >> to >>>> detail the history as much as done in section 4, e.g. rather = discuss >> the >>>> why than the actually comments by Lars and Tim. Also this section = is >>>> called =E2=80=9Edefinition=E2=80=9C but this background information = seems to go beyond >>>> just defining something. >>> [acm] >>> Ok the section is now titled, Definitions and Background, >>> and most of the details describing comments from Lars and Tim >>> are moved to an Appendix A. >>>=20 >>>>=20 >>>> Btw. Tianran, it would be nice if you could update your comments in = the >>>> shepherd write-up accordingly if they have been addressed or are >> obsolete. >>>> Thanks! >>> [acm] >>> Yes, please consider incorporating some of the details from >>> my e-mail last August, thanks! >>>=20 >>>>=20 >>>> 3) I don=E2=80=99t think there is any normative language require in = this doc. >> As >>>> you are =E2=80=9Ejust=E2=80=9C stating what has been normatively = defined in other >>>> documents, it is actually preferred to not re-state normatively. >>> [acm] >>> The Scope says: >>> The scope of this memo is to re-allocate well-known ports for = the >> UDP >>> Test protocols that compose necessary parts of their respective >>> standards track protocols, OWAMP and TWAMP, along with >> clarifications >>> of the complete protocol composition for the industry. >>>=20 >>> The controversy about TWAMP composition is partly what brought us = here! >>> We used the term REQUIRED in the Definitions to resolve the small >> ambiguity >>> created when OWAMP authors did not use normative language when >> describing >>> the protocols that comprise OWAMP, and TWAMP authors followed that >> choice of >>> wording (unfortunately). >>>=20 >>>>=20 >>>> 4) An update in the registry does not necessary mean an = =E2=80=9Eupdate=E2=80=9C of the >>>> RFCs that registered that ports in the first place, especially as >> rfc4656 >>>> doesn=E2=80=99t even mention the UDP port at all. Of course the use = of =E2=80=9Eupdate=E2=80=9C >> is >>>> very loosely defined and can be used if that is preferred but it is = not >>>> strictly necessary. Or is there another reason to update these = RFCs? If >>>> so, it should be clearly spelled out in the draft. >>> [acm] >>> Ok, drawing on the point from the Scope, and requirement Language = above, >>> the Abstract now ends with: >>>=20 >>> The memo updates RFC 4656 and RFC 5357, in terms of the UDP = well-known >> port >>> assignments, and clarifies the complete OWAMP and TWAMP protocol >> composition >>> for the industry. >>>=20 >>>>=20 >>>> 5) Given that these entries are updates it would be nice to also = fill >> the >>>> missing information about contact information and assignee in the >>>> registry. Instruction for IANA would need to be added to the IANA >> section >>>> in this case. Assignee should be the IESG and contact the IETF = chair. I >>>> assume the modification date will be filled by IANA respectively. >>> [acm] >>> ok >>>=20 >>>>=20 >>>> Thanks! >>>> Mirja >>>>=20 >>>>=20 >>>>=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- >>>>=20 >> = o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DfczRvYcfFcuwftALPl3iddxBq= rOCp >>>> UTLa2qfPshPmRY&s=3DD-D42Pu3DFr7TAIb4ras87t2cNxyDt4UURtFGkPZDOo&e=3D >=20 From nobody Fri Nov 9 21:14:28 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37828131094; Fri, 9 Nov 2018 21:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 oTxJ75pJwcYB; Fri, 9 Nov 2018 21:14:15 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F821310D8; Fri, 9 Nov 2018 21:14:15 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wAA54i8M032039; Sat, 10 Nov 2018 00:14:13 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049295.ppops.net-00191d01. with ESMTP id 2nnnpwmj4k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Nov 2018 00:14:13 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAA5EBmE082235; Fri, 9 Nov 2018 23:14:12 -0600 Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [135.46.181.158]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAA5E8C5082172; Fri, 9 Nov 2018 23:14:08 -0600 Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [127.0.0.1]) by zlp30495.vci.att.com (Service) with ESMTP id 1497441233DC; Sat, 10 Nov 2018 05:14:08 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30495.vci.att.com (Service) with ESMTP id E28404009E85; Sat, 10 Nov 2018 05:14:07 +0000 (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 wAA5E7L6022512; Fri, 9 Nov 2018 23:14:07 -0600 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 wAA5E0uX022028; Fri, 9 Nov 2018 23:14:00 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTP id B803FE1BEF; Sat, 10 Nov 2018 00:13:59 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Sat, 10 Nov 2018 00:13:09 -0500 From: "MORTON, ALFRED C (AL)" To: "Mirja Kuehlewind (IETF)" CC: "draft-ietf-ippm-port-twamp-test.all@ietf.org" , "spencerdawkins.ietf@gmail.com" , "ippm@ietf.org" Thread-Topic: [ippm] AD review of draft-ietf-ippm-port-twamp-test Thread-Index: AQHUb7IS2QGrObPQyUeFS1fWuZHhsKVAJHPwgAiIOwD//8EtMIAAasOA//+uuIA= Date: Sat, 10 Nov 2018 05:12:47 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557DE0DC@njmtexg5.research.att.com> References: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557D896F@njmtexg5.research.att.com> <7DAAE1B6-3F0C-472B-8185-9FACB35EF59E@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557DE051@njmtexg5.research.att.com> <879BC912-692D-4C82-8591-3FA76EF9F66E@kuehlewind.net> In-Reply-To: <879BC912-692D-4C82-8591-3FA76EF9F66E@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [110.170.235.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-10_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811100043 Archived-At: Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 05:14:19 -0000 TWlyamEgd3JvdGU6DQogICBJdOKAmXMgY2FsbGVkIERvd25yZWYgcmVnaXN0cnkgYW5kIGl0J3Mg aGVyZToNCiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Rvd25yZWYvDQoNCiAg IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBpdCB3aWxsIGdvIHRoZXJlIGF1dG9tYXRpY2FsbHkg DQogICBpZiBvbmNlIHJlZmVyZW5jZWQgYXMgYSBkb3ducmVmIGJ1dCBJIGNhbiBkb3VibGUtY2hl Y2sgDQogICBkdXJpbmcgdGhlIHB1YmxpY2F0aW9uIHByb2Nlc3MuDQoNCkkgYmVsaWV2ZSB3ZSBu ZWVkIHRvIG1ha2UgYSBzcGVjaWZpYyByZXF1ZXN0IGZvciBpbmNsdXNpb24NCm9mIFJGQzc1OTQg KGJlY2F1c2UgSSB0aGluayB3ZSd2ZSBhbHJlYWR5IGJlZW4gZG93biB0aGUgDQoiRG93bnJlZiBy b2FkIiBmb3IgNzU5NCwgYXQgbGVhc3QgTE1BUCBoYXMpLiBUaGlzIHdpbGwgDQpjb21lLXVwIHJl cGVhdGVkbHksIGFuZCBpdCdzIHdvcnRoIGFueSBleHRyYSBzdGVwcyBJTU8uDQoNCnRoYW5rcyBN aXJqYSENCkFsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWlyamEg S3VlaGxld2luZCAoSUVURikgW21haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0XQ0KPiBTZW50OiBG cmlkYXksIE5vdmVtYmVyIDksIDIwMTggMTE6NTkgUE0NCj4gVG86IE1PUlRPTiwgQUxGUkVEIEMg KEFMKSA8YWNtQHJlc2VhcmNoLmF0dC5jb20+DQo+IENjOiBkcmFmdC1pZXRmLWlwcG0tcG9ydC10 d2FtcC10ZXN0LmFsbEBpZXRmLm9yZzsNCj4gc3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb207 IGlwcG1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtpcHBtXSBBRCByZXZpZXcgb2YgZHJhZnQt aWV0Zi1pcHBtLXBvcnQtdHdhbXAtdGVzdA0KPiANCj4gSGkgQWwsDQo+IA0KPiBzZWUgaW5saW5l Lg0KPiANCj4gPiBBbSAxMC4xMS4yMDE4IHVtIDEwOjQ3IHNjaHJpZWIgTU9SVE9OLCBBTEZSRUQg QyAoQUwpDQo+IDxhY21AcmVzZWFyY2guYXR0LmNvbT46DQo+ID4NCj4gPiBIaSBNaXJqYSwgYW5k IFNwZW5jZXIsDQo+ID4NCj4gPiByZXBsaWVzIGJlbG93LCB3aXRoIGEgcXVlc3Rpb24gZm9yIHRo ZSAiT3V0Z29pbmcgQUQiDQo+ID4gQWwNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+PiBGcm9tOiBNaXJqYSBLdWVobGV3aW5kIChJRVRGKSBbbWFpbHRvOmlldGZAa3Vl aGxld2luZC5uZXRdDQo+ID4+IFNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgOSwgMjAxOCA5OjIyIFBN DQo+ID4+IFRvOiBkcmFmdC1pZXRmLWlwcG0tcG9ydC10d2FtcC10ZXN0LmFsbEBpZXRmLm9yZw0K PiA+PiBDYzogaXBwbUBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW2lwcG1dIEFEIHJldmll dyBvZiBkcmFmdC1pZXRmLWlwcG0tcG9ydC10d2FtcC10ZXN0DQo+ID4+DQo+ID4+IEhpIGFsbCwN Cj4gPj4NCj4gPj4gc29ycnkgb25lIG1vcmUgcXVlc3Rpb246IFJGQzc1OTQgd291bGQgYmUgYSBk b3ducmVmIGFuZCBJIHRoaW5rIGl0IGlzDQo+ID4+IGNvcnJlY3QgdGhhdCB0aGlzIGlzIGEgbm9y bWF0aXZlIHJlZmVyZW5jZSBiZWNhdXNlIGl0IHBvaW50ZWQgdG8gaW4gdGhlDQo+ID4+IHNlY3Vy aXR5IHNlYy4gT24gdGhlIG90aGVyIGl0IHNlZW1zIGEgYml0IHdlaXJkIHRvIHBvaW50IG5vcm1h dGl2ZWx5IHRvDQo+ID4+IHRoZSBzZWN1cml0eSBzZWN0aW9uIG9mIGFuIGluZm9ybWF0aW9uYWwg ZG9jLiBTbyBqdXN0IGRvdWJsZS1jaGVja2luZw0KPiBpZg0KPiA+PiB0aGF0IGlzIGFsbCByaWdo dCAoZ2l2ZW4gZG93bnJlZnMgbmVlZCB0byBiZSBjYWxsZWQgb3V0IGluIHRoZSBsYXN0DQo+IGNh bGwsDQo+ID4+IHNvIHdlIGhhdmUgdG8gZGVjaWRlIGJlZm9yZSBJIHN0YXJ0IGxhc3QgY2FsbCk/ DQo+ID4gW2FjbV0NCj4gPg0KPiA+IFllcywgSSdkIGxpa2UgdG8ga2VlcCB0aGUgRG93bnJlZiwg YW5kIGFsc28gYXNrIHRvIHBsYWNlIFJGQyA3NTk0DQo+ID4gb24gdGhlICJwZXJtYW5lbnQgRG93 bnJlZiBleGNlcHRpb24gbGlzdCIuIEkgZG9uJ3Qga25vdyB0aGUgZXhhY3QNCj4gPiBuYW1lIG9m IHRoaXMgbGlzdCwgYnV0IHRoZSBJUFBNIEZyYW1ld29yayBSRkMgMjMzMCB3YXMgcGxhY2VkIG9u IGl0Lg0KPiA+DQo+ID4gQFNwZW5jZXI6ICJPdXRnb2luZyBBRCIgbWF5IGJlIGFibGUgdG8gaGVs cCB1cyBmaW5kIHRoZSBsaXN0IGFib3ZlLA0KPiA+IGJlZm9yZSB5b3UgZ28gcGxlYXNlLiA6LSkN Cj4gDQo+IEl04oCZcyBjYWxsZWQgRG93bnJlZiByZWdpc3RyeSBhbmQgaXQncyBoZXJlOg0KPiAN Cj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAz QV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2Rvd25yZWZfJmQ9RHdJRmFRJmM9TEZZWi0NCj4g bzlfSFVNZU1UU1FpY3ZqSWcmcj1fNmNlbjNIbi1lX2hPbTBCaFk3YUlwQTU4ZGQxOVo5cUdRc3I4 LTZ6WU1JJm09LQ0KPiAyZ2pYV044R1NDSDJJM1BDTjRmUTVqeURuXzg2Tm4xX2RlUDdxMENxRWcm cz1jWnpwV2haV0xRdkZBckFoSWc0LQ0KPiB4aFFocHlRbkVMaEJmYWd0VWZhVGpUVSZlPQ0KPiAN Cj4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGl0IHdpbGwgZ28gdGhlcmUgYXV0b21hdGljYWxs eSBpZiBvbmNlIHJlZmVyZW5jZWQNCj4gYXMgYSBkb3ducmVmIGJ1dCBJIGNhbiBkb3VibGUtY2hl Y2sgZHVyaW5nIHRoZSBwdWJsaWNhdGlvbiBwcm9jZXNzLg0KPiANCj4gPg0KPiA+Pg0KPiA+PiBB bHNvIGxvb2tpbmcgYXQgdGhlIHJlZmVyZW5jZXMgYWdhaW4sIEkgdGhpbmsgUkZDNjMzNSBkb2Vz IG5vdCBuZWVkIHRvDQo+IGJlDQo+ID4+IGEgbm9ybWF0aXZlIHJlZmVyZW5jZS4NCj4gPiBbYWNt XQ0KPiA+IElmIG91ciBjb2xsZWFndWVzIGluIElBTkEgYXJlIG9rIHdpdGggdGhhdCwgc28gYW0g SS4NCj4gDQo+IE9rYXkuIEFjdHVhbGx5IHdlIGNhbiBkbyB0aGlzIGxhdGVyIGFuZCBkb27igJl0 IGhhdmUgdG8gZG8gaXQgYmVmb3JlIGxhc3QNCj4gY2FsbCwgd2hpY2ggSSB3aWxsIHJlc3BlY3Rp dmVseSBzdGFydCBub3cuDQo+IA0KPiBUaGFua3MhDQo+IE1pcmphDQo+IA0KPiANCj4gPg0KPiA+ Pg0KPiA+PiBAVGlhbnJhbjogYSBkb3ducmVmIGlzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBh IGRvY3VtZW50IHdpdGggYSBsb3dlcg0KPiA+PiBtYXR1cml0eSBsZXZlbCwgc28gYWxzbyBhIG5v cm1hdGl2ZSByZWZlcmVuY2UgZnJvbSBhIGRyYWZ0IHRoYXQgaXMNCj4gPj4gaW50ZW5kZWQgZm9y IFByb3Bvc2VkIFN0YW5kYXJkIHRvIGFuIGluZm9ybWF0aW9uYWwgUkZDIGlzIGEgZG93bnJlZi4g SW4NCj4gPj4gdGhlIHNoZXBoZXJkIHdyaXRlLXVwIHlvdSBvbmx5IHNheSB0aGF0IHRoZXJlIGFy ZSBub3JtYXRpdmUgcmVmZXJlbmNlDQo+IHRvDQo+ID4+IFJGQ3MsIGhvd2V2ZXIsIHlvdSB3b3Vs ZCBuZXh0IHRpbWUgYWxzbyBuZWVkIHRvIGNoZWNrIHRoZSBzdGF0dXMgb2YNCj4gdGhlc2UNCj4g Pj4gUkZDcy4gVGhhbmtzISBCdHcuIGNvdWxkIHlvdSBwbGVhc2UgdXBkYXRlIHRoZSBzaGVwaGVy ZCB3cml0ZS11cD8NCj4gPiBbYWNtXQ0KPiA+ICsxLCB0aGFua3MgVGlhbnJhbi4NCj4gPg0KPiA+ Pg0KPiA+PiBNaXJqYQ0KPiA+Pg0KPiA+Pg0KPiA+Pj4gQW0gMDUuMTEuMjAxOCB1bSAwNDo1NyBz Y2hyaWViIE1PUlRPTiwgQUxGUkVEIEMgKEFMKQ0KPiA+PiA8YWNtQHJlc2VhcmNoLmF0dC5jb20+ Og0KPiA+Pj4NCj4gPj4+IEhpIE1pcmphLA0KPiA+Pj4gcGxlYXNlIHNlZSByZXBsaWVzIGluLWxp bmUuDQo+ID4+PiBBbA0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+Pj4+IEZyb206IGlwcG0gW21haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBNaXJqYQ0KPiBLdWVobGV3aW5kDQo+ID4+Pj4gKElFVEYpDQo+ID4+Pj4gU2VudDogTW9u ZGF5LCBPY3RvYmVyIDI5LCAyMDE4IDI6MDYgUE0NCj4gPj4+PiBUbzogZHJhZnQtaWV0Zi1pcHBt LXBvcnQtdHdhbXAtdGVzdC5hbGxAaWV0Zi5vcmcNCj4gPj4+PiBDYzogaXBwbUBpZXRmLm9yZw0K PiA+Pj4+IFN1YmplY3Q6IFtpcHBtXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pcHBtLXBvcnQt dHdhbXAtdGVzdA0KPiA+Pj4+DQo+ID4+Pj4gSGkgYXV0aG9ycywNCj4gPj4+Pg0KPiA+Pj4+IGZp cnN0IG9mIGFsbCBzb3JyeSBmb3IgdGhlIHJhdGhlciBsb25nIGRlbGF5IGZvciB0aGlzIHNob3J0 IGRyYWZ0Lg0KPiBUaGUNCj4gPj4gYmFkDQo+ID4+Pj4gbmV3cyBpdCB0aGF0IEkgcHJvYmFibHkg aGF2ZSB0byBkZWxheSB0aGUgcHJvY2Vzc2luZyBldmVuIGZ1cnRoZXIgYXMNCj4gSQ0KPiA+Pj4+ IHdpbGwgbm90IGJlIGFibGUgdG8gam9pbiB0aGUgbmV4dCB0ZWxlY2hhdCBvbiBOb3YgMjEgYW5k IHdlIGhhdmUgdG8NCj4gPj4gd2FpdA0KPiA+Pj4+IGZvciB0aGUgdGVsZWNoYXQgb24gRGVjIDYu IFRoZSBnb29kIG5ld3MgaXMgdGhhdCBnaXZlcyB1cyBwbGVudHkgb2YNCj4gPj4gdGltZQ0KPiA+ Pj4+IGZvciB0aGUgSUVURiBsYXN0IGNhbGwgOi0pDQo+ID4+Pj4NCj4gPj4+PiBJIHJldmlld2Vk IHRoaXMgZG9jdW1lbnQgYW5kIEkgZG9u4oCZdCB0aGluayB0aGVyZSBhcmUgYW55IGlzc3VlcyB0 aGF0DQo+ID4+IHdvdWxkDQo+ID4+Pj4gbm90IGFsbG93IG1lIHRvIHN0YXJ0IHRoZSBJRVRGIGxh c3QgY2FsLCBidXQgZ2l2ZW4gd2UgaGF2ZSB0aW1lIEkNCj4gd291bGQNCj4gPj4+PiBsaWtlIHRv IGFzayBhIGZldyBxdWVzdGlvbnMvY29tbWVudHM6DQo+ID4+Pj4NCj4gPj4+PiAxKSBUaGUgZG9j dW1lbnQgZ2l2ZXMgcGxlbnR5IG9mIGJhY2tncm91bmQgaW5mb3JtYXRpb24gYW5kIHRhbGtzDQo+ IGFib3V0DQo+ID4+Pj4gaW1wYWN0cywgaG93ZXZlciwgaXQgc2F5cyB2ZXJ5IGxpdHRsZSBhYm91 dCB3aHkgaXQgaXMgZ29vZCB0byBoYXZlIGENCj4gPj4gZml4ZWQNCj4gPj4+PiBwb3J0LCBiZXNp ZGUgdGhpczoNCj4gPj4+PiAiSXQgbWF5IHNpbXBsaWZ5IHNvbWUgb3BlcmF0aW9ucyB0byBoYXZl IGEgd2VsbC0NCj4gPj4+PiAga25vd24gcG9ydCBhdmFpbGFibGUgZm9yIHRoZSBUZXN0IHByb3Rv Y29scywgb3IgZm9yIGZ1dHVyZQ0KPiA+Pj4+ICBzcGVjaWZpY2F0aW9ucyBpbnZvbHZpbmcgVFdB TVAtVGVzdCB0byB1c2UgdGhpcyBwb3J0IGFzIGEgZGVmYXVsdA0KPiA+Pj4+ICBwb3J0LuKAnA0K PiA+Pj4+IElzIHRoZXJlIGFueSBjaGFuY2UgdG8gc2F5IG1vcmUgdGhhbiB0aGlzPw0KPiA+Pj4g W2FjbV0NCj4gPj4+IHllcywgbWVudGlvbmVkIEJCRiBUUi0zOTAgaW1wbGVtZW50YXRpb25zIGFz IGJlbmVmYWN0b3JzLg0KPiA+Pj4+DQo+ID4+Pj4gMikgQWxzbywgSSBhZ3JlZSB3aXRoIHRoZSBz aGVwaGVyZCB0aGF0IEkgZG9u4oCZdCB0aGluayBpdCBpcyBuZWNlc3NhcnkNCj4gPj4gdG8NCj4g Pj4+PiBkZXRhaWwgdGhlIGhpc3RvcnkgYXMgbXVjaCBhcyBkb25lIGluIHNlY3Rpb24gNCwgZS5n LiByYXRoZXIgZGlzY3Vzcw0KPiA+PiB0aGUNCj4gPj4+PiB3aHkgdGhhbiB0aGUgYWN0dWFsbHkg Y29tbWVudHMgYnkgTGFycyBhbmQgVGltLiBBbHNvIHRoaXMgc2VjdGlvbiBpcw0KPiA+Pj4+IGNh bGxlZCDigJ5kZWZpbml0aW9u4oCcIGJ1dCB0aGlzIGJhY2tncm91bmQgaW5mb3JtYXRpb24gc2Vl bXMgdG8gZ28NCj4gYmV5b25kDQo+ID4+Pj4ganVzdCBkZWZpbmluZyBzb21ldGhpbmcuDQo+ID4+ PiBbYWNtXQ0KPiA+Pj4gT2sgdGhlIHNlY3Rpb24gaXMgbm93IHRpdGxlZCwgRGVmaW5pdGlvbnMg YW5kIEJhY2tncm91bmQsDQo+ID4+PiBhbmQgbW9zdCBvZiB0aGUgZGV0YWlscyBkZXNjcmliaW5n IGNvbW1lbnRzIGZyb20gTGFycyBhbmQgVGltDQo+ID4+PiBhcmUgbW92ZWQgdG8gYW4gQXBwZW5k aXggQS4NCj4gPj4+DQo+ID4+Pj4NCj4gPj4+PiBCdHcuIFRpYW5yYW4sIGl0IHdvdWxkIGJlIG5p Y2UgaWYgeW91IGNvdWxkIHVwZGF0ZSB5b3VyIGNvbW1lbnRzIGluDQo+IHRoZQ0KPiA+Pj4+IHNo ZXBoZXJkIHdyaXRlLXVwIGFjY29yZGluZ2x5IGlmIHRoZXkgaGF2ZSBiZWVuIGFkZHJlc3NlZCBv ciBhcmUNCj4gPj4gb2Jzb2xldGUuDQo+ID4+Pj4gVGhhbmtzIQ0KPiA+Pj4gW2FjbV0NCj4gPj4+ IFllcywgcGxlYXNlIGNvbnNpZGVyIGluY29ycG9yYXRpbmcgc29tZSBvZiB0aGUgZGV0YWlscyBm cm9tDQo+ID4+PiBteSBlLW1haWwgbGFzdCBBdWd1c3QsIHRoYW5rcyENCj4gPj4+DQo+ID4+Pj4N Cj4gPj4+PiAzKSBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgaXMgYW55IG5vcm1hdGl2ZSBsYW5ndWFn ZSByZXF1aXJlIGluIHRoaXMgZG9jLg0KPiA+PiBBcw0KPiA+Pj4+IHlvdSBhcmUg4oCeanVzdOKA nCBzdGF0aW5nIHdoYXQgaGFzIGJlZW4gbm9ybWF0aXZlbHkgZGVmaW5lZCBpbiBvdGhlcg0KPiA+ Pj4+IGRvY3VtZW50cywgaXQgaXMgYWN0dWFsbHkgcHJlZmVycmVkIHRvIG5vdCByZS1zdGF0ZSBu b3JtYXRpdmVseS4NCj4gPj4+IFthY21dDQo+ID4+PiBUaGUgU2NvcGUgc2F5czoNCj4gPj4+IAlU aGUgc2NvcGUgb2YgdGhpcyBtZW1vIGlzIHRvIHJlLWFsbG9jYXRlIHdlbGwta25vd24gcG9ydHMg Zm9yIHRoZQ0KPiA+PiBVRFANCj4gPj4+IAlUZXN0IHByb3RvY29scyB0aGF0IGNvbXBvc2UgbmVj ZXNzYXJ5IHBhcnRzIG9mIHRoZWlyIHJlc3BlY3RpdmUNCj4gPj4+IAlzdGFuZGFyZHMgdHJhY2sg cHJvdG9jb2xzLCBPV0FNUCBhbmQgVFdBTVAsIGFsb25nIHdpdGgNCj4gPj4gY2xhcmlmaWNhdGlv bnMNCj4gPj4+IAlvZiB0aGUgY29tcGxldGUgcHJvdG9jb2wgY29tcG9zaXRpb24gZm9yIHRoZSBp bmR1c3RyeS4NCj4gPj4+DQo+ID4+PiBUaGUgY29udHJvdmVyc3kgYWJvdXQgVFdBTVAgY29tcG9z aXRpb24gaXMgcGFydGx5IHdoYXQgYnJvdWdodCB1cw0KPiBoZXJlIQ0KPiA+Pj4gV2UgdXNlZCB0 aGUgdGVybSBSRVFVSVJFRCBpbiB0aGUgRGVmaW5pdGlvbnMgdG8gcmVzb2x2ZSB0aGUgc21hbGwN Cj4gPj4gYW1iaWd1aXR5DQo+ID4+PiBjcmVhdGVkIHdoZW4gT1dBTVAgYXV0aG9ycyBkaWQgbm90 IHVzZSBub3JtYXRpdmUgbGFuZ3VhZ2Ugd2hlbg0KPiA+PiBkZXNjcmliaW5nDQo+ID4+PiB0aGUg cHJvdG9jb2xzIHRoYXQgY29tcHJpc2UgT1dBTVAsIGFuZCBUV0FNUCBhdXRob3JzIGZvbGxvd2Vk IHRoYXQNCj4gPj4gY2hvaWNlIG9mDQo+ID4+PiB3b3JkaW5nICh1bmZvcnR1bmF0ZWx5KS4NCj4g Pj4+DQo+ID4+Pj4NCj4gPj4+PiA0KSBBbiB1cGRhdGUgaW4gdGhlIHJlZ2lzdHJ5IGRvZXMgbm90 IG5lY2Vzc2FyeSBtZWFuIGFuIOKAnnVwZGF0ZeKAnCBvZg0KPiB0aGUNCj4gPj4+PiBSRkNzIHRo YXQgcmVnaXN0ZXJlZCB0aGF0IHBvcnRzIGluIHRoZSBmaXJzdCBwbGFjZSwgZXNwZWNpYWxseSBh cw0KPiA+PiByZmM0NjU2DQo+ID4+Pj4gZG9lc27igJl0IGV2ZW4gbWVudGlvbiB0aGUgVURQIHBv cnQgYXQgYWxsLiBPZiBjb3Vyc2UgdGhlIHVzZSBvZg0KPiDigJ51cGRhdGXigJwNCj4gPj4gaXMN Cj4gPj4+PiB2ZXJ5IGxvb3NlbHkgZGVmaW5lZCBhbmQgY2FuIGJlIHVzZWQgaWYgdGhhdCBpcyBw cmVmZXJyZWQgYnV0IGl0IGlzDQo+IG5vdA0KPiA+Pj4+IHN0cmljdGx5IG5lY2Vzc2FyeS4gT3Ig aXMgdGhlcmUgYW5vdGhlciByZWFzb24gdG8gdXBkYXRlIHRoZXNlIFJGQ3M/DQo+IElmDQo+ID4+ Pj4gc28sIGl0IHNob3VsZCBiZSBjbGVhcmx5IHNwZWxsZWQgb3V0IGluIHRoZSBkcmFmdC4NCj4g Pj4+IFthY21dDQo+ID4+PiBPaywgZHJhd2luZyBvbiB0aGUgcG9pbnQgZnJvbSB0aGUgU2NvcGUs IGFuZCByZXF1aXJlbWVudCBMYW5ndWFnZQ0KPiBhYm92ZSwNCj4gPj4+IHRoZSBBYnN0cmFjdCBu b3cgZW5kcyB3aXRoOg0KPiA+Pj4NCj4gPj4+IFRoZSBtZW1vIHVwZGF0ZXMgUkZDIDQ2NTYgYW5k IFJGQyA1MzU3LCBpbiB0ZXJtcyBvZiB0aGUgVURQIHdlbGwta25vd24NCj4gPj4gcG9ydA0KPiA+ Pj4gYXNzaWdubWVudHMsIGFuZCBjbGFyaWZpZXMgdGhlIGNvbXBsZXRlIE9XQU1QIGFuZCBUV0FN UCBwcm90b2NvbA0KPiA+PiBjb21wb3NpdGlvbg0KPiA+Pj4gZm9yIHRoZSBpbmR1c3RyeS4NCj4g Pj4+DQo+ID4+Pj4NCj4gPj4+PiA1KSBHaXZlbiB0aGF0IHRoZXNlIGVudHJpZXMgYXJlIHVwZGF0 ZXMgaXQgd291bGQgYmUgbmljZSB0byBhbHNvIGZpbGwNCj4gPj4gdGhlDQo+ID4+Pj4gbWlzc2lu ZyBpbmZvcm1hdGlvbiBhYm91dCBjb250YWN0IGluZm9ybWF0aW9uIGFuZCBhc3NpZ25lZSBpbiB0 aGUNCj4gPj4+PiByZWdpc3RyeS4gSW5zdHJ1Y3Rpb24gZm9yIElBTkEgd291bGQgbmVlZCB0byBi ZSBhZGRlZCB0byB0aGUgSUFOQQ0KPiA+PiBzZWN0aW9uDQo+ID4+Pj4gaW4gdGhpcyBjYXNlLiBB c3NpZ25lZSBzaG91bGQgYmUgdGhlIElFU0cgYW5kIGNvbnRhY3QgdGhlIElFVEYgY2hhaXIuDQo+ IEkNCj4gPj4+PiBhc3N1bWUgdGhlIG1vZGlmaWNhdGlvbiBkYXRlIHdpbGwgYmUgZmlsbGVkIGJ5 IElBTkEgcmVzcGVjdGl2ZWx5Lg0KPiA+Pj4gW2FjbV0NCj4gPj4+IG9rDQo+ID4+Pg0KPiA+Pj4+ DQo+ID4+Pj4gVGhhbmtzIQ0KPiA+Pj4+IE1pcmphDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBpcHBtIG1haWxpbmcgbGlzdA0KPiA+Pj4+IGlw cG1AaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtDQo+ID4+Pj4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lw cG0mZD1Ed0lHYVEmYz1MRllaLQ0KPiA+Pj4+DQo+ID4+DQo+IG85X0hVTWVNVFNRaWN2aklnJnI9 T2ZzU3U4a1RJbHRWeUQxb0w3MmNCdyZtPWZjelJ2WWNmRmN1d2Z0QUxQbDNpZGR4QnFyT0NwDQo+ ID4+Pj4gVVRMYTJxZlBzaFBtUlkmcz1ELUQ0MlB1M0RGcjdUQUliNHJhczg3dDJjTnh5RHQ0VVVS dEZHa1BaRE9vJmU9DQo+ID4NCg0K From nobody Fri Nov 9 21:15:20 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423D2131094; Fri, 9 Nov 2018 21:15:17 -0800 (PST) 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 QFcOmcwKl1CF; Fri, 9 Nov 2018 21:15:14 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 1AF1C131091; Fri, 9 Nov 2018 21:15:14 -0800 (PST) Received: from vpn-global-dhcp3-221.ethz.ch ([129.132.210.221]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gLLbz-0002g2-QD; Sat, 10 Nov 2018 06:15:12 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF557DE0DC@njmtexg5.research.att.com> Date: Sat, 10 Nov 2018 12:15:08 +0700 Cc: "draft-ietf-ippm-port-twamp-test.all@ietf.org" , "spencerdawkins.ietf@gmail.com" , "ippm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557D896F@njmtexg5.research.att.com> <7DAAE1B6-3F0C-472B-8185-9FACB35EF59E@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557DE051@njmtexg5.research.att.com> <879BC912-692D-4C82-8591-3FA76EF9F66E@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557DE0DC@njmtexg5.research.att.com> To: "MORTON, ALFRED C (AL)" X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1541826914;bb82f5a5; X-HE-SMSGID: 1gLLbz-0002g2-QD Archived-At: Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 05:15:17 -0000 Okay, I=E2=80=99ll check! > Am 10.11.2018 um 12:12 schrieb MORTON, ALFRED C (AL) = : >=20 > Mirja wrote: > It=E2=80=99s called Downref registry and it's here: > https://datatracker.ietf.org/doc/downref/ >=20 > My understanding is that it will go there automatically=20 > if once referenced as a downref but I can double-check=20 > during the publication process. >=20 > I believe we need to make a specific request for inclusion > of RFC7594 (because I think we've already been down the=20 > "Downref road" for 7594, at least LMAP has). This will=20 > come-up repeatedly, and it's worth any extra steps IMO. >=20 > thanks Mirja! > Al >=20 >> -----Original Message----- >> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] >> Sent: Friday, November 9, 2018 11:59 PM >> To: MORTON, ALFRED C (AL) >> Cc: draft-ietf-ippm-port-twamp-test.all@ietf.org; >> spencerdawkins.ietf@gmail.com; ippm@ietf.org >> Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test >>=20 >> Hi Al, >>=20 >> see inline. >>=20 >>> Am 10.11.2018 um 10:47 schrieb MORTON, ALFRED C (AL) >> : >>>=20 >>> Hi Mirja, and Spencer, >>>=20 >>> replies below, with a question for the "Outgoing AD" >>> Al >>>=20 >>>> -----Original Message----- >>>> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] >>>> Sent: Friday, November 9, 2018 9:22 PM >>>> To: draft-ietf-ippm-port-twamp-test.all@ietf.org >>>> Cc: ippm@ietf.org >>>> Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test >>>>=20 >>>> Hi all, >>>>=20 >>>> sorry one more question: RFC7594 would be a downref and I think it = is >>>> correct that this is a normative reference because it pointed to in = the >>>> security sec. On the other it seems a bit weird to point = normatively to >>>> the security section of an informational doc. So just = double-checking >> if >>>> that is all right (given downrefs need to be called out in the last >> call, >>>> so we have to decide before I start last call)? >>> [acm] >>>=20 >>> Yes, I'd like to keep the Downref, and also ask to place RFC 7594 >>> on the "permanent Downref exception list". I don't know the exact >>> name of this list, but the IPPM Framework RFC 2330 was placed on it. >>>=20 >>> @Spencer: "Outgoing AD" may be able to help us find the list above, >>> before you go please. :-) >>=20 >> It=E2=80=99s called Downref registry and it's here: >>=20 >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__datatracker.ietf.org_doc_downref_&d=3DDwIFaQ&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3D_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=3D-= >> 2gjXWN8GSCH2I3PCN4fQ5jyDn_86Nn1_deP7q0CqEg&s=3DcZzpWhZWLQvFArAhIg4- >> xhQhpyQnELhBfagtUfaTjTU&e=3D >>=20 >> My understanding is that it will go there automatically if once = referenced >> as a downref but I can double-check during the publication process. >>=20 >>>=20 >>>>=20 >>>> Also looking at the references again, I think RFC6335 does not need = to >> be >>>> a normative reference. >>> [acm] >>> If our colleagues in IANA are ok with that, so am I. >>=20 >> Okay. Actually we can do this later and don=E2=80=99t have to do it = before last >> call, which I will respectively start now. >>=20 >> Thanks! >> Mirja >>=20 >>=20 >>>=20 >>>>=20 >>>> @Tianran: a downref is a normative reference to a document with a = lower >>>> maturity level, so also a normative reference from a draft that is >>>> intended for Proposed Standard to an informational RFC is a = downref. In >>>> the shepherd write-up you only say that there are normative = reference >> to >>>> RFCs, however, you would next time also need to check the status of >> these >>>> RFCs. Thanks! Btw. could you please update the shepherd write-up? >>> [acm] >>> +1, thanks Tianran. >>>=20 >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>> Am 05.11.2018 um 04:57 schrieb MORTON, ALFRED C (AL) >>>> : >>>>>=20 >>>>> Hi Mirja, >>>>> please see replies in-line. >>>>> Al >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Mirja >> Kuehlewind >>>>>> (IETF) >>>>>> Sent: Monday, October 29, 2018 2:06 PM >>>>>> To: draft-ietf-ippm-port-twamp-test.all@ietf.org >>>>>> Cc: ippm@ietf.org >>>>>> Subject: [ippm] AD review of draft-ietf-ippm-port-twamp-test >>>>>>=20 >>>>>> Hi authors, >>>>>>=20 >>>>>> first of all sorry for the rather long delay for this short = draft. >> The >>>> bad >>>>>> news it that I probably have to delay the processing even further = as >> I >>>>>> will not be able to join the next telechat on Nov 21 and we have = to >>>> wait >>>>>> for the telechat on Dec 6. The good news is that gives us plenty = of >>>> time >>>>>> for the IETF last call :-) >>>>>>=20 >>>>>> I reviewed this document and I don=E2=80=99t think there are any = issues that >>>> would >>>>>> not allow me to start the IETF last cal, but given we have time I >> would >>>>>> like to ask a few questions/comments: >>>>>>=20 >>>>>> 1) The document gives plenty of background information and talks >> about >>>>>> impacts, however, it says very little about why it is good to = have a >>>> fixed >>>>>> port, beside this: >>>>>> "It may simplify some operations to have a well- >>>>>> known port available for the Test protocols, or for future >>>>>> specifications involving TWAMP-Test to use this port as a default >>>>>> port.=E2=80=9C >>>>>> Is there any chance to say more than this? >>>>> [acm] >>>>> yes, mentioned BBF TR-390 implementations as benefactors. >>>>>>=20 >>>>>> 2) Also, I agree with the shepherd that I don=E2=80=99t think it = is necessary >>>> to >>>>>> detail the history as much as done in section 4, e.g. rather = discuss >>>> the >>>>>> why than the actually comments by Lars and Tim. Also this section = is >>>>>> called =E2=80=9Edefinition=E2=80=9C but this background = information seems to go >> beyond >>>>>> just defining something. >>>>> [acm] >>>>> Ok the section is now titled, Definitions and Background, >>>>> and most of the details describing comments from Lars and Tim >>>>> are moved to an Appendix A. >>>>>=20 >>>>>>=20 >>>>>> Btw. Tianran, it would be nice if you could update your comments = in >> the >>>>>> shepherd write-up accordingly if they have been addressed or are >>>> obsolete. >>>>>> Thanks! >>>>> [acm] >>>>> Yes, please consider incorporating some of the details from >>>>> my e-mail last August, thanks! >>>>>=20 >>>>>>=20 >>>>>> 3) I don=E2=80=99t think there is any normative language require = in this doc. >>>> As >>>>>> you are =E2=80=9Ejust=E2=80=9C stating what has been normatively = defined in other >>>>>> documents, it is actually preferred to not re-state normatively. >>>>> [acm] >>>>> The Scope says: >>>>> The scope of this memo is to re-allocate well-known ports for = the >>>> UDP >>>>> Test protocols that compose necessary parts of their respective >>>>> standards track protocols, OWAMP and TWAMP, along with >>>> clarifications >>>>> of the complete protocol composition for the industry. >>>>>=20 >>>>> The controversy about TWAMP composition is partly what brought us >> here! >>>>> We used the term REQUIRED in the Definitions to resolve the small >>>> ambiguity >>>>> created when OWAMP authors did not use normative language when >>>> describing >>>>> the protocols that comprise OWAMP, and TWAMP authors followed that >>>> choice of >>>>> wording (unfortunately). >>>>>=20 >>>>>>=20 >>>>>> 4) An update in the registry does not necessary mean an = =E2=80=9Eupdate=E2=80=9C of >> the >>>>>> RFCs that registered that ports in the first place, especially as >>>> rfc4656 >>>>>> doesn=E2=80=99t even mention the UDP port at all. Of course the = use of >> =E2=80=9Eupdate=E2=80=9C >>>> is >>>>>> very loosely defined and can be used if that is preferred but it = is >> not >>>>>> strictly necessary. Or is there another reason to update these = RFCs? >> If >>>>>> so, it should be clearly spelled out in the draft. >>>>> [acm] >>>>> Ok, drawing on the point from the Scope, and requirement Language >> above, >>>>> the Abstract now ends with: >>>>>=20 >>>>> The memo updates RFC 4656 and RFC 5357, in terms of the UDP = well-known >>>> port >>>>> assignments, and clarifies the complete OWAMP and TWAMP protocol >>>> composition >>>>> for the industry. >>>>>=20 >>>>>>=20 >>>>>> 5) Given that these entries are updates it would be nice to also = fill >>>> the >>>>>> missing information about contact information and assignee in the >>>>>> registry. Instruction for IANA would need to be added to the IANA >>>> section >>>>>> in this case. Assignee should be the IESG and contact the IETF = chair. >> I >>>>>> assume the modification date will be filled by IANA respectively. >>>>> [acm] >>>>> ok >>>>>=20 >>>>>>=20 >>>>>> Thanks! >>>>>> Mirja >>>>>>=20 >>>>>>=20 >>>>>>=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- >>>>>>=20 >>>>=20 >> = o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DfczRvYcfFcuwftALPl3iddxBq= rOCp >>>>>> UTLa2qfPshPmRY&s=3DD-D42Pu3DFr7TAIb4ras87t2cNxyDt4UURtFGkPZDOo&e=3D= >>>=20 >=20 From nobody Sat Nov 10 01:23:18 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2552F130E11 for ; Sat, 10 Nov 2018 01:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgZRQC3YTkMx for ; Sat, 10 Nov 2018 01:23:14 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 D0990130DE4 for ; Sat, 10 Nov 2018 01:23:13 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id q186-v6so3611368ljb.5 for ; Sat, 10 Nov 2018 01:23:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=16EbQ0J7ZSeBEFr+6gTPjHXkZZEzjBVoAbYqSIrZ+Kg=; b=FV6NkkTa8CElyoUJRk4Tj9FaE7Ba3gEdTeEntywPWE1n9Cs9l90QPASZRhTGuNjKyk CEg3X5HwPaqk1uVq/XN03CwehEfPSr0mrczFr5P6+cm5p2XExrAuoL1tMP+qY9sj/0Ks olHUFKXNHQA0yyF49c19jXtL63n9FFQXpVedoTnONaCmpXfT2f9k2TGB2c6nhOtH3AC4 rTj9tz5e84E8QMsp9Ssmwf2mzD7soRLGO2scb07n5tviH81jNzRGzp5IwPoT3OO0kVSq RQk22vPUBPhiC31zg+Mg9kM4EEepVvDZZEoPnahdPNEVmdvB4BBLCoXKBKty9qiRaX2H /B3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=16EbQ0J7ZSeBEFr+6gTPjHXkZZEzjBVoAbYqSIrZ+Kg=; b=sqHboULZp2eHJfcrWrQobv2umCtVTAe9k2AOt/7GdtWv0JfI4vf66aVA31eXNulD8a I1tNtmGSh7EmaeHtkf3/dlqtW47dp7VQ8CZ/E3vYv2y4MDtaL+kLB488+C+Y/6dwzom2 CAwyoQUkPlQf9J/rjZaUzZJdvNWSOhsx2EMT2oU1f0CuBoPq4MAsyhMSfppRlD9/aBWK g6rxZ/QyjSoeU946fqkgN+xxSGdmytQVe1NxgbnSdq8kNe3hw2X/KhP2rPDG9+w2eKjw c2Ra/X+sx6LDnMBhII7kF71cAfJYPvUeh0optoslXlKW5233ZJxV/q7AjLY6inLlMAfY G3sQ== X-Gm-Message-State: AGRZ1gK5V6+qL8jZxgnJ0lQx82+K69NPp4w9Ii39mdS3KzQkroboqtQB cUeO2F7Jfuzsc64DcLlRW3KLeCj/WibwntW9fdA= X-Google-Smtp-Source: AJdET5erumL7OV9qDRkVB86v8zyAhkig2W2X2gQ1jjDTAt67bMlowvQoKv4gohBpFv0x4zq9KIcqSeNkE8kTw7ltwrQ= X-Received: by 2002:a2e:c52:: with SMTP id o18-v6mr7576899ljd.94.1541841791742; Sat, 10 Nov 2018 01:23:11 -0800 (PST) MIME-Version: 1.0 References: <153635740444.28980.6908501775124770245@ietfa.amsl.com> <0861E2EE-9403-4F71-AFD7-1C89D73C773C@trammell.ch> <730E50FA-3318-43FE-9C1E-60D29B748BE0@trammell.ch> In-Reply-To: From: Greg Mirsky Date: Sat, 10 Nov 2018 16:23:01 +0700 Message-ID: To: bew@cisco.com Cc: "J. Ignacio Alvarez-Hamelin" , IETF IPPM WG Content-Type: multipart/alternative; boundary="0000000000004bf70a057a4c04a6" Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 10 Nov 2018 09:23:17 -0000 --0000000000004bf70a057a4c04a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Brian, I've started the new working version to apply updates resulting from our discussion and need to clarify one question with you. You've suggested that confidentiality may be provided by encryption at a higher level, i.e., not on the STAMP message. Thus, as I understand, we would not need to define the encrypted mode in STAMP and only have two modes - unauthenticated and authenticated. Would you agree? Regards, Greg On Wed, Nov 7, 2018 at 10:50 AM Brian Weis (bew) wrote: > Hi Ignacio and Greg, > > ECDSA is a digital signature algorithm, which is very expensive and > because of this it is not traditionally used to protect network data > packets. I don=E2=80=99t recommend specifying it. Unless this is a rarel= y sent > data packet sent, you would be consuming a substantial amount of the CPU = by > applying a digital signature to every packet sent with STAMP. Also, in > order to get the value you want, you actually have to create a hash of t= he > packet (e.g., using SHA1/SHA256) and then sign the hash, where the result > will be at least the length of a full HMAC output. So you=E2=80=99re not = saving any > space. > > Using HMAC-SHA1 or SHA256 on network data packets as shown in Figure 4 is > very reasonable. Section 5 of RFC 2104 (HMAC) says how it=E2=80=99s acce= ptable to > truncate the hash output, and security protocols usually do this. IPSec > truncates HMAC-SHA-1 output to 96 bits (RFC 2404), and HMAC-SHA-256 is > truncated to 128 bits (RFC 4868). Since -03 was willing to apply a 128-b= it > truncated hash, I think you could safely specify using HMAC-SHA-256 with = a > 128 bit truncation. Note that if you specify the use of HMAC-SHA1, you wi= ll > very likely run into SecDir complaints when you get to IETF last call. > > I did mention in the IPPM meeting that adding AES support is bit more > problematic. I would recommend specifying that when confidentiality is > needed that it be done a higher layer. If you do decide to keep it in thi= s > draft, you should describe what is the value of protecting only the first > 16 octets. Also, you should know that cryptographers do not recommend usi= ng > EBC. A Wikipedia page describes this plainly: "The disadvantage of this > method is a lack of diffusion. Because ECB encrypts > identical plaintext blocks into identical ciphertext blocks, it does not > hide data patterns well. In some senses, it doesn't provide serious messa= ge > confidentiality, and it is not recommended for use in cryptographic > protocols at all.=E2=80=9D ( > https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_C= odebook_(ECB)) > . > > The other mode -03 mentioned is using AES-CBC to protect the entire > message. That=E2=80=99s a conventional use of AES, but when AES-CBC is us= ed, both > the encryptor and decrypt need the same Initialization Vector (IV) used > with the method. Traditionally it is included in the packet, so that=E2= =80=99s > another 16 octets you probably need to add to the packet format. This > should NOT replace the HMAC field, because cryptographers strongly state > that it is bad practice to send an unauthenticated encrypted packet. > > I don=E2=80=99t see the rationale in -03 for needing confidentiality. So = it might > be best to stick with an HMAC-SHA256 hash, and if confidentiality is > required to use a higher layer encryption. Otherwise, you=E2=80=99ll need= to do a > lot more specification of how the confidentially is done in this draft. > > I hope that helps. > > Brian > > On Nov 7, 2018, at 9:15 AM, Greg Mirsky wrote: > > Ho J.Ignacio, > thank you for the comment and helpful suggestion. Will read the > draft-alavarez-hamelin-tictoc-sic and respond accordingly in a short time= . > From the quick run through the draft, I agree with you that ECDSA offers > advantages over the SHA1 of the same length. Just need to check for > possible impact on YANG data model. > > Regards, > Greg > > On Wed, Nov 7, 2018 at 2:26 AM J Ignacio Alvarez-Hamelin < > ihameli@cnet.fi.uba.ar> wrote: > >> Hi Greg, >> >> Today at the IPPM meeting I said that you could consider using SHA1 256 >> with bits for authentication, to respect some security standards. Your >> comment that is expensive, and I agree with that. >> I propose another alternative, is the one that I used in >> draft-alavarez-hamelin-tictoc-sic-02, the Elliptic Curve Digital Signatu= re >> Algorithm (ECDSA), which yields in few bits and has some securities form= de >> cryptographic point of view. >> >> >> Best withes, >> >> J. Ignacio >> _______________________________________________________________ >> >> Dr. Ing. Jos=C3=A9 Ignacio Alvarez-Hamelin >> CONICET and Facultad de Ingenier=C3=ADa, Universidad de Buenos Aires >> Av. Paseo Col=C3=B3n 850 - C1063ACV - Buenos Aires - Argentina >> +54 (11) 5285 0716 / 5285 0705 >> e-mail: ihameli@cnet.fi.uba.ar >> web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ >> _______________________________________________________________ >> >> >> >> > On 16 Oct 2018, at 05:24, Brian Trammell (IETF) >> wrote: >> > >> > hi Greg, >> > >> > We'll put this and a tentative start of WGLC on the Bangkok agenda.. >> > >> > Thanks, cheers, >> > >> > Brian >> > >> >> On 16 Oct 2018, at 01:00, Greg Mirsky wrote: >> >> >> >> Hi Brian, >> >> my apologies for the delayed response. The new version of the draft >> has been just uploaded. The updates include the new section that describ= es >> authentication and encryption operations on STAMP packets. I'd request t= he >> presentation slot at the meeting and, if there are no significant concer= ns, >> would ask to consider starting the WG LC on the base specification. The >> work on the STAMP YANG data model still on-going and we're addressing th= e >> comments from the early YANG Doctors review by Mahesh. I expect we'll ha= ve >> the new version by the end of November. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Thu, Oct 4, 2018 at 8:12 AM Brian Trammell (IETF) >> wrote: >> >> hi Greg, >> >> >> >> following up a bit late, perhaps... when do you think this will be >> ready for LC? >> >> >> >> Cheers, >> >> >> >> Brian (as WG co-chair) >> >> >> >>> On 8 Sep 2018, at 00:53, Greg Mirsky wrote: >> >>> >> >>> Dear All, >> >>> minor editorial improvements to the document.. >> >>> Your comments, questions, and suggestions always welcome and much >> appreciated. >> >>> >> >>> Regards, >> >>> Greg >> >>> >> >>> ---------- Forwarded message ---------- >> >>> From: >> >>> Date: Fri, Sep 7, 2018 at 2:56 PM >> >>> Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt >> >>> To: i-d-announce@ietf.org >> >>> Cc: ippm@ietf.org >> >>> >> >>> >> >>> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >>> This draft is a work item of the IP Performance Measurement WG of th= e >> IETF. >> >>> >> >>> Title : Simple Two-way Active Measurement Protocol >> >>> Authors : Greg Mirsky >> >>> Guo Jun >> >>> Henrik Nydell >> >>> Richard Foote >> >>> Filename : draft-ietf-ippm-stamp-02.txt >> >>> Pages : 14 >> >>> Date : 2018-09-07 >> >>> >> >>> Abstract: >> >>> This document describes a Simple Two-way Active Measurement Protoc= ol >> >>> which enables measurement of both one-way and round-trip performan= ce >> >>> metrics like delay, delay variation, and packet loss. >> >>> >> >>> >> >>> The IETF datatracker status page for this draft is: >> >>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ >> >>> >> >>> There are also htmlized versions available at: >> >>> https://tools.ietf.org/html/draft-ietf-ippm-stamp-02 >> >>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-02 >> >>> >> >>> A diff from the previous version is available at: >> >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-stamp-02 >> >>> >> >>> >> >>> Please note that it may take a couple of minutes from the time of >> submission >> >>> until the htmlized version and diff are available at tools.ietf.org. >> >>> >> >>> Internet-Drafts are also available by anonymous FTP at: >> >>> ftp://ftp.ietf.org/internet-drafts/ >> >>> >> >>> _______________________________________________ >> >>> ippm mailing list >> >>> ippm@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ippm >> >>> >> >>> _______________________________________________ >> >>> ippm mailing list >> >>> ippm@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ippm >> >> >> > >> > _______________________________________________ >> > ippm mailing list >> > ippm@ietf.org >> > https://www.ietf.org/mailman/listinfo/ippm >> >> _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > -- > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > --0000000000004bf70a057a4c04a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,
I've started the new working version to = apply updates resulting from our discussion and need to clarify one questio= n with you. You've suggested that confidentiality may be provided by en= cryption at a higher level, i.e., not on the STAMP message. Thus, as I unde= rstand, we would not need to define the encrypted mode in STAMP and only ha= ve two modes - unauthenticated and authenticated. Would you agree?

Regards,
Greg

On Wed, Nov 7, 2018 at 10:50 AM Brian Weis (bew) &= lt;bew@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hi Ignacio and Greg,

ECDSA is a digital signature algorithm, which is very expensive and be= cause of this it is not traditionally used to protect network data packets.= =C2=A0 I don=E2=80=99t recommend specifying it. Unless this is a rarely sen= t data packet sent, you would be consuming a substantial amount of the CPU by applying a digital signature to every p= acket sent with STAMP. Also, in order to get the value =C2=A0you want, you = actually have to create a hash of the packet (e.g., using SHA1/SHA256) and = then sign the hash, where the result will be at least the length of a full HMAC output. So you=E2=80=99re not s= aving any space.

Using HMAC-SHA1 or SHA256 on network data packets as shown in Figure 4= is very reasonable.=C2=A0 Section 5 of RFC 2104 (HMAC) says how it=E2=80= =99s acceptable to truncate the hash output, and security protocols usually= do this.=C2=A0 IPSec truncates HMAC-SHA-1 output to 96 bits (RFC 2404), and HMAC-SHA-256 is truncated to 128 bits (R= FC 4868).=C2=A0 Since -03 was willing to apply a 128-bit truncated hash, I = think you could safely specify using HMAC-SHA-256 with a 128 bit truncation= . Note that if you specify the use of HMAC-SHA1, you will very likely run into SecDir complaints when you get to= IETF last call.

I did mention in the IPPM meeting that adding AES support is bit more = problematic. I would recommend specifying that when confidentiality is need= ed that it be done a higher layer. If you do decide to keep it in this draf= t, you should describe what is the value of protecting only the first 16 octets. Also, you should= know that cryptographers do not recommend using EBC. A Wikipedia page desc= ribes this plainly: "The disadvantage of this method is a lack of=C2= =A0diffusion. Because ECB encrypts identical=C2=A0plaintext=C2=A0blocks into identical=C2=A0ciphertext=C2=A0blocks, it=C2=A0does not hide data pat= terns well. In some senses, it doesn't provide serious message confiden= tiality, and it is not recommended for use in=C2=A0cryptographic protocols = at all.=E2=80=9D (https://en.wik= ipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_(ECB)).

The other mode -03 mentioned is using AES-CBC to protect the entire me= ssage. That=E2=80=99s a conventional use of AES, but when AES-CBC is used, = both the encryptor and decrypt need the same Initialization Vector (IV) use= d with the method. Traditionally it is included in the packet, so that=E2=80=99s another 16 octets you prob= ably need to add to the packet format. This should NOT replace the HMAC fie= ld, because cryptographers strongly state that it is bad practice to send a= n unauthenticated encrypted packet.=C2=A0

I don=E2=80=99t see the rationale in -03 for needing confidentiality. = So it might be best to stick with an HMAC-SHA256 hash, and if confidentiali= ty is required to use a higher layer encryption. Otherwise, you=E2=80=99ll = need to do a lot more specification of how the confidentially is done in this draft.

I hope that helps.

Brian


Ho J.Ignacio,
thank you for the comment and helpful=C2=A0suggestion. Will read the d= raft-alavarez-hamelin-tictoc-sic and respond=C2=A0accordingly in a short ti= me. From the quick run through the draft, I agree with you that ECDSA offer= s advantages over the SHA1 of the=C2=A0same length. Just need to check for possible impact on YANG data model.

Regards,
Greg

On Wed, Nov 7, 2018 at 2:26 AM J Ignacio Alvarez-Hamelin &= lt;ihameli@cnet= .fi.uba.ar> wrote:
Hi Greg,

Today at the IPPM meeting I said that you could consider using SHA1 256 wit= h bits for authentication, to respect some security standards. Your comment= that is expensive, and I agree with that.
I propose another alternative, is the one that I used in draft-alavarez-ham= elin-tictoc-sic-02, the Elliptic Curve Digital Signature Algorithm (ECDSA),= which yields in few bits and has some securities form de cryptographic poi= nt of view.


Best withes,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 J. Ignacio
_______________________________________________________________

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



> On 16 Oct 2018, at 05:24, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>
> hi Greg,
>
> We'll put this and a tentative start of WGLC on the Bangkok agenda= ..
>
> Thanks, cheers,
>
> Brian
>
>> On 16 Oct 2018, at 01:00, Greg Mirsky <gregimirsky@gmail.com> wrote:
>>
>> Hi Brian,
>> my apologies for the delayed response. The new version of the draf= t has been just uploaded. The updates include the new section that describe= s authentication and encryption operations on STAMP packets. I'd reques= t the presentation slot at the meeting and, if there are no significant concerns, would ask to consider starting the W= G LC on the base specification. The work on the STAMP YANG data model still= on-going and we're addressing the comments from the early YANG Doctors= review by Mahesh. I expect we'll have the new version by the end of November.
>>
>> Regards,
>> Greg
>>
>> On Thu, Oct 4, 2018 at 8:12 AM Brian Trammell (IETF) <ietf@trammell.ch> wro= te:
>> hi Greg,
>>
>> following up a bit late, perhaps... when do you think this will be= ready for LC?
>>
>> Cheers,
>>
>> Brian (as WG co-chair)
>>
>>> On 8 Sep 2018, at 00:53, Greg Mirsky <gregimirsky@gmail.com> wrote:<= br> >>>
>>> Dear All,
>>> minor editorial improvements to the document..
>>> Your comments, questions, and suggestions always welcome and m= uch appreciated.
>>>
>>> Regards,
>>> Greg
>>>
>>> ---------- Forwarded message ----------
>>> From: <internet-drafts@ietf.org>
>>> Date: Fri, Sep 7, 2018 at 2:56 PM
>>> Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt
>>> To: i-d-announce@ietf.org
>>> Cc: ippm@ie= tf.org
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts directories.
>>> This draft is a work item of the IP Performance Measurement WG= of the IETF.
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Simple Two-way Active Measurement Protocol
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Greg Mirsky
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Guo Jun
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Henrik Nydell
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Richard Foote
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0= : draft-ietf-ippm-stamp-02.txt
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: 14
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2018-09-07
>>>
>>> Abstract:
>>>=C2=A0 =C2=A0This document describes a Simple Two-way Active Me= asurement Protocol
>>>=C2=A0 =C2=A0which enables measurement of both one-way and roun= d-trip performance
>>>=C2=A0 =C2=A0metrics like delay, delay variation, and packet lo= ss.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-ippm-stamp-02
>>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-02
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-stamp-02
>>>
>>>
>>> Please note that it may take a couple of minutes from the time= of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/ippm
>>>
>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/ippm
>>
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm

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

--=C2=A0
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com=

--0000000000004bf70a057a4c04a6-- From nobody Sun Nov 11 18:19:26 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84D612D4F2 for ; Sun, 11 Nov 2018 18:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 6EhJ5fUepsKr for ; Sun, 11 Nov 2018 18:19:20 -0800 (PST) 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 9F0391276D0 for ; Sun, 11 Nov 2018 18:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35430; q=dns/txt; s=iport; t=1541989160; x=1543198760; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=p46SNdkI37YlreCxn1VW+K8cK+C47oeFVRbVWw8fJ30=; b=aJMePYAr79H57v12Aj3YB1YhICt/fJ+Zsrkrm3wgEaJbUnfNpZ+h9/yS VYh2X0sZZe9oEfaK701o57qOIYQpkhBiuJZbaT1bVns40JGJ87VOXsJg1 xuBlCOzTnfYdvO6fp+BuCoBaxGuBlZhbBSZRuEa8mKpn5l2GNUGhxuc5u s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAA34uhb/49dJa1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIDZoECJwqDbogYi3iCDYdegSmOLhS?= =?us-ascii?q?BZgsBARgBDIRHAheDDSI0DQ0BAwEBAgEBAm0cDIU6AQEBAwEBASFLCwULAgE?= =?us-ascii?q?IEQMBAgEgBwMCAgIfBgsUCQgCBA4FgyEBgR1MAw0ID6hHgS+EMQIMQD+CMQ2?= =?us-ascii?q?CGYtjHReBf4ERJx+CTIJWRQEBAgEBFoEPBQESATYJAR0Jgj2CVwKJEiyFLoU?= =?us-ascii?q?HgSiKBi4JAoZ0gyeDVYMrEgaBWEyENoMihnSNJoEFiSYCERSBJg0QOGRxcBU?= =?us-ascii?q?aISoBgkEJgh0BF4F1hmmFPkExAYtZgR+BHwEB?= X-IronPort-AV: E=Sophos;i="5.54,493,1534809600"; d="scan'208,217";a="200211852" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 02:19:19 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id wAC2JI1H022205 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Nov 2018 02:19:18 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 11 Nov 2018 21:19:17 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1395.000; Sun, 11 Nov 2018 21:19:17 -0500 From: "Brian Weis (bew)" To: Greg Mirsky CC: "J. Ignacio Alvarez-Hamelin" , IETF IPPM WG Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt Thread-Index: AQHUdga0j7BtTkXoqE2P+bPcfo/CEqVD50GAgAAabwCABSTLgIACnX2A Date: Mon, 12 Nov 2018 02:19:17 +0000 Message-ID: References: <153635740444.28980.6908501775124770245@ietfa.amsl.com> <0861E2EE-9403-4F71-AFD7-1C89D73C773C@trammell.ch> <730E50FA-3318-43FE-9C1E-60D29B748BE0@trammell.ch> 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.24.30.241] Content-Type: multipart/alternative; boundary="_000_EA717254C51C4E04810C588464200852ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.145, xch-rtp-005.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-stamp-02.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 12 Nov 2018 02:19:24 -0000 --_000_EA717254C51C4E04810C588464200852ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KT24gTm92IDEwLCAyMDE4LCBhdCA0OjIzIFBNLCBHcmVnIE1pcnNreSA8Z3Jl Z2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToN Cg0KSGkgQnJpYW4sDQpJJ3ZlIHN0YXJ0ZWQgdGhlIG5ldyB3b3JraW5nIHZlcnNpb24gdG8gYXBw bHkgdXBkYXRlcyByZXN1bHRpbmcgZnJvbSBvdXIgZGlzY3Vzc2lvbiBhbmQgbmVlZCB0byBjbGFy aWZ5IG9uZSBxdWVzdGlvbiB3aXRoIHlvdS4gWW91J3ZlIHN1Z2dlc3RlZCB0aGF0IGNvbmZpZGVu dGlhbGl0eSBtYXkgYmUgcHJvdmlkZWQgYnkgZW5jcnlwdGlvbiBhdCBhIGhpZ2hlciBsZXZlbCwg aS5lLiwgbm90IG9uIHRoZSBTVEFNUCBtZXNzYWdlLiBUaHVzLCBhcyBJIHVuZGVyc3RhbmQsIHdl IHdvdWxkIG5vdCBuZWVkIHRvIGRlZmluZSB0aGUgZW5jcnlwdGVkIG1vZGUgaW4gU1RBTVAgYW5k IG9ubHkgaGF2ZSB0d28gbW9kZXMgLSB1bmF1dGhlbnRpY2F0ZWQgYW5kIGF1dGhlbnRpY2F0ZWQu IFdvdWxkIHlvdSBhZ3JlZT8NCg0KVGhhdCBwbGFuIG1ha2VzIHNlbnNlIHRvIG1lLg0KDQpUaGFu a3MsDQpCcmlhbg0KDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFdlZCwgTm92IDcsIDIwMTggYXQg MTA6NTAgQU0gQnJpYW4gV2VpcyAoYmV3KSA8YmV3QGNpc2NvLmNvbTxtYWlsdG86YmV3QGNpc2Nv LmNvbT4+IHdyb3RlOg0KSGkgSWduYWNpbyBhbmQgR3JlZywNCg0KRUNEU0EgaXMgYSBkaWdpdGFs IHNpZ25hdHVyZSBhbGdvcml0aG0sIHdoaWNoIGlzIHZlcnkgZXhwZW5zaXZlIGFuZCBiZWNhdXNl IG9mIHRoaXMgaXQgaXMgbm90IHRyYWRpdGlvbmFsbHkgdXNlZCB0byBwcm90ZWN0IG5ldHdvcmsg ZGF0YSBwYWNrZXRzLiAgSSBkb27igJl0IHJlY29tbWVuZCBzcGVjaWZ5aW5nIGl0LiBVbmxlc3Mg dGhpcyBpcyBhIHJhcmVseSBzZW50IGRhdGEgcGFja2V0IHNlbnQsIHlvdSB3b3VsZCBiZSBjb25z dW1pbmcgYSBzdWJzdGFudGlhbCBhbW91bnQgb2YgdGhlIENQVSBieSBhcHBseWluZyBhIGRpZ2l0 YWwgc2lnbmF0dXJlIHRvIGV2ZXJ5IHBhY2tldCBzZW50IHdpdGggU1RBTVAuIEFsc28sIGluIG9y ZGVyIHRvIGdldCB0aGUgdmFsdWUgIHlvdSB3YW50LCB5b3UgYWN0dWFsbHkgaGF2ZSB0byBjcmVh dGUgYSBoYXNoIG9mIHRoZSBwYWNrZXQgKGUuZy4sIHVzaW5nIFNIQTEvU0hBMjU2KSBhbmQgdGhl biBzaWduIHRoZSBoYXNoLCB3aGVyZSB0aGUgcmVzdWx0IHdpbGwgYmUgYXQgbGVhc3QgdGhlIGxl bmd0aCBvZiBhIGZ1bGwgSE1BQyBvdXRwdXQuIFNvIHlvdeKAmXJlIG5vdCBzYXZpbmcgYW55IHNw YWNlLg0KDQpVc2luZyBITUFDLVNIQTEgb3IgU0hBMjU2IG9uIG5ldHdvcmsgZGF0YSBwYWNrZXRz IGFzIHNob3duIGluIEZpZ3VyZSA0IGlzIHZlcnkgcmVhc29uYWJsZS4gIFNlY3Rpb24gNSBvZiBS RkMgMjEwNCAoSE1BQykgc2F5cyBob3cgaXTigJlzIGFjY2VwdGFibGUgdG8gdHJ1bmNhdGUgdGhl IGhhc2ggb3V0cHV0LCBhbmQgc2VjdXJpdHkgcHJvdG9jb2xzIHVzdWFsbHkgZG8gdGhpcy4gIElQ U2VjIHRydW5jYXRlcyBITUFDLVNIQS0xIG91dHB1dCB0byA5NiBiaXRzIChSRkMgMjQwNCksIGFu ZCBITUFDLVNIQS0yNTYgaXMgdHJ1bmNhdGVkIHRvIDEyOCBiaXRzIChSRkMgNDg2OCkuICBTaW5j ZSAtMDMgd2FzIHdpbGxpbmcgdG8gYXBwbHkgYSAxMjgtYml0IHRydW5jYXRlZCBoYXNoLCBJIHRo aW5rIHlvdSBjb3VsZCBzYWZlbHkgc3BlY2lmeSB1c2luZyBITUFDLVNIQS0yNTYgd2l0aCBhIDEy OCBiaXQgdHJ1bmNhdGlvbi4gTm90ZSB0aGF0IGlmIHlvdSBzcGVjaWZ5IHRoZSB1c2Ugb2YgSE1B Qy1TSEExLCB5b3Ugd2lsbCB2ZXJ5IGxpa2VseSBydW4gaW50byBTZWNEaXIgY29tcGxhaW50cyB3 aGVuIHlvdSBnZXQgdG8gSUVURiBsYXN0IGNhbGwuDQoNCkkgZGlkIG1lbnRpb24gaW4gdGhlIElQ UE0gbWVldGluZyB0aGF0IGFkZGluZyBBRVMgc3VwcG9ydCBpcyBiaXQgbW9yZSBwcm9ibGVtYXRp Yy4gSSB3b3VsZCByZWNvbW1lbmQgc3BlY2lmeWluZyB0aGF0IHdoZW4gY29uZmlkZW50aWFsaXR5 IGlzIG5lZWRlZCB0aGF0IGl0IGJlIGRvbmUgYSBoaWdoZXIgbGF5ZXIuIElmIHlvdSBkbyBkZWNp ZGUgdG8ga2VlcCBpdCBpbiB0aGlzIGRyYWZ0LCB5b3Ugc2hvdWxkIGRlc2NyaWJlIHdoYXQgaXMg dGhlIHZhbHVlIG9mIHByb3RlY3Rpbmcgb25seSB0aGUgZmlyc3QgMTYgb2N0ZXRzLiBBbHNvLCB5 b3Ugc2hvdWxkIGtub3cgdGhhdCBjcnlwdG9ncmFwaGVycyBkbyBub3QgcmVjb21tZW5kIHVzaW5n IEVCQy4gQSBXaWtpcGVkaWEgcGFnZSBkZXNjcmliZXMgdGhpcyBwbGFpbmx5OiAiVGhlIGRpc2Fk dmFudGFnZSBvZiB0aGlzIG1ldGhvZCBpcyBhIGxhY2sgb2YgZGlmZnVzaW9uLiBCZWNhdXNlIEVD QiBlbmNyeXB0cyBpZGVudGljYWwgcGxhaW50ZXh0IGJsb2NrcyBpbnRvIGlkZW50aWNhbCBjaXBo ZXJ0ZXh0IGJsb2NrcywgaXQgZG9lcyBub3QgaGlkZSBkYXRhIHBhdHRlcm5zIHdlbGwuIEluIHNv bWUgc2Vuc2VzLCBpdCBkb2Vzbid0IHByb3ZpZGUgc2VyaW91cyBtZXNzYWdlIGNvbmZpZGVudGlh bGl0eSwgYW5kIGl0IGlzIG5vdCByZWNvbW1lbmRlZCBmb3IgdXNlIGluIGNyeXB0b2dyYXBoaWMg cHJvdG9jb2xzIGF0IGFsbC7igJ0gKGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0Jsb2Nr X2NpcGhlcl9tb2RlX29mX29wZXJhdGlvbiNFbGVjdHJvbmljX0NvZGVib29rXyhFQ0IpKS4NCg0K VGhlIG90aGVyIG1vZGUgLTAzIG1lbnRpb25lZCBpcyB1c2luZyBBRVMtQ0JDIHRvIHByb3RlY3Qg dGhlIGVudGlyZSBtZXNzYWdlLiBUaGF04oCZcyBhIGNvbnZlbnRpb25hbCB1c2Ugb2YgQUVTLCBi dXQgd2hlbiBBRVMtQ0JDIGlzIHVzZWQsIGJvdGggdGhlIGVuY3J5cHRvciBhbmQgZGVjcnlwdCBu ZWVkIHRoZSBzYW1lIEluaXRpYWxpemF0aW9uIFZlY3RvciAoSVYpIHVzZWQgd2l0aCB0aGUgbWV0 aG9kLiBUcmFkaXRpb25hbGx5IGl0IGlzIGluY2x1ZGVkIGluIHRoZSBwYWNrZXQsIHNvIHRoYXTi gJlzIGFub3RoZXIgMTYgb2N0ZXRzIHlvdSBwcm9iYWJseSBuZWVkIHRvIGFkZCB0byB0aGUgcGFj a2V0IGZvcm1hdC4gVGhpcyBzaG91bGQgTk9UIHJlcGxhY2UgdGhlIEhNQUMgZmllbGQsIGJlY2F1 c2UgY3J5cHRvZ3JhcGhlcnMgc3Ryb25nbHkgc3RhdGUgdGhhdCBpdCBpcyBiYWQgcHJhY3RpY2Ug dG8gc2VuZCBhbiB1bmF1dGhlbnRpY2F0ZWQgZW5jcnlwdGVkIHBhY2tldC4NCg0KSSBkb27igJl0 IHNlZSB0aGUgcmF0aW9uYWxlIGluIC0wMyBmb3IgbmVlZGluZyBjb25maWRlbnRpYWxpdHkuIFNv IGl0IG1pZ2h0IGJlIGJlc3QgdG8gc3RpY2sgd2l0aCBhbiBITUFDLVNIQTI1NiBoYXNoLCBhbmQg aWYgY29uZmlkZW50aWFsaXR5IGlzIHJlcXVpcmVkIHRvIHVzZSBhIGhpZ2hlciBsYXllciBlbmNy eXB0aW9uLiBPdGhlcndpc2UsIHlvdeKAmWxsIG5lZWQgdG8gZG8gYSBsb3QgbW9yZSBzcGVjaWZp Y2F0aW9uIG9mIGhvdyB0aGUgY29uZmlkZW50aWFsbHkgaXMgZG9uZSBpbiB0aGlzIGRyYWZ0Lg0K DQpJIGhvcGUgdGhhdCBoZWxwcy4NCg0KQnJpYW4NCg0KT24gTm92IDcsIDIwMTgsIGF0IDk6MTUg QU0sIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5 QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIbyBKLklnbmFjaW8sDQp0aGFuayB5b3UgZm9yIHRoZSBj b21tZW50IGFuZCBoZWxwZnVsIHN1Z2dlc3Rpb24uIFdpbGwgcmVhZCB0aGUgZHJhZnQtYWxhdmFy ZXotaGFtZWxpbi10aWN0b2Mtc2ljIGFuZCByZXNwb25kIGFjY29yZGluZ2x5IGluIGEgc2hvcnQg dGltZS4gRnJvbSB0aGUgcXVpY2sgcnVuIHRocm91Z2ggdGhlIGRyYWZ0LCBJIGFncmVlIHdpdGgg eW91IHRoYXQgRUNEU0Egb2ZmZXJzIGFkdmFudGFnZXMgb3ZlciB0aGUgU0hBMSBvZiB0aGUgc2Ft ZSBsZW5ndGguIEp1c3QgbmVlZCB0byBjaGVjayBmb3IgcG9zc2libGUgaW1wYWN0IG9uIFlBTkcg ZGF0YSBtb2RlbC4NCg0KUmVnYXJkcywNCkdyZWcNCg0KT24gV2VkLCBOb3YgNywgMjAxOCBhdCAy OjI2IEFNIEogSWduYWNpbyBBbHZhcmV6LUhhbWVsaW4gPGloYW1lbGlAY25ldC5maS51YmEuYXI8 bWFpbHRvOmloYW1lbGlAY25ldC5maS51YmEuYXI+PiB3cm90ZToNCkhpIEdyZWcsDQoNClRvZGF5 IGF0IHRoZSBJUFBNIG1lZXRpbmcgSSBzYWlkIHRoYXQgeW91IGNvdWxkIGNvbnNpZGVyIHVzaW5n IFNIQTEgMjU2IHdpdGggYml0cyBmb3IgYXV0aGVudGljYXRpb24sIHRvIHJlc3BlY3Qgc29tZSBz ZWN1cml0eSBzdGFuZGFyZHMuIFlvdXIgY29tbWVudCB0aGF0IGlzIGV4cGVuc2l2ZSwgYW5kIEkg YWdyZWUgd2l0aCB0aGF0Lg0KSSBwcm9wb3NlIGFub3RoZXIgYWx0ZXJuYXRpdmUsIGlzIHRoZSBv bmUgdGhhdCBJIHVzZWQgaW4gZHJhZnQtYWxhdmFyZXotaGFtZWxpbi10aWN0b2Mtc2ljLTAyLCB0 aGUgRWxsaXB0aWMgQ3VydmUgRGlnaXRhbCBTaWduYXR1cmUgQWxnb3JpdGhtIChFQ0RTQSksIHdo aWNoIHlpZWxkcyBpbiBmZXcgYml0cyBhbmQgaGFzIHNvbWUgc2VjdXJpdGllcyBmb3JtIGRlIGNy eXB0b2dyYXBoaWMgcG9pbnQgb2Ygdmlldy4NCg0KDQpCZXN0IHdpdGhlcywNCg0KICAgICAgICBK LiBJZ25hY2lvDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KRHIuIEluZy4gSm9zw6kgSWduYWNpbyBBbHZhcmV6LUhhbWVs aW4NCkNPTklDRVQgYW5kIEZhY3VsdGFkIGRlIEluZ2VuaWVyw61hLCBVbml2ZXJzaWRhZCBkZSBC dWVub3MgQWlyZXMNCkF2LiBQYXNlbyBDb2zDs24gODUwIC0gQzEwNjNBQ1YgLSBCdWVub3MgQWly ZXMgLSBBcmdlbnRpbmENCis1NCAoMTEpIDUyODUgMDcxNiAvIDUyODUgMDcwNQ0KZS1tYWlsOiBp aGFtZWxpQGNuZXQuZmkudWJhLmFyPG1haWx0bzppaGFtZWxpQGNuZXQuZmkudWJhLmFyPg0Kd2Vi OiBodHRwOi8vY25ldC5maS51YmEuYXIvaWduYWNpby5hbHZhcmV6LWhhbWVsaW4vDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KDQoNCj4gT24gMTYgT2N0IDIwMTgsIGF0IDA1OjI0LCBCcmlhbiBUcmFtbWVsbCAoSUVURikg PGlldGZAdHJhbW1lbGwuY2g8bWFpbHRvOmlldGZAdHJhbW1lbGwuY2g+PiB3cm90ZToNCj4NCj4g aGkgR3JlZywNCj4NCj4gV2UnbGwgcHV0IHRoaXMgYW5kIGEgdGVudGF0aXZlIHN0YXJ0IG9mIFdH TEMgb24gdGhlIEJhbmdrb2sgYWdlbmRhLi4NCj4NCj4gVGhhbmtzLCBjaGVlcnMsDQo+DQo+IEJy aWFuDQo+DQo+PiBPbiAxNiBPY3QgMjAxOCwgYXQgMDE6MDAsIEdyZWcgTWlyc2t5IDxncmVnaW1p cnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4N Cj4+IEhpIEJyaWFuLA0KPj4gbXkgYXBvbG9naWVzIGZvciB0aGUgZGVsYXllZCByZXNwb25zZS4g VGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBoYXMgYmVlbiBqdXN0IHVwbG9hZGVkLiBUaGUg dXBkYXRlcyBpbmNsdWRlIHRoZSBuZXcgc2VjdGlvbiB0aGF0IGRlc2NyaWJlcyBhdXRoZW50aWNh dGlvbiBhbmQgZW5jcnlwdGlvbiBvcGVyYXRpb25zIG9uIFNUQU1QIHBhY2tldHMuIEknZCByZXF1 ZXN0IHRoZSBwcmVzZW50YXRpb24gc2xvdCBhdCB0aGUgbWVldGluZyBhbmQsIGlmIHRoZXJlIGFy ZSBubyBzaWduaWZpY2FudCBjb25jZXJucywgd291bGQgYXNrIHRvIGNvbnNpZGVyIHN0YXJ0aW5n IHRoZSBXRyBMQyBvbiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9uLiBUaGUgd29yayBvbiB0aGUgU1RB TVAgWUFORyBkYXRhIG1vZGVsIHN0aWxsIG9uLWdvaW5nIGFuZCB3ZSdyZSBhZGRyZXNzaW5nIHRo ZSBjb21tZW50cyBmcm9tIHRoZSBlYXJseSBZQU5HIERvY3RvcnMgcmV2aWV3IGJ5IE1haGVzaC4g SSBleHBlY3Qgd2UnbGwgaGF2ZSB0aGUgbmV3IHZlcnNpb24gYnkgdGhlIGVuZCBvZiBOb3ZlbWJl ci4NCj4+DQo+PiBSZWdhcmRzLA0KPj4gR3JlZw0KPj4NCj4+IE9uIFRodSwgT2N0IDQsIDIwMTgg YXQgODoxMiBBTSBCcmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g8bWFpbHRv OmlldGZAdHJhbW1lbGwuY2g+PiB3cm90ZToNCj4+IGhpIEdyZWcsDQo+Pg0KPj4gZm9sbG93aW5n IHVwIGEgYml0IGxhdGUsIHBlcmhhcHMuLi4gd2hlbiBkbyB5b3UgdGhpbmsgdGhpcyB3aWxsIGJl IHJlYWR5IGZvciBMQz8NCj4+DQo+PiBDaGVlcnMsDQo+Pg0KPj4gQnJpYW4gKGFzIFdHIGNvLWNo YWlyKQ0KPj4NCj4+PiBPbiA4IFNlcCAyMDE4LCBhdCAwMDo1MywgR3JlZyBNaXJza3kgPGdyZWdp bWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tPj4gd3JvdGU6DQo+ Pj4NCj4+PiBEZWFyIEFsbCwNCj4+PiBtaW5vciBlZGl0b3JpYWwgaW1wcm92ZW1lbnRzIHRvIHRo ZSBkb2N1bWVudC4uDQo+Pj4gWW91ciBjb21tZW50cywgcXVlc3Rpb25zLCBhbmQgc3VnZ2VzdGlv bnMgYWx3YXlzIHdlbGNvbWUgYW5kIG11Y2ggYXBwcmVjaWF0ZWQuDQo+Pj4NCj4+PiBSZWdhcmRz LA0KPj4+IEdyZWcNCj4+Pg0KPj4+IC0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0t LS0tLQ0KPj4+IEZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4+DQo+Pj4gRGF0ZTogRnJpLCBTZXAgNywgMjAxOCBhdCAyOjU2IFBN DQo+Pj4gU3ViamVjdDogW2lwcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaXBwbS1zdGFtcC0w Mi50eHQNCj4+PiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VA aWV0Zi5vcmc+DQo+Pj4gQ2M6IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQo+ Pj4NCj4+Pg0KPj4+DQo+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPj4+IFRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IFdHIG9mIHRo ZSBJRVRGLg0KPj4+DQo+Pj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFNpbXBsZSBUd28td2F5 IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbA0KPj4+ICAgICAgICBBdXRob3JzICAgICAgICAg OiBHcmVnIE1pcnNreQ0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBHdW8gSnVuDQo+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgIEhlbnJpayBOeWRlbGwNCj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgUmljaGFyZCBGb290ZQ0KPj4+ICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1pZXRmLWlwcG0tc3RhbXAtMDIudHh0DQo+Pj4gICAgICAgIFBhZ2VzICAgICAgICAgICA6 IDE0DQo+Pj4gICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTgtMDktMDcNCj4+Pg0KPj4+IEFi c3RyYWN0Og0KPj4+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBTaW1wbGUgVHdvLXdheSBB Y3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wNCj4+PiAgIHdoaWNoIGVuYWJsZXMgbWVhc3VyZW1l bnQgb2YgYm90aCBvbmUtd2F5IGFuZCByb3VuZC10cmlwIHBlcmZvcm1hbmNlDQo+Pj4gICBtZXRy aWNzIGxpa2UgZGVsYXksIGRlbGF5IHZhcmlhdGlvbiwgYW5kIHBhY2tldCBsb3NzLg0KPj4+DQo+ Pj4NCj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlwcG0t c3RhbXAvDQo+Pj4NCj4+PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFi bGUgYXQ6DQo+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXBwbS1z dGFtcC0wMg0KPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi1pcHBtLXN0YW1wLTAyDQo+Pj4NCj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wMg0KPj4+DQo+Pj4NCj4+PiBQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uDQo+Pj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCj4+Pg0KPj4+ IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN Cj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+DQo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBpcHBtIG1haWxp bmcgbGlzdA0KPj4+IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQo+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtDQo+Pj4NCj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IGlwcG0gbWFpbGlu ZyBsaXN0DQo+Pj4gaXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4NCj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0NCj4+DQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGlwcG0gbWFpbGluZyBs aXN0DQo+IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5v cmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwcG0NCg0KLS0NCkJyaWFuIFdlaXMNClNlY3VyaXR5LCBDU0csIENpc2NvIFN5c3Rl bXMNClRlbGVwaG9uZTogKzEgNDA4IDUyNiA0Nzk2DQpFbWFpbDogYmV3QGNpc2NvLmNvbTxtYWls dG86YmV3QGNpc2NvLmNvbT4NCg0KDQotLQ0KQnJpYW4gV2Vpcw0KU2VjdXJpdHksIENTRywgQ2lz Y28gU3lzdGVtcw0KVGVsZXBob25lOiArMSA0MDggNTI2IDQ3OTYNCkVtYWlsOiBiZXdAY2lzY28u Y29tPG1haWx0bzpiZXdAY2lzY28uY29tPg0KDQo= --_000_EA717254C51C4E04810C588464200852ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgR3JlZywNCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj5PbiBOb3YgMTAsIDIwMTgsIGF0IDQ6MjMgUE0sIEdyZWcgTWlyc2t5 ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiBjbGFzcz0iIj5ncmVn aW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xh c3M9IiI+SGkgQnJpYW4sDQo8ZGl2IGNsYXNzPSIiPkkndmUgc3RhcnRlZCB0aGUgbmV3IHdvcmtp bmcgdmVyc2lvbiB0byBhcHBseSB1cGRhdGVzIHJlc3VsdGluZyBmcm9tIG91ciBkaXNjdXNzaW9u IGFuZCBuZWVkIHRvIGNsYXJpZnkgb25lIHF1ZXN0aW9uIHdpdGggeW91LiBZb3UndmUgc3VnZ2Vz dGVkIHRoYXQgY29uZmlkZW50aWFsaXR5IG1heSBiZSBwcm92aWRlZCBieSBlbmNyeXB0aW9uIGF0 IGEgaGlnaGVyIGxldmVsLCBpLmUuLCBub3Qgb24gdGhlIFNUQU1QIG1lc3NhZ2UuDQogVGh1cywg YXMgSSB1bmRlcnN0YW5kLCB3ZSB3b3VsZCBub3QgbmVlZCB0byBkZWZpbmUgdGhlIGVuY3J5cHRl ZCBtb2RlIGluIFNUQU1QIGFuZCBvbmx5IGhhdmUgdHdvIG1vZGVzIC0gdW5hdXRoZW50aWNhdGVk IGFuZCBhdXRoZW50aWNhdGVkLiBXb3VsZCB5b3UgYWdyZWU/PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRoYXQgcGxhbiBt YWtlcyBzZW5zZSB0byBtZS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QnJpYW48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5SZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5HcmVnPC9kaXY+DQo8L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJs dHIiIGNsYXNzPSIiPk9uIFdlZCwgTm92IDcsIDIwMTggYXQgMTA6NTAgQU0gQnJpYW4gV2VpcyAo YmV3KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJld0BjaXNjby5jb20iIGNsYXNzPSIiPmJld0BjaXNj by5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJy ZWFrLXdvcmQiIGNsYXNzPSIiPkhpIElnbmFjaW8gYW5kIEdyZWcsDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FQ0RTQSBpcyBhIGRpZ2l0YWwgc2ln bmF0dXJlIGFsZ29yaXRobSwgd2hpY2ggaXMgdmVyeSBleHBlbnNpdmUgYW5kIGJlY2F1c2Ugb2Yg dGhpcyBpdCBpcyBub3QgdHJhZGl0aW9uYWxseSB1c2VkIHRvIHByb3RlY3QgbmV0d29yayBkYXRh IHBhY2tldHMuJm5ic3A7IEkgZG9u4oCZdCByZWNvbW1lbmQgc3BlY2lmeWluZyBpdC4gVW5sZXNz IHRoaXMgaXMgYSByYXJlbHkgc2VudCBkYXRhIHBhY2tldCBzZW50LCB5b3Ugd291bGQgYmUgY29u c3VtaW5nDQogYSBzdWJzdGFudGlhbCBhbW91bnQgb2YgdGhlIENQVSBieSBhcHBseWluZyBhIGRp Z2l0YWwgc2lnbmF0dXJlIHRvIGV2ZXJ5IHBhY2tldCBzZW50IHdpdGggU1RBTVAuIEFsc28sIGlu IG9yZGVyIHRvIGdldCB0aGUgdmFsdWUgJm5ic3A7eW91IHdhbnQsIHlvdSBhY3R1YWxseSBoYXZl IHRvIGNyZWF0ZSBhIGhhc2ggb2YgdGhlIHBhY2tldCAoZS5nLiwgdXNpbmcgU0hBMS9TSEEyNTYp IGFuZCB0aGVuIHNpZ24gdGhlIGhhc2gsIHdoZXJlIHRoZSByZXN1bHQNCiB3aWxsIGJlIGF0IGxl YXN0IHRoZSBsZW5ndGggb2YgYSBmdWxsIEhNQUMgb3V0cHV0LiBTbyB5b3XigJlyZSBub3Qgc2F2 aW5nIGFueSBzcGFjZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlVzaW5nIEhNQUMtU0hBMSBvciBTSEEyNTYgb24gbmV0d29yayBkYXRh IHBhY2tldHMgYXMgc2hvd24gaW4gRmlndXJlIDQgaXMgdmVyeSByZWFzb25hYmxlLiZuYnNwOyBT ZWN0aW9uIDUgb2YgUkZDIDIxMDQgKEhNQUMpIHNheXMgaG93IGl04oCZcyBhY2NlcHRhYmxlIHRv IHRydW5jYXRlIHRoZSBoYXNoIG91dHB1dCwgYW5kIHNlY3VyaXR5IHByb3RvY29scyB1c3VhbGx5 IGRvIHRoaXMuJm5ic3A7IElQU2VjIHRydW5jYXRlcyBITUFDLVNIQS0xDQogb3V0cHV0IHRvIDk2 IGJpdHMgKFJGQyAyNDA0KSwgYW5kIEhNQUMtU0hBLTI1NiBpcyB0cnVuY2F0ZWQgdG8gMTI4IGJp dHMgKFJGQyA0ODY4KS4mbmJzcDsgU2luY2UgLTAzIHdhcyB3aWxsaW5nIHRvIGFwcGx5IGEgMTI4 LWJpdCB0cnVuY2F0ZWQgaGFzaCwgSSB0aGluayB5b3UgY291bGQgc2FmZWx5IHNwZWNpZnkgdXNp bmcgSE1BQy1TSEEtMjU2IHdpdGggYSAxMjggYml0IHRydW5jYXRpb24uIE5vdGUgdGhhdCBpZiB5 b3Ugc3BlY2lmeSB0aGUgdXNlIG9mDQogSE1BQy1TSEExLCB5b3Ugd2lsbCB2ZXJ5IGxpa2VseSBy dW4gaW50byBTZWNEaXIgY29tcGxhaW50cyB3aGVuIHlvdSBnZXQgdG8gSUVURiBsYXN0IGNhbGwu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5JIGRpZCBtZW50aW9uIGluIHRoZSBJUFBNIG1lZXRpbmcgdGhhdCBhZGRpbmcgQUVTIHN1cHBv cnQgaXMgYml0IG1vcmUgcHJvYmxlbWF0aWMuIEkgd291bGQgcmVjb21tZW5kIHNwZWNpZnlpbmcg dGhhdCB3aGVuIGNvbmZpZGVudGlhbGl0eSBpcyBuZWVkZWQgdGhhdCBpdCBiZSBkb25lIGEgaGln aGVyIGxheWVyLiBJZiB5b3UgZG8gZGVjaWRlIHRvIGtlZXAgaXQgaW4gdGhpcyBkcmFmdCwgeW91 IHNob3VsZCBkZXNjcmliZQ0KIHdoYXQgaXMgdGhlIHZhbHVlIG9mIHByb3RlY3Rpbmcgb25seSB0 aGUgZmlyc3QgMTYgb2N0ZXRzLiBBbHNvLCB5b3Ugc2hvdWxkIGtub3cgdGhhdCBjcnlwdG9ncmFw aGVycyBkbyBub3QgcmVjb21tZW5kIHVzaW5nIEVCQy4gQSBXaWtpcGVkaWEgcGFnZSBkZXNjcmli ZXMgdGhpcyBwbGFpbmx5OiAmcXVvdDtUaGUgZGlzYWR2YW50YWdlIG9mIHRoaXMgbWV0aG9kIGlz IGEgbGFjayBvZiZuYnNwO2RpZmZ1c2lvbi4gQmVjYXVzZSBFQ0IgZW5jcnlwdHMgaWRlbnRpY2Fs Jm5ic3A7cGxhaW50ZXh0Jm5ic3A7YmxvY2tzDQogaW50byBpZGVudGljYWwmbmJzcDtjaXBoZXJ0 ZXh0Jm5ic3A7YmxvY2tzLCBpdCZuYnNwO2RvZXMgbm90IGhpZGUgZGF0YSBwYXR0ZXJucyB3ZWxs LiBJbiBzb21lIHNlbnNlcywgaXQgZG9lc24ndCBwcm92aWRlIHNlcmlvdXMgbWVzc2FnZSBjb25m aWRlbnRpYWxpdHksIGFuZCBpdCBpcyBub3QgcmVjb21tZW5kZWQgZm9yIHVzZSBpbiZuYnNwO2Ny eXB0b2dyYXBoaWMgcHJvdG9jb2xzIGF0IGFsbC7igJ0gKDxhIGhyZWY9Imh0dHBzOi8vZW4ud2lr aXBlZGlhLm9yZy93aWtpL0Jsb2NrX2NpcGhlcl9tb2RlX29mX29wZXJhdGlvbiNFbGVjdHJvbmlj X0NvZGVib29rXyhFQ0IpKSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vZW4ud2lr aXBlZGlhLm9yZy93aWtpL0Jsb2NrX2NpcGhlcl9tb2RlX29mX29wZXJhdGlvbiNFbGVjdHJvbmlj X0NvZGVib29rXyhFQ0IpKTwvYT4uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgb3RoZXIgbW9kZSAtMDMgbWVudGlvbmVkIGlzIHVz aW5nIEFFUy1DQkMgdG8gcHJvdGVjdCB0aGUgZW50aXJlIG1lc3NhZ2UuIFRoYXTigJlzIGEgY29u dmVudGlvbmFsIHVzZSBvZiBBRVMsIGJ1dCB3aGVuIEFFUy1DQkMgaXMgdXNlZCwgYm90aCB0aGUg ZW5jcnlwdG9yIGFuZCBkZWNyeXB0IG5lZWQgdGhlIHNhbWUgSW5pdGlhbGl6YXRpb24gVmVjdG9y IChJVikgdXNlZCB3aXRoIHRoZSBtZXRob2QuIFRyYWRpdGlvbmFsbHkNCiBpdCBpcyBpbmNsdWRl ZCBpbiB0aGUgcGFja2V0LCBzbyB0aGF04oCZcyBhbm90aGVyIDE2IG9jdGV0cyB5b3UgcHJvYmFi bHkgbmVlZCB0byBhZGQgdG8gdGhlIHBhY2tldCBmb3JtYXQuIFRoaXMgc2hvdWxkIE5PVCByZXBs YWNlIHRoZSBITUFDIGZpZWxkLCBiZWNhdXNlIGNyeXB0b2dyYXBoZXJzIHN0cm9uZ2x5IHN0YXRl IHRoYXQgaXQgaXMgYmFkIHByYWN0aWNlIHRvIHNlbmQgYW4gdW5hdXRoZW50aWNhdGVkIGVuY3J5 cHRlZCBwYWNrZXQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGRvbuKAmXQgc2VlIHRoZSByYXRpb25hbGUgaW4gLTAzIGZv ciBuZWVkaW5nIGNvbmZpZGVudGlhbGl0eS4gU28gaXQgbWlnaHQgYmUgYmVzdCB0byBzdGljayB3 aXRoIGFuIEhNQUMtU0hBMjU2IGhhc2gsIGFuZCBpZiBjb25maWRlbnRpYWxpdHkgaXMgcmVxdWly ZWQgdG8gdXNlIGEgaGlnaGVyIGxheWVyIGVuY3J5cHRpb24uIE90aGVyd2lzZSwgeW914oCZbGwg bmVlZCB0byBkbyBhIGxvdCBtb3JlIHNwZWNpZmljYXRpb24gb2YNCiBob3cgdGhlIGNvbmZpZGVu dGlhbGx5IGlzIGRvbmUgaW4gdGhpcyBkcmFmdC48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+SSBob3BlIHRoYXQgaGVscHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CcmlhbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIE5vdiA3LCAyMDE4LCBhdCA5OjE1IEFNLCBHcmVnIE1p cnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2 Pg0KPGJyIGNsYXNzPSJtXy04MzE5NTg2MjYwMjkxMjkzMzE3QXBwbGUtaW50ZXJjaGFuZ2UtbmV3 bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SG8gSi5JZ25h Y2lvLA0KPGRpdiBjbGFzcz0iIj50aGFuayB5b3UgZm9yIHRoZSBjb21tZW50IGFuZCBoZWxwZnVs Jm5ic3A7c3VnZ2VzdGlvbi4gV2lsbCByZWFkIHRoZSBkcmFmdC1hbGF2YXJlei1oYW1lbGluLXRp Y3RvYy1zaWMgYW5kIHJlc3BvbmQmbmJzcDthY2NvcmRpbmdseSBpbiBhIHNob3J0IHRpbWUuIEZy b20gdGhlIHF1aWNrIHJ1biB0aHJvdWdoIHRoZSBkcmFmdCwgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0 IEVDRFNBIG9mZmVycyBhZHZhbnRhZ2VzIG92ZXIgdGhlIFNIQTEgb2YgdGhlJm5ic3A7c2FtZQ0K IGxlbmd0aC4gSnVzdCBuZWVkIHRvIGNoZWNrIGZvciBwb3NzaWJsZSBpbXBhY3Qgb24gWUFORyBk YXRhIG1vZGVsLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+R3JlZzwvZGl2Pg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0i bHRyIiBjbGFzcz0iIj5PbiBXZWQsIE5vdiA3LCAyMDE4IGF0IDI6MjYgQU0gSiBJZ25hY2lvIEFs dmFyZXotSGFtZWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmloYW1lbGlAY25ldC5maS51YmEuYXIi IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5paGFtZWxpQGNuZXQuZmkudWJhLmFyPC9hPiZndDsg d3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij4NCkhpIEdyZWcsIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N ClRvZGF5IGF0IHRoZSBJUFBNIG1lZXRpbmcgSSBzYWlkIHRoYXQgeW91IGNvdWxkIGNvbnNpZGVy IHVzaW5nIFNIQTEgMjU2IHdpdGggYml0cyBmb3IgYXV0aGVudGljYXRpb24sIHRvIHJlc3BlY3Qg c29tZSBzZWN1cml0eSBzdGFuZGFyZHMuIFlvdXIgY29tbWVudCB0aGF0IGlzIGV4cGVuc2l2ZSwg YW5kIEkgYWdyZWUgd2l0aCB0aGF0Lg0KPGJyIGNsYXNzPSIiPg0KSSBwcm9wb3NlIGFub3RoZXIg YWx0ZXJuYXRpdmUsIGlzIHRoZSBvbmUgdGhhdCBJIHVzZWQgaW4gZHJhZnQtYWxhdmFyZXotaGFt ZWxpbi10aWN0b2Mtc2ljLTAyLCB0aGUgRWxsaXB0aWMgQ3VydmUgRGlnaXRhbCBTaWduYXR1cmUg QWxnb3JpdGhtIChFQ0RTQSksIHdoaWNoIHlpZWxkcyBpbiBmZXcgYml0cyBhbmQgaGFzIHNvbWUg c2VjdXJpdGllcyBmb3JtIGRlIGNyeXB0b2dyYXBoaWMgcG9pbnQgb2Ygdmlldy4NCjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJlc3Qgd2l0aGVzLDxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKLiBJZ25h Y2lvPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRHIu IEluZy4gSm9zw6kgSWduYWNpbyBBbHZhcmV6LUhhbWVsaW48YnIgY2xhc3M9IiI+DQpDT05JQ0VU IGFuZCBGYWN1bHRhZCBkZSBJbmdlbmllcsOtYSwgVW5pdmVyc2lkYWQgZGUgQnVlbm9zIEFpcmVz PGJyIGNsYXNzPSIiPg0KQXYuIFBhc2VvIENvbMOzbiA4NTAgLSBDMTA2M0FDViAtIEJ1ZW5vcyBB aXJlcyAtIEFyZ2VudGluYTxiciBjbGFzcz0iIj4NCiYjNDM7NTQgKDExKSA1Mjg1IDA3MTYgLyA1 Mjg1IDA3MDU8YnIgY2xhc3M9IiI+DQplLW1haWw6IDxhIGhyZWY9Im1haWx0bzppaGFtZWxpQGNu ZXQuZmkudWJhLmFyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aWhhbWVsaUBjbmV0LmZpLnVi YS5hcjwvYT48YnIgY2xhc3M9IiI+DQp3ZWI6IDxhIGhyZWY9Imh0dHA6Ly9jbmV0LmZpLnViYS5h ci9pZ25hY2lvLmFsdmFyZXotaGFtZWxpbi8iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPg0KaHR0cDovL2NuZXQuZmkudWJhLmFyL2lnbmFjaW8uYWx2YXJlei1oYW1l bGluLzwvYT48YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQomZ3Q7IE9uIDE2IE9jdCAyMDE4LCBhdCAw NToyNCwgQnJpYW4gVHJhbW1lbGwgKElFVEYpICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkB0cmFt bWVsbC5jaCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmlldGZAdHJhbW1lbGwuY2g8L2E+Jmd0 OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgaGkgR3JlZyw8 YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgV2UnbGwgcHV0IHRoaXMgYW5k IGEgdGVudGF0aXZlIHN0YXJ0IG9mIFdHTEMgb24gdGhlIEJhbmdrb2sgYWdlbmRhLi48YnIgY2xh c3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgVGhhbmtzLCBjaGVlcnMsPGJyIGNsYXNz PSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IEJyaWFuPGJyIGNsYXNzPSIiPg0KJmd0OyA8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBPbiAxNiBPY3QgMjAxOCwgYXQgMDE6MDAsIEdyZWcgTWly c2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgSGkgQnJpYW4sPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgbXkgYXBvbG9naWVzIGZvciB0aGUgZGVsYXllZCByZXNwb25zZS4g VGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBoYXMgYmVlbiBqdXN0IHVwbG9hZGVkLiBUaGUg dXBkYXRlcyBpbmNsdWRlIHRoZSBuZXcgc2VjdGlvbiB0aGF0IGRlc2NyaWJlcyBhdXRoZW50aWNh dGlvbiBhbmQgZW5jcnlwdGlvbiBvcGVyYXRpb25zIG9uIFNUQU1QIHBhY2tldHMuIEknZCByZXF1 ZXN0IHRoZSBwcmVzZW50YXRpb24gc2xvdCBhdCB0aGUgbWVldGluZyBhbmQsDQogaWYgdGhlcmUg YXJlIG5vIHNpZ25pZmljYW50IGNvbmNlcm5zLCB3b3VsZCBhc2sgdG8gY29uc2lkZXIgc3RhcnRp bmcgdGhlIFdHIExDIG9uIHRoZSBiYXNlIHNwZWNpZmljYXRpb24uIFRoZSB3b3JrIG9uIHRoZSBT VEFNUCBZQU5HIGRhdGEgbW9kZWwgc3RpbGwgb24tZ29pbmcgYW5kIHdlJ3JlIGFkZHJlc3Npbmcg dGhlIGNvbW1lbnRzIGZyb20gdGhlIGVhcmx5IFlBTkcgRG9jdG9ycyByZXZpZXcgYnkgTWFoZXNo LiBJIGV4cGVjdCB3ZSdsbCBoYXZlDQogdGhlIG5ldyB2ZXJzaW9uIGJ5IHRoZSBlbmQgb2YgTm92 ZW1iZXIuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgUmVn YXJkcyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBHcmVnPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgT24gVGh1LCBPY3QgNCwgMjAxOCBhdCA4OjEyIEFNIEJy aWFuIFRyYW1tZWxsIChJRVRGKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdHJhbW1lbGwuY2gi IHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pZXRmQHRyYW1tZWxsLmNoPC9hPiZndDsgd3JvdGU6 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgaGkgR3JlZyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBmb2xsb3dpbmcgdXAgYSBiaXQgbGF0ZSwgcGVyaGFwcy4u LiB3aGVuIGRvIHlvdSB0aGluayB0aGlzIHdpbGwgYmUgcmVhZHkgZm9yIExDPzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IENoZWVycyw8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBCcmlhbiAoYXMgV0cgY28tY2hhaXIp PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IE9uIDgg U2VwIDIwMTgsIGF0IDAwOjUzLCBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdp bWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyZndDsgRGVhciBBbGwsPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7 IG1pbm9yIGVkaXRvcmlhbCBpbXByb3ZlbWVudHMgdG8gdGhlIGRvY3VtZW50Li48YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyZndDsgWW91ciBjb21tZW50cywgcXVlc3Rpb25zLCBhbmQgc3VnZ2VzdGlv bnMgYWx3YXlzIHdlbGNvbWUgYW5kIG11Y2ggYXBwcmVjaWF0ZWQuPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7Jmd0OyBHcmVnPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0t LS08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgRnJvbTogJmx0OzxhIGhyZWY9Im1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBEYXRl OiBGcmksIFNlcCA3LCAyMDE4IGF0IDI6NTYgUE08YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsg U3ViamVjdDogW2lwcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wMi50eHQ8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgVG86IDxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3Vu Y2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pLWQtYW5ub3VuY2VAaWV0Zi5v cmc8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86aXBw bUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmlwcG1AaWV0Zi5vcmc8L2E+PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IEEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cyBkaXJlY3Rvcmllcy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgSVAgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgV0cgb2YgdGhl IElFVEYuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBTaW1wbGUgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQg UHJvdG9jb2w8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgQXV0aG9ycyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IEdyZWcgTWly c2t5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEd1byBKdW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgSGVucmlrIE55ZGVsbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSaWNoYXJkIEZvb3RlPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTAyLnR4dDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdl cyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAxNDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE4LTA5LTA3PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBBYnN0cmFjdDo8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYSBTaW1wbGUgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2w8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7d2hpY2ggZW5hYmxlcyBtZWFzdXJlbWVudCBv ZiBib3RoIG9uZS13YXkgYW5kIHJvdW5kLXRyaXAgcGVyZm9ybWFuY2U8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7bWV0cmljcyBsaWtlIGRlbGF5LCBkZWxheSB2YXJpYXRp b24sIGFuZCBwYWNrZXQgbG9zcy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyBUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1pcHBtLXN0YW1wLyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlwcG0t c3RhbXAvPC9hPjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyZndDsgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTAyIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0i X2JsYW5rIiBjbGFzcz0iIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWlwcG0tc3RhbXAtMDI8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLXN0YW1w LTAyIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTAyPC9h PjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsg QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0OjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTAyIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0i X2JsYW5rIiBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLWlwcG0tc3RhbXAtMDI8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy8iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPg0K dG9vbHMuaWV0Zi5vcmc8L2E+LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyZndDsgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0OjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJmdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayIgY2xhc3M9IiI+DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwv YT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsmZ3Q7IGlwcG0gbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+aXBwbUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtIiByZWw9Im5vcmVm ZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXBwbTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZndDsgPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IGlwcG0gbWFpbGluZyBsaXN0 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aXBwbUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHBtIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBwbTwvYT48YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQom Z3Q7IGlwcG0gbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86 aXBwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmlwcG1AaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwcG0iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtPC9hPjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQppcHBtIG1h aWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aXBwbUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0iIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwcG08L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+LS0mbmJzcDs8YnIgY2xhc3M9IiI+DQpCcmlhbiBX ZWlzPGJyIGNsYXNzPSIiPg0KU2VjdXJpdHksIENTRywgQ2lzY28gU3lzdGVtczxiciBjbGFzcz0i Ij4NClRlbGVwaG9uZTogJiM0MzsxIDQwOCA1MjYgNDc5NjxiciBjbGFzcz0iIj4NCkVtYWlsOiA8 YSBocmVmPSJtYWlsdG86YmV3QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmJl d0BjaXNjby5jb208L2E+IDwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+LS0mbmJzcDs8YnIgY2xhc3M9IiI+DQpCcmlhbiBXZWlz PGJyIGNsYXNzPSIiPg0KU2VjdXJpdHksIENTRywgQ2lzY28gU3lzdGVtczxiciBjbGFzcz0iIj4N ClRlbGVwaG9uZTogJiM0MzsxIDQwOCA1MjYgNDc5NjxiciBjbGFzcz0iIj4NCkVtYWlsOiA8YSBo cmVmPSJtYWlsdG86YmV3QGNpc2NvLmNvbSIgY2xhc3M9IiI+YmV3QGNpc2NvLmNvbTwvYT4gPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_EA717254C51C4E04810C588464200852ciscocom_-- From nobody Mon Nov 12 00:40:09 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1841298C5; Mon, 12 Nov 2018 00:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 ZEOwQY23BMm4; Mon, 12 Nov 2018 00:40:03 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED2F128D0C; Mon, 12 Nov 2018 00:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24514; q=dns/txt; s=iport; t=1542012003; x=1543221603; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=I1xl6EUETY9riKIpm9U9ZNbqorSTlFGHZfVhQ7oEzxg=; b=bh/lTF2Pd76aw8IziDdghM9DCV8VFnX/hOts2eCN7jrgFX7IirNeGBqV 4cmI4S91lFa3rYWq3GDK9W4cde7hakfm1LVQE6Qalo3ShccIyNx6mcM0G EZvcjtAtZOMJbnq0LqcPbxLW6mTQAuFx6LSDxNU0xYggJOk7QWWiqdAHd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAACgO+lb/4ENJK1YChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYFaKWaBAicKg26IGIt5gg2DQoVFji4?= =?us-ascii?q?UgWYLAQEYDYRHAheDDiI0DQ0BAwEBAgEBAm0cDIU6AQEBAwEBASEREwIeBws?= =?us-ascii?q?FBwQCAQgRBAEBAQICJgICAh8GCxUICAIEDgUIE4MHgWkDDQgPqTWBL4MqgQM?= =?us-ascii?q?BAwICDRiDFg2CGYELiUKBMxeBQD+BEYMSglYhJAEBA4EqCQQPJAuCbYJXAok?= =?us-ascii?q?ACAosA4cGjjMnLgkChnSGfIMjIJBwjSaBBYkmAhEUgSYdOIFVcBU7gmwJgh4?= =?us-ascii?q?XfwEChyE7hT5BMYtLgS6BHwEB?= X-IronPort-AV: E=Sophos;i="5.54,494,1534809600"; d="scan'208";a="199889604" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 08:40:01 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id wAC8e1bN008368 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Nov 2018 08:40:01 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 12 Nov 2018 02:40:00 -0600 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1395.000; Mon, 12 Nov 2018 02:40:00 -0600 From: "Frank Brockners (fbrockne)" To: Mark Smith CC: "C. M. Heard" , 6man WG , "ippm@ietf.org" Thread-Topic: v6 option types for IOAM data fields Thread-Index: AQHUb5iXbX4MUs3YyEqKVf0LZIK86aU2jG5ggACUzgCADm05gIAApqGAgAWuMPA= Date: Mon, 12 Nov 2018 08:40:00 +0000 Message-ID: <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> In-Reply-To: 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.61.203.192] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [ippm] v6 option types for IOAM data fields X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 12 Nov 2018 08:40:07 -0000 SGkgTWFyaywNCg0KdGhhbmtzIGZvciB0aGUgZGV0YWlscy4gT24geW91ciBzdWdnZXN0ZWQgc29s dXRpb24gZm9yIHY2LWluLXY2OiBMZXQncyBhc3N1bWUgYSBzZXR1cCB3aXRoIHNvdXJjZSBhbmQg ZGVzdGluYXRpb24gaG9zdCBhZGRyZXNzZXMgKFNBLCBEQSksIGFzIHdlbGwgYXMgYW4gSU9BTSBk b21haW4gd2hpY2ggaGFzIGRvbWFpbiBFZGdlLXJvdXRlcnMgRShpKS4gSWYgSSB1bmRlcnN0YW5k IHlvdXIgc3VnZ2VzdGlvbiBjb3JyZWN0bHksIHRoZW4gdGhlIGluZ3Jlc3MgZWRnZSByb3V0ZXIg d2l0aCBzb3VyY2UgYWRkcmVzcyBFLVNBIHdvdWxkIGhhdmUgLzEyOCByb3V0ZXMgdG8gYWxsIG90 aGVyIGRvbWFpbiBFZGdlLXJvdXRlcnMgRS1EQShpKS4gRm9yIHY2LWluLXY2LCB0aGUgaW5ncmVz cyBlZGdlIHJvdXRlciB3b3VsZCB1c2UgaXRzIG93biBzb3VyY2UgYWRkcmVzcyBhcyB0aGUgc291 cmNlIGFkZHJlc3Mgb2YgdGhlIGVuY2Fwc3VsYXRlZCBwYWNrZXQsIGFuZCBpdCB3b3VsZCB1c2Ug RS1EQShqKSBhcyB0aGUgZGVzdGluYXRpb24gYWRkcmVzcywgd2hlcmUgRS1EQShqKSBpcyB0aGUg YWRkcmVzcyB0aGF0IHBvaW50cyB0byB0aGUgc2FtZSBvdXRnb2luZyBsaW5rIGFzIHRoZSBvcmln aW5hbCAobm93IGlubmVyKSBEQS4NCk5vdyB0aGUgcXVlc3Rpb246IFdoeSB3b3VsZCB0aGlzIGNo b2ljZSBvZiBFLURBKGopIGVuc3VyZSB0aGF0IHRoZSBlbmNhcHN1bGF0ZWQgcGFja2V0IGxlYXZl cyB0aGUgSU9BTSBkb21haW4gYXQgdGhlIHNhbWUgZWdyZXNzIHJvdXRlciwgYXMgd291bGQgYSBw YWNrZXQgd2l0aG91dCB0aGUgZXh0cmEgdjYgaGVhZGVyPyBPciBpbiBvdGhlciB0ZXJtcywgd2h5 IHdvdWxkIHRoZSBlbmNhcHN1bGF0ZWQgcGFja2V0IGJlIGZvcndhcmRlZCB0aGUgc2FtZSB3YXkg YXMgYSBub24tZW5jYXBzdWxhdGVkIHBhY2tldCBpbiB0aGUgSU9BTSBkb21haW4/DQoNCk1hbnkg dGhhbmtzLCBGcmFuaw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFyayBT bWl0aCA8bWFya3p6enNtaXRoQGdtYWlsLmNvbT4gDQpTZW50OiBEb25uZXJzdGFnLCA4LiBOb3Zl bWJlciAyMDE4IDEyOjQwDQpUbzogRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSkgPGZicm9ja25l QGNpc2NvLmNvbT4NCkNjOiBDLiBNLiBIZWFyZCA8aGVhcmRAcG9ib3guY29tPjsgNm1hbiBXRyA8 aXB2NkBpZXRmLm9yZz47IGlwcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiB2NiBvcHRpb24gdHlw ZXMgZm9yIElPQU0gZGF0YSBmaWVsZHMNCg0KSGkgRnJhbmssDQoNCk9uIFRodSwgOCBOb3YgMjAx OCBhdCAxOTozNiwgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSkgPGZicm9ja25lQGNpc2NvLmNv bT4gd3JvdGU6DQo+DQo+IEhpIE1hcmssIE1pa2UsDQo+DQo+DQo+DQo+IHRoYW5rcyBmb3Igc3Vt bWFyaXppbmcgdGhlIGNvbmNlcm5zIGFyb3VuZCBsZWFrZWQgcGFja2V0cyDigJMgYW5kIG91dGxp bmluZyBhbiBhcHByb2FjaCB0byBtaXRpZ2F0ZSB0aG9zZS4gVGhlcmUgYXJlIGEgY291cGxlIG9m IG90aGVyIGNoYWxsZW5nZXMgd2UgZmFjZS4gVW5mb3J0dW5hdGVseSB3ZSBkaWQgbm90IGdldCB0 byBhIGRpc2N1c3Npb24gaW4gdGhlIDZtYW4gV0cgbWVldGluZyB0aGlzIHRpbWUgZHVlIHRvIHRo ZSBsaW1pdGVkIHRpbWUgd2UgaGFkLiBUaGUgbWVldGluZyBzbGlkZXMgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xpZGVzLTEwMy02bWFuLWluLXNp dHUtb2FtLWlwdjYtb3B0aW9ucy0wMCBwcm92aWRlIGEgc3VtbWFyeSBvZiBjb25jZXJucy4NCj4N Cj4NCj4NCj4gSW4gYSBudXRzaGVsbDoNCj4NCj4gMS4gICAgICAgUG90ZW50aWFsIEhiSCBleHQg aGVhZGVyIGFuZCBJT0FNIG9wdGlvbiBpbnNlcnRpb24gYW5kIHJlbW92YWwgYnkgdHJhbnNpdCBu b2RlcyAoaS5lLiDigJxlbiByb3V0ZeKAnSkgaW4gYSByZXN0cmljdGVkIGFkbWluaXN0cmF0aXZl IGRvbWFpbi4NCj4NCj4gYSkgICAgICAgSG93IGRvIHlvdSBkZWFsIHdpdGggUE1UVT8g4oCTIFBh Y2tldCBzaXplIGNoYW5nZXMgbWlnaHQgZXhjZWVkIFBNVFUuDQo+DQo+IGIpICAgICAgTWlzbGVh ZGluZyBJQ01QIGVycm9ycyBjb25mdXNpbmcgdGhlIHNvdXJjZQ0KPg0KPiBjKSAgICAgICBQb3Nz aWJsZSBsZWFrcyB0aGF0IGFmZmVjdCB0aGUgZm9yd2FyZGluZyBiZWhhdmlvciBhbmQgc3RhdGUg b2YgbmV0d29yayBlbGVtZW50cyBvdXRzaWRlIHRoZSBkb21haW4uDQo+DQoNClllcywgYWxsIG9m IHRoZSBhYm92ZSwgZ29vZCBzdW1tYXJ5Lg0KDQpBbiBhZGRpdGlvbmFsIG9uZSBpcyB0aGF0IGlm IHlvdSB3ZXJlIGFyZSByZWNlaXZlciBvZiB0aGlzIG91dHNpZGUgb2YgdGhlIGRvbWFpbiBiZWNh dXNlIGl0IGFzIGxlYWtlZCwgYXQgdGhlIGRlc3RpbmF0aW9uLCBhZnRlciB0aGUgcGFja2V0IGFz IHRyYXZlcnNlZCBhIG51bWJlciBvZiBBU2VzIG92ZXIgdGhlIEludGVybmV0LCB0aGVyZSBpcyBu b3RoaW5nIHRvIGlkZW50aWZ5IHRoZSBkZXZpY2UvQVMgdGhhdCBpbnNlcnRlZCB0aGUgRUguIFZl cnkgdGltZSBjb25zdW1pbmcgdG8gdHJvdWJsZXNob290IHdobyBpbnNlcnRlZCB0aGUgRUggYnV0 IGRpZG4ndCByZW1vdmUgaXQgKHlvdSBoYXZlIHRvIHdhbGsgdGhlIEFTIHBhdGgsIGNvbnRhY3Rp bmcgZWFjaCBvcGVyYXRvciwgYXNraW5nIHRoZW0gdG8gdmVyaWZ5IHRoZWlyIGNvbmZpZywgZ2V0 IHBhY2tldCBjYXB0dXJlcyBldGMuKSwgYW5kIGFsbCB0aGUgd2hpbGUgeW91IG1heSBoYXZlIGEg bnVtYmVyIG9mIGFuZ3J5IGN1c3RvbWVycy9lbmQtdXNlcnMuDQoNCj4gMi4gICAgICAgSW5jcmVt ZW50YWwgVHJhY2UgSU9BTSBIYkggT3B0aW9uIOKAkyB3aGljaCBpcyB0byBzdXBwb3J0IGEgaGFy ZHdhcmUtZnJpZW5kbHkgaW1wbGVtZW50YXRpb246IENoYW5nZXMgT3B0aW9uIERhdGEgTGVuIGVu LXJvdXRlLg0KPg0KPiBhKSAgICAgICBEZWFsaW5nIHdpdGggUE1UVeKAkyBQYWNrZXQgc2l6ZSBj aGFuZ2VzIGNhbiBleGNlZWQgUE1UVTsgc2VlIGFib3ZlDQo+DQo+IDMuICAgICAgIENsYXJpZnkg YXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgYW5kIHNjb3BlDQo+DQo+DQo+DQo+IFdoaWxlIDMuIGlz IHNvbWV0aGluZyB0aGF0IGlzIGluIHRoZSB3b3JrcywgdGhlcmUgYXJlIG5vIGVhc3kgYW5zd2Vy cyB0byAxLiBhbmQgMi4gQ29uc2lkZXJhdGlvbnM6DQo+DQo+DQo+DQo+IE9uIDEuIFN1cHBvcnRp bmcgSGJIIGV4dCBoZWFkZXIgYW5kIG9wdGlvbiBpbnNlcnRpb24vcmVtb3ZhbCBpbiANCj4gdHJh bnNpdC4gQSBjb3VwbGUgb2Ygc29sdXRpb24gYXBwcm9hY2hlc+KApg0KPg0KPiAxLiAgICAgICBG aXggUE1UVSBhbmQgb2Zmc2V0IGZvciBwYWNrZXQgc2l6ZSBjaGFuZ2UgaW4gUE1UVSBkaXNjb3Zl cnkgLSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHJvYW4tNm1hbi1wbXR1LXNv bHV0aW9uLXNwYWNlLTAwDQo+IEhvcGUgdGhhdCB3ZSBjYW4gbWFrZSBwcm9ncmVzcyB0b3dhcmRz IGEgc29sdXRpb24gdG9tb3Jyb3figKYNCj4NCj4gMi4gICAgICAgSVAtaW4tSVAgd2l0aCBJT0FN IGV4dGVuc2lvbiBoZWFkZXIgaW4gdGhlICppbm5lciogcGFja2V0Lg0KPiBOZXcgSVB2NiBwYWNr ZXQgaXMgY3JlYXRlZCB3aXRoIGVuY2Fwc3VsYXRpbmcgbm9kZSBhcyBzb3VyY2UgYW5kIHRoZSAN Cj4gb3JpZ2luYWwgZGVzdGluYXRpb24gYXMgdGhlIGRlc3RpbmF0aW9uICh0aGlzIGlzIHNsaWdo dGx5IGRpZmZlcmVudCB0aGFuIHdoYXQgeW91LCBNYXJrLCBzdWdnZXN0IOKAkyBiZWNhdXNlIHdl 4oCZZCBsaWtlIHRvIGtlZXAgdGhlIGZvcndhcmRpbmcgcGF0aCB0aGUgc2FtZS4gVHVubmVsaW5n IHdpdGggVUxBIHdvdWxkIG5vdCBnZXQgdXMgdGhlcmU7IHRoZSBzbGlkZXMgYWJvdmUgaGF2ZSBh IGRpYWdyYW0gdGhhdCBkZXBpY3RzIHRoZSBwb3RlbnRpYWwgZW5jYXApOg0KPg0KPiBhKSAgICAg ICBQYXlsb2FkIG9mIHRoaXMgcGFja2V0IGlzIHRoZSBvcmlnaW5hbCBJUHY2IHBhY2tldCBhbG9u ZyB3aXRoIGFuIGV4dGVuc2lvbiBoZWFkZXIgaW5zZXJ0ZWQgaW5zaWRlLg0KPg0KPiBiKSAgICAg IFRoZSBvcmlnaW5hbCBwYWNrZXQgaXMgcmVzdG9yZWQgYnkgcmVtb3ZpbmcgdGhlIG91dGVyIElQ djYgaGVhZGVyIGFuZCB0aGUgaW5uZXIgZXh0ZW5zaW9uIGhlYWRlciBieSBhIG5vZGUgYXQgdGhl IGRvbWFpbiBib3VuZGFyeS4NCj4NCj4gYykgICAgICAgQ2F2ZWF0czoNCj4NCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaS4g ICAgICBNb2RpZmllZCBwYWNrZXQgbWF5IHN0aWxsIGxlYWsg4oCTIGJ1dCB3aWxsIG9ubHkgY29u ZnVzZSB0aGUgZGVzdGluYXRpb24gbm9kZS4gVGhlIGRlc3Qgbm9kZSB3aWxsIGxpa2VseSBzZW5k IGFuIElDTVAgYmFjayB0byB0aGUgZW5jYXAgbm9kZSwgd2hpY2ggZ2V0cyB0aGUgZW5jYXAgbm9k ZSBhbiB1bmRlcnN0YW5kaW5nIHRoYXQgc29tZXRoaW5nIGlzIGdvaW5nIHdyb25nLg0KPg0KDQpU aGlzIGlzIGNlcnRhaW5seSBiZXR0ZXIsIGJlY2F1c2UgdGhlIHNvdXJjZSBhZGRyZXNzIGlkZW50 aWZpZXMgdGhlIGRldmljZSB0aGF0IGluc2VydGVkIHRoZSBFSCBvZiB0aGUgcGFja2V0IHRoYXQg bGVha2VkIHRvIHdoZXJlIGV2ZXIgaXQgbGVha2VkIHRvLg0KDQpXaGF0IHRoZSBzb3VyY2UgYWRk cmVzcyBzaG91bGQgYmUgaXMgYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24uDQoNCklmIGl0IGlzIGEg Z2xvYmFsL3B1YmxpYyBzb3VyY2UgYWRkcmVzcywgdGhlbiBhbnlib2R5IHdobyByZWNlaXZlcyB0 aGUgcGFja2V0IGxlYWtlZCB3aXRoIHRoZSBFSCBjYW4gaWRlbnRpZnkgd2hvIGluc2VydGVkIGl0 IGFuZCB0aGVyZWZvcmUgd2hvIGRpZG4ndCByZW1vdmUgaXQuDQoNCk9UT0gsIGlmIGl0IGlzIGEg cHJpdmF0ZS9sb2NhbCBVTEEgU291cmNlIEFkZHJlc3MsIHRoZW4gQkNQMzggc291cmNlIGFkZHJl c3MgZmlsdGVycyB3b3VsZCBjYXVzZSB0aGUgaW52YWxpZCBsZWFrZWQgcGFja2V0IHRvIGJlIGRy b3BwZWQgc29vbmVyLCByYXRoZXIgdGhhbiBiZWluZyBmb3J3YXJkZWQgb250byB0aGUgZmluYWwg ZGVzdGluYXRpb24uIFRvdGFsIHBhY2tldCBsb3NzIG9mIE9BTSBlbmNhcHN1bGF0ZWQgcGFja2V0 cyB3b3VsZCBtYWtlIHRoZSBmYWlsdXJlIG9idmlvdXMgdG8gdGhlIE9BTSBkb21haW4gb3BlcmF0 b3IuIFNsaWdodCBkcmF3YmFjayBpcyBCQ1AzOCBmaWx0ZXJzIGhhdmVuJ3QgYmVlbiB1bml2ZXJz YWxseSBpbXBsZW1lbnRlZCBhY3Jvc3MgdGhlIEludGVybmV0Lg0KDQpJIHRoaW5rIEkgbGlrZSB0 aGUgbGF0dGVyIGJldHRlciBiZWNhdXNlIGNvbW1vbmx5IGl0IHdvdWxkIGxvY2FsaXNlIHRoZSBz eW1wdG9tcyBvZiB0aGUgZmFpbHVyZSB0byByZW1vdmUgdGhlIEVIIHRvIHRoZSBkb21haW4gdGhh dCBpbnNlcnRlZCBpdCwgcmF0aGVyIHRoYW4gaGF2aW5nIHRvIGhhdmUgYW4gZXh0ZXJuYWwgcGFy dHkgZ2V0IGludm9sdmVkIGluIHRyb3VibGVzaG9vdGluZy4NCg0KDQoNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlpLiAgICAg IEVDTVAgY29tcHV0YXRpb24gbmVlZHMgdG8gYmUgcmV3b3JrZWQuDQo+DQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaWlpLiAgICAg IENvbXBsZXgvY29zdGx5IGltcGxlbWVudGF0aW9uIGluIEhXICYgU1cg4oCTIElPQU0tY2FwYWJs ZSBub2RlcyBuZWVkIHRvIGh1bnQgZm9yIHRoZSBJT0FNIGRhdGEgZmllbGRzIGluIHRoZSBpbm5l ciBwYWNrZXQuDQo+DQoNClllcywgdGhlIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkgb2YgaW5z ZXJ0aW9uIGlzIGFub3RoZXIgY29uY2VybiAtIGVuY2Fwc3VsYXRpb24gaXMgdGhlIG1vc3QgY29t bW9uIGFuZCBzaW1wbGVzdCBjcm9zcyBsYXllciBmb3J3YXJkaW5nIGZ1bmN0aW9uIHBlcmZvcm1l ZCBhbmQgdGhlcmUncyBkZWNhZGVzIG9mIGhpc3RvcnkgaW4gb3B0aW1pc2luZyBpdC4NCg0KVGhl IHJvb3QgY2F1c2Ugb2YgYm90aCB0aGUgcG9zc2libGUgbGVhayBhbmQgdGhlIHJpc2sgdGhhdCB0 aGUgaW5zZXJ0ZWQgRUggd2lsbCByZWFjaCB0aGUgZmluYWwgcGFja2V0IGRlc3RpbmF0aW9uIGlz IHRoYXQgdGhlIERlc3QuDQpBZGRyLiBvZiB0aGUgcGFja2V0IHdpdGggdGhlIGluc2VydGVkIEVI IGlzIGJvdGggdmFsaWQgb3V0c2lkZSBvZiB0aGUgZG9tYWluLCBhbmQgdmFsaWQgYWxsIHRoZSB3 YXkgYWNyb3NzIHRoZSBJbnRlcm5ldCB0byB0aGUgZmluYWwgYW5kIGFjdHVhbCBvcmlnaW5hbCBw YWNrZXQgZGVzdGluYXRpb24uIFRoYXQgY3JlYXRlcyBhICJkZWZhdWx0IHBlcm1pdCIgaWYgYSBw YWNrZXQgbGVha3Mgd2l0aCB0aGUgaW5zZXJ0ZWQgRUggcmF0aGVyIHRoYW4gYSBmYXIgYmV0dGVy ICJkZWZhdWx0IGRlbnkiIGluIHRoaXMgZmFpbHVyZSBzaXR1YXRpb24uDQoNCkluIHRoaXMgT0FN IGNhc2UsIGl0IHNlZW1zIHRvIG1lIHRoZSBpZGVhbCBhbmQgdGhlIHJlcXVpcmVtZW50cyB3b3Vs ZCBiZToNCg0KLSBoYXZlIHRoZSBwYWNrZXQgd2l0aCB0aGUgYWRkZWQgT0FNIGluZm9ybWF0aW9u IGZvbGxvdyB0aGUgc2FtZSBwYXRoIHdpdGhpbiB0aGUgZG9tYWluIHRoYXQgdGhlIHNhbWUgcGFj a2V0IHdpdGhvdXQgdGhlIE9BTSBpbmZvcm1hdGlvbiB3b3VsZCBmb2xsb3cgd2l0aGluIHRoZSBk b21haW4NCg0KLSBoYXZlIHRoZSBEZXN0LiBBZGRyLiBvZiB0aGUgcGFja2V0IHdpdGggdGhlIGFk ZGVkIE9BTSBpbmZvcm1hdGlvbiBvbmx5IGJlIHZhbGlkIHdpdGhpbiB0aGUgT0FNIGRvbWFpbiBp LmUuIGFuICJpbnRlcmlvciBEQSIsIHNvIHRoYXQgaWYgdGhyb3VnaCBmYWlsdXJlIHRoZSBwYWNr ZXQgbGVha3MsIGl0IGlzbid0IGEgdmFsaWQgREEgb24gdGhlIEludGVybmV0IGFuZCB3aWxsIGJl IGRyb3BwZWQgYnksIGlmIG5vdGhpbmcgZWxzZSBlYXJsaWVyLCBhbiBJbnRlcm5ldCByb3V0ZXIg d2l0aCBhIGRlZmF1bHQgZnJlZSByb3V0ZSB0YWJsZS4NCg0KLSBlbmNhcHN1bGF0ZSByYXRoZXIg dGhhbiBpbnNlcnQsIGJlY2F1c2UgZW5jYXBzdWxhdGlvbiB3b3VsZCBiZSBzaW1wbGVyLCBhbmQg aXMgdGhlIHRyYWRpdGlvbmFsIHdheSBvZiBhZGRpbmcgaW5mb3JtYXRpb24gdG8gUERVcyBhY3Jv c3MgbWFueSBkZWNhZGVzIGFuZCBtYW55IHByb3RvY29scyAoSSBjYW4gb25seSB0aGluayBvZiBW TEFOIElEIGluc2VydGlvbiBhcyB0aGUgb25seSBleGlzdGluZyBjb3VudGVyIGV4YW1wbGUsIGFu ZCBhY2NvcmRpbmcgdG8gUmFkaWEgUGVybG1hbiBpbiBoZXIgYm9vaywgdGhhdCBpcyBvbmx5IGJl Y2F1c2UgYXQgdGhlIHRpbWUgdGhleSB3ZXJlbid0IHN1cmUgaWYgYWxsIE5JQ3MgY29tbW9ubHkg YXZhaWxhYmxlIGNvdWxkIHN1Y2Nlc3NmdWxseSBlbmNhcHN1bGF0ZSBhIGZ1bGwgc2l6ZWQgZXRo ZXJuZXQgZnJhbWUgaW5zaWRlIGFub3RoZXIgb25lKS4NCg0KSW4gb3RoZXIgd29yZHMsIHByZXNl cnZlIHRoZSBvcmlnaW5hbCBJUHY2IHBhY2tldCwgYWRkIGFuIE9BTSBoZWFkZXIgaW4gZnJvbnQg b2YgaXQsIHRoZW4gZW5jYXBzdWxhdGUgaXQgaW4gYW5vdGhlciBoZWFkZXIgdG8gZm9yd2FyZCB3 aXRoaW4gYW5kIGFjcm9zcyB0aGUgT0FNIGRvbWFpbi4NCg0KQm9nIHN0YW5kYXJkIElHUC9MRFAg TVBMUyBjb3VsZCBhY2hpZXZlIHRob3NlIHJlcXVpcmVtZW50cywgd2l0aCB0aGUgT0FNIGhlYWRl ciBpbnNlcnRlZCBhZnRlciB0aGUgZmluYWwgTVBMUyB0YWcgYW5kIGJlZm9yZSB0aGUgSVB2NiBo ZWFkZXIuIFRoZSBNUExTL09BTS9JUHY2IHBhY2tldCBmb2xsb3dzIGFuIExTUCBhY3Jvc3MgdGhl IGRvbWFpbiB0aGF0IG1hdGNoZXMgdGhlIHBhdGggdGhhdCB0aGUgSVB2NiBwYWNrZXQgd2l0aG91 dCBNUExTIHdvdWxkIGZvbGxvdyBhY3Jvc3MgdGhlIGRvbWFpbi4gSW4gdGhhdCBzY2VuYXJpbywg dGhlIE1QTFMgTFNQIGFjcm9zcyB0aGUgZG9tYWluIGlzIHRoZSAiaW50ZXJpb3IgREEiIHRoYXQg aXNuJ3QgdmFsaWQgb3V0c2lkZSBvZiB0aGUgT0FNIGRvbWFpbiwgYmVjYXVzZSBNUExTIHdvdWxk bid0IChub3JtYWxseSkgYmUgdmFsaWQgb3V0c2lkZSBvZiB0aGUgT0FNIGRvbWFpbiAoaS5lLiBP QU0gZG9tYWluIGlzIE1QTFMgZG9tYWluIDE6MSkuIElmIE1QTFMgZmFpbHMgdG8gYmUgcmVtb3Zl ZCBhdCB0aGUgT0FNIGRvbWFpbiBlZ3Jlc3MgZWRnZSwgdGhlIHBhY2tldCBpcyBkcm9wcGVkIGlt bWVkaWF0ZWx5LCBzbyBhIGZhaWwgc2FmZSwgbG9jYWxpc2VkIHRvIHRoZSBPQU0gZG9tYWluLg0K DQpGb3IgYW4gSVB2Ni1pbi1JUHY2IHNjZW5hcmlvOg0KDQotIGZvciBlYWNoIE9BTSBkb21haW4g aW50ZXJpb3IgSVB2NiByb3V0ZXMvcHJlZml4ZXMgdXNlZCBieSBob3N0cyAoaS5lLiBob3N0cyBo YXZlIGFkZHJlc3NlcyBmcm9tIHRoZXNlIHByZWZpeGVzKSwgYXV0b21hdGljYWxseSBjcmVhdGUg YSBtYXRjaGluZyBpbnRlcmlvciBPQU0gcm91dGUvcHJlZml4IChtYXliZSBqdXN0IGEgLzEyOCks IDE6MSwgd2l0aCB0aGUgaW50ZXJpb3IgT0FNIHJvdXRlL3ByZWZpeCBvcmlnaW5hdGVkIGJ5IHRo ZSBzYW1lIHJvdXRlcihzKSB3aGVyZSB0aGUgaW50ZXJpb3IgSVB2NiByb3V0ZXMvcHJlZml4ZXMg YXJlIGNyZWF0ZWQvb3JpZ2luYXRlZC4gVGhlIGludGVyaW9yIE9BTSByb3V0ZXMgY29tZSBmcm9t IFVMQSBzcGFjZSBvciBwZXJoYXBzIGEgbmV3IGRlc2lnbmF0ZWQgYW5kIHJlc2VydmVkIHByaXZh dGUvbG9jYWwgT0FNIGFkZHJlc3Mgc3BhY2UgZm9yIHRoaXMgcHVycG9zZS4NCg0KV2hlbiBhIGVu ZCBob3N0IG9yaWdpbmF0ZWQgcGFja2V0IGluZ3Jlc3NlcyB0aGUgT0FNIGRvbWFpbiBlZGdlLCB0 aGUgREEgYWRkcmVzcyBvZiB0aGUgcGFja2V0IGlzIGxvb2tlZCB1cCB0byBmaW5kIHRoZSAxOjEg bWF0Y2hpbmcgaW50ZXJuYWwgT0FNIHJvdXRlL3ByZWZpeC9hZGRyZXNzLiBUaGlzIGludGVybmFs IE9BTSByb3V0ZS9wcmVmaXgvYWRkcmVzcyBpcyB1c2VkIGFzIHRoZSBEQSBmb3IgdGhlIG91dGVy IElQdjYgaGVhZGVyLCBvdXRlciBoZWFkZXIgU0EgaXMgdGhlIE9BTSBhZGRyZXNzIG9mIHRoZSBP QU0gaW5ncmVzcyBkZXZpY2UsIGFuIE9BTSBoZWFkZXIgZm9sbG93cywgYW5kIHRoZW4gdGhlIG9y aWdpbmFsLCBpbm5lciBJUHY2IHBhY2tldCBmb2xsb3dzIHdpdGhvdXQgbW9kaWZpY2F0aW9uLg0K DQpBcyB0aGUgT0FNIHJvdXRlL3ByZWZpeC9hZGRyZXNzIGlzIG9yaWdpbmF0ZWQgYXQgdGhlIHNh bWUgcGxhY2UgYXMgdGhlIE9BTSBkb21haW4gaW50ZXJpb3IgSVB2NiByb3V0ZS9wcmVmaXgsIHRo ZSBwYXRoIHRoZSBub3cgSVB2Ni1pbi1JUHY2IHBhY2tldCBmb2xsb3dzIHRocm91Z2ggdGhlIE9B TSBkb21haW4gc2hvdWxkIGJlIHRoZSBzYW1lIGFzIHRoYXQgd2hpY2ggdGhlIG9yaWdpbmFsLCBu b3cgaW5uZXIgcGFja2V0IHdvdWxkIGhhdmUgZm9sbG93ZWQgd2l0aCBpdHMgREEuIEluIGEgc2Vu c2UgdGhpcyBPQU0gcm91dGUvcHJlZml4L2FkZHJlc3MgaXMgYW4gaW50ZXJuYWwgcm91dGVhYmxl IGluZGV4IG9yIHByb3h5IGZvciB0aGUgaW5uZXIgcGFja2V0IGRlc3RpbmF0aW9uIHByZWZpeC4N Cg0KLSBmb3IgZXh0ZXJpb3Igcm91dGVzLCBJUHY2LWluLUlQdjYgdHVubmVsbGluZyB0b28gYmV0 d2VlbiBCR1AgYm9yZGVyIHJvdXRlcnMgcGVyIFJGQzE3NzIsICJBLjIuMyBFbmNhcHN1bGF0aW9u Iiwgd2l0aCB0aGUgYWRkaXRpb24gb2YgdGhlIE9BTSBoZWFkZXIgYmV0d2VlbiB0aGUgbmV3IG91 dGVyIElQdjYgaGVhZGVyIGFuZCB0aGUgaW5uZXIgb3JpZ2luYWwNCklQdjYgcGFja2V0LCBhbmQg T0FNIGxvY2FsIGFkZHJlc3NlcyBmb3IgdGhlIHR1bm5lbCBlbmQgcG9pbnRzLiBUaGlzIGF2b2lk cyBoYXZpbmcgdG8gY3JlYXRlIDE6MSBtYXRjaGluZyBpbnRlcm5hbCBPQU0gcm91dGUvcHJlZml4 L2FkZHJlc3MgZm9yIGVhY2ggZXh0ZXJpb3Igcm91dGUuDQoNCihBbmQgcGVyaGFwcyBhIHNvbWV3 aGF0IHJhZGljYWwgaWRlYSBmb3IgcmVkdWNpbmcgdHVubmVsbGluZyBvdmVyaGVhZC4NCkFsbCBv ZiB0aGlzIHR1bm5lbGxpbmcgc3R1ZmYgYWxyZWFkeSBleGlzdHMgZm9yIElQdjQ7IGFuZCBpdCBp cyBzdW5rIGNvc3QuIFdvdWxkIHRoZXJlIGJlIG11Y2ggaGFybSBpbiB1c2luZyBJUHY0IGFzIHRo ZSBpbnRlcmlvciBvdXRlciB0dW5uZWxsaW5nIHByb3RvY29sIGZvciB0aGlzIElQdjYgdHJhZmZp YyB3aXRoIHRoZSBhZGRlZCBPQU0gaW5mb3JtYXRpb24/IEknZCBtdWNoIHJhdGhlciBrZWVwIHJ1 bm5pbmcgYW4gSVB2NCBPQU0gaXNsYW5kIHRvIGNhcnJ5DQpJUHY2IHRoYW4gYW55IHNwbGl0dGlu ZyBhcGFydCBvZiBJUHY2IHBhY2tldHMgdG8gaW5zZXJ0IEVIcyBpbiB0aGVtDQouLi4pDQoNCj4g My4gICAgICAgTm8gc3VwcG9ydCBvZiBJT0FNIGluIHRyYW5zaXQgbmV0d29yay4gU3VwcG9ydCBv bmx5IHNvdXJjZSBpbml0aWF0ZWQgSU9BTSB0cmFjaW5nLCBwcm9vZiBvZiB0cmFuc2l0Li4NCj4g Q2F2ZWF0OiBMaW1pdHMgdXNhZ2Ugb2YgSU9BTSBzaWduaWZpY2FudGx5Lg0KPg0KPg0KPiBPbiAy LiBJbmNyZW1lbnRhbCBUcmFjZSBJT0FNIEhiSCBPcHRpb24NCj4NCj4gMS4gICAgICAgVXNlIFBN VFUgdG8gZGV0ZXJtaW5lIG1heCBwb3NzaWJsZSBJbmNyZW1lbnRhbCBUcmFjZSBJT0FNIE9wdGlv biBsZW5ndGgNCj4NCj4gMi4gICAgICAgRG8gbm90IHN1cHBvcnQgSW5jcmVtZW50YWwgVHJhY2Ug SU9BTSBPcHRpb24gaW4gSVB2Ni4NCj4NCj4NCg0KQ291bGQgd2hhdCBJJ3ZlIHN1Z2dlc3RlZCBh Ym92ZSBzb2x2ZSB0aG9zZT8gSSB0aGluayB0aGUgdXNlIG9mIHR1bm5lbGxpbmcvZW5jYXBzdWxh dGlvbiBzdXBwb3J0cyBhIHRyYW5zaXQgT0FNIHNjZW5hcmlvLg0KDQpSZWdhcmRzLA0KTWFyay4N Cg0KDQo+DQo+IFdoaWxlIHRoZXJlIGlzbuKAmXQgYW4gZWFzeSBhbnN3ZXIsIElNSE8gd2Ugc2hv dWxkIHN0aWxsIHRyeSB0byBmaW5kIGEgd29ya2FibGUgYW5kIGltcGxlbWVudGFibGUgc29sdXRp b24uIEkgc29tZXRpbWVzIGNvbXBhcmUgdGhlIHNpdHVhdGlvbiB3aXRoIHRoZSByb2FkIG5ldHdv cms6IFdoYXQgd2UgaGF2ZSB0b2RheSBpcyBhIG5ldHdvcmsgb2YgZ3JhdmVsIHJvYWRzIChJbnRl cm5ldCB3aXRoIG9mdGVuIHBvb3IgZXh0IGhlYWRlciBwcm9jZXNzaW5nKSBhbmQgY2FycyBhcmUg YnVpbHQgdG8gY29wZSB3aXRoIGdyYXZlbCByb2Fkcy4gTm93IGZhc3RlciBhbmQgY29tZnkgY2Fy cyBiZWNvbWUgYXZhaWxhYmxlLCB0aG91Z2ggdGhleSBvbmx5IHdvcmsgb24gdGFyZWQvY29uY3Jl dGUgcm9hZHMgKHNwZWNpZmljIGFkbWluaXN0cmF0aXZlIGRvbWFpbnMpLiBJZiB5b3UgdHJ5IHRv IGRyaXZlIHRoZXNlIG5ldyBjYXJzIG9uIGdyYXZlbCByb2FkcyB0aGV5IGJyZWFrIGFuZCB0aGUg d3JlY2tzIGphbSB0aGUgcm9hZHPigKYsIHN0aWxsIHdlIHByb2JhYmx5IHdhbnQgdG8gYWxsb3cg Zm9sa3MgdG8gYnV5IGFuZCB1c2UgdGhlIGZhc3QgJiBjb21meSBjYXJzLCBiZWNhdXNlIHRoZXkg d2lsbCBhbHNvIHB1c2ggZm9yIGJldHRlciByb2FkcyAgYXMgd2VsbCAoZG8gcHJvcGVyIGV4dCBo ZWFkZXIgcHJvY2Vzc2luZykuDQo+DQo+DQo+DQo+IFRob3VnaHRzPw0KPg0KPg0KPg0KPiBUaGFu a3MsIEZyYW5rDQo+DQo+DQo+DQo+DQo+DQo+IEZyb206IE1hcmsgU21pdGggPG1hcmt6enpzbWl0 aEBnbWFpbC5jb20+DQo+IFNlbnQ6IERpZW5zdGFnLCAzMC4gT2t0b2JlciAyMDE4IDA1OjI2DQo+ IFRvOiBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKSA8ZmJyb2NrbmVAY2lzY28uY29tPg0KPiBD YzogQy4gTS4gSGVhcmQgPGhlYXJkQHBvYm94LmNvbT47IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+ OyANCj4gaXBwbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogdjYgb3B0aW9uIHR5cGVzIGZvciBJ T0FNIGRhdGEgZmllbGRzDQo+DQo+DQo+DQo+DQo+IEhpIEZyYW5rLA0KPg0KPg0KPg0KPiBPbiBU dWUuLCAzMCBPY3QuIDIwMTgsIDA1OjM2IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpLCA8ZmJy b2NrbmVAY2lzY28uY29tPiB3cm90ZToNCj4NCj4gVGhhbmtzIE1pa2UuIE9uIHRoZSBzY29wZSBv ZiBhbiBJT0FNIGRlcGxveW1lbnQ6DQo+IGRyYWZ0LWlldGYtaXBwbS1pb2FtLWRhdGEtMDQgY2xh cmlmaWVzIGluIHNlY3Rpb24gMyB0aGF0IElPQU0gaXMgYSBkb21haW4gZm9jdXNlZCBmZWF0dXJl LCBpLmUuIG5vdCBleHBlY3RlZCB0byBiZSBkZXBsb3llZCBvbiB0aGUgb3BlbiBJbnRlcm5ldC4N Cj4NCj4NCj4NCj4gVGhhdCBzdGlsbCB2aW9sYXRlcyBSRkMgODIwMCwgdGhlcmUgYXJlIG5vIGV4 Y2VwdGlvbnMgZm9yICJjbG9zZWQiIGRvbWFpbnMuDQo+DQo+DQo+DQo+IEZyb20gc2VjdGlvbiAz Og0KPg0KPg0KPg0KPiAiRGVzaWduZXJzIG9mDQo+DQo+ICAgIGNhcnJpZXIgcHJvdG9jb2xzIGZv ciBJT0FNIG11c3Qgc3BlY2lmeSBtZWNoYW5pc21zIHRvIGVuc3VyZSB0aGF0DQo+DQo+ICAgIElP QU0gZGF0YSBzdGF5cyB3aXRoaW4gYW4gSU9BTSBkb21haW4uICBJbiBhZGRpdGlvbiwgdGhlIG9w ZXJhdG9yIA0KPiBvZg0KPg0KPiAgICBzdWNoIGEgZG9tYWluIGlzIGV4cGVjdGVkIHRvIHB1dCBw cm92aXNpb25zIGluIHBsYWNlIHRvIGVuc3VyZSB0aGF0DQo+DQo+ICAgIElPQU0gZGF0YSBkb2Vz IG5vdCBsZWFrIGJleW9uZCB0aGUgZWRnZSBvZiBhbiBJT0FNIGRvbWFpbiwgZS5nLiANCj4gdXNp bmcNCj4NCj4gICAgZm9yIGV4YW1wbGUgcGFja2V0IGZpbHRlcmluZyBtZXRob2RzLiINCj4NCj4N Cj4NCj4gTmVpdGhlciB0aGUgZGVzaWduZXJzIG9yIHRoZSBvcGVyYXRvcnMgY2FuIGVuc3VyZSB0 aGlzIElPQU0gaW5mb3JtYXRpb24gd29uJ3QgbGVhay4NCj4NCj4NCj4NCj4gUG9zc2libGUgcmVh c29ucyBpdCBjYW4gbGVhazoNCj4NCj4NCj4NCj4gLSBvcGVyYXRvciBjb25maWd1cmF0aW9uIGVy cm9yIC0gZS5nLiBmb3JnZXR0aW5nIHRvIGNvbmZpZ3VyZSB0aGUgZG9tYWluIGJvdW5kYXJ5IChl LmcuIHJvdXRlciB3aXRoIG11bHRpcGxlIGRvbWFpbiBleGl0IGludGVyZmFjZXMsIGZvcmdldHRp bmcgdG8gYWRkIHRoYXQgb3B0aW9uIG9uIG9uZSBvZiB0aGVtKSwgb3IgbWlzY29uZmlndXJpbmcg aXQuDQo+DQo+DQo+DQo+IC0gcGFydGlhbCBkZXZpY2UgZmFpbHVyZSAtIHRoZSBkZXZpY2Ugc3Rp bGwgZm9yd2FyZHMgcGFja2V0cywgYnV0IA0KPiBjZWFzZXMgdG8gcmVtb3ZlIHRoaXMgaW5mb3Jt YXRpb24gZHVlIHRvIGEgaGFyZHdhcmUgZmF1bHQgdGhhdCBoYXMgDQo+IGFwcGVhcmVkDQo+DQo+ DQo+DQo+IC0gdmVuZG9yIGltcGxlbWVudGF0aW9uIGJ1Z3MgdGhhdCBmYWlscyB0byByZW1vdmUg dGhlIGluZm9ybWF0aW9uLg0KPg0KPg0KPg0KPiBBbnkgb3IgYWxsIG9mIHRoZXNlIGNhbiBvY2N1 ciwgYW5kIGFzIGl0IGlzIG9uIGVncmVzcywgdGhlIGNvbnNlcXVlbmNlcyBtYXkgbm90IGJlIHZp c2libGUgdG8gdGhlIGRvbWFpbiBuZXR3b3JrIG9wZXJhdG9yLCBiZWNhdXNlIG5ldHdvcmsgb3Bl cmF0b3JzIHJhcmVseSBpbnNwZWN0IHBhY2tldHMgYWZ0ZXIgdGhleSd2ZSBsZWZ0IHRoZWlyIG5l dHdvcmsuIE9uY2UgYSBwYWNrZXQgaXMgc2VudCBvbnRvIHNvbWVib2R5IGVsc2UsIGl0IGlzIGFz c3VtZWQgdG8gaGF2ZSBiZWVuIHNlbnQgd2l0aG91dCBmYXVsdHMuDQo+DQo+DQo+DQo+IFRoZXJl IGFyZSBtYW55IGluc3RhbmNlcyBvZiBsZWFrcyBhdCB0aGUgYm91bmRhcnkgb2Ygd2hhdCBhcmUg c3VwcG9zZWQgDQo+IHRvIGJlIGNsb3NlZCBkb21haW5zLCBzdWNoIGFzIHBhY2tldHMgY29udGFp bmluZyBSRkMxOTE4IHByaXZhdGUgDQo+IGFkZHJlc3NlcyAoaW4gcGFja2V0IGhlYWRlcnMgdGhl bXNlbHZlcywgb3IgaW4gRE5TIHBhY2tldHMgLSBzdWNoIGEgDQo+IGJpZyBwcm9ibGVtIHRoYXQg d3d3LmFzMTEyLm5ldCB3YXMgY3JlYXRlZCksIGFuZCByb3V0ZSBsZWFrcyBlLmcuIA0KPiBodHRw czovL2JncG1vbi5uZXQvaG93LXRoZS1pbnRlcm5ldC1pbi1hdXN0cmFsaWEtd2VudC1kb3duLXVu ZGVyLw0KPg0KPg0KPg0KPiBBcyBvcGVyYXRvcnMgdXN1YWxseSBoYXZlIG9ubHkgb25lIGRldmlj ZSBhdCB0aGUgZWRnZSBvZiB0aGUgZG9tYWluLCB0aGF0IHdvdWxkIGJlIHBlcmZvcm1pbmcgdGhl IGRvbWFpbiBib3VuZGFyeSBmdW5jdGlvbiwgdGhhdCBkZXZpY2UgYmVjb21lcyBhIHNpbmdsZSBw b2ludCBvZiBmYWlsdXJlLiBFbmZvcmNlbWVudCBpcyB0aGVyZWZvcmUgcXVpdGUgZnJhZ2lsZS4g QSBkb21haW4gYm91bmRhcnkgZW5mb3JjZWQgYnkgdHdvIGRvbWFpbiBlZGdlIGRldmljZXMgaW4t bGluZSB3b3VsZCBpbmNyZWFzZSByb2J1c3RuZXNzLCBob3dldmVyIEknZCB0aGluayB0aGF0IHdv dWxkIGJlIHJhcmVseSBkZXBsb3llZCwgYmVjYXVzZSB3ZSBoYXZlbid0IHNlZW4gdGhhdCBjb21t b25seSB3aXRoIElQdjQgTkFULg0KPg0KPg0KPg0KPiBUaGUgb25seSB3YXkgZm9yIGFuIG9wZXJh dG9yIHRvIGVuc3VyZSB0aGVzZSBsZWFrcyBkb24ndCBhbmQgbmV2ZXIgb2NjdXIgaXMgZm9yIHRo ZSBkb21haW4gdG8gbGl0ZXJhbGx5IG5vdCBiZSBwaHlzaWNhbGx5IGNvbm5lY3RlZCB0byB0aGUg SW50ZXJuZXQgaS5lLiB0aGUgZG9tYWluIGlzIGFpciBnYXBwZWQgZnJvbSB0aGUgSW50ZXJuZXQu IElmIHRoZXJlIGlzIGEgbGluayBiZXR3ZWVuIHRoZSBkb21haW4gYW5kIHRoZSBJbnRlcm5ldCB0 aGF0IGNhbiBjYXJyeSBJUCBwYWNrZXRzLCB0aGVuIHRoZXJlIGlzIGFsd2F5cyBhIHBvc3NpYmls aXR5IHRoYXQgaW5mb3JtYXRpb24gY2FuIGxlYWsgZnJvbSB0aGUgZG9tYWluLg0KPg0KPg0KPg0K PiBTbyBhY2NlcHRpbmcgdGhhdCBsZWFrcyBjYW4gYWx3YXlzIG9jY3VyLCBhIGZhciBtb3JlIHJv YnVzdCBvcHRpb24gaXMgdG8gbGVhdmUgdGhlIG9yaWdpbmFsIHBhY2tldCBhbG9uZSBlbnRpcmVs eSwgYW5kIGVuY2Fwc3VsYXRlIGl0IGluIGEgZG9tYWluIGxvY2FsIElQdjYgaGVhZGVyIChpLmUg UkZDMjQ3Mywgc2VjdGlvbiAzLjEpIHdpdGggZG9tYWluIGxvY2FsIGxpbWl0ZWQgYWRkcmVzc2Vz IChpLmUuIFVMQSBhZGRyZXNzZXMpIGFuZCB0aGUgYWRkaXRpb25hbCBFSC4NCj4NCj4NCj4NCj4g VGhhdCBzdGlsbCBkb2Vzbid0IGVuc3VyZSB0aGF0IHBhY2tldCB3b24ndCBsZWFrIG91dHNpZGUg dGhlIGRvbWFpbiwgYmVjYXVzZSB0aG9zZSBwYWNrZXRzIHdpbGwgZm9sbG93IGEgZGVmYXVsdCBy b3V0ZSwgaG93ZXZlciBhcyB0aGUgcGFja2V0J3MgYWRkcmVzc2luZyBpcyBpbnZhbGlkIG91dHNp ZGUgb2YgdGhlIGRvbWFpbiwgdGhhdCBwYWNrZXQgd2lsbCBiZSBkcm9wcGVkIG9uY2UgaXQgcmVh Y2hlcyBlaXRoZXIgYW4gaW52YWxpZCBJbnRlcm5ldCBhZGRyZXNzIGZpbHRlciwgb3IgYSBkZWZh dWx0IGZyZWUgSW50ZXJuZXQgcm91dGVyLiBUaGUgcGFja2V0IHdpdGggdGhlIGZhaWxlZC10by1i ZS1yZW1vdmVkIG91dGVyIFVMQSBJUHY2IGhlYWRlciB3aWxsIG5ldmVyIHJlYWNoIHRoZSBkZXN0 aW5hdGlvbiBhZGRyZXNzIG9mIHRoZSBpbm5lciBwYWNrZXQsIGJlY2F1c2UgdGhlIERBIG9mIHRo ZSBpbm5lciBwYWNrZXQgaXMgaW4gdGhlIFVMQSBJUHY2IHBhY2tldCdzIHBheWxvYWQuDQo+DQo+ DQo+DQo+IEZhaWx1cmUgb2YgdGhlIG1lY2hhbmlzbSB3b3VsZCBiZSBtdWNoIG1vcmUgb2J2aW91 cywgbG9jYWxpc2VkIHRvIHRoZSBkb21haW4gaW1wbGVtZW50aW5nIHRoZSBtZWNoYW5pc20gKHJh dGhlciB0aGFuIGJlaW5nIGV4dGVybmFsaXNlZCB0byBzb21lYm9keSBlbHNlJ3MgZG9tYWluL25l dHdvcmspLCBhbmQgYWJzb2x1dGUsIGJlY2F1c2UgdGhlIGZhaWx1cmUgbW9kZSBpcyBwYWNrZXRz IGJlaW5nIGVudGlyZWx5IGRpc2NhcmRlZC4NCj4NCj4NCj4NCj4gUmVnYXJkcywNCj4NCj4gTWFy ay4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gRnJhbmsNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogQy4gTS4gSGVhcmQgPGhlYXJkQHBvYm94LmNvbT4NCj4gU2VudDogTW9u dGFnLCAyOS4gT2t0b2JlciAyMDE4IDE2OjAzDQo+IFRvOiA2bWFuIDxpcHY2QGlldGYub3JnPjsg SVBQTSA8aXBwbUBpZXRmLm9yZz4NCj4gQ2M6IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxm YnJvY2tuZUBjaXNjby5jb20+DQo+IFN1YmplY3Q6IFJlOiB2NiBvcHRpb24gdHlwZXMgZm9yIElP QU0gZGF0YSBmaWVsZHMNCj4NCj4gT24gVGh1LCAyNSBPY3QgMjAxOCAxNTowNjo1NyArMDAwMCBG cmFuayBCcm9ja25lcnMgKGZicm9ja25lKSB3cm90ZToNCj4gPiBRdWljayBoZWFkcyB1cDogSW4g dGhlIDZNQU4gbWVldGluZyBpbiBCS0ssIHdl4oCZbGwgcmV2aWV3DQo+ID4gZHJhZnQtaW9hbWV0 YWwtaXBwbS02bWFuLWlvYW0taXB2Ni1vcHRpb25zLTAxIOKAkyB3aGljaCByZXF1ZXN0cyAyIA0K PiA+IG9wdGlvbiB0eXBlcyBmcm9tIHRoZSBETy9IYnlIIG9wdGlvbnMgc3ViLXJlZ2lzdHJ5Lg0K PiA+DQo+ID4gV2hpbGUgdGhlIGJ1bGsgb2YgdGhlIElPQU0gd29yayBpcyBwcm9ncmVzc2VkIGlu IHRoZSBJUFBNIFdHLCB3ZeKAmWQgDQo+ID4gZ3JlYXRseSBhcHByZWNpYXRlIHlvdXIgZmVlZGJh Y2sgb24gDQo+ID4gZHJhZnQtaW9hbWV0YWwtaXBwbS02bWFuLWlvYW0taXB2Ni1vcHRpb25zLTAx LA0KPiA+IHdoaWNoIGRlZmluZXMgaG93IElPQU0gZGF0YSBmaWVsZHMgYXJlIGNhcnJpZWQgdXNp bmcgdjYgZXh0ZW5zaW9uIGhlYWRlcnMuDQo+ID4gQ2PigJlpbmcgdGhlIElQUE0gV0cgYXMgd2Vs bCwgdG8ga2VlcCBldmVyeW9uZSBvbiB0aGUgc2FtZSBwYWdlLg0KPg0KPiBJIGhhdmUgdHdvIGJy aWVmIGNvbW1lbnRzIG9uIHRoaXMgd29yay4NCj4NCj4gRmlyc3QsIEkgc2VlIHRoYXQgdGhlIElu Y3JlbWVudGFsIFRyYWNpbmcgT3B0aW9uIGNoYW5nZXMgbGVuZ3RoIGluIHRyYW5zaXQuDQo+IEl0 IGlzIG5vdCBhcHByb3ByaWF0ZSBmb3IgaXQgdG8gYmUgY2FycmllZCBpbiBhbiBJUHY2IG9wdGlv biBpbnRlbmRlZCBmb3IgdXNlIG9uIHRoZSBvcGVuIEludGVybmV0LCBmb3IgZXhhY3RseSB0aGUg c2FtZSByZWFzb24gdGhhdCBpbnNlcnRpb24gb2YgZXh0ZW5zaW9uIGhlYWRlcnMgYnkgaW50ZXJt ZWRpYXRlIG5vZGVzIGlzIG5vdCBhbGxvd2VkIG9uIHRoZSBvcGVuIEludGVybmV0Lg0KPg0KPiBT ZWNvbmQsIEkgc2VlIHRoYXQgdHdvIElQdjYgb3B0aW9uIGNvZGUgcG9pbnRzIGFyZSByZXF1ZXN0 ZWQsIG9uZSB3aXRoIHRoZSAiY2hnIiBmbGFnIHNldCwgdGhlIG90aGVyIHdpdGggdGhlICJjaGci IGZsYWcgY2xlYXIuIFdoaWxlIHRoZXJlIGlzIG5vIGhhcm0gaW4gdGhpcywgaXQgaXMgbm90IHN0 cmljdGx5IG5lY2Vzc2FyeTsgdGhlIG9ubHkgcmVhbCBwdXJwb3NlIG9mIHRoaXMgZmxhZyBpcyB0 byBkZXRlcm1pbmUgd2hldGhlciB0aGUgb3B0aW9uIGRhdGEgaXMgb3IgaXMgbm90IGluY2x1ZGVk IGluIHRoZSBBdXRoZW50aWNhdGlvbiBIZWFkZXIgSW50ZWdyaXR5IENoZWNrIFZhbHVlIGNvbXB1 dGF0aW9uLg0KPg0KPiBNaWtlIEhlYXJkDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3Jr aW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZl IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg== From nobody Mon Nov 12 09:54:44 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6282D130E2A; Mon, 12 Nov 2018 09:54:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-ippm-port-twamp-test@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, ietf@kuehlewind.net, Tianran Zhou , zhoutianran@huawei.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154204527539.4298.3977756213741547520.idtracker@ietfa.amsl.com> Date: Mon, 12 Nov 2018 09:54:35 -0800 Archived-At: Subject: [ippm] Last Call: (OWAMP and TWAMP Well-Known Port Assignments) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 17:54:35 -0000 The IESG has received a request from the IP Performance Measurement WG (ippm) to consider the following document: - 'OWAMP and TWAMP Well-Known Port Assignments' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-11-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo explains the motivation and describes the re-assignment of well-known ports for the OWAMP and TWAMP protocols for control and measurement, and clarifies the meaning and composition of these standards track protocol names for the industry. The memo updates RFC 4656 and RFC 5357, in terms of the UDP well- known port assignments, and clarifies the complete OWAMP and TWAMP protocol composition for the industry. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ippm-port-twamp-test/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ippm-port-twamp-test/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7594: A Framework for Large-Scale Measurement of Broadband Performance (LMAP) (Informational - IETF stream) From nobody Wed Nov 14 07:35:50 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25F41292AD; Wed, 14 Nov 2018 07:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qD8rOJHDpQf; Wed, 14 Nov 2018 07:35:45 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 BC2B0124BE5; Wed, 14 Nov 2018 07:35:44 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id p17so11821965lfh.4; Wed, 14 Nov 2018 07:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mDuU3M9ST1dpTAsFL7qoox62DXlMm+zRmcpz2bQl3YQ=; b=VXfWOaeM0w7azTBK37cugyPnc4Bmwt2mXRhpZd9EDExi6tbBn98hjhsaLjTLITOt7e SzXThYG0eyMTU1CRLwI90KlMNOc+QnbY+Da45Ll8r0gvN8QIePVZTE1/H7F2aNSUxYev yidKO4BTkonqEibgwgrkeJsRvRfERTe0/TDhxpg5/BLEOMqqo1UbREAdaGJLJnlXuJ+V oMZgLpr4tfQAcdhHEYuUjdCNWJN8tiJjGEPVyZWROgzwAffuHnt3y/j5Cu7b8LosxHTl WEGrMYhaA+bfFX1Dq2KF4qQty5ERWrYvrpN2Jkmyk+zMLXn0rO/WKkso3oHkkLKpj2l3 eO/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mDuU3M9ST1dpTAsFL7qoox62DXlMm+zRmcpz2bQl3YQ=; b=QX1AANjCdfiMpawgKU6bHSJ63Ne3zGXKsv3T3aQEBMnsKdudAUzBIOjDB7JiFf92Gj i3REKk+DKrTLVywmVMeuSHCeODn3e84NEL+ZLhDcTX9GTd41tcIyhpcH04D71XgP3r+R Oz0PRMfnmGvtsuaNZaEYQm5rzHDU3aro24pbeVRmixU26Q4ic8bzFV6er6ny1D9pyMXF 2gJoj+jLYJAWhzTTeOFkkcCieEGVJFx3GJbb7cwlYSkBF3kpOHHigCrQ4J8Nm3ADJFca fhYwBLUrqBEgNqL1XCEeFJCP26ERxX49VQJi+cXXCt6i1EZRg/h+ev2979K1XLnizsR/ gujw== X-Gm-Message-State: AGRZ1gKIKCZiD0J2GYHstDsgiKyfwZMO2+nyBkMLYhiymW/GQGUjvauo orhfYL5l0auRLrEeBNX9TvWsdZVps8ND1VgpSOo= X-Google-Smtp-Source: AJdET5cT4WFsDTX9v+ePGWO99MUILzTi1NvyQQAi4SdM/VUj5j51+wFLfshiNZBhG+gxcYwhUTiEyanPACilZJ8yKsY= X-Received: by 2002:a19:d145:: with SMTP id i66mr1370685lfg.97.1542209742514; Wed, 14 Nov 2018 07:35:42 -0800 (PST) MIME-Version: 1.0 References: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557D896F@njmtexg5.research.att.com> <7DAAE1B6-3F0C-472B-8185-9FACB35EF59E@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557DE051@njmtexg5.research.att.com> <879BC912-692D-4C82-8591-3FA76EF9F66E@kuehlewind.net> In-Reply-To: <879BC912-692D-4C82-8591-3FA76EF9F66E@kuehlewind.net> From: Spencer Dawkins at IETF Date: Wed, 14 Nov 2018 09:35:29 -0600 Message-ID: To: Mirja Kuehlewind Cc: "MORTON, ALFRED C (AL)" , draft-ietf-ippm-port-twamp-test.all@ietf.org, ippm@ietf.org Content-Type: multipart/alternative; boundary="000000000000df30c9057aa1aff8" Archived-At: Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 14 Nov 2018 15:35:49 -0000 --000000000000df30c9057aa1aff8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Mirja, On Fri, Nov 9, 2018 at 10:59 PM Mirja Kuehlewind (IETF) wrote: > Hi Al, > > see inline. > > > Am 10.11.2018 um 10:47 schrieb MORTON, ALFRED C (AL) < > acm@research.att.com>: > > > > Hi Mirja, and Spencer, > > > > replies below, with a question for the "Outgoing AD" > > Al > > > >> -----Original Message----- > >> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] > >> Sent: Friday, November 9, 2018 9:22 PM > >> To: draft-ietf-ippm-port-twamp-test.all@ietf.org > >> Cc: ippm@ietf.org > >> Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test > >> > >> Hi all, > >> > >> sorry one more question: RFC7594 would be a downref and I think it is > >> correct that this is a normative reference because it pointed to in th= e > >> security sec. On the other it seems a bit weird to point normatively t= o > >> the security section of an informational doc. So just double-checking = if > >> that is all right (given downrefs need to be called out in the last > call, > >> so we have to decide before I start last call)? > > [acm] > > > > Yes, I'd like to keep the Downref, and also ask to place RFC 7594 > > on the "permanent Downref exception list". I don't know the exact > > name of this list, but the IPPM Framework RFC 2330 was placed on it. > > > > @Spencer: "Outgoing AD" may be able to help us find the list above, > > before you go please. :-) > > It=E2=80=99s called Downref registry and it's here: > > https://datatracker.ietf.org/doc/downref/ > > My understanding is that it will go there automatically if once reference= d > as a downref but I can double-check during the publication process. > Right, on the location. I can't verify whether downrefs are automatically added or not now, but I THOUGHT that the idea is that a downref to (say) Informational RFC F00 might be OK for draft A, but not for draft B, so this wasn't intended to happen automatically. If we think the downrefs to RFC F00 will always be good enough, no matter what the referring document is, we would add the reference to the downref registry. Spencer > > > > >> > >> Also looking at the references again, I think RFC6335 does not need to > be > >> a normative reference. > > [acm] > > If our colleagues in IANA are ok with that, so am I. > > Okay. Actually we can do this later and don=E2=80=99t have to do it befor= e last > call, which I will respectively start now. > > Thanks! > Mirja > > > > > >> > >> @Tianran: a downref is a normative reference to a document with a lowe= r > >> maturity level, so also a normative reference from a draft that is > >> intended for Proposed Standard to an informational RFC is a downref. I= n > >> the shepherd write-up you only say that there are normative reference = to > >> RFCs, however, you would next time also need to check the status of > these > >> RFCs. Thanks! Btw. could you please update the shepherd write-up? > > [acm] > > +1, thanks Tianran. > > > >> > >> Mirja > >> > >> > >>> Am 05.11.2018 um 04:57 schrieb MORTON, ALFRED C (AL) > >> : > >>> > >>> Hi Mirja, > >>> please see replies in-line. > >>> Al > >>> > >>>> -----Original Message----- > >>>> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Mirja > Kuehlewind > >>>> (IETF) > >>>> Sent: Monday, October 29, 2018 2:06 PM > >>>> To: draft-ietf-ippm-port-twamp-test.all@ietf.org > >>>> Cc: ippm@ietf.org > >>>> Subject: [ippm] AD review of draft-ietf-ippm-port-twamp-test > >>>> > >>>> Hi authors, > >>>> > >>>> first of all sorry for the rather long delay for this short draft. T= he > >> bad > >>>> news it that I probably have to delay the processing even further as= I > >>>> will not be able to join the next telechat on Nov 21 and we have to > >> wait > >>>> for the telechat on Dec 6. The good news is that gives us plenty of > >> time > >>>> for the IETF last call :-) > >>>> > >>>> I reviewed this document and I don=E2=80=99t think there are any iss= ues that > >> would > >>>> not allow me to start the IETF last cal, but given we have time I > would > >>>> like to ask a few questions/comments: > >>>> > >>>> 1) The document gives plenty of background information and talks abo= ut > >>>> impacts, however, it says very little about why it is good to have a > >> fixed > >>>> port, beside this: > >>>> "It may simplify some operations to have a well- > >>>> known port available for the Test protocols, or for future > >>>> specifications involving TWAMP-Test to use this port as a default > >>>> port.=E2=80=9C > >>>> Is there any chance to say more than this? > >>> [acm] > >>> yes, mentioned BBF TR-390 implementations as benefactors. > >>>> > >>>> 2) Also, I agree with the shepherd that I don=E2=80=99t think it is = necessary > >> to > >>>> detail the history as much as done in section 4, e.g. rather discuss > >> the > >>>> why than the actually comments by Lars and Tim. Also this section is > >>>> called =E2=80=9Edefinition=E2=80=9C but this background information = seems to go beyond > >>>> just defining something. > >>> [acm] > >>> Ok the section is now titled, Definitions and Background, > >>> and most of the details describing comments from Lars and Tim > >>> are moved to an Appendix A. > >>> > >>>> > >>>> Btw. Tianran, it would be nice if you could update your comments in > the > >>>> shepherd write-up accordingly if they have been addressed or are > >> obsolete. > >>>> Thanks! > >>> [acm] > >>> Yes, please consider incorporating some of the details from > >>> my e-mail last August, thanks! > >>> > >>>> > >>>> 3) I don=E2=80=99t think there is any normative language require in = this doc. > >> As > >>>> you are =E2=80=9Ejust=E2=80=9C stating what has been normatively def= ined in other > >>>> documents, it is actually preferred to not re-state normatively. > >>> [acm] > >>> The Scope says: > >>> The scope of this memo is to re-allocate well-known ports for the > >> UDP > >>> Test protocols that compose necessary parts of their respective > >>> standards track protocols, OWAMP and TWAMP, along with > >> clarifications > >>> of the complete protocol composition for the industry. > >>> > >>> The controversy about TWAMP composition is partly what brought us her= e! > >>> We used the term REQUIRED in the Definitions to resolve the small > >> ambiguity > >>> created when OWAMP authors did not use normative language when > >> describing > >>> the protocols that comprise OWAMP, and TWAMP authors followed that > >> choice of > >>> wording (unfortunately). > >>> > >>>> > >>>> 4) An update in the registry does not necessary mean an =E2=80=9Eupd= ate=E2=80=9C of > the > >>>> RFCs that registered that ports in the first place, especially as > >> rfc4656 > >>>> doesn=E2=80=99t even mention the UDP port at all. Of course the use = of > =E2=80=9Eupdate=E2=80=9C > >> is > >>>> very loosely defined and can be used if that is preferred but it is > not > >>>> strictly necessary. Or is there another reason to update these RFCs? > If > >>>> so, it should be clearly spelled out in the draft. > >>> [acm] > >>> Ok, drawing on the point from the Scope, and requirement Language > above, > >>> the Abstract now ends with: > >>> > >>> The memo updates RFC 4656 and RFC 5357, in terms of the UDP well-know= n > >> port > >>> assignments, and clarifies the complete OWAMP and TWAMP protocol > >> composition > >>> for the industry. > >>> > >>>> > >>>> 5) Given that these entries are updates it would be nice to also fil= l > >> the > >>>> missing information about contact information and assignee in the > >>>> registry. Instruction for IANA would need to be added to the IANA > >> section > >>>> in this case. Assignee should be the IESG and contact the IETF chair= . > I > >>>> assume the modification date will be filled by IANA respectively. > >>> [acm] > >>> ok > >>> > >>>> > >>>> Thanks! > >>>> Mirja > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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=3DfczRvYcfFcuwftALPl3iddxB= qrOCp > >>>> UTLa2qfPshPmRY&s=3DD-D42Pu3DFr7TAIb4ras87t2cNxyDt4UURtFGkPZDOo&e=3D > > > > --000000000000df30c9057aa1aff8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Mirja,=C2=A0

On Fri, Nov 9, 2018 at 10:59 PM Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
Hi Al,

see inline.

> Am 10.11.2018 um 10:47 schrieb MORTON, ALFRED C (AL) <acm@research.att.com>:<= br> >
> Hi Mirja, and Spencer,
>
> replies below, with a question for the "Outgoing AD"
> Al
>
>> -----Original Message-----
>> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net]
>> Sent: Friday, November 9, 2018 9:22 PM
>> To: draft-ietf-ippm-port-twamp-test.all@ietf.org
>> Cc: ippm@ietf.o= rg
>> Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test >>
>> Hi all,
>>
>> sorry one more question: RFC7594 would be a downref and I think it= is
>> correct that this is a normative reference because it pointed to i= n the
>> security sec. On the other it seems a bit weird to point normative= ly to
>> the security section of an informational doc. So just double-check= ing if
>> that is all right (given downrefs need to be called out in the las= t call,
>> so we have to decide before I start last call)?
> [acm]
>
> Yes, I'd like to keep the Downref, and also ask to place RFC 7594<= br> > on the "permanent Downref exception list". I don't know = the exact
> name of this list, but the IPPM Framework RFC 2330 was placed on it. >
> @Spencer: "Outgoing AD" may be able to help us find the list= above,
> before you go please. :-)

It=E2=80=99s called Downref registry and it's here:

https://datatracker.ietf.org/doc/downref/

My understanding is that it will go there automatically if once referenced = as a downref but I can double-check during the publication process.

Right, on the location.=C2=A0

I can't verify whether downrefs are automatically added or not= now, but I THOUGHT that the idea is that a downref to (say) Informational = RFC F00 might be OK for draft A, but not for draft B, so this wasn't in= tended to happen automatically.=C2=A0

If we think = the downrefs to RFC F00 will always be good enough, no matter what the refe= rring document is, we would add the reference to the downref registry.

Spencer
=C2=A0

>
>>
>> Also looking at the references again, I think RFC6335 does not nee= d to be
>> a normative reference.
> [acm]
> If our colleagues in IANA are ok with that, so am I.

Okay. Actually we can do this later and don=E2=80=99t have to do it before = last call, which I will respectively start now.

Thanks!
Mirja


>
>>
>> @Tianran: a downref is a normative reference to a document with a = lower
>> maturity level, so also a normative reference from a draft that is=
>> intended for Proposed Standard to an informational RFC is a downre= f. In
>> the shepherd write-up you only say that there are normative refere= nce to
>> RFCs, however, you would next time also need to check the status o= f these
>> RFCs. Thanks! Btw. could you please update the shepherd write-up?<= br> > [acm]
> +1, thanks Tianran.
>
>>
>> Mirja
>>
>>
>>> Am 05.11.2018 um 04:57 schrieb MORTON, ALFRED C (AL)
>> <acm@= research.att.com>:
>>>
>>> Hi Mirja,
>>> please see replies in-line.
>>> Al
>>>
>>>> -----Original Message-----
>>>> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Mirja Kuehlewin= d
>>>> (IETF)
>>>> Sent: Monday, October 29, 2018 2:06 PM
>>>> To: draft-ietf-ippm-port-twamp-test.all@ietf.org
>>>> Cc: ipp= m@ietf.org
>>>> Subject: [ippm] AD review of draft-ietf-ippm-port-twamp-te= st
>>>>
>>>> Hi authors,
>>>>
>>>> first of all sorry for the rather long delay for this shor= t draft. The
>> bad
>>>> news it that I probably have to delay the processing even = further as I
>>>> will not be able to join the next telechat on Nov 21 and w= e have to
>> wait
>>>> for the telechat on Dec 6. The good news is that gives us = plenty of
>> time
>>>> for the IETF last call :-)
>>>>
>>>> I reviewed this document and I don=E2=80=99t think there a= re any issues that
>> would
>>>> not allow me to start the IETF last cal, but given we have= time I would
>>>> like to ask a few questions/comments:
>>>>
>>>> 1) The document gives plenty of background information and= talks about
>>>> impacts, however, it says very little about why it is good= to have a
>> fixed
>>>> port, beside this:
>>>> "It may simplify some operations to have a well-
>>>>=C2=A0 known port available for the Test protocols, or for = future
>>>>=C2=A0 specifications involving TWAMP-Test to use this port= as a default
>>>>=C2=A0 port.=E2=80=9C
>>>> Is there any chance to say more than this?
>>> [acm]
>>> yes, mentioned BBF TR-390 implementations as benefactors.
>>>>
>>>> 2) Also, I agree with the shepherd that I don=E2=80=99t th= ink it is necessary
>> to
>>>> detail the history as much as done in section 4, e.g. rath= er discuss
>> the
>>>> why than the actually comments by Lars and Tim. Also this = section is
>>>> called =E2=80=9Edefinition=E2=80=9C but this background in= formation seems to go beyond
>>>> just defining something.
>>> [acm]
>>> Ok the section is now titled, Definitions and Background,
>>> and most of the details describing comments from Lars and Tim<= br> >>> are moved to an Appendix A.
>>>
>>>>
>>>> Btw. Tianran, it would be nice if you could update your co= mments in the
>>>> shepherd write-up accordingly if they have been addressed = or are
>> obsolete.
>>>> Thanks!
>>> [acm]
>>> Yes, please consider incorporating some of the details from >>> my e-mail last August, thanks!
>>>
>>>>
>>>> 3) I don=E2=80=99t think there is any normative language r= equire in this doc.
>> As
>>>> you are =E2=80=9Ejust=E2=80=9C stating what has been norma= tively defined in other
>>>> documents, it is actually preferred to not re-state normat= ively.
>>> [acm]
>>> The Scope says:
>>>=C2=A0 =C2=A0 =C2=A0The scope of this memo is to re-allocate we= ll-known ports for the
>> UDP
>>>=C2=A0 =C2=A0 =C2=A0Test protocols that compose necessary parts= of their respective
>>>=C2=A0 =C2=A0 =C2=A0standards track protocols, OWAMP and TWAMP,= along with
>> clarifications
>>>=C2=A0 =C2=A0 =C2=A0of the complete protocol composition for th= e industry.
>>>
>>> The controversy about TWAMP composition is partly what brought= us here!
>>> We used the term REQUIRED in the Definitions to resolve the sm= all
>> ambiguity
>>> created when OWAMP authors did not use normative language when=
>> describing
>>> the protocols that comprise OWAMP, and TWAMP authors followed = that
>> choice of
>>> wording (unfortunately).
>>>
>>>>
>>>> 4) An update in the registry does not necessary mean an = =E2=80=9Eupdate=E2=80=9C of the
>>>> RFCs that registered that ports in the first place, especi= ally as
>> rfc4656
>>>> doesn=E2=80=99t even mention the UDP port at all. Of cours= e the use of =E2=80=9Eupdate=E2=80=9C
>> is
>>>> very loosely defined and can be used if that is preferred = but it is not
>>>> strictly necessary. Or is there another reason to update t= hese RFCs? If
>>>> so, it should be clearly spelled out in the draft.
>>> [acm]
>>> Ok, drawing on the point from the Scope, and requirement Langu= age above,
>>> the Abstract now ends with:
>>>
>>> The memo updates RFC 4656 and RFC 5357, in terms of the UDP we= ll-known
>> port
>>> assignments, and clarifies the complete OWAMP and TWAMP protoc= ol
>> composition
>>> for the industry.
>>>
>>>>
>>>> 5) Given that these entries are updates it would be nice t= o also fill
>> the
>>>> missing information about contact information and assignee= in the
>>>> registry. Instruction for IANA would need to be added to t= he IANA
>> section
>>>> in this case. Assignee should be the IESG and contact the = IETF chair. I
>>>> assume the modification date will be filled by IANA respec= tively.
>>> [acm]
>>> ok
>>>
>>>>
>>>> Thanks!
>>>> Mirja
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ippm mailing list
>>>> ippm@ie= tf.org
>>>> https://urldefense.proofpoint.co= m/v2/url?u=3Dhttps-
>>>> 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwIGaQ&= c=3DLFYZ-
>>>>
>> o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DfczRvYcfF= cuwftALPl3iddxBqrOCp
>>>> UTLa2qfPshPmRY&s=3DD-D42Pu3DFr7TAIb4ras87t2cNxyDt4UURt= FGkPZDOo&e=3D
>

--000000000000df30c9057aa1aff8-- From nobody Wed Nov 14 07:51:54 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D42124BAA; Wed, 14 Nov 2018 07:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4Ery50M5hai; Wed, 14 Nov 2018 07:51:44 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 3352D128D09; Wed, 14 Nov 2018 07:51:44 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id t22-v6so14512109lji.7; Wed, 14 Nov 2018 07:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wxAg83FRiGA2wdjnj/faXeyMfS5obMTRqciBXDnYrII=; b=bH/PecRLkQH/E+VM4BowfMnHOd9/36oxzV4Nq/RGVxyXrOqtcZeNpYr0z4V2lxmI2E KHT+s/0IlCBmReABulrotAr3QaGqKXrnVo0hnCCscjcTZL+IqPeAbRsC8y2ZcsRUFDQ6 yrI3wKlFE6oNMbWv88lZdDEXsZJ2hkjztyyM9+5AlQeaO4kaaUMR6g5h6D0bFKQ6ttlX TeK58wv/X+ihOIrvzocdHP03dve0uNg0c8GOZIIkOFBSqv95XBhk6AgUTQJb3eC7x/6M q9xP2upZpjWGggz6CPwi6KKpGs+ijQfTKK1JU2zYCvA1y2LIr5dEbP26ByLmP03U00Ov ZwQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wxAg83FRiGA2wdjnj/faXeyMfS5obMTRqciBXDnYrII=; b=l8xv+C4MJN3+aMqZYgHfihUhAosjCvK/B3iyugxr/7SMg32u2DWC8Dr93mpslhj9Ml 47FKQvk6xnOeeZWH6zHqvyijtn6G371lWstNsj2ezXaiqib2eE42yyhBX1do3J4919xL xNV4lHbKvh2E+LoqE8s2RgzOONQfjAaLsOgoCeFmmgwSn/zdMP6kG3C30lPHI/PFR6FF doDEavf5Ww/NFIYrxCwET3LD1beROBWkUOGHOz7NdfWzNYEckuY+Ka47VslfJ3V1haEE OpWQspLn8q5ud7vuMgZXw5oGYOiHU9qOiMQIW/mL7XHbzYtVhRUfGSzusPwRqIai/VUf A87A== X-Gm-Message-State: AGRZ1gJ+bshyRYK/F0Kzeqyga7wGQYid8+WrIFD0F/LniVsk9t1EAgbl u2LuZCRJESCfhNiA6EJSy+bcIr8by170fkxTHV+kE3v+6A== X-Google-Smtp-Source: AJdET5cwrNn/dJ/I1AIQUWkr/5wrHpCzV7IjYNsZNcEGcC4L4KnyMc2h9XzqPcD8yfrVVO/LRFOm+TPDaGt7F5D01w4= X-Received: by 2002:a2e:99d7:: with SMTP id l23-v6mr1385526ljj.165.1542210702099; Wed, 14 Nov 2018 07:51:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rakesh Gandhi Date: Wed, 14 Nov 2018 10:51:30 -0500 Message-ID: To: Greg Mirsky Cc: draft-gandhi-spring-udp-pm@ietf.org, spring@ietf.org, ippm@ietf.org, ipv6@ietf.org Content-Type: multipart/alternative; boundary="000000000000114f09057aa1e94e" Archived-At: Subject: Re: [ippm] Sequence Number in RFC 6374 and Synthetic Loss Measurement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 14 Nov 2018 15:51:47 -0000 --000000000000114f09057aa1e94e Content-Type: text/plain; charset="UTF-8" Thanks Greg for your review comments. Right, the RFC 6374 DM and LM messages can carry either sequence number or timestamp but not both. There might be some cases where both are desired. The proposed sequence number TLV is optional and can be used with timestamps in DM and LM messages. We can clarify the text in the next update of the draft-gandhi-spring-udp-pm . Thanks, Rakesh On Tue, Nov 6, 2018 at 1:06 AM Greg Mirsky wrote: > Dear Authors, > in your presentation of this draft at IPPM WG meeting I've pointed that > assertion in Section 6 of the draft: > The message formats for DM and LM [RFC6374] do not contain sequence > number for probe query packets. > is not accurate. RFC 6374 allows interpretation of the Timestamp field as > a sequence number. Section 3.4 explains that QTF and RTF values could be 0, > 1, 2, or 3, with 1 identifying the sequence number: > 1: Sequence number. This value indicates that the timestamp field > is to be viewed as a simple 64-bit sequence number. This provides > a simple solution for applications that do not require a real > absolute timestamp, but only an indication of message ordering; an > example is LM exception detection. > > Regards, > Greg > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --000000000000114f09057aa1e94e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Greg for your review comments.

<= /div>
Right, the RFC 6374 DM and LM messages can carry either sequence = number or timestamp but not both. There might be some cases where both are = desired. The proposed sequence number TLV is optional and can be used with = timestamps in DM and LM messages. We can clarify the text in the next updat= e of the draft-gandhi-spring-udp-pm.

Thanks,
Rakesh


On Tue, Nov 6, 2018 at 1:06 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Authors,
in your presentation of this draft at IPPM WG meeting= I've pointed that assertion in Section 6 of the draft:
= =C2=A0 =C2=A0The message formats for DM and LM [RFC6374] do not contain seq= uence
=C2=A0 =C2=A0number for probe query packets.
is not accurate. RFC 6374 allows interpretation of the Timestamp field as= a sequence number. Section 3.4 explains that QTF and RTF values could be 0= , 1, 2, or 3, with 1 identifying the sequence number:
=C2=A0= =C2=A0 =C2=A0 1: Sequence number.=C2=A0 This value indicates that the time= stamp field
=C2=A0 =C2=A0 =C2=A0 is to be viewed as a simple 64-b= it sequence number.=C2=A0 This provides
=C2=A0 =C2=A0 =C2=A0 a si= mple solution for applications that do not require a real
=C2=A0 = =C2=A0 =C2=A0 absolute timestamp, but only an indication of message orderin= g; an
=C2=A0 =C2=A0 =C2=A0 example is LM exception detection.

Regards,
Greg

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--000000000000114f09057aa1e94e-- From nobody Wed Nov 14 08:32:39 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DC6130F02; Wed, 14 Nov 2018 08:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, URIBL_BLOCKED=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 rK7KnOSm26XW; Wed, 14 Nov 2018 08:32:29 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 C9C2A130F1E; Wed, 14 Nov 2018 08:32:28 -0800 (PST) Received: from [96.30.73.156] (helo=[192.168.182.81]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gMy5U-0006YD-4v; Wed, 14 Nov 2018 17:32:20 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 14 Nov 2018 23:31:55 +0700 Cc: "MORTON, ALFRED C (AL)" , draft-ietf-ippm-port-twamp-test.all@ietf.org, ippm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2E89928D-9E30-4030-8FBA-F8430758E723@kuehlewind.net> References: <7C471953-2F6F-4C8E-B9B5-AD861807D05B@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557D896F@njmtexg5.research.att.com> <7DAAE1B6-3F0C-472B-8185-9FACB35EF59E@kuehlewind.net> <4D7F4AD313D3FC43A053B309F97543CF557DE051@njmtexg5.research.att.com> <879BC912-692D-4C82-8591-3FA76EF9F66E@kuehlewind.net> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1542213148;cd158107; X-HE-SMSGID: 1gMy5U-0006YD-4v Archived-At: Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 14 Nov 2018 16:32:37 -0000 Spencer, you are right! I=E2=80=99ll check what the process is when = I=E2=80=99m back! > Am 14.11.2018 um 22:35 schrieb Spencer Dawkins at IETF = : >=20 > Hi, Mirja, >=20 > On Fri, Nov 9, 2018 at 10:59 PM Mirja Kuehlewind (IETF) = > wrote: >=20 >> Hi Al, >>=20 >> see inline. >>=20 >>> Am 10.11.2018 um 10:47 schrieb MORTON, ALFRED C (AL) < >> acm@research.att.com>: >>>=20 >>> Hi Mirja, and Spencer, >>>=20 >>> replies below, with a question for the "Outgoing AD" >>> Al >>>=20 >>>> -----Original Message----- >>>> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] >>>> Sent: Friday, November 9, 2018 9:22 PM >>>> To: draft-ietf-ippm-port-twamp-test.all@ietf.org >>>> Cc: ippm@ietf.org >>>> Subject: Re: [ippm] AD review of draft-ietf-ippm-port-twamp-test >>>>=20 >>>> Hi all, >>>>=20 >>>> sorry one more question: RFC7594 would be a downref and I think it = is >>>> correct that this is a normative reference because it pointed to in = the >>>> security sec. On the other it seems a bit weird to point = normatively to >>>> the security section of an informational doc. So just = double-checking if >>>> that is all right (given downrefs need to be called out in the last >> call, >>>> so we have to decide before I start last call)? >>> [acm] >>>=20 >>> Yes, I'd like to keep the Downref, and also ask to place RFC 7594 >>> on the "permanent Downref exception list". I don't know the exact >>> name of this list, but the IPPM Framework RFC 2330 was placed on it. >>>=20 >>> @Spencer: "Outgoing AD" may be able to help us find the list above, >>> before you go please. :-) >>=20 >> It=E2=80=99s called Downref registry and it's here: >>=20 >> https://datatracker.ietf.org/doc/downref/ >>=20 >> My understanding is that it will go there automatically if once = referenced >> as a downref but I can double-check during the publication process. >>=20 >=20 > Right, on the location. >=20 > I can't verify whether downrefs are automatically added or not now, = but I > THOUGHT that the idea is that a downref to (say) Informational RFC F00 > might be OK for draft A, but not for draft B, so this wasn't intended = to > happen automatically. >=20 > If we think the downrefs to RFC F00 will always be good enough, no = matter > what the referring document is, we would add the reference to the = downref > registry. >=20 > Spencer >=20 >=20 >>=20 >>>=20 >>>>=20 >>>> Also looking at the references again, I think RFC6335 does not need = to >> be >>>> a normative reference. >>> [acm] >>> If our colleagues in IANA are ok with that, so am I. >>=20 >> Okay. Actually we can do this later and don=E2=80=99t have to do it = before last >> call, which I will respectively start now. >>=20 >> Thanks! >> Mirja >>=20 >>=20 >>>=20 >>>>=20 >>>> @Tianran: a downref is a normative reference to a document with a = lower >>>> maturity level, so also a normative reference from a draft that is >>>> intended for Proposed Standard to an informational RFC is a = downref. In >>>> the shepherd write-up you only say that there are normative = reference to >>>> RFCs, however, you would next time also need to check the status of >> these >>>> RFCs. Thanks! Btw. could you please update the shepherd write-up? >>> [acm] >>> +1, thanks Tianran. >>>=20 >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>> Am 05.11.2018 um 04:57 schrieb MORTON, ALFRED C (AL) >>>> : >>>>>=20 >>>>> Hi Mirja, >>>>> please see replies in-line. >>>>> Al >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Mirja >> Kuehlewind >>>>>> (IETF) >>>>>> Sent: Monday, October 29, 2018 2:06 PM >>>>>> To: draft-ietf-ippm-port-twamp-test.all@ietf.org >>>>>> Cc: ippm@ietf.org >>>>>> Subject: [ippm] AD review of draft-ietf-ippm-port-twamp-test >>>>>>=20 >>>>>> Hi authors, >>>>>>=20 >>>>>> first of all sorry for the rather long delay for this short = draft. The >>>> bad >>>>>> news it that I probably have to delay the processing even further = as I >>>>>> will not be able to join the next telechat on Nov 21 and we have = to >>>> wait >>>>>> for the telechat on Dec 6. The good news is that gives us plenty = of >>>> time >>>>>> for the IETF last call :-) >>>>>>=20 >>>>>> I reviewed this document and I don=E2=80=99t think there are any = issues that >>>> would >>>>>> not allow me to start the IETF last cal, but given we have time I >> would >>>>>> like to ask a few questions/comments: >>>>>>=20 >>>>>> 1) The document gives plenty of background information and talks = about >>>>>> impacts, however, it says very little about why it is good to = have a >>>> fixed >>>>>> port, beside this: >>>>>> "It may simplify some operations to have a well- >>>>>> known port available for the Test protocols, or for future >>>>>> specifications involving TWAMP-Test to use this port as a default >>>>>> port.=E2=80=9C >>>>>> Is there any chance to say more than this? >>>>> [acm] >>>>> yes, mentioned BBF TR-390 implementations as benefactors. >>>>>>=20 >>>>>> 2) Also, I agree with the shepherd that I don=E2=80=99t think it = is necessary >>>> to >>>>>> detail the history as much as done in section 4, e.g. rather = discuss >>>> the >>>>>> why than the actually comments by Lars and Tim. Also this section = is >>>>>> called =E2=80=9Edefinition=E2=80=9C but this background = information seems to go beyond >>>>>> just defining something. >>>>> [acm] >>>>> Ok the section is now titled, Definitions and Background, >>>>> and most of the details describing comments from Lars and Tim >>>>> are moved to an Appendix A. >>>>>=20 >>>>>>=20 >>>>>> Btw. Tianran, it would be nice if you could update your comments = in >> the >>>>>> shepherd write-up accordingly if they have been addressed or are >>>> obsolete. >>>>>> Thanks! >>>>> [acm] >>>>> Yes, please consider incorporating some of the details from >>>>> my e-mail last August, thanks! >>>>>=20 >>>>>>=20 >>>>>> 3) I don=E2=80=99t think there is any normative language require = in this doc. >>>> As >>>>>> you are =E2=80=9Ejust=E2=80=9C stating what has been normatively = defined in other >>>>>> documents, it is actually preferred to not re-state normatively. >>>>> [acm] >>>>> The Scope says: >>>>> The scope of this memo is to re-allocate well-known ports for = the >>>> UDP >>>>> Test protocols that compose necessary parts of their respective >>>>> standards track protocols, OWAMP and TWAMP, along with >>>> clarifications >>>>> of the complete protocol composition for the industry. >>>>>=20 >>>>> The controversy about TWAMP composition is partly what brought us = here! >>>>> We used the term REQUIRED in the Definitions to resolve the small >>>> ambiguity >>>>> created when OWAMP authors did not use normative language when >>>> describing >>>>> the protocols that comprise OWAMP, and TWAMP authors followed that >>>> choice of >>>>> wording (unfortunately). >>>>>=20 >>>>>>=20 >>>>>> 4) An update in the registry does not necessary mean an = =E2=80=9Eupdate=E2=80=9C of >> the >>>>>> RFCs that registered that ports in the first place, especially as >>>> rfc4656 >>>>>> doesn=E2=80=99t even mention the UDP port at all. Of course the = use of >> =E2=80=9Eupdate=E2=80=9C >>>> is >>>>>> very loosely defined and can be used if that is preferred but it = is >> not >>>>>> strictly necessary. Or is there another reason to update these = RFCs? >> If >>>>>> so, it should be clearly spelled out in the draft. >>>>> [acm] >>>>> Ok, drawing on the point from the Scope, and requirement Language >> above, >>>>> the Abstract now ends with: >>>>>=20 >>>>> The memo updates RFC 4656 and RFC 5357, in terms of the UDP = well-known >>>> port >>>>> assignments, and clarifies the complete OWAMP and TWAMP protocol >>>> composition >>>>> for the industry. >>>>>=20 >>>>>>=20 >>>>>> 5) Given that these entries are updates it would be nice to also = fill >>>> the >>>>>> missing information about contact information and assignee in the >>>>>> registry. Instruction for IANA would need to be added to the IANA >>>> section >>>>>> in this case. Assignee should be the IESG and contact the IETF = chair From nobody Wed Nov 14 12:44:11 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3823130F90; Wed, 14 Nov 2018 12:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Z4_3ZHX6M8dU; Wed, 14 Nov 2018 12:44:02 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66895130F3C; Wed, 14 Nov 2018 12:44:02 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 80F5CB8130E; Wed, 14 Nov 2018 12:43:39 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ippm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20181114204339.80F5CB8130E@rfc-editor.org> Date: Wed, 14 Nov 2018 12:43:39 -0800 (PST) Archived-At: Subject: [ippm] =?utf-8?q?RFC_8468_on_IPv4=2C_IPv6=2C_and_IPv4-IPv6_Coexi?= =?utf-8?q?stence=3A_Updates_for_the_IP_Performance_Metrics_=28IPPM=29_Fra?= =?utf-8?q?mework?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 14 Nov 2018 20:44:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8468 Title: IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework Author: A. Morton, J. Fabini, N. Elkins, M. Ackermann, V. Hegde Status: Informational Stream: IETF Date: November 2018 Mailbox: acmorton@att.com, joachim.fabini@tuwien.ac.at, nalini.elkins@insidethestack.com, mackermann@bcbsm.com, vinayakh@gmail.com Pages: 15 Characters: 35970 Updates: RFC 2330 I-D Tag: draft-ietf-ippm-2330-ipv6-06.txt URL: https://www.rfc-editor.org/info/rfc8468 DOI: 10.17487/RFC8468 This memo updates the IP Performance Metrics (IPPM) framework defined by RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets to include IPv6 packets, deprecates the definition of minimal IP packet, and augments distinguishing aspects, referred to as Type-P, for test packets in RFC 2330. This memo identifies that IPv4-IPv6 coexistence can challenge measurements within the scope of the IPPM framework. Example use cases include, but are not limited to, IPv4-IPv6 translation, NAT, and protocol encapsulation. IPv6 header compression and use of IPv6 over Low-Power Wireless Area Networks (6LoWPAN) are considered and excluded from the standard-formed packet evaluation. This document is a product of the IP Performance Measurement Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Nov 19 20:26:03 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D37EC128CFD; Mon, 19 Nov 2018 20:25:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <154268795484.26597.1121625255218544908@ietfa.amsl.com> Date: Mon, 19 Nov 2018 20:25:54 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 04:25:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Simple Two-way Active Measurement Protocol Authors : Greg Mirsky Guo Jun Henrik Nydell Richard Foote Filename : draft-ietf-ippm-stamp-04.txt Pages : 15 Date : 2018-11-19 Abstract: This document describes a Simple Two-way Active Measurement Protocol which enables the measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-stamp-04 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 19 20:40:56 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B09128CFD; Mon, 19 Nov 2018 20:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXj-xDE2-_gr; Mon, 19 Nov 2018 20:40:51 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 62663128766; Mon, 19 Nov 2018 20:40:51 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id v1-v6so487530ljd.0; Mon, 19 Nov 2018 20:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=bnR2vyxLb01rcmXU4YhY30jjcV+a+iGur6MIT8Lr5A4=; b=aCKq0IrOoEDc4/Ex9iQ6ZCF/rYfPr0BDcmKiF1vfaZKm6pfxKOPtWQrXI6A8nm4as9 s7jlV9UEAVMW/W/ZHUcG4brC6hFg/9Y8QgEDPcwIomDKZ4jypI2WRA2rsVBnLubc7iIs t8Ce/WWww21q4uT7KOjElPNAvW7xF+m0Fou0EpKQZTQZpgqlR0+ZrSz7CCq6Bsy0riM+ TGJeNLv7/n+P31TyUHenB/TPXWrbHlTPKCctilg18IduEGH1f6mXoUDB0i2hK39jkwS+ V61plfFLILG+Z0TGJS1DL+EmKN/WD2d5XqG2mmiZMJPbprodTHQcDEWZCONLR8IXhKJJ LyOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=bnR2vyxLb01rcmXU4YhY30jjcV+a+iGur6MIT8Lr5A4=; b=aKObTataAA3z/Tj+cGuRawpEO4ReLwnw63S36eeZiF6JHwt8osBLuHAPabsaI3mz6W z6oR/WBwjYKFZY7ELW84QDmgWGWwnjYzM52gChi3vEJTdWc9cvdJmiILWFHmqk7dMfIX ltF5esi9rfwVNBA7YZmLv7pz16PIyWODvoQm1woKQc/ZaPgBuFtDKN7b5EJ6RLlJx2+N oyQSPjZfqfqz5+NUuBkcxOCS8ILzVlbdHWv6TWoyP90QPOES0O/nlNiQJpLshnx8lOP2 jSlj4GOF0gatEQrSamNEa76QiLxKub8/A8lBwS2WjHiyB9a9HrNHzAtERVGUTLyYdIe0 AAJQ== X-Gm-Message-State: AA+aEWaEyI/4o1UM0f5W0AX6lYKWL2kiiRANPE/Mia4jP4uVJCJs104H 1L+cj3BTZMhErNbYCC0g0YBbaiL3ofnJfMqXUrb/wA== X-Google-Smtp-Source: AFSGD/W4AbiEvh4A6smsXyu5/X/KFpNkIukHBOolWFlGD+pyUhFXo77yuaspOxuOrCKrS3CFCqqYP8sAr9pth9AH9jQ= X-Received: by 2002:a2e:5109:: with SMTP id f9-v6mr289504ljb.52.1542688849142; Mon, 19 Nov 2018 20:40:49 -0800 (PST) MIME-Version: 1.0 References: <154268795484.26597.1121625255218544908@ietfa.amsl.com> In-Reply-To: <154268795484.26597.1121625255218544908@ietfa.amsl.com> From: Greg Mirsky Date: Mon, 19 Nov 2018 20:40:38 -0800 Message-ID: To: IETF IPPM WG , IPPM Chairs Content-Type: multipart/alternative; boundary="000000000000da2882057b113c60" Archived-At: Subject: [ippm] Fwd: I-D Action: draft-ietf-ippm-stamp-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2018 04:40:54 -0000 --000000000000da2882057b113c60 Content-Type: text/plain; charset="UTF-8" Dear All, this version includes the updates that address comments and suggestions made at the meeting in Bangkok by Ignacio and Brian (many, many thanks for the most helpful and pragmatic insights into the area of integrity and security). Much appreciate your review, comments. Dear WG Chairs, authors believe that the document is ready for the WGLC. We're committed to addressing all comments in a timely manner to progress it all the way. Regards, Greg ---------- Forwarded message --------- From: Date: Mon, Nov 19, 2018 at 8:26 PM Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-04.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Simple Two-way Active Measurement Protocol Authors : Greg Mirsky Guo Jun Henrik Nydell Richard Foote Filename : draft-ietf-ippm-stamp-04.txt Pages : 15 Date : 2018-11-19 Abstract: This document describes a Simple Two-way Active Measurement Protocol which enables the measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-stamp-04 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-04 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/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --000000000000da2882057b113c60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear All,
this version includes the updates that a= ddress comments and suggestions made at the meeting in Bangkok by Ignacio a= nd Brian (many, many thanks for the most helpful and pragmatic insights int= o the area of integrity and security).
Much appreciate your revie= w, comments.

Dear WG Chairs,
authors bel= ieve that the document is ready for the WGLC. We're committed to addres= sing all comments in a timely=C2=A0manner to progress it all the way.
=

Regards,
Greg

---------- Forwarded message ---------
From: = <internet-= drafts@ietf.org>
Date: Mon, Nov 19, 2018 at 8:26 PM
Sub= ject: [ippm] I-D Action: draft-ietf-ippm-stamp-04.txt
To: <i-d-announce@ietf.org>
Cc: <= ;ippm@ietf.org>


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IP Performance Measurement WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Simple Two-way Active Measurement Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Greg= Mirsky
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Guo Jun
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Henrik Nydell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Richard Foote
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ippm-stamp-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 15
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-11-19

Abstract:
=C2=A0 =C2=A0This document describes a Simple Two-way Active Measurement Pr= otocol
=C2=A0 =C2=A0which enables the measurement of both one-way and round-trip =C2=A0 =C2=A0performance metrics like delay, delay variation, and packet lo= ss.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i= ppm-stamp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ippm-stam= p-04
https://datatracker.ietf.org/doc/html/= draft-ietf-ippm-stamp-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-ippm-stamp-04


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--000000000000da2882057b113c60-- From nobody Tue Nov 20 17:28:37 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076BF126CC7; Tue, 20 Nov 2018 17:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=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 awqVSvBEcmB9; Tue, 20 Nov 2018 17:28:32 -0800 (PST) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 4C5BA12896A; Tue, 20 Nov 2018 17:28:32 -0800 (PST) Received: by mail-ot1-x332.google.com with SMTP id k98so3553725otk.3; Tue, 20 Nov 2018 17:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6/sCZCYtAyR6uM+GFSt24qk5TnN8L8VZEO94Px+svZk=; b=WPYmu0J/x1RcdbxMR1S2h5fJm0l1QJmf63V5q01yXHrm7E6o3MxH8NJr8EAX4w3VMt WkzsP44XqcE1FtFGrEAOjJeYgHtP9iUQSCMUBQ+YOfTxOVHwFvqxnXRYBcCtwyA+PngI qDqOZp5YfYDr/f7WBgUmXS/Jy8Z9i6VBd1TiGU5T4LgFxg1w+/Uv4bTR5vgNXzB5yTfL nwRpfIo4hv5GEBzeoFfRoYnq3ZlqjP6+LdCrRue4nf96BiAnwyf1y/fvMKLiwTrVEBC4 8VPOPP4ZZCzb4qhZ1EuyyUbxyTuBW6hFpkmkLCmjWIHECH3LCMM7tl7/IvTqfy6wclqH VTOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6/sCZCYtAyR6uM+GFSt24qk5TnN8L8VZEO94Px+svZk=; b=lCRjP1yIrAfIcMOZXFBY86aqFmWog9Eq5CW6E/BMwzVc2aWuDa7IX+2gPBIzy0d2Jr d+CqoofpCEm6CDBIVeqNAXnehLlFSxTX3D4nNCdCTIa3sfTCQZS+ao5SeaQR9iHniHbW II6thfPPYJHWKbe7mszVIAXVUS2+aTMOyFrVSNbTDT0aSdKFHlRfspEVWVR/OuXBnQrs FsJaeBx8V3s7/3aLHQXtn4gZDQtUiHDhSq0T70Tft+WHQ4fiH40wx5DXEzagvBtWwHb/ DBw+pvLtHH29004ZwMlna+8ZAENf4G5OtEufsuaxP5nRElRF72ojGruy+7pt0xs9sgqF GyIQ== X-Gm-Message-State: AA+aEWadj67hPhbZKqPY4TXq1j8PtcbOtWsDPTbxefQREBvjydqMcG1T pytCZ3tV56jSWaxsUrbxtQgYXe+wpCVi1aNQc4Q= X-Google-Smtp-Source: AFSGD/UlmCshQi9SXYQKDmDYLq1mrgPJtPdpUt35UJXZOyrsVWGKYKUYPE11vqn8SlnqpLBriKiF8dRA7XUt9VSDhMQ= X-Received: by 2002:a9d:7059:: with SMTP id x25mr2753180otj.35.1542763711278; Tue, 20 Nov 2018 17:28:31 -0800 (PST) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> In-Reply-To: <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> From: Mark Smith Date: Wed, 21 Nov 2018 12:28:04 +1100 Message-ID: To: Frank Brockners Cc: "C. M. Heard" , 6man WG , ippm@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] v6 option types for IOAM data fields X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 01:28:36 -0000 Hi Frank, Sorry not to get back to you sooner. On Mon, 12 Nov 2018 at 19:40, Frank Brockners (fbrockne) wrote: > > Hi Mark, > > thanks for the details. On your suggested solution for v6-in-v6: Let's as= sume a setup with source and destination host addresses (SA, DA), as well a= s an IOAM domain which has domain Edge-routers E(i). If I understand your s= uggestion correctly, then the ingress edge router with source address E-SA = would have /128 routes to all other domain Edge-routers E-DA(i). Close, but not quite. Rather than having a /128 per Edge-router, you would have a domain internal /128 per non-IOAM prefix announced by each Edge-edge router, 1:1. You do this so that you can have the same IGP metric for the domain internal /128 for each of the corresponding non-IOAM prefixes. That then means that the IOAM tunnelled packet should then follow the same path through the IOAM domain as the packet if it wasn't IOAM tunnelled. e.g. IOAM Router A has the following global prefixes configured on its interfaces, with the following IGP metrics: intf A: 2001:db8:0:1234::/64, metric 10 intf B: 2001:db8:0:2345::/64, metric 40 intf C: 2001:db8:0:4567::/64, metric 100 intf C: 2001:db8:0:abcd::/64, metric 150 intf D: 2001:db8:0:4321::/64, metric 10 Note that intf C has been configured with two different prefixes with different metrics. When these prefixes are configured on the interfaces, IOAM Router A would also automatically generate and announce into the IGP (or BGP with No Export community) matching IOAM internal /128s for each of them, using a ULA or other internal scope prefix (perhaps a special IANA reserved one for this IOAM purpose so routers could be factory configured with it) - I'll use fd04:3f29:de90::/48 for this example. The corresponding example IOAM /128s for IOAM Router A's interfaces would (could) be: intf A: fd04:3f29:de90::1234/128, metric 10 intf B: fd04:3f29:de90::2345/128, metric 40 intf C: fd04:3f29:de90::4567/128, metric 100 intf C: fd04:3f29:de90::abcd/128, metric 150 intf D: fd04:3f29:de90::4321/128, metric 10 (There may be better schemes to generate the matching global /64:IOAM /128 prefixes, its probably useful to encode some unique part of the global prefix in the corresponding /128.) So when a packet enters the IOAM domain at IOAM Router Z, with a destination address that falls within 2001:db8:0:1234::/64 (IOAM Router A's intf A: prefix), the outer tunnel header's DA would be the corresponding fd04:3f29:de90::1234/128 (IOAM Router A's intf A: OAM /128 prefix). This post-tunnel packet should follow the same path through the IOAM domain that a packet destined towards 2001:db8:0:1234::/64 should, from IOAM Router Z to IOAM Router A, because 2001:db8:0:1234::/64 and fd04:3f29:de90::1234/128 prefixes have both the same origin router and the same path metrics. If another packet enters the IOAM domain at IOAM Router Z, with a destination address that falls within 2001:db8:0:4567::/64 (IOAM Router A intf C's second prefix), then the outer packet tunnel DA would be the corresponding fd04:3f29:de90::4567/128 ((IOAM Router A intf C's second and matching IOAM /128 prefix). As the metric for 2001:db8:0:4567::/64 / fd04:3f29:de90::4567/128 on IOAM Router A is 100, the path through the IOAM domain between IOAM Router Z and IOAM Router A for this packet (IOAM tunnel/tagged or not) could be different to the one taken in the previous example. For completeness, for different IOAM Router Y, with a destination address that falls within 2001:db8:0:abcd::/64 (IOAM Router A intf C's second prefix), then the outer packet tunnel DA would be the corresponding fd04:3f29:de90::abcd/128 ((IOAM Router A intf C's second and matching IOAM /128 prefix). > For v6-in-v6, the ingress edge router would use its own source address as= the source address of the encapsulated packet, and it would use E-DA(j) as= the destination address, where E-DA(j) is the address that points to the s= ame outgoing link as the original (now inner) DA. > Now the question: Why would this choice of E-DA(j) ensure that the encaps= ulated packet leaves the IOAM domain at the same egress router, as would a = packet without the extra v6 header? Or in other terms, why would the encaps= ulated packet be forwarded the same way as a non-encapsulated packet in the= IOAM domain? > Hopefully the above example answers that. There are automatically generated IOAM tunnel end-point /128s per individual non-IOAM prefix, rather than per IOAM router, and as the IOAM /128s are per non-IOAM prefix, they can have and carry per prefix specific metric information that matches the corresponding non-IOAM prefix. This would the size of the IGP's route table, as there is now a matching IOAM /128 for each non-IOAM prefix. However, there is an optimisation opportunity. If two different non-IOAM prefixes have the same metric at the origin IOAM router (as intf A: 2001:db8:0:1234::/64, metric 10, and intf D: fd04:3f29:de90::4321/128, metric 10 do above on IOAM Router A), then a per-router IOAM /128 could be used instead, suppressing the generation of 1:1 per-prefix IOAM /128s when origin prefix metrics are the same. Regards, Mark. > Many thanks, Frank > > -----Original Message----- > From: Mark Smith > Sent: Donnerstag, 8. November 2018 12:40 > To: Frank Brockners (fbrockne) > Cc: C. M. Heard ; 6man WG ; ippm@ietf.org > Subject: Re: v6 option types for IOAM data fields > > Hi Frank, > > On Thu, 8 Nov 2018 at 19:36, Frank Brockners (fbrockne) wrote: > > > > Hi Mark, Mike, > > > > > > > > thanks for summarizing the concerns around leaked packets =E2=80=93 and= outlining an approach to mitigate those. There are a couple of other chall= enges we face. Unfortunately we did not get to a discussion in the 6man WG = meeting this time due to the limited time we had. The meeting slides https:= //datatracker.ietf.org/meeting/103/materials/slides-103-6man-in-situ-oam-ip= v6-options-00 provide a summary of concerns. > > > > > > > > In a nutshell: > > > > 1. Potential HbH ext header and IOAM option insertion and removal= by transit nodes (i.e. =E2=80=9Cen route=E2=80=9D) in a restricted adminis= trative domain. > > > > a) How do you deal with PMTU? =E2=80=93 Packet size changes might= exceed PMTU. > > > > b) Misleading ICMP errors confusing the source > > > > c) Possible leaks that affect the forwarding behavior and state o= f network elements outside the domain. > > > > Yes, all of the above, good summary. > > An additional one is that if you were are receiver of this outside of the= domain because it as leaked, at the destination, after the packet as trave= rsed a number of ASes over the Internet, there is nothing to identify the d= evice/AS that inserted the EH. Very time consuming to troubleshoot who inse= rted the EH but didn't remove it (you have to walk the AS path, contacting = each operator, asking them to verify their config, get packet captures etc.= ), and all the while you may have a number of angry customers/end-users. > > > 2. Incremental Trace IOAM HbH Option =E2=80=93 which is to suppor= t a hardware-friendly implementation: Changes Option Data Len en-route. > > > > a) Dealing with PMTU=E2=80=93 Packet size changes can exceed PMTU= ; see above > > > > 3. Clarify applicability statement and scope > > > > > > > > While 3. is something that is in the works, there are no easy answers t= o 1. and 2. Considerations: > > > > > > > > On 1. Supporting HbH ext header and option insertion/removal in > > transit. A couple of solution approaches=E2=80=A6 > > > > 1. Fix PMTU and offset for packet size change in PMTU discovery -= https://tools.ietf.org/html/draft-troan-6man-pmtu-solution-space-00 > > Hope that we can make progress towards a solution tomorrow=E2=80=A6 > > > > 2. IP-in-IP with IOAM extension header in the *inner* packet. > > New IPv6 packet is created with encapsulating node as source and the > > original destination as the destination (this is slightly different tha= n what you, Mark, suggest =E2=80=93 because we=E2=80=99d like to keep the f= orwarding path the same. Tunneling with ULA would not get us there; the sli= des above have a diagram that depicts the potential encap): > > > > a) Payload of this packet is the original IPv6 packet along with = an extension header inserted inside. > > > > b) The original packet is restored by removing the outer IPv6 head= er and the inner extension header by a node at the domain boundary. > > > > c) Caveats: > > > > i. = Modified packet may still leak =E2=80=93 but will only confuse the destinat= ion node. The dest node will likely send an ICMP back to the encap node, wh= ich gets the encap node an understanding that something is going wrong. > > > > This is certainly better, because the source address identifies the devic= e that inserted the EH of the packet that leaked to where ever it leaked to= . > > What the source address should be is an interesting question. > > If it is a global/public source address, then anybody who receives the pa= cket leaked with the EH can identify who inserted it and therefore who didn= 't remove it. > > OTOH, if it is a private/local ULA Source Address, then BCP38 source addr= ess filters would cause the invalid leaked packet to be dropped sooner, rat= her than being forwarded onto the final destination. Total packet loss of O= AM encapsulated packets would make the failure obvious to the OAM domain op= erator. Slight drawback is BCP38 filters haven't been universally implement= ed across the Internet. > > I think I like the latter better because commonly it would localise the s= ymptoms of the failure to remove the EH to the domain that inserted it, rat= her than having to have an external party get involved in troubleshooting. > > > > > ii. E= CMP computation needs to be reworked. > > > > iii. Co= mplex/costly implementation in HW & SW =E2=80=93 IOAM-capable nodes need to= hunt for the IOAM data fields in the inner packet. > > > > Yes, the implementation complexity of insertion is another concern - enca= psulation is the most common and simplest cross layer forwarding function p= erformed and there's decades of history in optimising it. > > The root cause of both the possible leak and the risk that the inserted E= H will reach the final packet destination is that the Dest. > Addr. of the packet with the inserted EH is both valid outside of the dom= ain, and valid all the way across the Internet to the final and actual orig= inal packet destination. That creates a "default permit" if a packet leaks = with the inserted EH rather than a far better "default deny" in this failur= e situation. > > In this OAM case, it seems to me the ideal and the requirements would be: > > - have the packet with the added OAM information follow the same path wit= hin the domain that the same packet without the OAM information would follo= w within the domain > > - have the Dest. Addr. of the packet with the added OAM information only = be valid within the OAM domain i.e. an "interior DA", so that if through fa= ilure the packet leaks, it isn't a valid DA on the Internet and will be dro= pped by, if nothing else earlier, an Internet router with a default free ro= ute table. > > - encapsulate rather than insert, because encapsulation would be simpler,= and is the traditional way of adding information to PDUs across many decad= es and many protocols (I can only think of VLAN ID insertion as the only ex= isting counter example, and according to Radia Perlman in her book, that is= only because at the time they weren't sure if all NICs commonly available = could successfully encapsulate a full sized ethernet frame inside another o= ne). > > In other words, preserve the original IPv6 packet, add an OAM header in f= ront of it, then encapsulate it in another header to forward within and acr= oss the OAM domain. > > Bog standard IGP/LDP MPLS could achieve those requirements, with the OAM = header inserted after the final MPLS tag and before the IPv6 header. The MP= LS/OAM/IPv6 packet follows an LSP across the domain that matches the path t= hat the IPv6 packet without MPLS would follow across the domain. In that sc= enario, the MPLS LSP across the domain is the "interior DA" that isn't vali= d outside of the OAM domain, because MPLS wouldn't (normally) be valid outs= ide of the OAM domain (i.e. OAM domain is MPLS domain 1:1). If MPLS fails t= o be removed at the OAM domain egress edge, the packet is dropped immediate= ly, so a fail safe, localised to the OAM domain. > > For an IPv6-in-IPv6 scenario: > > - for each OAM domain interior IPv6 routes/prefixes used by hosts (i.e. h= osts have addresses from these prefixes), automatically create a matching i= nterior OAM route/prefix (maybe just a /128), 1:1, with the interior OAM ro= ute/prefix originated by the same router(s) where the interior IPv6 routes/= prefixes are created/originated. The interior OAM routes come from ULA spac= e or perhaps a new designated and reserved private/local OAM address space = for this purpose. > > When a end host originated packet ingresses the OAM domain edge, the DA a= ddress of the packet is looked up to find the 1:1 matching internal OAM rou= te/prefix/address. This internal OAM route/prefix/address is used as the DA= for the outer IPv6 header, outer header SA is the OAM address of the OAM i= ngress device, an OAM header follows, and then the original, inner IPv6 pac= ket follows without modification. > > As the OAM route/prefix/address is originated at the same place as the OA= M domain interior IPv6 route/prefix, the path the now IPv6-in-IPv6 packet f= ollows through the OAM domain should be the same as that which the original= , now inner packet would have followed with its DA. In a sense this OAM rou= te/prefix/address is an internal routeable index or proxy for the inner pac= ket destination prefix. > > - for exterior routes, IPv6-in-IPv6 tunnelling too between BGP border rou= ters per RFC1772, "A.2.3 Encapsulation", with the addition of the OAM heade= r between the new outer IPv6 header and the inner original > IPv6 packet, and OAM local addresses for the tunnel end points. This avoi= ds having to create 1:1 matching internal OAM route/prefix/address for each= exterior route. > > (And perhaps a somewhat radical idea for reducing tunnelling overhead. > All of this tunnelling stuff already exists for IPv4; and it is sunk cost= . Would there be much harm in using IPv4 as the interior outer tunnelling p= rotocol for this IPv6 traffic with the added OAM information? I'd much rath= er keep running an IPv4 OAM island to carry > IPv6 than any splitting apart of IPv6 packets to insert EHs in them > ...) > > > 3. No support of IOAM in transit network. Support only source ini= tiated IOAM tracing, proof of transit.. > > Caveat: Limits usage of IOAM significantly. > > > > > > On 2. Incremental Trace IOAM HbH Option > > > > 1. Use PMTU to determine max possible Incremental Trace IOAM Opti= on length > > > > 2. Do not support Incremental Trace IOAM Option in IPv6. > > > > > > Could what I've suggested above solve those? I think the use of tunnellin= g/encapsulation supports a transit OAM scenario. > > Regards, > Mark. > > > > > > While there isn=E2=80=99t an easy answer, IMHO we should still try to f= ind a workable and implementable solution. I sometimes compare the situatio= n with the road network: What we have today is a network of gravel roads (I= nternet with often poor ext header processing) and cars are built to cope w= ith gravel roads. Now faster and comfy cars become available, though they o= nly work on tared/concrete roads (specific administrative domains). If you = try to drive these new cars on gravel roads they break and the wrecks jam t= he roads=E2=80=A6, still we probably want to allow folks to buy and use the= fast & comfy cars, because they will also push for better roads as well (= do proper ext header processing). > > > > > > > > Thoughts? > > > > > > > > Thanks, Frank > > > > > > > > > > > > From: Mark Smith > > Sent: Dienstag, 30. Oktober 2018 05:26 > > To: Frank Brockners (fbrockne) > > Cc: C. M. Heard ; 6man WG ; > > ippm@ietf.org > > Subject: Re: v6 option types for IOAM data fields > > > > > > > > > > Hi Frank, > > > > > > > > On Tue., 30 Oct. 2018, 05:36 Frank Brockners (fbrockne), wrote: > > > > Thanks Mike. On the scope of an IOAM deployment: > > draft-ietf-ippm-ioam-data-04 clarifies in section 3 that IOAM is a doma= in focused feature, i.e. not expected to be deployed on the open Internet. > > > > > > > > That still violates RFC 8200, there are no exceptions for "closed" doma= ins. > > > > > > > > From section 3: > > > > > > > > "Designers of > > > > carrier protocols for IOAM must specify mechanisms to ensure that > > > > IOAM 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." > > > > > > > > Neither the designers or the operators can ensure this IOAM information= won't leak. > > > > > > > > Possible reasons it can leak: > > > > > > > > - operator configuration error - e.g. forgetting to configure the domai= n boundary (e.g. router with multiple domain exit interfaces, forgetting to= add that option on one of them), or misconfiguring it. > > > > > > > > - partial device failure - the device still forwards packets, but > > ceases to remove this information due to a hardware fault that has > > appeared > > > > > > > > - vendor implementation bugs that fails to remove the information. > > > > > > > > Any or all of these can occur, and as it is on egress, the consequences= may not be visible to the domain network operator, because network operato= rs rarely inspect packets after they've left their network. Once a packet i= s sent onto somebody else, it is assumed to have been sent without faults. > > > > > > > > There are many instances of leaks at the boundary of what are supposed > > to be closed domains, such as packets containing RFC1918 private > > addresses (in packet headers themselves, or in DNS packets - such a > > big problem that www.as112.net was created), and route leaks e.g. > > https://bgpmon.net/how-the-internet-in-australia-went-down-under/ > > > > > > > > As operators usually have only one device at the edge of the domain, th= at would be performing the domain boundary function, that device becomes a = single point of failure. Enforcement is therefore quite fragile. A domain b= oundary enforced by two domain edge devices in-line would increase robustne= ss, however I'd think that would be rarely deployed, because we haven't see= n that commonly with IPv4 NAT. > > > > > > > > The only way for an operator to ensure these leaks don't and never occu= r is for the domain to literally not be physically connected to the Interne= t i.e. the domain is air gapped from the Internet. If there is a link betwe= en the domain and the Internet that can carry IP packets, then there is alw= ays a possibility that information can leak from the domain. > > > > > > > > So accepting that leaks can always occur, a far more robust option is t= o leave the original packet alone entirely, and encapsulate it in a domain = local IPv6 header (i.e RFC2473, section 3.1) with domain local limited addr= esses (i.e. ULA addresses) and the additional EH. > > > > > > > > That still doesn't ensure that packet won't leak outside the domain, be= cause those packets will follow a default route, however as the packet's ad= dressing is invalid outside of the domain, that packet will be dropped once= it reaches either an invalid Internet address filter, or a default free In= ternet router. The packet with the failed-to-be-removed outer ULA IPv6 head= er will never reach the destination address of the inner packet, because th= e DA of the inner packet is in the ULA IPv6 packet's payload. > > > > > > > > Failure of the mechanism would be much more obvious, localised to the d= omain implementing the mechanism (rather than being externalised to somebod= y else's domain/network), and absolute, because the failure mode is packets= being entirely discarded. > > > > > > > > Regards, > > > > Mark. > > > > > > > > > > > > > > Frank > > > > -----Original Message----- > > From: C. M. Heard > > Sent: Montag, 29. Oktober 2018 16:03 > > To: 6man ; IPPM > > Cc: Frank Brockners (fbrockne) > > Subject: Re: v6 option types for IOAM data fields > > > > On Thu, 25 Oct 2018 15:06:57 +0000 Frank Brockners (fbrockne) wrote: > > > Quick heads up: In the 6MAN meeting in BKK, we=E2=80=99ll review > > > draft-ioametal-ippm-6man-ioam-ipv6-options-01 =E2=80=93 which request= s 2 > > > option types from the DO/HbyH options sub-registry. > > > > > > While the bulk of the IOAM work is progressed in the IPPM WG, we=E2= =80=99d > > > greatly appreciate your feedback on > > > draft-ioametal-ippm-6man-ioam-ipv6-options-01, > > > which defines how IOAM data fields are carried using v6 extension hea= ders. > > > Cc=E2=80=99ing the IPPM WG as well, to keep everyone on the same page= . > > > > I have two brief comments on this work. > > > > First, I see that the Incremental Tracing Option changes length in tran= sit. > > It is not appropriate for it to be carried in an IPv6 option intended f= or use on the open Internet, for exactly the same reason that insertion of = extension headers by intermediate nodes is not allowed on the open Internet= . > > > > Second, I see that two IPv6 option code points are requested, one with = the "chg" flag set, the other with the "chg" flag clear. While there is no = harm in this, it is not strictly necessary; the only real purpose of this f= lag is to determine whether the option data is or is not included in the Au= thentication Header Integrity Check Value computation. > > > > Mike Heard > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- From nobody Mon Nov 26 10:16:30 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF23130FFC; Mon, 26 Nov 2018 10:16:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Linda Dunbar To: Cc: draft-ietf-ippm-port-twamp-test.all@ietf.org, ietf@ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154325617182.8377.125843704037564868@ietfa.amsl.com> Date: Mon, 26 Nov 2018 10:16:11 -0800 Archived-At: Subject: [ippm] Genart last call review of draft-ietf-ippm-port-twamp-test-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 18:16:17 -0000 Reviewer: Linda Dunbar Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ippm-port-twamp-test-?? Reviewer: Linda Dunbar Review Date: 2018-11-26 IETF LC End Date: 2018-11-26 IESG Telechat date: 2018-12-06 Summary: The draft briefs how TWAMP&OWAMP work and assigned a fixed UDP ports for TWAMP & OWAMP Test messages Major issues: Section 5.1 states that the UDP port used for TEST are negotiated, whereas the IANA section of this document states the explicit fixed UDP port . Does it mean the negotiation is no longer needed? Than all TEST messages are on the same UDP ports? Makings it not effective in making test messages traversing different ECMP paths. Why? “ Section 3.5 [RFC5357] describes the detailed process of negotiating the Receiver Port number, on which the TWAMP Session-Reflector will send and receive TWAMP-Test packets. The Control-Client, acting on behalf of the Session-Sender, proposes the Receiver port number from the Dynamic Port range [RFC6335]: "The Receiver Port is the desired UDP port to which TWAMP-Test packets will be sent by the Session-Sender (the port where the Session-Reflector is asked to receive test packets). The Receiver Port is also the UDP port from which TWAMP-Test packets will be sent by the Session-Reflector (the Session-Reflector will use the same UDP port to send and receive packets)." Minor issues: Does the following sentence mean the UDP port was already assigned to to OWAMP & TWAMP control? “ Since OWAMP-Control and TWAMP-Control require TCP transport, they cannot make use of the UDP ports which were originally assigned. However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP transport.” The text then states that “Use of this UDP port is OPTIONAL in standards-track OWAMP and TWAMP. “ If not using UDP ports, does it mean that the TCP ports are uses for OWAMP-TEST & TWAMP-TEST? Nits/editorial comments: the head note has “WAMP W-K UDP Ports” as the title which is different from the draft title. P.s. what does W-K mean? From nobody Mon Nov 26 13:54:28 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A4E130F36; Mon, 26 Nov 2018 13:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 qdP7Fre_jCPc; Mon, 26 Nov 2018 13:54:25 -0800 (PST) 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 D436E130E54; Mon, 26 Nov 2018 13:54:24 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wAQLkJUD043201; Mon, 26 Nov 2018 16:54:20 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049463.ppops.net-00191d01. with ESMTP id 2p0r6ya2xt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Nov 2018 16:54:20 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAQLsJMt047166; Mon, 26 Nov 2018 15:54:19 -0600 Received: from zlp30497.vci.att.com (zlp30497.vci.att.com [135.46.181.156]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAQLsF6N047101; Mon, 26 Nov 2018 15:54:15 -0600 Received: from zlp30497.vci.att.com (zlp30497.vci.att.com [127.0.0.1]) by zlp30497.vci.att.com (Service) with ESMTP id 76BC140141EB; Mon, 26 Nov 2018 21:54:15 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30497.vci.att.com (Service) with ESMTP id 5487540141E9; Mon, 26 Nov 2018 21:54:15 +0000 (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 wAQLsFwL023785; Mon, 26 Nov 2018 15:54:15 -0600 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 wAQLs442023150; Mon, 26 Nov 2018 15:54:05 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-blue.research.att.com (Postfix) with ESMTP id 8FEE7F1F2B; Mon, 26 Nov 2018 16:54:04 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Mon, 26 Nov 2018 16:53:09 -0500 From: "MORTON, ALFRED C (AL)" To: Linda Dunbar , "gen-art@ietf.org" CC: "draft-ietf-ippm-port-twamp-test.all@ietf.org" , "ietf@ietf.org" , "ippm@ietf.org" Thread-Topic: Genart last call review of draft-ietf-ippm-port-twamp-test-03 Thread-Index: AQHUhbQMyemhs/RRPk6ubhizAP935qVilRIQ Date: Mon, 26 Nov 2018 21:54:04 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557E4F1E@njmtexg5.research.att.com> References: <154325617182.8377.125843704037564868@ietfa.amsl.com> In-Reply-To: <154325617182.8377.125843704037564868@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [212.147.28.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-26_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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811260184 Archived-At: Subject: Re: [ippm] Genart last call review of draft-ietf-ippm-port-twamp-test-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 21:54:27 -0000 SGkgTGluZGEsIA0KdGhhbmtzIGZvciB5b3VyIGdlbi1hcnQgcmV2aWV3LCBjb25jaXNlIHJlcGxp ZXMgYmVsb3csDQpBbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog TGluZGEgRHVuYmFyIFttYWlsdG86TGluZGEuZHVuYmFyQGh1YXdlaS5jb21dDQo+IFNlbnQ6IE1v bmRheSwgTm92ZW1iZXIgMjYsIDIwMTggMToxNiBQTQ0KPiBUbzogZ2VuLWFydEBpZXRmLm9yZw0K PiBDYzogZHJhZnQtaWV0Zi1pcHBtLXBvcnQtdHdhbXAtdGVzdC5hbGxAaWV0Zi5vcmc7IGlldGZA aWV0Zi5vcmc7DQo+IGlwcG1AaWV0Zi5vcmcNCj4gU3ViamVjdDogR2VuYXJ0IGxhc3QgY2FsbCBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1pcHBtLXBvcnQtdHdhbXAtdGVzdC0wMw0KPiANCj4gUmV2aWV3 ZXI6IExpbmRhIER1bmJhcg0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KPiAN Cj4gSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhl IEdlbmVyYWwgQXJlYQ0KPiBSZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBk b2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkDQo+IGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFp ci4gIFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0DQo+IGxpa2UgYW55IG90aGVyIGxh c3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2Vl IHRoZSBGQVEgYXQNCj4gDQo+IDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtDQo+IDNBX190cmFjLmlldGYub3JnX3RyYWNfZ2VuX3dpa2lfR2VuQXJ0ZmFx JmQ9RHdJRGFRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNTdThrVElsdFZ5RDFv TDcyY0J3Jm09LQ0KPiBJOGNxb2RhejB1X2dGN3Y2bGF4MzFLYk5EZzdJR1phWUJUSXB1Q3VWT00m cz16dE1vS1dqRm5tRWJuSlQyV0lPempXWFZOM3Rsdw0KPiBJdm15OHA5YktPcHl6WSZlPT4uDQo+ IA0KPiBEb2N1bWVudDogZHJhZnQtaWV0Zi1pcHBtLXBvcnQtdHdhbXAtdGVzdC0/Pw0KPiBSZXZp ZXdlcjogTGluZGEgRHVuYmFyDQo+IFJldmlldyBEYXRlOiAyMDE4LTExLTI2DQo+IElFVEYgTEMg RW5kIERhdGU6IDIwMTgtMTEtMjYNCj4gSUVTRyBUZWxlY2hhdCBkYXRlOiAyMDE4LTEyLTA2DQo+ IA0KPiBTdW1tYXJ5Og0KPiBUaGUgZHJhZnQgYnJpZWZzIGhvdyBUV0FNUCZPV0FNUCB3b3JrIGFu ZCBhc3NpZ25lZCBhIGZpeGVkIFVEUCBwb3J0cyBmb3INCj4gVFdBTVANCj4gJiBPV0FNUCBUZXN0 IG1lc3NhZ2VzDQpbYWNtXSANCk5vdCBxdWl0ZSByaWdodCwgdGhlIGFic3RyYWN0IHNheXM6DQoN CiAgIFRoaXMgbWVtbyBleHBsYWlucyB0aGUgbW90aXZhdGlvbiBhbmQgZGVzY3JpYmVzIHRoZSAq cmUtYXNzaWdubWVudCogb2YNCiAgIHdlbGwta25vd24gcG9ydHMgZm9yIHRoZSBPV0FNUCBhbmQg VFdBTVAgcHJvdG9jb2xzIGZvciBjb250cm9sIGFuZA0KICAgbWVhc3VyZW1lbnQsLi4uDQo+IA0K PiBNYWpvciBpc3N1ZXM6DQo+IFNlY3Rpb24gNS4xIHN0YXRlcyB0aGF0IHRoZSBVRFAgcG9ydCB1 c2VkIGZvciBURVNUIGFyZSBuZWdvdGlhdGVkLCB3aGVyZWFzDQo+IHRoZQ0KPiBJQU5BIHNlY3Rp b24gb2YgdGhpcyBkb2N1bWVudCBzdGF0ZXMgdGhlIGV4cGxpY2l0IGZpeGVkIFVEUCBwb3J0IC4g IERvZXMNCj4gaXQNCj4gbWVhbiB0aGUgbmVnb3RpYXRpb24gaXMgbm8gbG9uZ2VyIG5lZWRlZD8g DQpbYWNtXSANCk5vLCB3ZSBhcmUgbWFraW5nIGEgdGhlIHdlbGwta25vd24gcG9ydCBhdmFpbGFi bGUNCmZvciBjYXNlcyB3aGVyZSB0aGUgVFdBTVAgc3lzdGVtcyBkb24ndCB3aXNoIHRvIG5lZ290 aWF0ZS4NCiAgDQoNCj4gVGhhbiBhbGwgVEVTVCBtZXNzYWdlcyBhcmUgb24NCj4gdGhlDQo+IHNh bWUgVURQIHBvcnRzPyBNYWtpbmdzIGl0IG5vdCBlZmZlY3RpdmUgaW4gbWFraW5nIHRlc3QgbWVz c2FnZXMNCj4gdHJhdmVyc2luZw0KPiBkaWZmZXJlbnQgRUNNUCBwYXRocy4gV2h5Pw0KW2FjbV0g DQpObywgZHluYW1pYyByYW5nZSBzdGlsbCBhbGxvd2VkLA0KYW5kIEVDTVAgaGFzaCBjYWxjdWxh dGlvbnMgYXJlIHVuYWZmZWN0ZWQuDQoNCj4gDQo+ICDigJwgU2VjdGlvbiAzLjUgW1JGQzUzNTdd IGRlc2NyaWJlcyB0aGUgZGV0YWlsZWQgcHJvY2VzcyBvZiBuZWdvdGlhdGluZw0KPiAgICB0aGUg UmVjZWl2ZXIgUG9ydCBudW1iZXIsIG9uIHdoaWNoIHRoZSBUV0FNUCBTZXNzaW9uLVJlZmxlY3Rv ciB3aWxsDQo+ICAgIHNlbmQgYW5kIHJlY2VpdmUgVFdBTVAtVGVzdCBwYWNrZXRzLiAgVGhlIENv bnRyb2wtQ2xpZW50LCBhY3Rpbmcgb24NCj4gICAgYmVoYWxmIG9mIHRoZSBTZXNzaW9uLVNlbmRl ciwgcHJvcG9zZXMgdGhlIFJlY2VpdmVyIHBvcnQgbnVtYmVyIGZyb20NCj4gICAgdGhlIER5bmFt aWMgUG9ydCByYW5nZSBbUkZDNjMzNV06DQo+ICAgICAgICJUaGUgUmVjZWl2ZXIgUG9ydCBpcyB0 aGUgZGVzaXJlZCBVRFAgcG9ydCB0byB3aGljaCBUV0FNUC1UZXN0DQo+ICAgICAgIHBhY2tldHMg d2lsbCBiZSBzZW50IGJ5IHRoZSBTZXNzaW9uLVNlbmRlciAodGhlIHBvcnQgd2hlcmUgdGhlDQo+ ICAgICAgIFNlc3Npb24tUmVmbGVjdG9yIGlzIGFza2VkIHRvIHJlY2VpdmUgdGVzdCBwYWNrZXRz KS4gIFRoZSBSZWNlaXZlcg0KPiBQb3J0DQo+ICAgICAgIGlzIGFsc28gdGhlIFVEUCBwb3J0IGZy b20gd2hpY2ggVFdBTVAtVGVzdCBwYWNrZXRzIHdpbGwgYmUgc2VudCBieQ0KPiB0aGUNCj4gICAg ICAgU2Vzc2lvbi1SZWZsZWN0b3IgKHRoZSBTZXNzaW9uLVJlZmxlY3RvciB3aWxsIHVzZSB0aGUg c2FtZSBVRFAgcG9ydA0KPiB0bw0KPiAgICAgICBzZW5kIGFuZCByZWNlaXZlIHBhY2tldHMpLiIN Cj4gDQo+IE1pbm9yIGlzc3VlczoNCj4gDQo+IERvZXMgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBt ZWFuIHRoZSBVRFAgcG9ydCB3YXMgYWxyZWFkeSBhc3NpZ25lZCB0byB0bw0KPiBPV0FNUA0KPiAm IFRXQU1QIGNvbnRyb2w/DQpbYWNtXSANClllcywgdGhhdCdzIHdoeSB0aGUgQWJzdHJhY3Qgc2F5 cyAqcmUtYXNzaWdubWVudCouDQoNCj4gDQo+ICDigJwgIFNpbmNlIE9XQU1QLUNvbnRyb2wgYW5k IFRXQU1QLUNvbnRyb2wgcmVxdWlyZSBUQ1AgdHJhbnNwb3J0LCB0aGV5DQo+ICAgIGNhbm5vdCBt YWtlIHVzZSBvZiB0aGUgVURQIHBvcnRzIHdoaWNoIHdlcmUgb3JpZ2luYWxseSBhc3NpZ25lZC4N Cj4gICAgSG93ZXZlciwgdGVzdCBzZXNzaW9ucyB1c2luZyBPV0FNUC1UZXN0IG9yIFRXQU1QLVRl c3Qgb3BlcmF0ZSBvbiBVRFANCj4gICAgdHJhbnNwb3J0LuKAnQ0KPiANCj4gVGhlIHRleHQgdGhl biBzdGF0ZXMgdGhhdCDigJxVc2Ugb2YgdGhpcyBVRFAgcG9ydCBpcyBPUFRJT05BTCBpbiBzdGFu ZGFyZHMtDQo+IHRyYWNrDQo+ICAgIE9XQU1QIGFuZCBUV0FNUC4g4oCcDQpbYWNtXSANCkV4YWN0 bHksIHRoZSBEeW5hbWljIHJhbmdlIGlzIHN0aWxsIGF2YWlsYWJsZSwgYWNjb3JkaW5nIHRvIFJG QzUzNTcuDQoNCg0KPiBJZiBub3QgdXNpbmcgVURQIHBvcnRzLCBkb2VzIGl0IG1lYW4gdGhhdCB0 aGUgVENQIHBvcnRzIGFyZSB1c2VzIGZvcg0KPiBPV0FNUC1URVNUDQo+ICYgVFdBTVAtVEVTVD8N ClthY21dIA0KTm8sIG5ldmVyLg0KDQo+IA0KPiBOaXRzL2VkaXRvcmlhbCBjb21tZW50czoNCj4g DQo+IHRoZSBoZWFkIG5vdGUgaGFzIOKAnFdBTVAgVy1LIFVEUCBQb3J0c+KAnSBhcyB0aGUgdGl0 bGUgd2hpY2ggaXMgZGlmZmVyZW50DQpbYWNtXSANCml0IHNheXMgKldBTVAsIG1lYW5pbmcgZWl0 aGVyIE9XQU1QIG9yIFRXQU1QLg0KDQo+IGZyb20gdGhlDQo+IGRyYWZ0IHRpdGxlLiBQLnMuIHdo YXQgZG9lcyBXLUsgbWVhbj8NClthY21dIA0KVy1LID09IFdlbGwtS25vd24gDQoNCg== From nobody Mon Nov 26 20:11:19 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1445D130E25 for ; Mon, 26 Nov 2018 20:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 dTkDznZJnCd6 for ; Mon, 26 Nov 2018 20:11:15 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 BC7F6127333 for ; Mon, 26 Nov 2018 20:11:15 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id RUMCgSvnvVWHQRUiQg1rlg; Tue, 27 Nov 2018 04:11:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1543291874; bh=EPWUGC6AZMNofIl8ZaAorKgxKlihNoVUGCqVNcMlXnQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=NzIZYPu3D4SrSvRGuzP9oEOFTKacLy7Hu3n/aeD73AsB8dBNMFia4uhqOKYhpde/w TsbhtY4j8gG/tBkmu+LqfMLz7AUhlhZT891EKG1aUUGlnhSRfJIS0kTuQqa+VDyuuR VMMlKndDHRW1O+lrxq+QXvNZj/1DkZufBsHvX7AcE+XyDqgB89EFLOOkoxfvYCCaAN gCmVYJegWmJK12YFnKuryYd2piLRHPiCgTzqLEREpxPhnp1YN6YdlsOHXwhrwIOwUJ xgqhEexIMUCzhYZrq2i2/am/QOEbJczySRM/o/xveqWYzbSHkJhNEPBzvOf1f7fBML EsV7YLPakhQ5A== Received: from hobgoblin.ariadne.com ([24.91.37.100]) by resomta-ch2-01v.sys.comcast.net with ESMTPA id RUiPgClgj5r3BRUiQgSDif; Tue, 27 Nov 2018 04:11:14 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id wAR4BCY7019091; Mon, 26 Nov 2018 23:11:12 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id wAR4BClD019088; Mon, 26 Nov 2018 23:11:12 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: ippm@ietf.org Cc: draft-ietf-ippm-port-twamp-test.all@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 26 Nov 2018 23:11:11 -0500 Message-ID: <87pnurkvmo.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfKwHgN9wWpt8Hh7UK6/kCkcceyCtVvCqyGioUf/17rdXAaVS0CVgpS+zs05bAJZeahMAEpoZ3Tx5CTUVHGmma7y4cE/Ekm9oqktdQh1+iY9Pz4G+xfQq hMvJJ0+O2LAtMFJQeTQ5fcN7POT67akWoQWQpEMDdyW/JukFTQYzeeW6gZJTlf1PtGFgA3mBRC7sLazsxMacO/Jy24dLKJbtFl+L44bjCUJTaoW743oYW7Pr Archived-At: Subject: [ippm] Some nits for draft-ietf-ippm-port-twamp-test-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Nov 2018 04:11:18 -0000 Here are a couple of nits in draft-ietf-ippm-port-twamp-test-03: 1. The essence of the I-D is in section 5: This memo requests re-assignment of the UDP well-known port from the Control protocol to the Test protocol (see the IANA Considerations Section 7). Despite the simplicity of this, I didn't understand that was what the I-D did after reading either the Abstract or the Introduction (section 1). Perhaps using this sentence in both places would clarify the situation: This memo requests re-assignment of the UDP well-known ports from the Control protocols of OWAMP and TWAMP to the corresponding Test protocols. 2. Sections 5.1 and 5.2 contain the following odd uses of "Section 7": A Control Client that supports use of the allocated TWAMP-Test Receiver Port Section 7 MAY request to use that port number in the Request-TW-Session Command. As described above, an OWAMP Control Client that supports use of the allocated OWAMP-Test Receiver Port Section 7 MAY request to use that port number in the Request-Session Command. Dale From nobody Mon Nov 26 21:00:45 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07ACA130E3C for ; Mon, 26 Nov 2018 21:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 WFXOisT-BEkA for ; Mon, 26 Nov 2018 21:00:42 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 AAE1B130E1C for ; Mon, 26 Nov 2018 21:00:42 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-02v.sys.comcast.net with ESMTP id RVRBgsnj9ZH9kRVUHgUsvJ; Tue, 27 Nov 2018 05:00:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1543294841; bh=GbvAqSyScia5O7PsRiCEwqJWjT9l+C1Iz1NXvhOUnSQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=hdMS1A2cgOVbW0PLjC2X3Ik0tbFlQTlA9pQxIMHUUd96csO7ySUTQiJ3bLDNNNkDq YNYoyAG3lXNUbiGry6XyAH/LlhvSMCvgTtU6GUkpbs6y/ZQ5xEOtW5XWfj6kdP/ZrO PbM427ykqDly9TeRgkJJDkjYB4+Mi91Q+SPegBev/kkyq+ILRhwz9LoAsEZE5bXp27 P2cDMSm0sxYjCpTfHnY6b3QD4Md2eyUof/Ifz7r2esjvdgHvgiG6b3yr5AJYkn2jES DHp3nrUJvPWU3I6NeeTuZiVkjmefqTF4LOW8B3/qdR7uKA6Uoivn+5a3vJkMTf1/Al M/CjpqxnNTrPg== Received: from hobgoblin.ariadne.com ([24.91.37.100]) by resomta-ch2-20v.sys.comcast.net with ESMTPA id RVUGg5M22858ERVUHgm26W; Tue, 27 Nov 2018 05:00:41 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id wAR50d9q025029; Tue, 27 Nov 2018 00:00:39 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id wAR50d2R025026; Tue, 27 Nov 2018 00:00:39 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: ippm@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 27 Nov 2018 00:00:39 -0500 Message-ID: <875zwjktc8.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJu7v/Rd2GfMOUECsmQD1aR+NBzJr0R3ln7bZZdWX2AJ5d88SVI4Sey5hIBBeIBH4wmzPF8XqzESzzplWDbrmXQBqgYJ53meENAcaawoovQ3t3GcYYfc A5OT+veNkBJmeP/FxNK4KqPh1UJ62oSUSXjGdA/IAwmEvovTxZS811QaodcIL2ZTQA7O+dqaArSd9EwbVY/GdE7vbDYvu1NirXo= Archived-At: Subject: [ippm] Nit for draft-ietf-ippm-stamp-04 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Nov 2018 05:00:44 -0000 In section 4.1.1, it says that the IANA Considerations describes the registry of TLV types. But the IANA Considerations section of draft-ietf-ippm-stamp-04 is null. (Is it possible to have STAMP share a TLV registry with other IPPM protocols?) Dale From nobody Mon Nov 26 23:48:13 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A704130E12; Mon, 26 Nov 2018 23:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 dhVb3XBga8bS; Mon, 26 Nov 2018 23:48:10 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFA4127133; Mon, 26 Nov 2018 23:48:10 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wAR7jf7O020066; Tue, 27 Nov 2018 02:46:57 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049295.ppops.net-00191d01. with ESMTP id 2p10ap9xkm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Nov 2018 02:46:56 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAR7ktj6047531; Tue, 27 Nov 2018 01:46:55 -0600 Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [135.46.181.149]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAR7kqD4047494; Tue, 27 Nov 2018 01:46:52 -0600 Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [127.0.0.1]) by zlp30499.vci.att.com (Service) with ESMTP id 221824013B25; Tue, 27 Nov 2018 07:46:52 +0000 (GMT) Received: from tlpd252.dadc.sbc.com (unknown [135.31.184.157]) by zlp30499.vci.att.com (Service) with ESMTP id EC69E4013B23; Tue, 27 Nov 2018 07:46:51 +0000 (GMT) Received: from dadc.sbc.com (localhost [127.0.0.1]) by tlpd252.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAR7koXl121728; Tue, 27 Nov 2018 01:46:51 -0600 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by tlpd252.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAR7kjKS121538; Tue, 27 Nov 2018 01:46:45 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-blue.research.att.com (Postfix) with ESMTP id 7F7C5F1AFB; Tue, 27 Nov 2018 02:41:11 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Tue, 27 Nov 2018 02:40:16 -0500 From: "MORTON, ALFRED C (AL)" To: "Dale R. Worley" , "ippm@ietf.org" CC: "draft-ietf-ippm-port-twamp-test.all@ietf.org" Thread-Topic: [ippm] Some nits for draft-ietf-ippm-port-twamp-test-03 Thread-Index: AQHUhgcoX1P8dCtWYUa4/9H/xq7b+KVjOmmQ Date: Tue, 27 Nov 2018 07:40:14 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557E510D@njmtexg5.research.att.com> References: <87pnurkvmo.fsf@hobgoblin.ariadne.com> In-Reply-To: <87pnurkvmo.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.106.224.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-27_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811270071 Archived-At: Subject: Re: [ippm] Some nits for draft-ietf-ippm-port-twamp-test-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 27 Nov 2018 07:48:13 -0000 Hi Dale, you're absolutely right. these are nits. the abstract says: This memo explains the motivation and describes the re-assignment of well-known ports for the OWAMP and TWAMP protocols for control and measurement, If the definition of "re-assignment" is clear, then the sentence is fully=20 functional. The sentence mentions the motivation and other details because= =20 some people were saying that TWAMP-Control was OPTIONAL last year (it's not). The sentence summarizes the entire memo, as we tend to=20 do in an abstract - it's not only about re-assignment. The Scope section is really clear, and it's only 3 paragraphs from the begi= nning: 3. Scope The scope of this memo is to re-allocate well-known ports for the UDP Test protocols that compose necessary parts of their respective standards track protocols, OWAMP and TWAMP, along with clarifications of the complete protocol composition for the industry. We seem to be missing some parens around "Section 7",=20 thanks for pointing that out. Al > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Dale R. Worley > Sent: Monday, November 26, 2018 11:11 PM > To: ippm@ietf.org > Cc: draft-ietf-ippm-port-twamp-test.all@ietf.org > Subject: [ippm] Some nits for draft-ietf-ippm-port-twamp-test-03 >=20 > Here are a couple of nits in draft-ietf-ippm-port-twamp-test-03: >=20 > 1. The essence of the I-D is in section 5: >=20 > This memo requests re-assignment of the UDP well-known port from the > Control protocol to the Test protocol (see the IANA Considerations > Section 7). >=20 > Despite the simplicity of this, I didn't understand that was what the > I-D did after reading either the Abstract or the Introduction (section > 1). Perhaps using this sentence in both places would clarify the > situation: >=20 > This memo requests re-assignment of the UDP well-known ports from the > Control protocols of OWAMP and TWAMP to the corresponding Test > protocols. >=20 > 2. Sections 5.1 and 5.2 contain the following odd uses of "Section 7": >=20 > A Control Client that supports use of the allocated TWAMP-Test > Receiver Port Section 7 MAY request to use that port number in the > Request-TW-Session Command. >=20 > As described above, an OWAMP Control Client that supports use of the > allocated OWAMP-Test Receiver Port Section 7 MAY request to use that > port number in the Request-Session Command. >=20 > Dale >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3D1uSWVJOd4Kjn2r0iKMW1iRFM= 4v3a0 > hRAbUoOxQsG7qs&s=3D6Zq0OFWI5YPg2lutPrNnNtxj6Upvbq403eFdO0rlIhg&e=3D From nobody Tue Nov 27 19:44:12 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD05130EE7 for ; Tue, 27 Nov 2018 19:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 3Y5SIp36SnSZ for ; Tue, 27 Nov 2018 19:44:08 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 B6CAB130E29 for ; Tue, 27 Nov 2018 19:44:08 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id RqYHgpKmQC1mXRqljgomZS; Wed, 28 Nov 2018 03:44:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1543376647; bh=2GHSFnNsOVB8hYJ84zfRrD4qcjJ5+9QohlswjGgDx6k=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=kuiUigyTLLxtlo6ln0qaAl4+JDhB8o0/0ag6Eu9mxLlcrhThPz+Asxg4591IosnfP wQe+Ohu1LDy96w4tMxUyjE7MMvxQYjAA2IcZ8waSeXekNIHxeeb//7Ky1D7guzSNxV qsJ1RXpGGHtZ7k4pJlWWf5YlvKrzvaev6CNu4wQJU/W/3XybRO6CcZlxjIUvqVLsb0 lr28Vkt/RiKFs7BI9NiRnqtfFFJzUlNZr6F8U1XPJOCsiRsZbEmci5gxB+RFa1L2qF pcnwp8Ou70C7L/R7skJ4K30Hsj42+e8x0+OdLCAh2XILcLBhW7eLZp7lR+z6Yl+dLA iCAuS87uSkILw== Received: from hobgoblin.ariadne.com ([24.91.37.100]) by resomta-ch2-07v.sys.comcast.net with ESMTPA id RqligMyVWsSYsRqljg9ug3; Wed, 28 Nov 2018 03:44:07 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id wAS3i5Sk014275; Tue, 27 Nov 2018 22:44:05 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id wAS3i4tc014259; Tue, 27 Nov 2018 22:44:04 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "MORTON\, ALFRED C \(AL\)" Cc: ippm@ietf.org, draft-ietf-ippm-port-twamp-test.all@ietf.org In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF557E510D@njmtexg5.research.att.com> (acm@research.att.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 27 Nov 2018 22:44:04 -0500 Message-ID: <87tvk1kgsb.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMPurlCXSSCFnwdEmnEpjfniLddwaQynTaQS8pkYup+LU0NWMSQLVpPbXYpCwasXehx9FuzNBNBQKsHpWjeaj2TQCjRbVVNBZud4EXo04DVX4W4ei2Aw dzyievhwnO9MLyXJWA7sS/eGTweNPMJ9ooANAOPAl3LmJPFwRJnFgOIzVKH/C6GQb/sryaWpuhPrHxRhuJk91eieVsuKtOAcubt2c1vmeFgi1VuIEpneStqT +gm7GmlNAmH+5ZeqDc1LnFtOqwtoQaChn70B31t1glQ= Archived-At: Subject: Re: [ippm] Some nits for draft-ietf-ippm-port-twamp-test-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 03:44:10 -0000 "MORTON, ALFRED C (AL)" writes: > Hi Dale, > you're absolutely right. these are nits. > > the abstract says: > This memo explains the motivation and describes the re-assignment of > well-known ports for the OWAMP and TWAMP protocols for control and > measurement, > If the definition of "re-assignment" is clear, then the sentence is fully > functional. The sentence mentions the motivation and other details because > some people were saying that TWAMP-Control was OPTIONAL last year > (it's not). The sentence summarizes the entire memo, as we tend to > do in an abstract - it's not only about re-assignment. > > The Scope section is really clear, and it's only 3 paragraphs from the beginning: > 3. Scope > > The scope of this memo is to re-allocate well-known ports for the UDP > Test protocols that compose necessary parts of their respective > standards track protocols, OWAMP and TWAMP, along with clarifications > of the complete protocol composition for the industry. Yes ... but although it "describes the re-assignment of well-known ports", it doesn't say *what* re-assignment is done. I had assumed that the re-assignment was some complex thing, because the details weren't "in line". But in reality, the specifics can be described by adding just a few words to the sentence that describes the generalities. Dale From nobody Wed Nov 28 00:42:35 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FB8130E4A; Wed, 28 Nov 2018 00:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 RlOtB-KZKuTD; Wed, 28 Nov 2018 00:42:30 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BA8130E4D; Wed, 28 Nov 2018 00:42:30 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wAS8ZDZ6037444; Wed, 28 Nov 2018 03:41:50 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0048589.ppops.net-00191d01. with ESMTP id 2p1hmhyyk6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Nov 2018 03:41:50 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAS8fnlH024011; Wed, 28 Nov 2018 02:41:49 -0600 Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [135.46.181.157]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAS8fjcG023907; Wed, 28 Nov 2018 02:41:45 -0600 Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [127.0.0.1]) by zlp30496.vci.att.com (Service) with ESMTP id 01FB240F6CEC; Wed, 28 Nov 2018 08:41:45 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30496.vci.att.com (Service) with ESMTP id D55294081D13; Wed, 28 Nov 2018 08:41:44 +0000 (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 wAS8fiEF004769; Wed, 28 Nov 2018 02:41:44 -0600 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 wAS8faHB004358; Wed, 28 Nov 2018 02:41:36 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTP id C97E7E1BC5; Wed, 28 Nov 2018 03:41:35 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Wed, 28 Nov 2018 03:40:40 -0500 From: "MORTON, ALFRED C (AL)" To: "Dale R. Worley" CC: "ippm@ietf.org" , "draft-ietf-ippm-port-twamp-test.all@ietf.org" Thread-Topic: [ippm] Some nits for draft-ietf-ippm-port-twamp-test-03 Thread-Index: AQHUhsybX1P8dCtWYUa4/9H/xq7b+KVk3Nvw Date: Wed, 28 Nov 2018 08:41:35 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557E5882@njmtexg5.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF557E510D@njmtexg5.research.att.com> (acm@research.att.com) <87tvk1kgsb.fsf@hobgoblin.ariadne.com> In-Reply-To: <87tvk1kgsb.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.106.224.244] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-28_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811280078 Archived-At: Subject: Re: [ippm] Some nits for draft-ietf-ippm-port-twamp-test-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 08:42:33 -0000 > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Tuesday, November 27, 2018 10:44 PM > To: MORTON, ALFRED C (AL) > Cc: ippm@ietf.org; draft-ietf-ippm-port-twamp-test.all@ietf.org > Subject: Re: [ippm] Some nits for draft-ietf-ippm-port-twamp-test-03 >=20 > "MORTON, ALFRED C (AL)" writes: > > Hi Dale, > > you're absolutely right. these are nits. > > > > the abstract says: > > This memo explains the motivation and describes the re-assignment of > > well-known ports for the OWAMP and TWAMP protocols for control and > > measurement, > > If the definition of "re-assignment" is clear, then the sentence is > fully > > functional. The sentence mentions the motivation and other details > because > > some people were saying that TWAMP-Control was OPTIONAL last year > > (it's not). The sentence summarizes the entire memo, as we tend to > > do in an abstract - it's not only about re-assignment. > > > > The Scope section is really clear, and it's only 3 paragraphs from the > beginning: > > 3. Scope > > > > The scope of this memo is to re-allocate well-known ports for the UD= P > > Test protocols that compose necessary parts of their respective > > standards track protocols, OWAMP and TWAMP, along with clarification= s > > of the complete protocol composition for the industry. >=20 > Yes ... but although it "describes the re-assignment of well-known > ports", it doesn't say *what* re-assignment is done. I had assumed that > the re-assignment was some complex thing, because the details weren't > "in line". But in reality, the specifics can be described by adding > just a few words to the sentence that describes the generalities. >=20 > Dale [acm]=20 At present, each part of the Scope is described at an equal level of detail= . The most important part of this memo for me is the clarification of=20 the complete protocol composition; IPPM working group exchanged many more spirited e-mail messages on that aspect, than on the port re-assignment. Al From nobody Wed Nov 28 00:49:49 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B0B130E4F; Wed, 28 Nov 2018 00:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 7rvkGejwzRWm; Wed, 28 Nov 2018 00:49:46 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D978D130E4D; Wed, 28 Nov 2018 00:49:46 -0800 (PST) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wAS8jXda040394; Wed, 28 Nov 2018 03:49:22 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by mx0a-00191d01.pphosted.com with ESMTP id 2p1jt9xebf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Nov 2018 03:49:22 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAS8nL3c034870; Wed, 28 Nov 2018 02:49:21 -0600 Received: from zlp30497.vci.att.com (zlp30497.vci.att.com [135.46.181.156]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAS8nH5U034805; Wed, 28 Nov 2018 02:49:17 -0600 Received: from zlp30497.vci.att.com (zlp30497.vci.att.com [127.0.0.1]) by zlp30497.vci.att.com (Service) with ESMTP id 7AFC340141EC; Wed, 28 Nov 2018 08:49:17 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30497.vci.att.com (Service) with ESMTP id 5C95840141EA; Wed, 28 Nov 2018 08:49:17 +0000 (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 wAS8nHXd029440; Wed, 28 Nov 2018 02:49:17 -0600 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 wAS8n99I028923; Wed, 28 Nov 2018 02:49:09 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-blue.research.att.com (Postfix) with ESMTP id 9E778F1D5C; Wed, 28 Nov 2018 03:49:08 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Wed, 28 Nov 2018 03:48:12 -0500 From: "MORTON, ALFRED C (AL)" To: "Dale R. Worley" CC: "ippm@ietf.org" , "draft-ietf-ippm-port-twamp-test.all@ietf.org" Thread-Topic: [ippm] Some nits for draft-ietf-ippm-port-twamp-test-03 Thread-Index: AQHUhsybX1P8dCtWYUa4/9H/xq7b+KVk3Nvw Date: Wed, 28 Nov 2018 08:49:08 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557E58B0@njmtexg5.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF557E510D@njmtexg5.research.att.com> (acm@research.att.com) <87tvk1kgsb.fsf@hobgoblin.ariadne.com> In-Reply-To: <87tvk1kgsb.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.106.224.244] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-28_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811280080 Archived-At: Subject: Re: [ippm] Some nits for draft-ietf-ippm-port-twamp-test-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 08:49:48 -0000 Re-sending - the last five live were truncated in the message I=20 received back from the ippm list... > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Tuesday, November 27, 2018 10:44 PM > To: MORTON, ALFRED C (AL) > Cc: ippm@ietf.org; draft-ietf-ippm-port-twamp-test.all@ietf.org > Subject: Re: [ippm] Some nits for draft-ietf-ippm-port-twamp-test-03 >=20 > "MORTON, ALFRED C (AL)" writes: > > Hi Dale, > > you're absolutely right. these are nits. > > > > the abstract says: > > This memo explains the motivation and describes the re-assignment of > > well-known ports for the OWAMP and TWAMP protocols for control and > > measurement, > > If the definition of "re-assignment" is clear, then the sentence is > fully > > functional. The sentence mentions the motivation and other details > because > > some people were saying that TWAMP-Control was OPTIONAL last year > > (it's not). The sentence summarizes the entire memo, as we tend to > > do in an abstract - it's not only about re-assignment. > > > > The Scope section is really clear, and it's only 3 paragraphs from the > beginning: > > 3. Scope > > > > The scope of this memo is to re-allocate well-known ports for the UD= P > > Test protocols that compose necessary parts of their respective > > standards track protocols, OWAMP and TWAMP, along with clarification= s > > of the complete protocol composition for the industry. >=20 > Yes ... but although it "describes the re-assignment of well-known > ports", it doesn't say *what* re-assignment is done. I had assumed that > the re-assignment was some complex thing, because the details weren't > "in line". But in reality, the specifics can be described by adding > just a few words to the sentence that describes the generalities. >=20 > Dale [acm]=20 At present, each part of the Scope is described at an equal level of detail= . The most important part of this memo for me is the clarification of=20 the complete protocol composition; IPPM working group exchanged many more spirited e-mail messages on that aspect, than on the port re-assignment. Al From nobody Wed Nov 28 04:47:52 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D68512D4EF for ; Wed, 28 Nov 2018 04:47:50 -0800 (PST) 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 lM78d1AuOCpM for ; Wed, 28 Nov 2018 04:47:47 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 CEB881294D0 for ; Wed, 28 Nov 2018 04:47:46 -0800 (PST) Received: from 200116b82c8aff008423b6791577d8ab.dip.versatel-1u1.de ([2001:16b8:2c8a:ff00:8423:b679:1577:d8ab]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gRzFo-0000A2-DV; Wed, 28 Nov 2018 13:47:44 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF557DDDB0@njmtexg5.research.att.com> Date: Wed, 28 Nov 2018 13:47:42 +0100 Cc: "ippm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0EE1717C-4587-4E1B-8222-AFCD03217FEC@kuehlewind.net> References: <20181107043043.5854CB80EE3@rfc-editor.org> <4D7F4AD313D3FC43A053B309F97543CF557DDDB0@njmtexg5.research.att.com> To: "MORTON, ALFRED C (AL)" X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1543409266;c5b158d7; X-HE-SMSGID: 1gRzFo-0000A2-DV Archived-At: Subject: Re: [ippm] [Technical Errata Reported] RFC6038 (5549) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 12:47:50 -0000 Hi Al, thanks! Actually the one from last year wasn=E2=80=99t marked as = verified yet. Verified both errata now! Mirja > Am 09.11.2018 um 17:29 schrieb MORTON, ALFRED C (AL) = : >=20 > It looks like this Errata should be verified. >=20 > A similar point was verified in RFC 5357 (last year): > https://www.rfc-editor.org/errata/eid5046 >=20 > Al >=20 >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: Tuesday, November 6, 2018 11:31 PM >> To: MORTON, ALFRED C (AL) ; CIAVATTONE, LEN >> ; spencerdawkins.ietf@gmail.com; ietf@kuehlewind.net; >> ietf@wjcerveny.com; ietf@trammell.ch; tpauly@apple.com >> Cc: prabhjot.sethi@gmail.com; ippm@ietf.org; = rfc-editor@rfc-editor.org >> Subject: [Technical Errata Reported] RFC6038 (5549) >>=20 >> The following errata report has been submitted for RFC6038, >> "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and >> Symmetrical Size Features". >>=20 >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid5549 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Prabhjot Singh Sethi >>=20 >> Section: 5.1.5 >>=20 >> Original Text >> ------------- >> In this combined mode, the Packet Padding to be reflected follows the >> 27 MBZ octets. In Authenticated or Encrypted modes, the Packet >> Padding to be reflected follows the 56 MBZ octets. >>=20 >> Corrected Text >> -------------- >> In this combined mode, the Packet Padding to be reflected follows the >> 27 MBZ octets. In Authenticated or Encrypted modes, the Packet >> Padding to be reflected follows the 64 MBZ octets. >>=20 >> Notes >> ----- >> to achieve symmetrical size in authenticated and encrypted mode = length of >> mbz field needs to be 64 octects instead of 56 octects >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC6038 (draft-ietf-ippm-twamp-reflect-octets-09) >> -------------------------------------- >> Title : Two-Way Active Measurement Protocol (TWAMP) = Reflect >> Octets and Symmetrical Size Features >> Publication Date : October 2010 >> Author(s) : A. Morton, L. Ciavattone >> Category : PROPOSED STANDARD >> Source : IP Performance Measurement >> Area : Transport >> Stream : IETF >> Verifying Party : IESG > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Wed Nov 28 09:13:47 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F1C130F9A for ; Wed, 28 Nov 2018 09:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VAy0ZcYbdEA for ; Wed, 28 Nov 2018 09:13:43 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 347F0130F8A for ; Wed, 28 Nov 2018 09:13:43 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id f23so19902460lfc.13 for ; Wed, 28 Nov 2018 09:13:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cZlLgYWwJ5HC5/ZzIwe3FfRf33yiG2RuuZtj6rMICVQ=; b=F45JfS934Yb9sAp5aA17MBx2Z571gdqHGmEo9PMJmnjZGhQEJ+I4MCNmKbxCZyyiMS 9mQivIJ7ICUbZcQWtPX9KNQYCxusFu5nnj8IsfCfQnhuAvguuRLeFocfEvBcvqID69NA IsxOhnwAG6RNn2+PKgDmI62NRH5WQVDFeISCsgvfSmhwFv0nYjFBcqPbSDUc1pLWU9AN RDRqYNnzeOUgmiBJ//7WYlt8cMDDKrsRrEmegcQCfXo3fo88dsj423KS3Zg1WRdnBruH LF1uig/QFGfmF5bN8BE4rV8j+zAwSdOvYF8DnpqdQbeCAHhpiPXYwAiCRLLqbslkN5vb 6LrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cZlLgYWwJ5HC5/ZzIwe3FfRf33yiG2RuuZtj6rMICVQ=; b=XLHP3WMDhuAu3beMug0WUUcWeaqvl5yuphL+nzw5MsieEeGfS0EulyIh/fdQajIup2 PZ9WMYJeedtySJZVqm71SGlI+VQ/E+V2Fu9vCp9j2IPTqaHQpT8W9Z6m+wnuBO1Lgq/b 3ri9c6EZ1q2b6XSAo/974ZeCcvJ1s/tDZXWRwkfnA638ZG4OLZlw7zZqlyLnD1Q7Fu6z f2pGyIBTDp+m+6GnRPT5HSfaW/KbS/PLcpYiVuzn1YIsup21sgK313MeQqhLMxuq03CT 9ANwl9wHlT7b2oKh6e/Rb54v3YbJXyCq6QAJSprqgXRsOO6aetS0geOTATHDhlM8HHYI E8/w== X-Gm-Message-State: AGRZ1gK/VUFz3LCIXP5XaraNhbwR73GdHNqkQAogy7C/ZWoBifxidu5L LDZDtvIuozSNfBndR119PNNfgyQyE4R+k9YZQ/WEcolj X-Google-Smtp-Source: AJdET5ceYPiJdGTYNC6xC5bf71mXC9RiAGD3iqpDmaggRKSYftCl7m+vxGR/h5zoaRj1wGp+oMnWgH93dJbP8RH64IA= X-Received: by 2002:a19:6f0a:: with SMTP id k10mr21409146lfc.119.1543425220883; Wed, 28 Nov 2018 09:13:40 -0800 (PST) MIME-Version: 1.0 References: <875zwjktc8.fsf@hobgoblin.ariadne.com> In-Reply-To: <875zwjktc8.fsf@hobgoblin.ariadne.com> From: Greg Mirsky Date: Wed, 28 Nov 2018 09:13:29 -0800 Message-ID: To: "Dale R. Worley" Cc: IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000073cd0057bbcb0a1" Archived-At: Subject: Re: [ippm] Nit for draft-ietf-ippm-stamp-04 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 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, 28 Nov 2018 17:13:45 -0000 --000000000000073cd0057bbcb0a1 Content-Type: text/plain; charset="UTF-8" Hi Dale, thank you for the thorough review. Indeed, we've moved STAMP TLV extensions in draft-mirsky-ippm-stamp-option-tlv . I'll remove the reference to IANA registry from the STAMP specification. I agree that re-use of encodings may be helpful. Which would you suggest? Also, appreciate your comments on the STAMP Options draft. Regards, Greg On Mon, Nov 26, 2018 at 9:00 PM Dale R. Worley wrote: > In section 4.1.1, it says that the IANA Considerations describes the > registry of TLV types. But the IANA Considerations section of > draft-ietf-ippm-stamp-04 is null. > > (Is it possible to have STAMP share a TLV registry with other IPPM > protocols?) > > Dale > --000000000000073cd0057bbcb0a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dale,
thank you for the thorough r= eview. Indeed, we've moved STAMP TLV extensions in draft-mirsky-ippm= -stamp-option-tlv. I'll remove the reference to IANA registry from = the STAMP specification.
I agree that re-use of encodings may be = helpful. Which would you suggest? Also, appreciate your comments on the STA= MP Options draft.

Regards,
Greg

On Mon, Nov 26, 20= 18 at 9:00 PM Dale R. Worley <worl= ey@ariadne.com> wrote:
In se= ction 4.1.1, it says that the IANA Considerations describes the
registry of TLV types.=C2=A0 But the IANA Considerations section of
draft-ietf-ippm-stamp-04 is null.

(Is it possible to have STAMP share a TLV registry with other IPPM
protocols?)

Dale
--000000000000073cd0057bbcb0a1-- From nobody Wed Nov 28 09:56:05 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CE7128D68; Wed, 28 Nov 2018 09:55:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <154342775721.13644.12792295372880886404@ietfa.amsl.com> Date: Wed, 28 Nov 2018 09:55:57 -0800 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 17:55:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Simple Two-way Active Measurement Protocol Authors : Greg Mirsky Guo Jun Henrik Nydell Richard Foote Filename : draft-ietf-ippm-stamp-05.txt Pages : 15 Date : 2018-11-28 Abstract: This document describes a Simple Two-way Active Measurement Protocol which enables the measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-stamp-05 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 29 15:33:27 2018 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C25F124C04; Thu, 29 Nov 2018 15:33:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-ippm-port-twamp-test@ietf.org, Tianran Zhou , ippm-chairs@ietf.org, zhoutianran@huawei.com, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154353440537.25943.10294246641909208146.idtracker@ietfa.amsl.com> Date: Thu, 29 Nov 2018 15:33:25 -0800 Archived-At: Subject: [ippm] Adam Roach's No Objection on draft-ietf-ippm-port-twamp-test-03: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2018 23:33:25 -0000 Adam Roach has entered the following ballot position for draft-ietf-ippm-port-twamp-test-03: 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-port-twamp-test/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please expand "OWAMP" and "TWAMP" in the title, abstract, and upon first use in the body. From nobody Thu Nov 29 17:08:07 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0328012426E; Thu, 29 Nov 2018 17:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 Z4CzwepAtdDI; Thu, 29 Nov 2018 17:08:04 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 2561E124408; Thu, 29 Nov 2018 17:08:01 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.22/8.16.0.22) with SMTP id wAU0phoR049414; Thu, 29 Nov 2018 17:08:00 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : subject : date : references : cc : to : message-id; s=20180706; bh=K+ooq5w4Re+Gfn5vXk6mkopaUDpGzI6ubqxckZCb6dI=; b=uz0XaOJoZoedHaw/ZgH4uAbF1KuyJUSdc/+g2sFiWmG9nEivp5lpGbBlr4GRMhuGsZvl aBsO3LR/hajDhmqjN6cgP/MuX1s108tF2BgnM7vEljFb7aj3LBOdeYfB/9XCWXTaLvta pzZhSVfTYH3ahUXqaNiU1rtDwh4NDkGW2as45TwMruR1P3w21NgxqjCTlAy0ZTFbovps 8tVLf1aC91Q0L8e9OiN4CaGRpgzmgqoxZmlaMm9c43kQo6Fb2IDXPd1as3BDsuI5O9Ev C8Sc0z/M8jP50D/KDcIar+E8b2XexNfDNl7wO0WDwLUk9wb0QhpWh1pp+Xu/ln/SBvam QA== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2ny66f82xw-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 29 Nov 2018 17:08:00 -0800 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_h1IxbgN61oUGR3C/Zj1NBQ)" Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PIZ00E0PF5ASNB0@mr2-mtap-s02.rno.apple.com>; Thu, 29 Nov 2018 17:07:58 -0800 (PST) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PIZ00A00EFALJ00@nwk-mmpp-sz10.apple.com>; Thu, 29 Nov 2018 17:07:58 -0800 (PST) X-Va-A: X-Va-T-CD: 159681ac17b4bf28eab1955e26a63a9c X-Va-E-CD: 24f5b816b385182329c00ccda1f0500e X-Va-R-CD: 665e53ad834f9f4864b71ffee0b45292 X-Va-CD: 0 X-Va-ID: f0e96094-3dc4-4fb4-937b-86fbfdec0c09 X-V-A: X-V-T-CD: 60eba1048664b2c2d1e823e0b55422b4 X-V-E-CD: 24f5b816b385182329c00ccda1f0500e X-V-R-CD: 665e53ad834f9f4864b71ffee0b45292 X-V-CD: 0 X-V-ID: 7b53d4d0-dece-4f3c-a7d8-c28723a3081a Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PIZ00L00F4HU700@nwk-mmpp-sz10.apple.com>; Thu, 29 Nov 2018 17:07:58 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-29_14:,, signatures=0 Received: from [17.234.40.219] (unknown [17.234.40.219]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PIZ00AJQF5A6760@nwk-mmpp-sz10.apple.com>; Thu, 29 Nov 2018 17:07:58 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Date: Thu, 29 Nov 2018 17:07:57 -0800 References: Cc: draft-xie-v6ops-network-happyeyeballs.authors@ietf.org To: ippm@ietf.org Message-id: X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-29_14:, , signatures=0 Archived-At: Subject: [ippm] Fwd: [v6ops] draft-xie-v6ops-network-happyeyeballs X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 01:08:06 -0000 --Boundary_(ID_h1IxbgN61oUGR3C/Zj1NBQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi IPPM, There's a document being discussed on the v6ops list that describes a strategy for actively measuring IPv4 vs IPv6 performance to help ISP deployments. https://tools.ietf.org/html/draft-xie-v6ops-network-happyeyeballs-01 This certainly seems like an area where IPPM solutions could help out, so if anyone would like to review the document and make suggestions, that'd be great. Best, Tommy > Begin forwarded message: > > From: Ron Bonica > Subject: [v6ops] draft-xie-v6ops-network-happyeyeballs > Date: November 26, 2018 at 6:22:58 AM PST > To: "v6ops@ietf.org list" > > Folks, > > Each week between now and IETF 104, we will review and discuss one draft with an eye towards progressing it. > > This week, please review and comment on draft-xie-v6ops-network-happyeyeballs. > > Fred and Ron > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Boundary_(ID_h1IxbgN61oUGR3C/Zj1NBQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi = IPPM,

There's a = document being discussed on the v6ops list that describes a strategy for = actively measuring IPv4 vs IPv6 performance to help ISP = deployments.

https://tools.ietf.org/html/draft-xie-v6ops-network-happyeyebal= ls-01

This = certainly seems like an area where IPPM solutions could help out, so if = anyone would like to review the document and make suggestions, that'd be = great.

Best,
Tommy

Begin = forwarded message:

From: = Ron Bonica <rbonica@juniper.net>
Subject: = [v6ops] = draft-xie-v6ops-network-happyeyeballs
Date: = November 26, 2018 at 6:22:58 AM = PST
To: = "v6ops@ietf.org list" = <v6ops@ietf.org>

Folks,

Each week between now and = IETF 104, we will review and discuss one draft with an eye towards = progressing it.

This week, please review = and comment on draft-xie-v6ops-network-happyeyeballs.

=             &n= bsp;           &nbs= p;            =             &n= bsp;          Fred and = Ron

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

= --Boundary_(ID_h1IxbgN61oUGR3C/Zj1NBQ)-- From nobody Fri Nov 30 05:40:06 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5C1130E26; Fri, 30 Nov 2018 05:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 euOY70h9T2Um; Fri, 30 Nov 2018 05:39:52 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7DC0130E19; Fri, 30 Nov 2018 05:39:52 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wAUDZjfF038025; Fri, 30 Nov 2018 08:39:49 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049295.ppops.net-00191d01. with ESMTP id 2p34m0akdq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Nov 2018 08:39:49 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAUDdlBS039251; Fri, 30 Nov 2018 07:39:48 -0600 Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [135.46.181.158]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAUDdgSg039047; Fri, 30 Nov 2018 07:39:42 -0600 Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [127.0.0.1]) by zlp30495.vci.att.com (Service) with ESMTP id C1A0240D3C41; Fri, 30 Nov 2018 13:39:42 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30495.vci.att.com (Service) with ESMTP id A61A040D3C40; Fri, 30 Nov 2018 13:39:42 +0000 (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 wAUDdgST020589; Fri, 30 Nov 2018 07:39:42 -0600 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 wAUDdZLs019946; Fri, 30 Nov 2018 07:39:35 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-green.research.att.com (Postfix) with ESMTP id 6D371E1C4B; Fri, 30 Nov 2018 08:35:38 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Fri, 30 Nov 2018 08:39:34 -0500 From: "MORTON, ALFRED C (AL)" To: Adam Roach , The IESG CC: "draft-ietf-ippm-port-twamp-test@ietf.org" , Tianran Zhou , "ippm-chairs@ietf.org" , "zhoutianran@huawei.com" , "ippm@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-ippm-port-twamp-test-03: (with COMMENT) Thread-Index: AQHUiDwBZy1cn7eqcUmcZL3DGu3yJqVoUjZA Date: Fri, 30 Nov 2018 13:38:37 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557E6A14@njmtexg5.research.att.com> References: <154353440537.25943.10294246641909208146.idtracker@ietfa.amsl.com> In-Reply-To: <154353440537.25943.10294246641909208146.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.106.224.143] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-30_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=702 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811300116 Archived-At: Subject: Re: [ippm] Adam Roach's No Objection on draft-ietf-ippm-port-twamp-test-03: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 13:39:55 -0000 SGkgQWRhbSwNCg0KLi4uDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gDQo+IFBsZWFzZSBleHBhbmQgIk9XQU1QIiBhbmQgIlRXQU1QIiBpbiB0aGUg dGl0bGUsIGFic3RyYWN0LCBhbmQgdXBvbiBmaXJzdA0KPiB1c2UgaW4NCj4gdGhlIGJvZHkuDQo+ IA0KW2FjbV0gDQpubyBwcm9ibGVtIGFib3V0IGV4cGFuc2lvbnMgaW4gYWJzdHJhY3QgYW5kIGJv ZHksIGJ1dA0KDQpPbmUtd2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCBhbmQgVHdvLXdh eSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgV2VsbC1Lbm93biBQb3J0IEFzc2lnbm1lbnRz DQoNCm1ha2VzIGZvciBhIHJlYWxseS1sb25nIHRpdGxlLA0KDQpBbA0KDQo= From nobody Fri Nov 30 05:55:13 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41436124D68; Fri, 30 Nov 2018 05:55:10 -0800 (PST) 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 xyO33s4-Msyw; Fri, 30 Nov 2018 05:55:06 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 6CBAD123FFD; Fri, 30 Nov 2018 05:55:06 -0800 (PST) Received: from 200116b82c80b800edb9c5bbca946738.dip.versatel-1u1.de ([2001:16b8:2c80:b800:edb9:c5bb:ca94:6738]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gSjG0-000348-6q; Fri, 30 Nov 2018 14:55:00 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF557E6A14@njmtexg5.research.att.com> Date: Fri, 30 Nov 2018 14:54:58 +0100 Cc: Adam Roach , The IESG , "draft-ietf-ippm-port-twamp-test@ietf.org" , "ippm-chairs@ietf.org" , "zhoutianran@huawei.com" , "ippm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6844C928-66BA-44D4-8CAB-B29054180A04@kuehlewind.net> References: <154353440537.25943.10294246641909208146.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CF557E6A14@njmtexg5.research.att.com> To: "MORTON, ALFRED C (AL)" X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1543586106;37117e2b; X-HE-SMSGID: 1gSjG0-000348-6q Archived-At: Subject: Re: [ippm] Adam Roach's No Objection on draft-ietf-ippm-port-twamp-test-03: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 13:55:10 -0000 Yes, as these are listed in the well-known abbreviations list, I don=E2=80= =99t think we should spell them out in the title. I=E2=80=99m also not = sure about expanding in the abstract but spelling them out in the intro = clearly is a good idea anyway. > Am 30.11.2018 um 14:38 schrieb MORTON, ALFRED C (AL) = : >=20 > Hi Adam, >=20 > ... >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Please expand "OWAMP" and "TWAMP" in the title, abstract, and upon = first >> use in >> the body. >>=20 > [acm]=20 > no problem about expansions in abstract and body, but >=20 > One-way Active Measurement Protocol and Two-way Active Measurement = Protocol Well-Known Port Assignments >=20 > makes for a really-long title, >=20 > Al >=20 From nobody Fri Nov 30 06:36:10 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525D41200B3; Fri, 30 Nov 2018 06:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 8lYC43bdPZTF; Fri, 30 Nov 2018 06:35:58 -0800 (PST) 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 A7806126CC7; Fri, 30 Nov 2018 06:35:58 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wAUEZFEC012388; Fri, 30 Nov 2018 09:35:44 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049462.ppops.net-00191d01. with ESMTP id 2p32w6egye-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Nov 2018 09:35:43 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAUEZg4H017618; Fri, 30 Nov 2018 08:35:42 -0600 Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [135.46.181.149]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAUEZX4A017380; Fri, 30 Nov 2018 08:35:34 -0600 Received: from zlp30499.vci.att.com (zlp30499.vci.att.com [127.0.0.1]) by zlp30499.vci.att.com (Service) with ESMTP id 8BB034013B27; Fri, 30 Nov 2018 14:35:33 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30499.vci.att.com (Service) with ESMTP id 64E1D4013B25; Fri, 30 Nov 2018 14:35:33 +0000 (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 wAUEZXOD022765; Fri, 30 Nov 2018 08:35:33 -0600 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 wAUEZRlY022263; Fri, 30 Nov 2018 08:35:27 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTP id 2192AE1059; Fri, 30 Nov 2018 09:35:26 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Fri, 30 Nov 2018 09:35:26 -0500 From: "MORTON, ALFRED C (AL)" To: "Mirja Kuehlewind (IETF)" CC: Adam Roach , The IESG , "draft-ietf-ippm-port-twamp-test@ietf.org" , "ippm-chairs@ietf.org" , "zhoutianran@huawei.com" , "ippm@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-ippm-port-twamp-test-03: (with COMMENT) Thread-Index: AQHUiDwBZy1cn7eqcUmcZL3DGu3yJqVoUjZAgABZswD//7cAUA== Date: Fri, 30 Nov 2018 14:34:29 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557E6AA9@njmtexg5.research.att.com> References: <154353440537.25943.10294246641909208146.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CF557E6A14@njmtexg5.research.att.com> <6844C928-66BA-44D4-8CAB-B29054180A04@kuehlewind.net> In-Reply-To: <6844C928-66BA-44D4-8CAB-B29054180A04@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.106.224.143] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-30_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=830 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811300124 Archived-At: Subject: Re: [ippm] Adam Roach's No Objection on draft-ietf-ippm-port-twamp-test-03: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 14:36:01 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWlyamEgS3VlaGxld2lu ZCAoSUVURikgW21haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0XQ0KLi4uDQo+IA0KPiBZZXMsIGFz IHRoZXNlIGFyZSBsaXN0ZWQgaW4gdGhlIHdlbGwta25vd24gYWJicmV2aWF0aW9ucyBsaXN0LCBJ IGRvbuKAmXQNCj4gdGhpbmsgd2Ugc2hvdWxkIHNwZWxsIHRoZW0gb3V0IGluIHRoZSB0aXRsZS4g SeKAmW0gYWxzbyBub3Qgc3VyZSBhYm91dA0KPiBleHBhbmRpbmcgaW4gdGhlIGFic3RyYWN0IGJ1 dCBzcGVsbGluZyB0aGVtIG91dCBpbiB0aGUgaW50cm8gY2xlYXJseSBpcyBhDQo+IGdvb2QgaWRl YSBhbnl3YXkuDQpbYWNtXSANClRoZSBGaXJzdCBTZW50ZW5jZSBvZiB0aGUgSW50cm9kdWN0aW9u IGFscmVhZHkgc3BlbGxlZCB0aGVtIG91dC4uLg0KDQpBbA0KDQo+IA0KPiANCj4gDQo+ID4gQW0g MzAuMTEuMjAxOCB1bSAxNDozOCBzY2hyaWViIE1PUlRPTiwgQUxGUkVEIEMgKEFMKQ0KPiA8YWNt QHJlc2VhcmNoLmF0dC5jb20+Og0KPiA+DQo+ID4gSGkgQWRhbSwNCj4gPg0KPiA+IC4uLg0KPiA+ Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IENPTU1FTlQ6DQo+ID4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPj4NCj4gPj4gUGxlYXNlIGV4cGFuZCAiT1dBTVAiIGFuZCAiVFdBTVAiIGluIHRoZSB0aXRs ZSwgYWJzdHJhY3QsIGFuZCB1cG9uDQo+IGZpcnN0DQo+ID4+IHVzZSBpbg0KPiA+PiB0aGUgYm9k eS4NCj4gPj4NCj4gPiBbYWNtXQ0KPiA+IG5vIHByb2JsZW0gYWJvdXQgZXhwYW5zaW9ucyBpbiBh YnN0cmFjdCBhbmQgYm9keSwgYnV0DQo+ID4NCj4gPiBPbmUtd2F5IEFjdGl2ZSBNZWFzdXJlbWVu dCBQcm90b2NvbCBhbmQgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQNCj4gUHJvdG9jb2wgV2Vs bC1Lbm93biBQb3J0IEFzc2lnbm1lbnRzDQo+ID4NCj4gPiBtYWtlcyBmb3IgYSByZWFsbHktbG9u ZyB0aXRsZSwNCj4gPg0KPiA+IEFsDQo+ID4NCg0K From nobody Fri Nov 30 08:13:55 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B1A1294D7; Fri, 30 Nov 2018 08:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 iqDX7PNgrTAu; Fri, 30 Nov 2018 08:13:51 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 7A4A21271FF; Fri, 30 Nov 2018 08:13:51 -0800 (PST) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wAUGDmDF053541 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 30 Nov 2018 10:13:49 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: "Mirja Kuehlewind (IETF)" , "MORTON, ALFRED C (AL)" Cc: The IESG , "draft-ietf-ippm-port-twamp-test@ietf.org" , "ippm-chairs@ietf.org" , "zhoutianran@huawei.com" , "ippm@ietf.org" References: <154353440537.25943.10294246641909208146.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CF557E6A14@njmtexg5.research.att.com> <6844C928-66BA-44D4-8CAB-B29054180A04@kuehlewind.net> From: Adam Roach Message-ID: <18da3dd1-ebbb-4602-726f-5ed504ee7750@nostrum.com> Date: Fri, 30 Nov 2018 10:13:43 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <6844C928-66BA-44D4-8CAB-B29054180A04@kuehlewind.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [ippm] Adam Roach's No Objection on draft-ietf-ippm-port-twamp-test-03: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 16:13:53 -0000 On 11/30/18 7:54 AM, Mirja Kuehlewind (IETF) wrote: > Yes, as these are listed in the well-known abbreviations list, I don’t think we should spell them out in the title. It is, of course, up to you and the authors what you want to progress; but I'll point out that OWAMP and TWAMP are specifically _not_ marked with an asterisk at ("In the following list of abbreviations, those that are usually (but not necessarily) treated as 'well known' are marked with asterisks.") > I’m also not sure about expanding in the abstract but spelling them out in the intro clearly is a good idea anyway. The guidance here (also from the page cited above) is: "Editorial guidelines for the RFC series generally require expansion of these abbreviations on first occurrence in a title, in an abstract, or in the body of the document." Again, it's up to you what to do here, but my suggestion remains expanding these acronyms. I do take the point that this makes the title rather long. Perhaps consider something like "One-Way and Two-Way Active Measurement Protocol (OWAMP and TWAMP) Well-Known Port Assignments". /a From nobody Fri Nov 30 08:17:11 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BA6128BCC; Fri, 30 Nov 2018 08:17:00 -0800 (PST) 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 FlOCgp15lqH5; Fri, 30 Nov 2018 08:16:58 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 3E4FB1271FF; Fri, 30 Nov 2018 08:16:58 -0800 (PST) Received: from 200116b82c80b800edb9c5bbca946738.dip.versatel-1u1.de ([2001:16b8:2c80:b800:edb9:c5bb:ca94:6738]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gSlTB-00045z-SX; Fri, 30 Nov 2018 17:16:45 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <18da3dd1-ebbb-4602-726f-5ed504ee7750@nostrum.com> Date: Fri, 30 Nov 2018 17:16:44 +0100 Cc: "MORTON, ALFRED C (AL)" , "draft-ietf-ippm-port-twamp-test@ietf.org" , "ippm-chairs@ietf.org" , The IESG , "ippm@ietf.org" , "zhoutianran@huawei.com" Content-Transfer-Encoding: quoted-printable Message-Id: References: <154353440537.25943.10294246641909208146.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CF557E6A14@njmtexg5.research.att.com> <6844C928-66BA-44D4-8CAB-B29054180A04@kuehlewind.net> <18da3dd1-ebbb-4602-726f-5ed504ee7750@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.9.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1543594618;9436ea6f; X-HE-SMSGID: 1gSlTB-00045z-SX Archived-At: Subject: Re: [ippm] Adam Roach's No Objection on draft-ietf-ippm-port-twamp-test-03: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 16:17:00 -0000 Oh sorry, my fault, I misread the entry and thought they were marked as = well-known. Still not sure about the title, but please expand at least = in the abstract then! > Am 30.11.2018 um 17:13 schrieb Adam Roach : >=20 > On 11/30/18 7:54 AM, Mirja Kuehlewind (IETF) wrote: >> Yes, as these are listed in the well-known abbreviations list, I = don=E2=80=99t think we should spell them out in the title. >=20 >=20 > It is, of course, up to you and the authors what you want to progress; = but I'll point out that OWAMP and TWAMP are specifically _not_ marked = with an asterisk at = ("In the = following list of abbreviations, those that are usually (but not = necessarily) treated as 'well known' are marked with asterisks.") >=20 >=20 >> I=E2=80=99m also not sure about expanding in the abstract but = spelling them out in the intro clearly is a good idea anyway. >=20 >=20 > The guidance here (also from the page cited above) is: "Editorial = guidelines for the RFC series generally require expansion of these = abbreviations on first occurrence in a title, in an abstract, or in the = body of the document." Again, it's up to you what to do here, but my = suggestion remains expanding these acronyms. >=20 > I do take the point that this makes the title rather long. Perhaps = consider something like "One-Way and Two-Way Active Measurement Protocol = (OWAMP and TWAMP) Well-Known Port Assignments". >=20 > /a >=20 >=20 From nobody Fri Nov 30 12:47:21 2018 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB02130FF7; Fri, 30 Nov 2018 12:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 hw_-5xJqc0yF; Fri, 30 Nov 2018 12:47:09 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12A11130FF5; Fri, 30 Nov 2018 12:47:08 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id wAUKijSm006527; Fri, 30 Nov 2018 15:47:05 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049287.ppops.net-00191d01. with ESMTP id 2p3acrcdvp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Nov 2018 15:47:05 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAUKl3Ux072458; Fri, 30 Nov 2018 14:47:04 -0600 Received: from zlp30493.vci.att.com (zlp30493.vci.att.com [135.46.181.176]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id wAUKkwue072312; Fri, 30 Nov 2018 14:46:58 -0600 Received: from zlp30493.vci.att.com (zlp30493.vci.att.com [127.0.0.1]) by zlp30493.vci.att.com (Service) with ESMTP id BC47240470D8; Fri, 30 Nov 2018 20:46:58 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30493.vci.att.com (Service) with ESMTP id 9D1A840006A0; Fri, 30 Nov 2018 20:46:58 +0000 (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 wAUKkwSW023309; Fri, 30 Nov 2018 14:46:58 -0600 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 wAUKkoKZ022807; Fri, 30 Nov 2018 14:46:51 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTP id 5DE54E1345; Fri, 30 Nov 2018 15:46:49 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0415.000; Fri, 30 Nov 2018 15:46:49 -0500 From: "MORTON, ALFRED C (AL)" To: "Mirja Kuehlewind (IETF)" , Adam Roach CC: "draft-ietf-ippm-port-twamp-test@ietf.org" , "ippm-chairs@ietf.org" , The IESG , "ippm@ietf.org" , "zhoutianran@huawei.com" Thread-Topic: Adam Roach's No Objection on draft-ietf-ippm-port-twamp-test-03: (with COMMENT) Thread-Index: AQHUiDwBZy1cn7eqcUmcZL3DGu3yJqVoUjZAgABZswCAACbEgIAAANgA///2WJA= Date: Fri, 30 Nov 2018 20:45:51 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF557E6C8B@njmtexg5.research.att.com> References: <154353440537.25943.10294246641909208146.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CF557E6A14@njmtexg5.research.att.com> <6844C928-66BA-44D4-8CAB-B29054180A04@kuehlewind.net> <18da3dd1-ebbb-4602-726f-5ed504ee7750@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [46.193.140.198] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-30_09:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811300176 Archived-At: Subject: Re: [ippm] Adam Roach's No Objection on draft-ietf-ippm-port-twamp-test-03: (with COMMENT) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 20:47:11 -0000 T2ssIEkndmUgZXhwYW5kZWQgKldBTVAgaW4gdGhlIEFic3RyYWN0LA0KdGhlIEludHJvIGFscmVh ZHkgaGFkIGV4cGFuc2lvbnMgLSBsZXQncyANCmxlYXZlIGl0IGF0IHRoYXQuDQoNCkFsDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWlyamEgS3VlaGxld2luZCAoSUVU RikgW21haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0XQ0KPiBTZW50OiBGcmlkYXksIE5vdmVtYmVy IDMwLCAyMDE4IDExOjE3IEFNDQo+IFRvOiBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPg0K PiBDYzogTU9SVE9OLCBBTEZSRUQgQyAoQUwpIDxhY21AcmVzZWFyY2guYXR0LmNvbT47IGRyYWZ0 LWlldGYtaXBwbS1wb3J0LQ0KPiB0d2FtcC10ZXN0QGlldGYub3JnOyBpcHBtLWNoYWlyc0BpZXRm Lm9yZzsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+Ow0KPiBpcHBtQGlldGYub3JnOyB6aG91dGlh bnJhbkBodWF3ZWkuY29tDQo+IFN1YmplY3Q6IFJlOiBBZGFtIFJvYWNoJ3MgTm8gT2JqZWN0aW9u IG9uIGRyYWZ0LWlldGYtaXBwbS1wb3J0LXR3YW1wLXRlc3QtDQo+IDAzOiAod2l0aCBDT01NRU5U KQ0KPiANCj4gT2ggc29ycnksIG15IGZhdWx0LCBJIG1pc3JlYWQgdGhlIGVudHJ5IGFuZCB0aG91 Z2h0IHRoZXkgd2VyZSBtYXJrZWQgYXMNCj4gd2VsbC1rbm93bi4gU3RpbGwgbm90IHN1cmUgYWJv dXQgdGhlIHRpdGxlLCBidXQgcGxlYXNlIGV4cGFuZCBhdCBsZWFzdCBpbg0KPiB0aGUgYWJzdHJh Y3QgdGhlbiENCj4gDQo+ID4gQW0gMzAuMTEuMjAxOCB1bSAxNzoxMyBzY2hyaWViIEFkYW0gUm9h Y2ggPGFkYW1Abm9zdHJ1bS5jb20+Og0KPiA+DQo+ID4gT24gMTEvMzAvMTggNzo1NCBBTSwgTWly amEgS3VlaGxld2luZCAoSUVURikgd3JvdGU6DQo+ID4+IFllcywgYXMgdGhlc2UgYXJlIGxpc3Rl ZCBpbiB0aGUgd2VsbC1rbm93biBhYmJyZXZpYXRpb25zIGxpc3QsIEkgZG9u4oCZdA0KPiB0aGlu ayB3ZSBzaG91bGQgc3BlbGwgdGhlbSBvdXQgaW4gdGhlIHRpdGxlLg0KPiA+DQo+ID4NCj4gPiBJ dCBpcywgb2YgY291cnNlLCB1cCB0byB5b3UgYW5kIHRoZSBhdXRob3JzIHdoYXQgeW91IHdhbnQg dG8gcHJvZ3Jlc3M7DQo+IGJ1dCBJJ2xsIHBvaW50IG91dCB0aGF0IE9XQU1QIGFuZCBUV0FNUCBh cmUgc3BlY2lmaWNhbGx5IF9ub3RfIG1hcmtlZCB3aXRoDQo+IGFuIGFzdGVyaXNrIGF0IDxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cu cmZjLTJEZWRpdG9yLm9yZ19tYXRlcmlhbHNfYWJicmV2LmV4cGFuc2lvbi50eHQmZD1Ed0lGYVEm Yz1MRllaLQ0KPiBvOV9IVU1lTVRTUWljdmpJZyZyPU9mc1N1OGtUSWx0VnlEMW9MNzJjQncmbT1B ODMxZUhrczM4bU1MdjAtDQo+IHJHc0ExZFBma1hXVFZyMjZhYUpIc1k1amZudyZzPU42a3ZKRWtB Z3hGcHFSMTFjbW42T0lyWHNVZnhSVkxlaVl6TlE0WEkxcjAmDQo+IGU9PiAoIkluIHRoZSBmb2xs b3dpbmcgbGlzdCBvZiBhYmJyZXZpYXRpb25zLCB0aG9zZSB0aGF0IGFyZSB1c3VhbGx5IChidXQN Cj4gbm90IG5lY2Vzc2FyaWx5KSB0cmVhdGVkIGFzICd3ZWxsIGtub3duJyBhcmUgbWFya2VkIHdp dGggYXN0ZXJpc2tzLiIpDQo+ID4NCj4gPg0KPiA+PiBJ4oCZbSBhbHNvIG5vdCBzdXJlIGFib3V0 IGV4cGFuZGluZyBpbiB0aGUgYWJzdHJhY3QgYnV0IHNwZWxsaW5nIHRoZW0gb3V0DQo+IGluIHRo ZSBpbnRybyBjbGVhcmx5IGlzIGEgZ29vZCBpZGVhIGFueXdheS4NCj4gPg0KPiA+DQo+ID4gVGhl IGd1aWRhbmNlIGhlcmUgKGFsc28gZnJvbSB0aGUgcGFnZSBjaXRlZCBhYm92ZSkgaXM6ICJFZGl0 b3JpYWwNCj4gZ3VpZGVsaW5lcyBmb3IgdGhlIFJGQyBzZXJpZXMgZ2VuZXJhbGx5IHJlcXVpcmUg ZXhwYW5zaW9uIG9mIHRoZXNlDQo+IGFiYnJldmlhdGlvbnMgb24gZmlyc3Qgb2NjdXJyZW5jZSBp biBhIHRpdGxlLCBpbiBhbiBhYnN0cmFjdCwgb3IgaW4gdGhlDQo+IGJvZHkgb2YgdGhlIGRvY3Vt ZW50LiIgQWdhaW4sIGl0J3MgdXAgdG8geW91IHdoYXQgdG8gZG8gaGVyZSwgYnV0IG15DQo+IHN1 Z2dlc3Rpb24gcmVtYWlucyBleHBhbmRpbmcgdGhlc2UgYWNyb255bXMuDQo+ID4NCj4gPiBJIGRv IHRha2UgdGhlIHBvaW50IHRoYXQgdGhpcyBtYWtlcyB0aGUgdGl0bGUgcmF0aGVyIGxvbmcuIFBl cmhhcHMNCj4gY29uc2lkZXIgc29tZXRoaW5nIGxpa2UgIk9uZS1XYXkgYW5kIFR3by1XYXkgQWN0 aXZlIE1lYXN1cmVtZW50IFByb3RvY29sDQo+IChPV0FNUCBhbmQgVFdBTVApIFdlbGwtS25vd24g UG9ydCBBc3NpZ25tZW50cyIuDQo+ID4NCj4gPiAvYQ0KPiA+DQo+ID4NCg0K