From nobody Sun Apr 2 06:15:42 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C723E128CB9 for ; Sun, 2 Apr 2017 06:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9m3AZOup8ut for ; Sun, 2 Apr 2017 06:15:38 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id DB35C128DE5 for ; Sun, 2 Apr 2017 06:15:37 -0700 (PDT) Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id E592061832; Sun, 2 Apr 2017 13:15:36 +0000 (UTC) References: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> <00c501d2a8a5$265dfe10$7319fa30$@ndzh.com> <002001d2a8a8$2f2dd2b0$8d897810$@ndzh.com> User-agent: mu4e 0.9.19; emacs 25.1.1 From: Christian Hopps To: Susan Hares Cc: "'Acee Lindem \(acee\)'" , rtgwg@ietf.org Subject: Re: Question on draft-ietf-rtgwg-routing-types In-reply-to: <002001d2a8a8$2f2dd2b0$8d897810$@ndzh.com> Date: Sun, 02 Apr 2017 09:15:35 -0400 Message-ID: <878tnj54so.fsf@chopps.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 13:15:40 -0000 --=-=-= Content-Type: text/plain Susan Hares writes: > Acee: > > I was querying about operational experience with draft-ietf-rtgwg-routing-types as input for IDR. IDR has adopted BGP model that predates this work. Hi Sue, There are a few openconfig folks on the design team although there are differing levels of participation so something may have been missed in the initial revisions. Please feel free to suggest types from the OpenConfig BGP model that would be useful for other routing modules. :) Thanks, Chris. > Sue > > From: Acee Lindem (acee) [mailto:acee@cisco.com] > Sent: Wednesday, March 29, 2017 12:12 PM > To: Susan Hares; rtgwg@ietf.org > Subject: Re: Question on draft-ietf-rtgwg-routing-types > > From: Susan Hares > Date: Wednesday, March 29, 2017 at 10:57 AM > To: Acee Lindem , Routing WG > Subject: RE: Question on draft-ietf-rtgwg-routing-types > > Acee: > > Thank you. Just to clarify your answer, does mean you had a discussion with the operators (e.g. openconfig) who implement the basic BGP model as well? > > If you have looked OpenConfig models in Github, they have their own factoring of types. The bigger question of OpenConfig and IETF models is certainly not addressed by this model. > > Acee > > Sue > > From: Acee Lindem (acee) [mailto:acee@cisco.com] > Sent: Wednesday, March 29, 2017 11:47 AM > To: Susan Hares; rtgwg@ietf.org > Subject: Re: Question on draft-ietf-rtgwg-routing-types > > Hi Sue, > > We incorporated the types that were required for L3VPN/L2VPN models. Specifically, route-distinguisher, route-target, route-target-type, and the vpn-route-target. There was an extensive discussion with the authors of these models. > > Thanks, > > Acee > > From: rtgwg on behalf of Susan Hares > Date: Wednesday, March 29, 2017 at 10:35 AM > To: Routing WG > Subject: Question on draft-ietf-rtgwg-routing-types > > RTGWG DT: > > Just curious, did the DT consider BGP routing types? If so, where did you decide BGP routing types were not common routing types? > > Sue --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAljg+XcACgkQLh2DDte4 MCUb7BAAgCaN/O+41EWUGKKFcuaWQP9suceO0qse3iyhA4FrY3ZOwuW2Ob4Ns0UB hUWp5/Rc6NZlzOm4WjwrCE266XaeHW+weF7JqUm6H9GnkMfeoKJt+SNE8hJjm+y/ sMNxAlmHB7ALgGlqS6PZVJGbMIBhy/n8UVL5xEyS/Rdw/YxzRryEiwTYW//G+2ov gJ8aQl6EAC7W5jtdmoZyZUebwcLkOyYiwYhCWuXK3FnpRyw8L0fsp923XLzX1Oyk G3SQZeN60KSTVft/+Ju6gtOuP6pkYYrBDt7L0DgeHmujtnmVzxMz2alEBA53i28X TpXc69Wcaj07XHRmb9d0XgmYMjvzCVnP9S2fK5PH/Lj1q5orcUfavzmKHxb7qaqA K6ZNIaBAdOAKkGWGLCRa+Evzhls+q36pXReBRAyP07P6TUeu+Ngva4rZsNQsjtv4 4leFfD/glXDuqKvKvr3aEJUTCDvlxf0iBbxYNAjchfFf3xAQbWOQ25GJOyXEeCae ACS3Nu7Sj2xA/vB2l+qvA8kNaI718rWONPMDLEbP49BT2V5+5AmPvlHpBihGmZP5 PnWRQO90S7khlPRlsz7hBxnUEEzAOGebzEznO+bZYktoTDGsvRiM7fSmBO9Q5wGO 9WD7zdYanqKJlZSofTO3+QYH/8//L6BiRxYJ/Azh3ZG7XDpaC2w= =4D74 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Apr 2 06:27:03 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069E81293DB for ; Sun, 2 Apr 2017 06:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ghp_f-aTpGlQ for ; Sun, 2 Apr 2017 06:26:58 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7C812704B for ; Sun, 2 Apr 2017 06:26:58 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 3D1271E1D3; Sun, 2 Apr 2017 09:33:38 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1B5C8211-5BEF-4017-A329-E2B12B268E87" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Question on draft-ietf-rtgwg-routing-types From: Jeffrey Haas In-Reply-To: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> Date: Sun, 2 Apr 2017 09:26:55 -0400 Cc: rtgwg@ietf.org Message-Id: References: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> To: Sue Hares X-Mailer: Apple Mail (2.3259) Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 13:27:01 -0000 --Apple-Mail=_1B5C8211-5BEF-4017-A329-E2B12B268E87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 29, 2017, at 11:35 AM, Susan Hares wrote: >=20 > RTGWG DT:=20 > =20 > Just curious, did the DT consider BGP routing types? If so, where did = you decide BGP routing types were not common routing types? =20 FWIW, I had already flagged to a few members of the design team that the = route-target types are not sufficiently general. I owe them an email about the details, which I'll do when I have a pause = in my travels. -- Jeff --Apple-Mail=_1B5C8211-5BEF-4017-A329-E2B12B268E87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mar 29, 2017, at 11:35 AM, Susan Hares <shares@ndzh.com> = wrote:

RTGWG DT: 
 
Just = curious, did the DT consider BGP routing types?  If so, where did = you decide BGP routing types were not common routing types? =  

FWIW, I = had already flagged to a few members of the design team that the = route-target types are not sufficiently general.

I owe them an email about the details, which I'll = do when I have a pause in my travels.

-- Jeff

= --Apple-Mail=_1B5C8211-5BEF-4017-A329-E2B12B268E87-- From nobody Sun Apr 2 08:17:01 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7F8129473 for ; Sun, 2 Apr 2017 08:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.695 X-Spam-Level: X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 SyoKagZ_TNYU for ; Sun, 2 Apr 2017 08:16:57 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id D45E4128C81 for ; Sun, 2 Apr 2017 08:16:57 -0700 (PDT) Received: (qmail 14109 invoked by uid 0); 2 Apr 2017 15:16:55 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 2 Apr 2017 15:16:55 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 3TGr1v00W2SSUrH01TGuhw; Sun, 02 Apr 2017 09:16:55 -0600 X-Authority-Analysis: v=2.2 cv=LIwWeNe9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=AzvcPWV-tVgA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=1sjgXBK7AAAA:8 a=48vgC7mUAAAA:8 a=Igm-X3-OErGU2H59aBIA:9 a=CjuIK1q_8ugA:10 a=rKrVYePj7rwA:10 a=pi3-yr8yO_zqpSwmd0MA:9 a=HCpUvJAvz56Vt7wt:21 a=UiCQ7L4-1S4A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=qowbMnUzjQcM5iyYROrS:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=PL93i+YV4Yi1Jwc4AiCO7NSkCdbxFjeR9DOzKUfu7/U=; b=fnvoqVa6ek2sTNwmhnUdXk6Jeu Ic4JDCbPx065TUWt+n2Uy7SoRXhi+r6XaTFhiTFnNAsWHXrBOA+QyCCClmRMpLuhR6Qsqx9PIW+yB nljFmc87MYOOSKlFJN1+8kXho; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:47238 helo=[11.4.0.6]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cuhFL-0003p7-9D; Sun, 02 Apr 2017 09:16:51 -0600 From: Lou Berger To: Susan Hares , Date: Sun, 02 Apr 2017 11:16:49 -0400 Message-ID: <15b2f3d76e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> References: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> User-Agent: AquaMail/1.8.2-216 (build: 100800200) Subject: Re: Question on draft-ietf-rtgwg-routing-types MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------15b2f3d78c227d27d33d09e35" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1cuhFL-0003p7-9D X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([11.4.0.6]) [100.15.84.20]:47238 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 15:17:00 -0000 This is a multi-part message in MIME format. ------------15b2f3d78c227d27d33d09e35 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Hi Sue, I took another look at bgp types and the only thing that jumps out at me as common that isn't already covered is enumeration of protocols (for potential use in route redistribution and interface config). We can certainly consider this if this what you were thinking about. Are there are types you think we overlooked? Lou On March 29, 2017 11:41:25 AM "Susan Hares" wrote: > RTGWG DT: > > > > Just curious, did the DT consider BGP routing types? If so, where did you > decide BGP routing types were not common routing types? > > > > Sue > > > > > > > > > ---------- > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > ------------15b2f3d78c227d27d33d09e35 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Hi Sue,

I took another look at bgp types and the only thing that jumps out at me as common that isn't already covered is enumeration of protocols  (for potential use in route redistribution and interface config).  We can certainly consider this if this what you were thinking about.

Are there are types you think we overlooked?

Lou

On March 29, 2017 11:41:25 AM "Susan Hares" <shares@ndzh.com> wrote:

RTGWG DT:

 

Just curious, did the DT consider BGP routing types?  If so, where did you decide BGP routing types were not common routing types?  

 

Sue

 

 

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

------------15b2f3d78c227d27d33d09e35-- From nobody Sun Apr 2 08:17:29 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E8B127010 for ; Sun, 2 Apr 2017 08:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.695 X-Spam-Level: X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 uKsti3fwh6Pn for ; Sun, 2 Apr 2017 08:17:26 -0700 (PDT) Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 75EA4129473 for ; Sun, 2 Apr 2017 08:17:26 -0700 (PDT) Received: from cmgw3 (cmgw4 [10.0.90.84]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 9F98C175A77 for ; Sun, 2 Apr 2017 09:17:24 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 3THL1v00q2SSUrH01THP9L; Sun, 02 Apr 2017 09:17:24 -0600 X-Authority-Analysis: v=2.2 cv=VKStp5HX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=AzvcPWV-tVgA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=1sjgXBK7AAAA:8 a=Q6XCrp0U8GuplQl5XQ4A:9 a=IqxotuLH5cl84XIr:21 a=afuvNTdQPCXoJQO1:21 a=CjuIK1q_8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=O64UODVX2ur98GVsgPIA:9 a=79Ljacg0Tac9wCyP:21 a=g5-n473TM8IiQZNI:21 a=bumTfReOh3TqGq10:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=qowbMnUzjQcM5iyYROrS:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=x8vDBINV5GXv7lQIOIO32yK/oRBwVBE+SpOIE6Fpq0o=; b=WuzSWaIWOknlVpZu01ZwpgUvQr T66HZaSYXY6FP1pc14im1urtNgDUo4GswfCCdgkgNkRZoYdLpL0zXa+U3bRaZYfKuN4Bkl5F1f8pI xUHHcUA/jSjpBjJhqwHLKFJjH; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:55291 helo=[11.4.0.6]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cuhFo-0003sY-Im; Sun, 02 Apr 2017 09:17:20 -0600 From: Lou Berger To: "Acee Lindem (acee)" , Susan Hares , Date: Sun, 02 Apr 2017 11:17:18 -0400 Message-ID: <15b2f3de830.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> User-Agent: AquaMail/1.8.2-216 (build: 100800200) Subject: Re: Question on draft-ietf-rtgwg-routing-types MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------15b2f3dea7227d27d36f32dd0" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1cuhFo-0003sY-Im X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([11.4.0.6]) [100.15.84.20]:55291 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 15:17:28 -0000 This is a multi-part message in MIME format. ------------15b2f3dea7227d27d36f32dd0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Also afi... On March 29, 2017 11:47:28 AM "Acee Lindem (acee)" wrote: > Hi Sue, > We incorporated the types that were required for L3VPN/L2VPN models. > Specifically, route-distinguisher, route-target, route-target-type, and the > vpn-route-target. There was an extensive discussion with the authors of > these models. > Thanks, > Acee > > From: rtgwg > on > behalf of Susan Hares > > Date: Wednesday, March 29, 2017 at 10:35 AM > To: Routing WG > > Subject: Question on draft-ietf-rtgwg-routing-types > > RTGWG DT: > > Just curious, did the DT consider BGP routing types? If so, where did you > decide BGP routing types were not common routing types? > > Sue > > > > > > ---------- > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > ------------15b2f3dea7227d27d36f32dd0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Also afi...

On March 29, 2017 11:47:28 AM "Acee Lindem (acee)" <acee@cisco.com> wrote:

Hi Sue, 
We incorporated the types that were required for L3VPN/L2VPN models. Specifically, route-distinguisher, route-target, route-target-type, and the vpn-route-target. There was an extensive discussion with the authors of these models. 
Thanks,
Acee

From: rtgwg <rtgwg-bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com>
Date: Wednesday, March 29, 2017 at 10:35 AM
To: Routing WG <rtgwg@ietf.org>
Subject: Question on draft-ietf-rtgwg-routing-types

RTGWG DT:

 

Just curious, did the DT consider BGP routing types?  If so, where did you decide BGP routing types were not common routing types?  

 

Sue

 

 

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

------------15b2f3dea7227d27d36f32dd0-- From nobody Wed Apr 5 06:20:46 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A01F127863 for ; Wed, 5 Apr 2017 06:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 O7IoY3OGpAf6 for ; Wed, 5 Apr 2017 06:20:43 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 4811A1250B8 for ; Wed, 5 Apr 2017 06:20:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.36.81.153; From: "Susan Hares" To: "'Lou Berger'" , References: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> <15b2f3d76e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <15b2f3d76e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Subject: RE: Question on draft-ietf-rtgwg-routing-types Date: Wed, 5 Apr 2017 09:15:41 -0400 Message-ID: <00bd01d2ae0e$b9fb1220$2df13660$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BE_01D2ADED.32ECCD80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDXwzi4B96BBr1TfUCFM48H2sYUSwLMXWpio5Yz2bA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:20:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BE_01D2ADED.32ECCD80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Lou: Let me recheck. I thought there was something relating to the MP-BGP that was not covered. I'll get back to you by Thursday am. Sue From: Lou Berger [mailto:lberger@labn.net] Sent: Sunday, April 2, 2017 11:17 AM To: Susan Hares; rtgwg@ietf.org Subject: Re: Question on draft-ietf-rtgwg-routing-types Hi Sue, I took another look at bgp types and the only thing that jumps out at me as common that isn't already covered is enumeration of protocols (for potential use in route redistribution and interface config). We can certainly consider this if this what you were thinking about. Are there are types you think we overlooked? Lou On March 29, 2017 11:41:25 AM "Susan Hares" wrote: RTGWG DT: Just curious, did the DT consider BGP routing types? If so, where did you decide BGP routing types were not common routing types? Sue _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ------=_NextPart_000_00BE_01D2ADED.32ECCD80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lou:

 

Let me recheck.  I = thought there was something relating to the MP-BGP that was not = covered.   I’ll get back to you by Thursday am. =

 

Sue =

 

From:= = Lou Berger [mailto:lberger@labn.net]
Sent: Sunday, April 2, = 2017 11:17 AM
To: Susan Hares; = rtgwg@ietf.org
Subject: Re: Question on = draft-ietf-rtgwg-routing-types

 

Hi = Sue,

I took another look at bgp = types and the only thing that jumps out at me as common that isn't = already covered is enumeration of protocols  (for potential use in = route redistribution and interface config).  We can certainly = consider this if this what you were thinking = about.

Are there are types you think = we overlooked?

Lou

O= n March 29, 2017 11:41:25 AM "Susan Hares" <shares@ndzh.com> = wrote:

RTGWG DT:

 

Just curious, did the DT = consider BGP routing types?  If so, where did you decide BGP = routing types were not common routing types? =  

 

Sue =

 

 

_____________________________________________= __
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org= /mailman/listinfo/rtgwg

------=_NextPart_000_00BE_01D2ADED.32ECCD80-- From nobody Thu Apr 6 09:40:36 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5225112955E; Thu, 6 Apr 2017 09:40:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-uloop-delay-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149149682928.22060.7404108265659324801@ietfa.amsl.com> Date: Thu, 06 Apr 2017 09:40:29 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 16:40:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Micro-loop prevention by introducing a local convergence delay Authors : Stephane Litkowski Bruno Decraene Clarence Filsfils Pierre Francois Filename : draft-ietf-rtgwg-uloop-delay-04.txt Pages : 23 Date : 2017-04-06 Abstract: This document describes a mechanism for link-state routing protocols to prevent local transient forwarding loops in case of link failure. This mechanism proposes a two-steps convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network wide convergence. As this mechanism delays the IGP convergence it may only be used for planned maintenance or when fast reroute protects the traffic between the link failure time and the IGP convergence. The proposed mechanism will be limited to the link down event in order to keep simplicity. Simulations using real network topologies have been performed and show that local loops are a significant portion (>50%) of the total forwarding loops. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-uloop-delay-04 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-uloop-delay-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-uloop-delay-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 Fri Apr 7 02:55:48 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F20C12783A; Fri, 7 Apr 2017 02:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHHIQVoM6AT2; Fri, 7 Apr 2017 02:55:39 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10093.outbound.protection.outlook.com [40.107.1.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4001200DF; Fri, 7 Apr 2017 02:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MOulneM97Byv8lG29izuRp00h/NFjw5CxKHXa+3qJUM=; b=EbU8WPyr52UWm1gUYBC5Zmc3UkSC7vEQfnCzweypqbiuaXgN63s93+hIv09b5euV41mMTjB1mskay2Rl8kZfDBdeFcxhwIB8yRXWgMhzIQ4IHpD9UfmKwormJ9DN42T6NIfQgD6geX+IDxYZS11GEuNsdxlvlKS0eI4lETeLJlw= Received: from DB4PR07MB314.eurprd07.prod.outlook.com (10.141.234.15) by DB4PR07MB315.eurprd07.prod.outlook.com (10.141.234.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Fri, 7 Apr 2017 09:55:36 +0000 Received: from DB4PR07MB314.eurprd07.prod.outlook.com ([10.141.234.15]) by DB4PR07MB314.eurprd07.prod.outlook.com ([10.141.234.15]) with mapi id 15.01.1019.021; Fri, 7 Apr 2017 09:55:35 +0000 From: "Bocci, Matthew (Nokia - GB)" To: "bier@ietf.org" , "rtgwg@ietf.org" , "sfc@ietf.org" CC: Alia Atlas , "nvo3-chairs@ietf.org" Subject: WG adoption call of OAM drafts in NVO3 Thread-Topic: WG adoption call of OAM drafts in NVO3 Thread-Index: AQHSr4UaFFkL5W1aTUW+Qil//t4Svg== Date: Fri, 7 Apr 2017 09:55:35 +0000 Message-ID: <011C4A09-BD1B-497A-A114-1B3FF1BB14C5@nokia.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [81.129.17.253] x-microsoft-exchange-diagnostics: 1; DB4PR07MB315; 7:m3RSciDB2b9YMn/dV+HNIjIarIgetmOFMiLwJeyODXZ6D03aVrq7oWyMEwRyDCc3nEhDPmbJe4Lpr+UyF4YJONOmJjgjlRdM+g17x0XqZCeRBTABJ7hkcDb65ltKCCIm7NA+mEewxZ5Xt0VsFG2S+He3ZhtJ7f4oLt9tKVGIHbctTS4jkANibnzCL8ySWBw3WNgdX8m4Ww8njX7aDTi6HM3LzGXpIQY8iJZ2HjFEMKU0VgQtqA4Hsix/GBciynwQL+1KV0LlF2b6hx3GlbD91Wn2hz1/pPag3wuhB9t+z/iXgUzXQn/rhGFPp3dZpfVxoGhImPaD4Q6M/eskfU8mNg== x-ms-office365-filtering-correlation-id: 3fd6409a-bcde-41ed-fead-08d47d9c3d13 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB4PR07MB315; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:DB4PR07MB315; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB315; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39410400002)(39840400002)(39400400002)(39850400002)(3660700001)(82746002)(83716003)(36756003)(2900100001)(6306002)(99286003)(54896002)(66066001)(6512007)(6436002)(6486002)(33656002)(54906002)(4326008)(8676002)(6506006)(83506001)(38730400002)(2501003)(53936002)(81166006)(8936002)(77096006)(4001350100001)(7736002)(3846002)(6116002)(189998001)(2201001)(86362001)(54356999)(102836003)(2906002)(50986999)(558084003)(3280700002)(122556002)(39060400002)(25786009)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR07MB315; H:DB4PR07MB314.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_011C4A09BD1B497AA1141B3FF1BB14C5nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2017 09:55:35.7602 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB315 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 09:55:41 -0000 --_000_011C4A09BD1B497AA1141B3FF1BB14C5nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNCldlIGFyZSBjdXJyZW50bHkgcG9sbGluZyBmb3IgYWRvcHRpb24gaW4gdGhlIE5W TzMgd29ya2luZyBncm91cCBvZiB0aGUgZm9sbG93aW5nIHR3byBkcmFmdHMgcmVsYXRlZCB0byBv dmVybGF5IE9BTS4NCg0KZHJhZnQtb29hbWR0LXJ0Z3dnLW9vYW0taGVhZGVyLTAzDQpkcmFmdC1v b2FtZHQtcnRnd2ctZGVtYW5kLWNjLWN2LTAzDQoNClBsZWFzZSBwb3N0IGFueSBjb21tZW50cyB0 byB0aGUgTlZPMyBtYWlsaW5nIGxpc3QuDQoNClRoYW5rcw0KDQpNYXR0aGV3IGFuZCBTYW0NCihO Vk8zIFdHIGNvLWNoYWlycykNCg== --_000_011C4A09BD1B497AA1141B3FF1BB14C5nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <56C04524A146894DB087433F63AAB2AE@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkZvbGtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+V2Ug YXJlIGN1cnJlbnRseSBwb2xsaW5nIGZvciBhZG9wdGlvbiBpbiB0aGUgTlZPMyB3b3JraW5nIGdy b3VwIG9mIHRoZSBmb2xsb3dpbmcgdHdvIGRyYWZ0cyByZWxhdGVkIHRvIG92ZXJsYXkgT0FNLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ZHJhZnQtb29hbWR0LXJ0 Z3dnLW9vYW0taGVhZGVyLTAzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmRyYWZ0LW9vYW1kdC1ydGd3Zy1k ZW1hbmQtY2MtY3YtMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlBsZWFzZSBwb3N0IGFueSBjb21tZW50cyB0byB0aGUgTlZPMyBtYWlsaW5nIGxpc3QuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3M8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk1hdHRoZXcgYW5kIFNhbSA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+KE5WTzMgV0cgY28tY2hhaXJzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_011C4A09BD1B497AA1141B3FF1BB14C5nokiacom_-- From nobody Fri Apr 7 10:59:08 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F387129552; Fri, 7 Apr 2017 10:58:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: draft-ietf-rtgwg-yang-key-chain.all@ietf.org, ietf@ietf.org, rtgwg@ietf.org Subject: Genart last call review of draft-ietf-rtgwg-yang-key-chain-17 X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149158793224.11224.1489071223626497682@ietfa.amsl.com> Date: Fri, 07 Apr 2017 10:58:52 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:58:52 -0000 Reviewer: Matthew Miller Review result: Almost Ready 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-rtgwg-yang-key-chain-17 Reviewer: Matthew A. Miller Review Date: 2017-04-07 IETF LC End Date: 2017-04-07 IESG Telechat date: 2017-04-13 Summary: This document is almost ready to be published as a Proposed Standard, once the issues noted herein are resolved. Major issues: NONE Minor issues: * Forgive me for my limited knowledge of YANG, but is there a reason key-strings are only representable as either a YANG string or hex-string type, and not the YANG binary type? * This document does not provide much guidance around AES key wrap other than it can be used and the KEK is provided out-of-band/-context. For instance, AES key-wrapped key-strings probably require using "hexidecimal-string". Also, assuming I'm reading the model correctly, it appears this feature applies to the whole chain, which I think is worth calling out. * This document warns against using the "clear-text" algorithm, which the reader is lead to understand is for legacy implementation reasons. However, is there not a similar concern with cryptographically weak algorithms, such as md5 and (arguably) sha1? Nits/editorial comments: * In Section 3.2. "Key Chain Model Features", the word "of" is missing between "configuration" and "an" in the phrase "support configuration an acceptance tolerance". Non-nits: * I note that idnits is calling out some odd spacing issues, but I think they are safe to ignore. From nobody Fri Apr 7 13:57:14 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5386012786A; Fri, 7 Apr 2017 13:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LSaj6A3vdxL; Fri, 7 Apr 2017 13:56:56 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEAE120454; Fri, 7 Apr 2017 13:56:54 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id b187so99400864oif.0; Fri, 07 Apr 2017 13:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZtYxLllyN1b6oq+E76CqYS0TFubwBGvLtCrT4O30jlA=; b=XtJofOlpbP9SFCoQbPR2ReHgigRZKU14XMyghU3XJV/aRGjlyAhWO20tLOe4ZEgeLu STs9Ey5KOfAYduL6kgaG7JrEWkyVxzgaC2FaAa+FC0crrzLSy0oY0q9LY0EMfHeRludk mUnX1Ru4u6Jc1km8l0NGWuvhvMtwGauosE+UAS5CRFLEOfmCZ9AknkN2EI8iJAiBd8qj erAkjYUzh3PXffksyeYpArLhCvertJZ0SACc+2tzEK87F89jM21OhiRk+bGnLYteXsaI 9/KO5LmlR3FkT74Mkl9LuaAaxa7zBIPWUVVAPKJLxP5IRHC/6u0ca5VGRZeDP9Vfqoxf z2jA== 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=ZtYxLllyN1b6oq+E76CqYS0TFubwBGvLtCrT4O30jlA=; b=JF+hDSBeEGq2mV5VgYsBKUUOqsDdzSgQeoS9gySZQEvJgaJOqQvCGMeQJfDy4EqGLm tpVF3/YJoG4eLq/Mcqz7G7Ri1OFYAB+EUIk7Fi4vEiNLF6NKGDk3mKUB64LWGLJov6nF LlvZOoCmoLGEoZgc3h94DTs8OxilTSq+tHm9X2wcXLKfRt49M0l/QPJ6+d6P8XpJgbFw InH10beCuZxoEKopkpRp40e6uwRhLELBIBYIfP4Jp2OowCQz3U5jx5SD5u4CmaDaJvRu WA1jXtFBti2U50TJyUyYW8vJRa1LxydsvQkT9cdrI0EHB09iMz6K/+0XPv5/0Fy1n65R CtMQ== X-Gm-Message-State: AFeK/H2eS5Sv6tq5LUgDkiTaPqFs9xZYXcoRHsg7aXiUUWggZdwkMLumSA/JpsUHN++pv0nYpXj8XNNGgUTDFA== X-Received: by 10.157.49.11 with SMTP id e11mr24719547otc.206.1491598613486; Fri, 07 Apr 2017 13:56:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Fri, 7 Apr 2017 13:56:52 -0700 (PDT) In-Reply-To: References: <16320f45864d445f9a1bc3463d0c6352@TELMBXB02RM001.telecomitalia.local> From: Greg Mirsky Date: Fri, 7 Apr 2017 13:56:52 -0700 Message-ID: Subject: Re: Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03 To: David Mozes , "rtgwg@ietf.org" , sfc@ietf.org, bier@ietf.org Cc: Fioccola Giuseppe , "Bocci, Matthew (Nokia - GB)" , NVO3 , "draft-ooamdt-rtgwg-ooam-header@ietf.org" Content-Type: multipart/related; boundary=001a1146eeda8142b5054c99dde7 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 20:57:00 -0000 --001a1146eeda8142b5054c99dde7 Content-Type: multipart/alternative; boundary=001a1146eeda8142b3054c99dde6 --001a1146eeda8142b3054c99dde6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David, please find my notes in-line tagged GIM2>>. Regards, Greg On Thu, Apr 6, 2017 at 12:32 AM, David Mozes wrote: > Greg , > > I have a lot to say on what you write below , but let put the discussion > in the right content. > > The main thing is: > > I think yours work and the OAM design team should be focus to define the > OAM related data and the OAM mechanism and there is a lot to do on this > area .and try to make it uniform on all the diffenet encapsulations > (NVO3,BEIR,SFC) and not dealing with the encapsulation itself. By this yo= u > mixed all things up and we will achieve nothing . > GIM2>> I feel that you assume that the proposed solution is for NVO3 only and thus had not thought about SFC and BIER. Dave Dolson had pointed out that the proposed solution is beneficial for SFC. > > > > > Specifically: > > 1)The extension header (container) concept was discussed on the encap > design team . the content was to make VXLN-GPE extendable (While it is no= t > by adding NSH header to it and was rejected because of the bytes overhea= d > (less bytes than your proposal). > Now you like to take encap protocol with build in extension and add to it > extension header ? what we will do with other extensions like security a= dd > extension header as well ? This doesn=E2=80=99t make sense and not neede= d in all > the cases > GIM2>> What are these cases that don't require active OAM? > 2) the total header length on the base header is important and help for > parsing in all the cases especially when you don=E2=80=99t like to deal w= ith the > extensions . > > 3) 8 bytes overhead is important > GIM2>> To be precise, if I look at TLV-based approach then the difference is, at most, 4 bytes. > 4)and adding ether type to the parsing graph is costly and can complicate > things especially if you need to parse options(TLV) before > GIM2>> What EtherType? Who says that active OAM must be combined with TLVs? The benefit, in my opinion, of using Overlay Associated Channel, is that it is self-contained and processing can be offloaded once the packet was identified as OAC packet. > > > Thx > > David > > > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* Wednesday, April 05, 2017 10:44 PM > > *To:* David Mozes > *Cc:* Fioccola Giuseppe ; Bocci, > Matthew (Nokia - GB) ; NVO3 ; > draft-ooamdt-rtgwg-ooam-header@ietf.org > *Subject:* Re: Poll for NVO3 WG adoption and IPR call for > draft-ooamdt-rtgwg-ooam-header-03 > > > > Hi David, > > thank you for your detailed follow-up comments. Please find my notes > in-line and tagged GIM>>. > > > > Regards, > > Greg > > > > On Wed, Apr 5, 2017 at 10:54 AM, David Mozes wrote: > > Hi Greg , > > PSB > > > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* Wednesday, April 05, 2017 2:23 AM > *To:* David Mozes > *Cc:* Fioccola Giuseppe ; Bocci, > Matthew (Nokia - GB) ; NVO3 ; > draft-ooamdt-rtgwg-ooam-header@ietf.org > *Subject:* Re: Poll for NVO3 WG adoption and IPR call for > draft-ooamdt-rtgwg-ooam-header-03 > > > > Hi David, > > thank you for sharing your opinion. > > Could you please clarify your position. You propose to use > extensions/options for end-to-end active OAM? > > David> yes > > Let us look at proactive continuity check between NVEs. Why you think a > middlebox needs to be aware of the OAM payload? > > I believe that a transient NVO3 node should not look into payload if it i= s > not addressed to it at all. > > David> Are you limit the header just for proactive OAM ? so change the > draft to include just that . On the current draft I see all kinds of OAM > > GIM>> I want to point that the draft introduces Associated Channel for an > overlay network. Associated Channel may be used for signalling or OAM. OA= M > methods enable operators to perform Fault Management and Performance > Monitoring. Among functions required to perform comprehensive Fault > Management are: > > - failure detection, usually detection of Loss of Continuity but may > include Mis-connection defect as well for connection-oriented network; > - defect localization; > - Alarm Indication Signal; > - Remote Defect Indication. > > Depending on the requirements towards resiliency and restoration, > Protection Switchover Coordination protocol may be required. > > Performance Measurement usually supports the following: > > - one-way and two-way Packet Loss measurement; > - one-way and two-way Packet Delay measurement; > - Synthetic Loss Measurement. > > Service Activation Protocol, as part of active OAM toolset, usually > combines OAM functions from FM and PM operations. > > The goal of Overlay OAM work, as I understand, is to create common set of > OAM protocols that supports all of listed above FM and PM operations. I s= ee > such set as combination of active, hybrid and passive OAM methods. I > believe that the draft states that clearly. The proactive OAM is usually > used to perform monitor network for defects and performance degradation. > On-demand OAM tools may be used to localize the defects. > > > > > While I agree with you regarding Middle box and proactive OAM .The > same can be achieve with the protocol extensions > > Thus I don't agree that the requirement you refer to is applicable to use > of active OAM. > > David> I think if the WG decide on NVO3 encap protocol that include > extension (Like GUE and Geneve) we have to use the build in extensions f= or > such protocol and not innovate extra header that use for protocols > without extensions. > > GIM>> I question your assumption that use of variable length header > mandates how OAM, active OAM, must be implemented. And since some network= s > choose to use fixed size header, using Overlay Associated Channel header > with multiplexed Overlay OAM functionality appears, in my opinion, as > common solution for either type of overlay encapsulation. > > > > David > > Greg > > > > On Mon, Apr 3, 2017 at 11:19 AM, David Mozes wrote: > > Hi , > > I am not supporting the adoption > > I think while the working group decided on Geneve as the encap protocol > > > > This OAM need to be via one of the extensions/options the protocol is > supporting! > > > > This header also violate the number 1 requirements from the > extensions/options > > That node/middlbox don not need to be part of the extensions/ option ca= n > jump directly to the overlay by reading the base header length only > > > > Thx > > David > > > > *From:* nvo3 [mailto:nvo3-bounces@ietf.org] *On Behalf Of *Fioccola > Giuseppe > *Sent:* Monday, April 03, 2017 5:40 PM > *To:* Bocci, Matthew (Nokia - GB) ; NVO3 < > nvo3@ietf.org>; draft-ooamdt-rtgwg-ooam-header@ietf.org > *Subject:* [nvo3] R: Poll for NVO3 WG adoption and IPR call for > draft-ooamdt-rtgwg-ooam-header-03 > > > > Hi All, > > I have read the draft and support its adoption. > > > > Regards, > > > > Giuseppe > > > > *Da:* nvo3 [mailto:nvo3-bounces@ietf.org ] *Per > conto di *Bocci, Matthew (Nokia - GB) > *Inviato:* venerd=C3=AC 31 marzo 2017 17:35 > *A:* NVO3; draft-ooamdt-rtgwg-ooam-header@ietf.org > *Oggetto:* [nvo3] Poll for NVO3 WG adoption and IPR call for > draft-ooamdt-rtgwg-ooam-header-03 > > > > This email begins a two week poll for adoption of draft-ooamdt-rtgwg-ooam= -header-03 > in the NVO3 working group. > > > > Please review the draft and send any comments to the NVO3 list. > > Please also indicate whether you support adoption of the draft as an NVO3 > working group document. > > > > Simultaneously, we are also poling for any IPR that may apply to the draf= t. > > > > Authors and contributors, are you aware of any IPR that applies to this > draft? > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details)? > > > > If you are listed as a document author or contributor, please respond to > > this email stating of whether or not you are aware of any relevant > > IPR. The response needs to be sent to the NVO3 WG mailing list. The > > document will not advance to the next stage until a response > > has been received from each author and each contributor. > > > > This poll closes on Friday 14th April 2017. > > > > Regards > > > > Matthew and Sam > > 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. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > *This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments an= d > advise the sender by return e-mail, Thanks.* > > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mai= l > se non =C3=A8 necessario.* > > > > > > > --001a1146eeda8142b3054c99dde6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David,
please find my notes in-line tagged GIM2>= >.

Regards,
Greg

On Thu, Apr 6, 2017 at 12:32 AM,= David Mozes <davidm@mellanox.com> wrote:

Greg ,

I have a lot to say on what you write below , but l= et put the discussion in the right content.

The main thing is:

I think yours work and the OAM design team should b= e focus to define the OAM related data and=C2=A0 the OAM mechanism and ther= e is a lot to do on this area .and try to make it uniform on all the diffenet encapsulations (NVO3,BEIR,SFC) and not dealing with th= e encapsulation itself. By this you mixed all things up and we will achieve= nothing .

GIM2>> =C2=A0I fee= l that you assume that the proposed solution is for NVO3 only and thus had = not thought about SFC and BIER. Dave Dolson had pointed out that the propos= ed solution is beneficial for SFC.

=C2=A0

=C2=A0

Specifically:

1)The extension header (container) concept was disc= ussed on the encap design team . the content was to make VXLN-GPE extendabl= e (While it is not by adding NSH=C2=A0 header to it and was rejected because of the bytes overhead (less bytes than your propo= sal).

Now you like to take encap pr= otocol with build=C2=A0 in extension and add to it extension header ?=C2=A0= what we will do with other extensions like security add extension header a= s well=C2=A0 ? This doesn=E2=80=99t make sense and not needed in all the cases

GIM2>> What are these cases that don&= #39;t require active OAM?=C2=A0

2) the total header length on the base header is im= portant and help for parsing in all the cases especially when you don=E2=80= =99t like to deal with the extensions .

3) 8 bytes overhead is important

GIM2>> To be precise, if I look at TLV-based ap= proach then the difference is, at most, 4 bytes.

4)and adding ether type to the parsing graph is cos= tly and can complicate things especially if you need to parse options(TLV)= =C2=A0 before=C2=A0

GIM2>> Wh= at EtherType? Who says that active OAM must be combined with TLVs? The bene= fit, in my opinion, of using Overlay Associated Channel, is that it is self= -contained and processing can be offloaded once the packet was identified a= s OAC packet.

=C2=A0

Thx

David

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Wednesday, April 05, 2017 10:44 PM


To: David Mozes <davidm@mellanox.com>
Cc: Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it&g= t;; Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>; NVO3 <nvo3@ietf.org>; draft-ooam= dt-rtgwg-ooam-header@ietf.org
Subject: Re: Poll for NVO3 WG adoption and IPR call for draft-ooamdt= -rtgwg-ooam-header-03

=C2=A0

Hi David,

thank you for your detailed follow-up comments. Plea= se find my notes in-line and tagged GIM>>.

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Apr 5, 2017 at 10:54 AM, David Mozes <davidm@mellanox.com> wrote:

Hi Greg=C2=A0 ,<= /p>

PSB

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Wednesday, April 05, 2017 2:23 AM
To: David Mozes <davidm@mellanox.com>
Cc: Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it&g= t;; Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>; NVO3 <nvo3@ietf.org&g= t;; draft-ooamdt-rtgwg-ooam-header@ietf.org
Subject: Re: Poll for NVO3 WG adoption and IPR call for draft-ooamdt= -rtgwg-ooam-header-03

=C2=A0

Hi David,

thank you for sharing your opinion.

Could you please clarify your position. You propose = to use extensions/options for end-to-end active OAM?

David> yes

=C2=A0Let us look at proactive continuity check betw= een NVEs. Why you think a middlebox needs to be aware of the OAM payload?

I believe that a transient NVO3 node should not look= into payload if it is not addressed to it at all.

David> Are you limit the header ju= st for proactive OAM ? =C2=A0so change the draft to include just that . On the current =C2=A0draft I see all kinds of OAM

GIM>> I want to point that the draft introduce= s Associated Channel for an overlay network. Associated Channel may be used= for signalling or OAM. OAM methods enable operators to perform Fault Manag= ement and Performance Monitoring. Among functions required to perform comprehensive Fault Management are:

  • failure detection, usually detection of Loss of Continuity but may include = Mis-connection defect as well for connection-oriented network;
  • defect localization;
  • Alarm Indication Signal;
  • Remote Defect Indication.

Depending on the requirements towards resiliency and= restoration, Protection Switchover Coordination protocol may be required.<= u>

Performance Measurement usually supports the followi= ng:

  • one-way and two-way Packet Loss measurement;
  • one-way and two-way Packet Delay measurement;
  • Synthetic Loss Measurement.

Service Activation Protocol, as part of active OAM t= oolset, usually combines OAM functions from FM and PM operations.=

The goal of Overlay OAM work, as I understand, is to= create common set of OAM protocols that supports all of listed above FM an= d PM operations. I see such set as combination of active, hybrid and passiv= e OAM methods. I believe that the draft states that clearly. The proactive OAM is usually used to perform mo= nitor network for defects and performance degradation. On-demand OAM tools = may be used to localize the defects.

=C2=A0

> While=C2=A0 I agree with you reg= arding =C2=A0Middle box and proactive OAM .The same can be achieve with the protocol extensions

Thus I don't agree that the requirement you refe= r to is applicable to use of active OAM.

David> I think if t= he WG decide on NVO3 encap protocol that include =C2=A0extension (Like GUE = and Geneve) we have to use the build in extensions for such protocol and not innovate =C2=A0extra header =C2=A0that use for protocols = without extensions.

GIM>> I question your assumption that use of v= ariable length header mandates how OAM, active OAM, must be implemented. An= d since some networks choose to use fixed size header, using Overlay Associ= ated Channel header with multiplexed Overlay OAM functionality appears, in my opinion, as common solution for either ty= pe of overlay encapsulation.

=C2=A0

David

Greg

=C2=A0

On Mon, Apr 3, 2017 at 11:19 AM, David Mozes <davidm@mellanox.com> wrote:

Hi ,<= /span>

I am = not supporting the adoption

I thi= nk while the working group decided on Geneve as the encap protocol

=C2= =A0

This = OAM need to be via one of the extensions/options=C2=A0 the protocol=C2=A0= =C2=A0 is supporting!

=C2= =A0

This = header also violate the number 1 requirements from the extensions/options= =C2=A0

That = node/middlbox=C2=A0 don not=C2=A0 need to be part of the extensions/ option= can jump directly=C2=A0 to the overlay by reading the base header length only

=C2= =A0

Thx

David

=C2= =A0

From:= nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Fioccola Giuseppe
Sent: Monday, April 03, 2017 5:40 PM
To: Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>; NVO3 <nvo3@ietf.org>; draft-ooamdt-rtgwg-ooam-header@ietf.org
Subject: [nvo3] R: Poll for NVO3 WG adoption and IPR call for draft-= ooamdt-rtgwg-ooam-header-03

=C2=A0

Hi Al= l,

I hav= e read the draft and support its adoption.

=C2= =A0

Regar= ds,

=C2= =A0

Giuse= ppe

=C2= =A0

Da: nvo3 [= mailto:nvo3-boun= ces@ietf.org] Per conto di Bocci, Matthew (Nokia - GB)
Inviato: venerd=C3=AC 31 marzo 2017 17:35
A: NVO3; draft-ooamdt-rtgwg-ooam-header@ietf.org
Oggetto: [nvo3] Poll for NVO3 WG adoption and IPR call for draft-ooa= mdt-rtgwg-ooam-header-03

=C2=A0

This= email begins a two week poll for adoption of draft-ooamdt-rtgwg-ooam-= header-03 in the NVO3 working group.

=C2= =A0

Plea= se review the draft and send any comments to the NVO3 list.

Plea= se also indicate whether you support adoption of the draft as an NVO3 worki= ng group document.

=C2= =A0

Simu= ltaneously, we are also poling for any IPR that may apply to the draft.

=C2= =A0

Auth= ors and contributors, are you aware of any IPR that applies to this draft?<= /span>

=C2= =A0

If s= o, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs = 3979, 4879, 3669 and 5378 for more details)?

=C2= =A0

If y= ou are listed as a document author or contributor, please respond to=

this= email stating of whether or not you are aware of any relevant

IPR.= The response needs to be sent to the NVO3 WG mailing list. The

docu= ment will not advance to the next stage until a response

has = been received from each author and each contributor.

=C2= =A0

This= poll closes on Friday 14th April 2017.

=C2= =A0

Rega= rds

=C2= =A0

Matt= hew and Sam

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

This e-mail and any attachments=C2=A0is=C2=A0confidential and may contain = privileged information intended for the addressee(s) only. Dissemination, copying, pr= inting or use by anybody else is unauthorised. If you are not the intended = recipient, please delete this message and any attachments and advise the se= nder by return e-mail, Thanks.

3D"rispetta= Rispetta l'ambiente. Non stampare questa mail se non =C3=A8 necessario.<= /b>

=C2=A0

=C2=A0

=C2=A0


--001a1146eeda8142b3054c99dde6-- --001a1146eeda8142b5054c99dde7 Content-Type: image/gif; name="image001.gif" Content-Disposition: inline; filename="image001.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 734d5321e2fbe09f_0.1 R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --001a1146eeda8142b5054c99dde7-- From nobody Sat Apr 8 15:56:00 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5A912714F; Sat, 8 Apr 2017 15:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.623 X-Spam-Level: X-Spam-Status: No, score=-12.623 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXtyUZw2JLQz; Sat, 8 Apr 2017 15:55:40 -0700 (PDT) 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 98F6F1250B8; Sat, 8 Apr 2017 15:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2806; q=dns/txt; s=iport; t=1491692140; x=1492901740; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zkVtu0DpB2Azi2hOQXUF+XPu8DkbyNAYSk2OO6g01JI=; b=e2S1wqGEecRZhBbvHwIf0oWaumhFFzA91H4dQs4rGQwESOPZ62Qms7w4 c8iZlU5/GiTXxY+XfEDVjHWbGmPQpeksgIvleBU6UDnlfFkqt+I7bp6HA SzJXzf8Q8SHffB0mJwXUsNXHxscCPPs+QETtu7qWpyCwbR5+cPf+9+Mz3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQCfaelY/4ENJK1CGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNTYYELB41ykUCVV4IPLIV4AoNePxgBAgEBAQEBAQFrKIUWAQQ?= =?us-ascii?q?BeQULAgEIFDIyJQIEAQ0FCYl+CA4xqW+KXAEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R2LQIJwgUIkhWUFkCuFdYZbAYZ/i1mBf4UuihSKNYlKAR84gQVbFYUdG4FjdQG?= =?us-ascii?q?Gb4EwgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,174,1488844800"; d="scan'208";a="409393167" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2017 22:55:39 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v38MtdX4015015 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 8 Apr 2017 22:55:39 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 8 Apr 2017 18:55:35 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Sat, 8 Apr 2017 18:55:36 -0400 From: "Acee Lindem (acee)" To: Matthew Miller , "gen-art@ietf.org" CC: "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" , "ietf@ietf.org" , "rtgwg@ietf.org" Subject: Re: Genart last call review of draft-ietf-rtgwg-yang-key-chain-17 Thread-Topic: Genart last call review of draft-ietf-rtgwg-yang-key-chain-17 Thread-Index: AQHSr8ihxBldHKjCb0K6BYj9/alinKG8FuQA Date: Sat, 8 Apr 2017 22:55:35 +0000 Message-ID: References: <149158793224.11224.1489071223626497682@ietfa.amsl.com> In-Reply-To: <149158793224.11224.1489071223626497682@ietfa.amsl.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.116.152.197] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 22:55:43 -0000 Hi Matt, Thanks for the review. On 4/7/17, 1:58 PM, "Matthew Miller" wrote: >Reviewer: Matthew Miller >Review result: Almost Ready > >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-rtgwg-yang-key-chain-17 >Reviewer: Matthew A. Miller >Review Date: 2017-04-07 >IETF LC End Date: 2017-04-07 >IESG Telechat date: 2017-04-13 > >Summary: > >This document is almost ready to be published as a Proposed Standard, >once the issues noted herein are resolved. > >Major issues: > >NONE > >Minor issues: > >* Forgive me for my limited knowledge of YANG, but is there a reason >key-strings are only representable as either a YANG string or >hex-string type, and not the YANG binary type? Let me ask why I=B9d want to use this type? I can get all the entropy I wan= t with a hex string and implementations are familiar with this representation. I=B9m not really fond of the obscure base64 representation used by the YANG type and if one consults Benoit=B9s search tool, the type is not widely used. http://www.yangcatalog.org/yang-search/yang-search.php > >* This document does not provide much guidance around AES key wrap >other than it can be used and the KEK is provided >out-of-band/-context. >For instance, AES key-wrapped key-strings probably require using >"hexidecimal-string". Yes - I=B9ll add that. > Also, assuming I'm reading the model >correctly, >it appears this feature applies to the whole chain, which I think is >worth calling out. In YANG, if you support a feature, it is for the entire model. The per-chain boolean indicates whether or not it is applies to all the keys in that particular key-chain. I will clarify this. > >* This document warns against using the "clear-text" algorithm, which >the >reader is lead to understand is for legacy implementation reasons. >However, is there not a similar concern with cryptographically weak >algorithms, such as md5 and (arguably) sha1? I can add something for MD5. > >Nits/editorial comments: > >* In Section 3.2. "Key Chain Model Features", the word "of" is >missing >between "configuration" and "an" in the phrase "support configuration >an >acceptance tolerance". Good catch. I will fix. > >Non-nits: > >* I note that idnits is calling out some odd spacing issues, but I >think >they are safe to ignore. Though the line numbers don=B9t match the draft, I was able to fix these. Thanks, Acee=20 > From nobody Sun Apr 9 18:59:57 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87459129405; Sun, 9 Apr 2017 18:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WEYGFzTS3tJ; Sun, 9 Apr 2017 18:59:54 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02931293FC; Sun, 9 Apr 2017 18:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1344; q=dns/txt; s=iport; t=1491789592; x=1492999192; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6Nj0OfX6oqtejTWb0CBOan70/avT6VCiRfCGgNp3LfE=; b=Nuw31Gu1Mvx5FHDvH8KW5Z/7WQu623mf65Ten/dZ8Jk1pr1sRTeo/OSG qA/K7cRlKYddsYfaKq1znub0uw31uP27Y+Mb7IE0ZDYa9nzXCgTfU4QeD 2G4tQn3HuqzEGdBmLIPjrgCCHfz2Nl60KoG8SLU3iTYhaSKz+2I+54Qg9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOBAAp5upY/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygrgWwHnxMfiBqNPYIPhiQCGoNEQRYBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBHQYRRQULAgEIGAICJgICAh8RFRACBA4FG4lcAw0IqFuCJochDYMtAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYELhUWCBQmCYoJRhQsugjEBBJxAOwGOG4Q9gX+?= =?us-ascii?q?FLooUiwCIfwEmATCBBVsVUgGEfoFKdYd7gQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,180,1488844800"; d="scan'208";a="409901562" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2017 01:59:51 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v3A1xpfk010113 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Apr 2017 01:59:51 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 9 Apr 2017 21:59:50 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sun, 9 Apr 2017 21:59:50 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: David Mozes , "rtgwg@ietf.org" , "sfc@ietf.org" , "bier@ietf.org" , "Bocci, Matthew (Nokia - GB)" , NVO3 , "draft-ooamdt-rtgwg-ooam-header@ietf.org" Subject: Re: Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03 Thread-Topic: Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03 Thread-Index: AQHSrqf5WceqzCP3V0C9KzvolVDqmqG6qLQAgAN5UAA= Date: Mon, 10 Apr 2017 01:59:50 +0000 Message-ID: References: <16320f45864d445f9a1bc3463d0c6352@TELMBXB02RM001.telecomitalia.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.217.90] Content-Type: text/plain; charset="utf-8" Content-ID: <3CC268BE710C6C4FB99A895B5E633585@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 01:59:56 -0000 DQoNCj4gT24gQXByIDcsIDIwMTcsIGF0IDQ6NTYgUE0sIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNr eUBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gVGhlIG1haW4gdGhpbmcgaXM6DQo+IA0KPiBJIHRo aW5rIHlvdXJzIHdvcmsgYW5kIHRoZSBPQU0gZGVzaWduIHRlYW0gc2hvdWxkIGJlIGZvY3VzIHRv IGRlZmluZSB0aGUgT0FNIHJlbGF0ZWQgZGF0YSBhbmQgIHRoZSBPQU0gbWVjaGFuaXNtIGFuZCB0 aGVyZSBpcyBhIGxvdCB0byBkbyBvbiB0aGlzIGFyZWEgLmFuZCB0cnkgdG8gbWFrZSBpdCB1bmlm b3JtIG9uIGFsbCB0aGUgZGlmZmVuZXQgZW5jYXBzdWxhdGlvbnMgKE5WTzMsQkVJUixTRkMpIGFu ZCBub3QgZGVhbGluZyB3aXRoIHRoZSBlbmNhcHN1bGF0aW9uIGl0c2VsZi4gQnkgdGhpcyB5b3Ug bWl4ZWQgYWxsIHRoaW5ncyB1cCBhbmQgd2Ugd2lsbCBhY2hpZXZlIG5vdGhpbmcgLg0KPiANCj4g R0lNMj4+ICBJIGZlZWwgdGhhdCB5b3UgYXNzdW1lIHRoYXQgdGhlIHByb3Bvc2VkIHNvbHV0aW9u IGlzIGZvciBOVk8zIG9ubHkgYW5kIHRodXMgaGFkIG5vdCB0aG91Z2h0IGFib3V0IFNGQyBhbmQg QklFUi4gRGF2ZSBEb2xzb24gaGFkIHBvaW50ZWQgb3V0IHRoYXQgdGhlIHByb3Bvc2VkIHNvbHV0 aW9uIGlzIGJlbmVmaWNpYWwgZm9yIFNGQy4NCj4gDQo+IA0KDQpDb3VsZCB5b3UgcGxlYXNlIGVs YWJvcmF0ZSBvbiB3aGF0IHNwZWNpZmljYWxseSBhbmQgcHJlY2lzZWx5IHRoZSBiZW5lZml0IGZv ciBTRkMgaXM/IEkgbWlnaHQgaGF2ZSBtaXNzZWQgd2hhdOKAmXMgb3RoZXIgdGhhbiBvdmVyaGVh ZCBpbiB0aGlzIGluZGlyZWN0aW9uLg0KDQpUaGFua3MsDQoNCuKAlA0KQ2FybG9zIFBpZ25hdGFy bywgY2FybG9zQGNpc2NvLmNvbQ0KDQrigJxTb21ldGltZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQg SSBkbyBub3QgZnVsbHkgdW5kZXJzdGFuZCwgdG8gbWFrZSBteXNlbGYgc291bmQgbW9yZSBwaG90 b3N5bnRoZXNpcy4i From nobody Sun Apr 9 19:08:03 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A289128B8D; Sun, 9 Apr 2017 19:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyKL3QG3cD-t; Sun, 9 Apr 2017 19:07:51 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432A6128B8F; Sun, 9 Apr 2017 19:07:51 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id f22so3161850oib.2; Sun, 09 Apr 2017 19:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=1K63fbjOA7nvuOsdamSHYRrar9Hyi4v5sjePFzmDbbw=; b=r+J2vQXeYeVgyoY4h1SWtE/tS9H7FzfjI/A2vKgbl44mj0VENK/JdRvVfnahxGDZIT 9zQQsQGVF07iFFE6+jnKiq/zG4sYDgPR3Z/T9kEsc4sM/7EIRwTQZ/B4JaECoGHEVEt5 CVe3ksRWHMO0/KZTu+992zWg1PCNwl49pakxOYJbQ3bru2Ysp6Qwh/ovP0+UM1fR4ZO1 gETOL/DtAepcLvyTeJF+0KE4HiX54bA+ZZmF0v62SthRlhN8DmOkFuSXFDKWUxWClLe1 zMn+XjtnMOTfJNr+SJvFD9AxITLim41j0Wkn7x4C3/ZiWorF/TF3LJKamgfyd7jjk/0+ xSpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=1K63fbjOA7nvuOsdamSHYRrar9Hyi4v5sjePFzmDbbw=; b=e4pJhN03HaoBKI9HkTR6LZH9GZr42bMsuIlQzuVFJB9rZ0Si0OYc1i7ciQJ0Ljeoai x7w2wtVO2Dg/fvvMGDksMaS5ysulCTumx0vDiowtZMsCiWSv1G8rA88xIV4REIrnBFFw tGtlP/Lgjw2T+RTyxvmC8cUY2cJiuqRHjEMvlwHJbNg1EzAXRqv8HpoKP6qLMg+7I+qj cVIr9cJFu/cbv2+21dwuURBowjvDqCqcaVGdFzcbn+8YLWbFDPsnY6JyhWBBdC+xvtVa vRo8DBTspW+hsqdBF4KA0yQn6jDrPJ3MvitO44ge8La1kGnKqZUjfNbDNJXINyl4rQKo 5aPA== X-Gm-Message-State: AFeK/H2io6QLmZAj4VPeNdsPSGABdeeIX9izsGnKLXmL+e/esczlKHy9IvNBzn/00gkJN94R4OZgR2mb3yxRaA== X-Received: by 10.202.74.193 with SMTP id x184mr26833673oia.167.1491790070485; Sun, 09 Apr 2017 19:07:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Sun, 9 Apr 2017 19:07:50 -0700 (PDT) From: Greg Mirsky Date: Sun, 9 Apr 2017 19:07:50 -0700 Message-ID: Subject: Re: [nvo3] Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03 To: "Carlos Pignataro (cpignata)" Cc: David Mozes , "Bocci, Matthew (Nokia - GB)" , NVO3 , "draft-ooamdt-rtgwg-ooam-header@ietf.org" , Fioccola Giuseppe , sfc@ietf.org, bier@ietf.org, "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=001a1134f93c3b18da054cc67189 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 02:07:54 -0000 --001a1134f93c3b18da054cc67189 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, if we had the OAM requirements that WGs, i.e. NVO3, SFC, and BIER, agreed on, then, I believe, we only had to check if the proposed solution addresses one of the requirements. I strongly believe that having OAM requirements as working document, not necessarily to be published, is very helpful. But I'm surprised that you suggest that defect indication, in peer and multi-layer OAM interworking in not required. You're co-author of OAM requirements draft in SPRING WG that has the following requirement: REQ#11: When SR OAM is initialized from centralized controller, it MUST have the ability to alert any edge node in SR domain about the corresponding path or service failure. The node on receiving the alert MAY take a local protection action or pop an informational message. Isn't that the functionality that is exactly supported by RDI and AIS? Then in BIER WG adopted OAM Requirements, that you are co-author ed, I find this: 10. BIER OAM MUST support Reverse Defect Indication (RDI) notification of the source of continuity checking BFR by Bit- Forwarding Egress Routers (BFERs), e.g. by using Diag in p2mp BFD with active tail support. and this 13. BIER OAM MUST support defect notification mechanism, like Alarm Indication Signal. Any BFR in the given BIER domain MAY originate a defect notification addressed to any subset of BFRs within the domain. You don't agree with these requirements? Regards, Greg On Thu, Apr 6, 2017 at 7:55 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > David responded to this, though I=E2=80=99d like to add a couple thoughts= , inline. > > > On Apr 5, 2017, at 3:43 PM, Greg Mirsky wrote: > > > > Hi David, > > thank you for your detailed follow-up comments. Please find my notes > in-line and tagged GIM>>. > > > > Regards, > > Greg > > > > On Wed, Apr 5, 2017 at 10:54 AM, David Mozes > wrote: > > Hi Greg , > > > > PSB > > > > > > > > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > > Sent: Wednesday, April 05, 2017 2:23 AM > > To: David Mozes > > Cc: Fioccola Giuseppe ; Bocci, > Matthew (Nokia - GB) ; NVO3 ; > draft-ooamdt-rtgwg-ooam-header@ietf.org > > Subject: Re: Poll for NVO3 WG adoption and IPR call for > draft-ooamdt-rtgwg-ooam-header-03 > > > > > > > > Hi David, > > > > thank you for sharing your opinion. > > > > Could you please clarify your position. You propose to use > extensions/options for end-to-end active OAM? > > > > David> yes > > > > Let us look at proactive continuity check between NVEs. Why you think = a > middlebox needs to be aware of the OAM payload? > > > > I believe that a transient NVO3 node should not look into payload if it > is not addressed to it at all. > > > > David> Are you limit the header just for proactive OAM ? so change the > draft to include just that . On the current draft I see all kinds of OAM > > > > GIM>> I want to point that the draft introduces Associated Channel for > an overlay network. Associated Channel may be used for signalling or OAM. > > Whoa=E2=80=A6 what problem are we solving? Inline signaling of OAM, on a = covert > channel? As if we do not have enough ways already to address the > requirements? > > > OAM methods enable operators to perform Fault Management and Performanc= e > Monitoring. Among functions required to perform comprehensive Fault > Management are: > > =E2=80=A2 failure detection, usually detection of Loss of Continu= ity but > may include Mis-connection defect as well for connection-oriented network= ; > > =E2=80=A2 defect localization; > > =E2=80=A2 Alarm Indication Signal; > > =E2=80=A2 Remote Defect Indication. > > I thought one strong point made quite a few times by operators is to move > into less-ATM-like OAMs and more into traceroute-like tools. Less AIS / > RDIs and more treetrace and udp singers. > > > Depending on the requirements towards resiliency and restoration, > Protection Switchover Coordination protocol may be required. > > Performance Measurement usually supports the following: > > =E2=80=A2 one-way and two-way Packet Loss measurement; > > =E2=80=A2 one-way and two-way Packet Delay measurement; > > =E2=80=A2 Synthetic Loss Measurement. > > Service Activation Protocol, as part of active OAM toolset, usually > combines OAM functions from FM and PM operations. > > The goal of Overlay OAM work, as I understand, is to create common set > of OAM protocols that supports all of listed above FM and PM operations. = I > see such set as combination of active, hybrid and passive OAM methods. I > believe that the draft states that clearly. The proactive OAM is usually > used to perform monitor network for defects and performance degradation. > On-demand OAM tools may be used to localize the defects. > > > > The temperature of the ocean does not seem to change... > > > > > > While I agree with you regarding Middle box and proactive OAM .The > same can be achieve with the protocol extensions > > > > Thus I don't agree that the requirement you refer to is applicable to > use of active OAM. > > > > David> I think if the WG decide on NVO3 encap protocol that include > extension (Like GUE and Geneve) we have to use the build in extensions fo= r > such protocol and not innovate extra header that use for protocols > without extensions. > > > > GIM>> I question your assumption that use of variable length header > mandates how OAM, active OAM, must be implemented. And since some network= s > choose to use fixed size header, using Overlay Associated Channel header > with multiplexed Overlay OAM functionality appears, in my opinion, as > common solution for either type of overlay encapsulation. > > > > > > I still do not see how an overlay layer benefits from this unnecessary > overhead. > > Support-- > > Carlos. > > > > > David > > > > Greg > > > > > > > > On Mon, Apr 3, 2017 at 11:19 AM, David Mozes > wrote: > > > > Hi , > > > > I am not supporting the adoption > > > > I think while the working group decided on Geneve as the encap protocol > > > > > > > > This OAM need to be via one of the extensions/options the protocol i= s > supporting! > > > > > > > > This header also violate the number 1 requirements from the > extensions/options > > > > That node/middlbox don not need to be part of the extensions/ option > can jump directly to the overlay by reading the base header length only > > > > > > > > Thx > > > > David > > > > > > > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Fioccola Giusepp= e > > Sent: Monday, April 03, 2017 5:40 PM > > To: Bocci, Matthew (Nokia - GB) ; NVO3 < > nvo3@ietf.org>; draft-ooamdt-rtgwg-ooam-header@ietf.org > > Subject: [nvo3] R: Poll for NVO3 WG adoption and IPR call for > draft-ooamdt-rtgwg-ooam-header-03 > > > > > > > > Hi All, > > > > I have read the draft and support its adoption. > > > > > > > > Regards, > > > > > > > > Giuseppe > > > > > > > > Da: nvo3 [mailto:nvo3-bounces@ietf.org] Per conto di Bocci, Matthew > (Nokia - GB) > > Inviato: venerd=C3=AC 31 marzo 2017 17:35 > > A: NVO3; draft-ooamdt-rtgwg-ooam-header@ietf.org > > Oggetto: [nvo3] Poll for NVO3 WG adoption and IPR call for > draft-ooamdt-rtgwg-ooam-header-03 > > > > > > > > This email begins a two week poll for adoption of > draft-ooamdt-rtgwg-ooam-header-03 in the NVO3 working group. > > > > > > > > Please review the draft and send any comments to the NVO3 list. > > > > Please also indicate whether you support adoption of the draft as an > NVO3 working group document. > > > > > > > > Simultaneously, we are also poling for any IPR that may apply to the > draft. > > > > > > > > Authors and contributors, are you aware of any IPR that applies to this > draft? > > > > > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > > > > > > > If you are listed as a document author or contributor, please respond t= o > > > > this email stating of whether or not you are aware of any relevant > > > > IPR. The response needs to be sent to the NVO3 WG mailing list. The > > > > document will not advance to the next stage until a response > > > > has been received from each author and each contributor. > > > > > > > > This poll closes on Friday 14th April 2017. > > > > > > > > Regards > > > > > > > > Matthew and Sam > > > > 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. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > > > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments an= d > advise the sender by return e-mail, Thanks. > > > > Rispetta l'ambiente. Non stampare questa mail se non =C3= =A8 > necessario. > > > > > > > > > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 > > --001a1134f93c3b18da054cc67189 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,
if we had the OAM requirements that WGs, i.= e. NVO3, SFC, and BIER, agreed on, then, I believe, we only had to check if= the proposed solution addresses one of the requirements. I strongly believ= e that having OAM requirements as working document, not necessarily to be p= ublished, is very helpful.
But I'm surprised that you suggest= that defect indication, in peer and multi-layer OAM interworking in not re= quired. You're co-author of OAM requirements draft in SPRING WG that ha= s the following requirement:
=
   REQ#11:  When SR OAM is initialized from centralized controller, it
            MUST have the ability to alert any edge node in SR domain
            about the corresponding path or service failure.  The node
            on receiving the alert MAY take a local protection action or
            pop an informational message.
Isn't that the functionality that is exactly supported= by RDI and AIS?
Then in BIER WG adopted OAM Requirements, that y= ou are co-author ed, I find this:
   10.  BIER OAM MUST support Re=
verse Defect Indication (RDI)
        notification of the source of continuity checking BFR by Bit-
        Forwarding Egress Routers (BFERs), e.g. by using Diag in p2mp
        BFD with active tail support.
and this
   13.  BIER OAM MUST support defect not=
ification mechanism, like Alarm
        Indication Signal.  Any BFR in the given BIER domain MAY
        originate a defect notification addressed to any subset of BFRs
        within the domain.
You don't agree with these requirements?
Regards,
Greg

On Thu, Apr 6, 2017 at 7:55 PM, Carlos Pignataro (c= pignata) <cpignata@cisco.com> wrote:
David responded to this, though I=E2=80=99d like to add a cou= ple thoughts, inline.

> On Apr 5, 2017, at 3:43 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi David,
> thank you for your detailed follow-up comments. Please find my notes i= n-line and tagged GIM>>.
>
> Regards,
> Greg
>
> On Wed, Apr 5, 2017 at 10:54 AM, David Mozes <davidm@mellanox.com> wrote:
> Hi Greg=C2=A0 ,
>
> PSB
>
>
>
> From: Greg Mirsky [mailto:gre= gimirsky@gmail.com]
> Sent: Wednesday, April 05, 2017 2:23 AM
> To: David Mozes <davidm@mell= anox.com>
> Cc: Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it>; Bocci, Matthew (= Nokia - GB) <matthew.bocci@no= kia.com>; NVO3 <nvo3@ietf.org>; draft-ooa= mdt-rtgwg-ooam-header@ietf.org
> Subject: Re: Poll for NVO3 WG adoption and IPR call for draft-ooamdt-r= tgwg-ooam-header-03
>
>
>
> Hi David,
>
> thank you for sharing your opinion.
>
> Could you please clarify your position. You propose to use extensions/= options for end-to-end active OAM?
>
> David> yes
>
>=C2=A0 Let us look at proactive continuity check between NVEs. Why you = think a middlebox needs to be aware of the OAM payload?
>
> I believe that a transient NVO3 node should not look into payload if i= t is not addressed to it at all.
>
> David> Are you limit the header just for proactive OAM ?=C2=A0 so c= hange the draft to include just that . On the current=C2=A0 draft I see all= kinds of OAM
>
> GIM>> I want to point that the draft introduces Associated Chann= el for an overlay network. Associated Channel may be used for signalling or= OAM.

Whoa=E2=80=A6 what problem are we solving? Inline signaling of OAM, = on a covert channel? As if we do not have enough ways already to address th= e requirements?

> OAM methods enable operators to perform Fault Management and Performan= ce Monitoring. Among functions required to perform comprehensive Fault Mana= gement are:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 failure detection, usually detecti= on of Loss of Continuity but may include Mis-connection defect as well for = connection-oriented network;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 defect localization;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Alarm Indication Signal;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Remote Defect Indication.

I thought one strong point made quite a few times by operators is to= move into less-ATM-like OAMs and more into traceroute-like tools. Less AIS= / RDIs and more treetrace and udp singers.

> Depending on the requirements towards resiliency and restoration, Prot= ection Switchover Coordination protocol may be required.
> Performance Measurement usually supports the following:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 one-way and two-way Packet Loss me= asurement;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 one-way and two-way Packet Delay m= easurement;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Synthetic Loss Measurement.
> Service Activation Protocol, as part of active OAM toolset, usually co= mbines OAM functions from FM and PM operations.
> The goal of Overlay OAM work, as I understand, is to create common set= of OAM protocols that supports all of listed above FM and PM operations. I= see such set as combination of active, hybrid and passive OAM methods. I b= elieve that the draft states that clearly. The proactive OAM is usually use= d to perform monitor network for defects and performance degradation. On-de= mand OAM tools may be used to localize the defects.
>

The temperature of the ocean does not seem to change...

>
> > While=C2=A0 I agree with you regarding=C2=A0 Middle box and proac= tive OAM .The same can be achieve with the protocol extensions
>
> Thus I don't agree that the requirement you refer to is applicable= to use of active OAM.
>
> David> I think if the WG decide on NVO3 encap protocol that include= =C2=A0 extension (Like GUE and Geneve) we have to use the build in extensio= ns for such protocol and not innovate=C2=A0 extra header=C2=A0 that use for= protocols without extensions.
>
> GIM>> I question your assumption that use of variable length hea= der mandates how OAM, active OAM, must be implemented. And since some netwo= rks choose to use fixed size header, using Overlay Associated Channel heade= r with multiplexed Overlay OAM functionality appears, in my opinion, as com= mon solution for either type of overlay encapsulation.
>
>

I still do not see how an overlay layer benefits from this unnecessa= ry overhead.

Support--

Carlos.

>
> David
>
> Greg
>
>
>
> On Mon, Apr 3, 2017 at 11:19 AM, David Mozes <davidm@mellanox.com> wrote:
>
> Hi ,
>
> I am not supporting the adoption
>
> I think while the working group decided on Geneve as the encap protoco= l
>
>
>
> This OAM need to be via one of the extensions/options=C2=A0 the protoc= ol=C2=A0 =C2=A0is supporting!
>
>
>
> This header also violate the number 1 requirements from the extensions= /options
>
> That node/middlbox=C2=A0 don not=C2=A0 need to be part of the extensio= ns/ option can jump directly=C2=A0 to the overlay by reading the base heade= r length only
>
>
>
> Thx
>
> David
>
>
>
> From: nvo3 [mailto:nvo3-bounc= es@ietf.org] On Behalf Of Fioccola Giuseppe
> Sent: Monday, April 03, 2017 5:40 PM
> To: Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>; NVO3 <nvo3@ietf.org>; draft-ooamdt-rtgwg-ooam-header@ietf.org
> Subject: [nvo3] R: Poll for NVO3 WG adoption and IPR call for draft-oo= amdt-rtgwg-ooam-header-03
>
>
>
> Hi All,
>
> I have read the draft and support its adoption.
>
>
>
> Regards,
>
>
>
> Giuseppe
>
>
>
> Da: nvo3 [mailto:nvo3-bounces= @ietf.org] Per conto di Bocci, Matthew (Nokia - GB)
> Inviato: venerd=C3=AC 31 marzo 2017 17:35
> A: NVO3; dr= aft-ooamdt-rtgwg-ooam-header@ietf.org
> Oggetto: [nvo3] Poll for NVO3 WG adoption and IPR call for draft-ooamd= t-rtgwg-ooam-header-03
>
>
>
> This email begins a two week poll for adoption of draft-ooamdt-rtgwg-o= oam-header-03 in the NVO3 working group.
>
>
>
> Please review the draft and send any comments to the NVO3 list.
>
> Please also indicate whether you support adoption of the draft as an N= VO3 working group document.
>
>
>
> Simultaneously, we are also poling for any IPR that may apply to the d= raft.
>
>
>
> Authors and contributors, are you aware of any IPR that applies to thi= s draft?
>
>
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules (= see RFCs 3979, 4879, 3669 and 5378 for more details)?
>
>
>
> If you are listed as a document author or contributor, please respond = to
>
> this email stating of whether or not you are aware of any relevant
>
> IPR. The response needs to be sent to the NVO3 WG mailing list. The >
> document will not advance to the next stage until a response
>
> has been received from each author and each contributor.
>
>
>
> This poll closes on Friday 14th April 2017.
>
>
>
> Regards
>
>
>
> Matthew and Sam
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente all= e persone indicate. La diffusione, copia o qualsiasi altra azione derivante= dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualor= a abbiate ricevuto questo documento per errore siete cortesemente pregati d= i darne immediata comunicazione al mittente e di provvedere alla sua distru= zione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privil= eged information intended for the addressee(s) only. Dissemination, copying= , printing or use by anybody else is unauthorised. If you are not the inten= ded recipient, please delete this message and any attachments and advise th= e sender by return e-mail, Thanks.
>
> <image001.gif>Rispetta l'ambiente. Non stampare = questa mail se non =C3=A8 necessario.
>
>
>
>
>
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3

--001a1134f93c3b18da054cc67189-- From nobody Mon Apr 10 09:05:12 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6077E129573 for ; Mon, 10 Apr 2017 09:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWdwoUOOyook for ; Mon, 10 Apr 2017 09:05:08 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FB64129566 for ; Mon, 10 Apr 2017 09:05:07 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id t63so7792772oih.0 for ; Mon, 10 Apr 2017 09:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=UPM72sq92ZDu4opqFNzUO6qFYswQGFh9okmQcjhj6qA=; b=JYO9gr/R36dtSc3aBjtpSL1iQgWymi8w5R95X11Xr+9rZaduwz1qw6VMFoiscJZo+T oPFRGTFSenS39Oer5CfRZQzj8CxqucSRY9lFMzy4zlK5idSUP5lWPYvAzW5zAfd73JV5 Rf4oIk7yWf8hzl0GwiiWf3B4TFONrCt0dkUkyEY9unu0stuxFj9CydYSweAKUqLn974Z kDOWwY1iosHGDfmsQW+GtnjvN3i6+9J6mJ60n/Hep5S35pFRUC/12ndpu2lZxHgd1nyN lI6KUjgAuy+yOEOVKEsnx1QNeHwQSasIt/E5og3ksXcUD1Selkp1PpwQimfe0eVMZCA8 Ny2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to; bh=UPM72sq92ZDu4opqFNzUO6qFYswQGFh9okmQcjhj6qA=; b=c9hf1Ap/BRviOtiSUsxHHX0g6iV8dKvtVqD2TKeKF6X0AoyHIfDscs9+nQedK4Rm7R lEsZNdmBX9dlqUVVqlrTgVk9DQrtwXQ2sq0LQeU6XczA2BH3eltgSsTA4gzhzaQz4AHs dOvnQeUY2w3gKLqXTwBuRntkTWHcPDvvy0eq2zViSvfxINUOOQ/dFnc86SV56UFKmy9o zcbNg6CaENifkEhkWRkj6NrON1ViW37QZGL1BhUwUcxscl8ODX5isadgMeWYCGiskCfF KUmHyYksmfVu4b/pco5agrv0IWCBlNHmbgtFOEZXzdsKiLXDHIAC2Qmdzg8SHrC31BrQ IFSA== X-Gm-Message-State: AN3rC/6Pm67dVXhe3dV5nUS2eKkqm4Wh0BbwtlsCm8+8W8bTdjW6JFajTCo58qgy/URhyQ== X-Received: by 10.202.96.132 with SMTP id u126mr1797762oib.183.1491840306789; Mon, 10 Apr 2017 09:05:06 -0700 (PDT) Received: from [10.6.23.170] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id y198sm6407011oie.8.2017.04.10.09.05.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 09:05:05 -0700 (PDT) Sender: Matthew Miller Subject: Re: Genart last call review of draft-ietf-rtgwg-yang-key-chain-17 To: "Acee Lindem (acee)" , "gen-art@ietf.org" Cc: "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" , "ietf@ietf.org" , "rtgwg@ietf.org" References: <149158793224.11224.1489071223626497682@ietfa.amsl.com> From: "Matthew A. Miller" Message-ID: <6f34a4cc-6492-a354-f257-412b0f5e84a1@outer-planes.net> Date: Mon, 10 Apr 2017 10:05:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QkgNiHQAfBscnI68RtA2QqVf0dI9QJ52c" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:05:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QkgNiHQAfBscnI68RtA2QqVf0dI9QJ52c Content-Type: multipart/mixed; boundary="L4swmtKLJ5mrwTLR8UO1A3aCKF4QSjA3w"; protected-headers="v1" From: "Matthew A. Miller" To: "Acee Lindem (acee)" , "gen-art@ietf.org" Cc: "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" , "ietf@ietf.org" , "rtgwg@ietf.org" Message-ID: <6f34a4cc-6492-a354-f257-412b0f5e84a1@outer-planes.net> Subject: Re: Genart last call review of draft-ietf-rtgwg-yang-key-chain-17 References: <149158793224.11224.1489071223626497682@ietfa.amsl.com> In-Reply-To: --L4swmtKLJ5mrwTLR8UO1A3aCKF4QSjA3w Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Thanks for responding Acee, I look forward to the next revision. Responses inline ... - m&m Matthew A. Miller On 17/04/08 16:55, Acee Lindem (acee) wrote: > Hi Matt, >=20 > Thanks for the review. >=20 > On 4/7/17, 1:58 PM, "Matthew Miller" > wrote: >=20 >> Reviewer: Matthew Miller >> Review result: Almost Ready >> >> 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-rtgwg-yang-key-chain-17 >> Reviewer: Matthew A. Miller >> Review Date: 2017-04-07 >> IETF LC End Date: 2017-04-07 >> IESG Telechat date: 2017-04-13 >> >> Summary: >> >> This document is almost ready to be published as a Proposed Standard, >> once the issues noted herein are resolved. >> >> Major issues: >> >> NONE >> >> Minor issues: >> >> * Forgive me for my limited knowledge of YANG, but is there a reason >> key-strings are only representable as either a YANG string or >> hex-string type, and not the YANG binary type? >=20 > Let me ask why I=C2=B9d want to use this type? I can get all the entrop= y I want > with a hex string and implementations are familiar with this > representation. I=C2=B9m not really fond of the obscure base64 represen= tation > used by the YANG type and if one consults Benoit=C2=B9s search tool, th= e type > is not widely used. http://www.yangcatalog.org/yang-search/yang-search.= php >=20 Thanks for explaining. I asked because (more) efficient transfer of binary data has come up for other textual formats (read: JSON), and the rough consensus was for base64. That said, if the community is already fine with hex, then I consider this a non-issue. >> >> * This document does not provide much guidance around AES key wrap >> other than it can be used and the KEK is provided >> out-of-band/-context. >> For instance, AES key-wrapped key-strings probably require using >> "hexidecimal-string". >=20 > Yes - I=C2=B9ll add that. >=20 Thanks. >> Also, assuming I'm reading the model >> correctly, >> it appears this feature applies to the whole chain, which I think is >> worth calling out. >=20 > In YANG, if you support a feature, it is for the entire model. > The per-chain boolean indicates whether or not it is applies to all the= > keys in that particular key-chain. I will clarify this. >> >> * This document warns against using the "clear-text" algorithm, which >> the >> reader is lead to understand is for legacy implementation reasons. >> However, is there not a similar concern with cryptographically weak >> algorithms, such as md5 and (arguably) sha1? >=20 > I can add something for MD5. Thanks. I know I said arguably sha1, but at the apps layer it is considered weak with in-the-wild tools able to produce collisions, which leads to the minimum being sha256. I would consider including a note about sha1 and md5, but I understand that maybe operational realities are such that sha256 is not widely deployed for these devices, or its not otherwise seen as a problem yet. >> >> Nits/editorial comments: >> >> * In Section 3.2. "Key Chain Model Features", the word "of" is >> missing >> between "configuration" and "an" in the phrase "support configuration >> an >> acceptance tolerance". >=20 > Good catch. I will fix. >> >> Non-nits: >> >> * I note that idnits is calling out some odd spacing issues, but I >> think >> they are safe to ignore. >=20 > Though the line numbers don=C2=B9t match the draft, I was able to fix t= hese. >=20 > Thanks, > Acee=20 >> >=20 --L4swmtKLJ5mrwTLR8UO1A3aCKF4QSjA3w-- --QkgNiHQAfBscnI68RtA2QqVf0dI9QJ52c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY6602AAoJEOz0ck4QngW72r0H/1bMTPltgvYGOnyVUPmK95U/ dIj0sFlmyQpfaiiSnNgdBOw5mzkKsbyaaYdfBcCn+nI2HVc8o6rF+oLSREXYUywM ZQ5AIU8lCmfVSQRald7QTk+AyWFrtsjNclwNaqy3yzYmq2I4XF3meP69w6T9TSce bajwM47C6DebrWSvyBf94uc8pMcVIqXtcSeOLywJkvX4oU0NoIY/ejU7WMQZKwM5 sbrb/2YjXCtHaXwlKxJi+SRyeTaNY+wyLgN5PELNXNG5jtbwAF+PWiJFLWCC8Bos dfq1bGQs18D1jJ0bCrd4iLHV1jcTO+tuwZMraKAXiXVdTJZTydGBOSeZwJ5piOY= =JxPb -----END PGP SIGNATURE----- --QkgNiHQAfBscnI68RtA2QqVf0dI9QJ52c-- From nobody Tue Apr 11 11:13:07 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF8812EB76; Tue, 11 Apr 2017 11:12:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-yang-key-chain-18.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149193437885.15788.9995920650504218251@ietfa.amsl.com> Date: Tue, 11 Apr 2017 11:12:58 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:12:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Routing Key Chain YANG Data Model Authors : Acee Lindem Yingzhen Qu Derek Yeung Ing-Wher Chen Jeffrey Zhang Filename : draft-ietf-rtgwg-yang-key-chain-18.txt Pages : 25 Date : 2017-04-11 Abstract: This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. In some applications, the protocols do not use the key chain element key directly, but rather a key derivation function is used to derive a short-lived key from the key chain element key (e.g., the Master Keys used in the TCP Authentication Option(TCP-AO)). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-18 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-key-chain-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-yang-key-chain-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 11 11:17:53 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4B612EBC7 for ; Tue, 11 Apr 2017 11:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdCZQNRpGarX for ; Tue, 11 Apr 2017 11:17:50 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AD012EBA4 for ; Tue, 11 Apr 2017 11:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2604; q=dns/txt; s=iport; t=1491934641; x=1493144241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tU+auq0IAD+yRGapO7TDPspSH0joav4dOCqM4sOah/A=; b=Jp77Kp2AfM8qozSatfjw64Y1Oas9nmyYtpn7BCK+42bzUX2T8GKrGOne nrz4r6zVX1r2NOgTpH9BnZaHW6Vw2+vY6KdwXfR3BGg8NHITH+qnELly9 VoNGoBsPttHQbgtJw+hqfRgoxTCV218HJGoFNthesVWj2xqUfZpAV6Scu E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQBZHO1Y/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHjXKnJoIPIQ2FdgKDYj8YAQIBAQEBAQEBayiFFgIBAwE?= =?us-ascii?q?BODQLEAIBCDYQJwslAgQBDQWKEA6rSIp6AQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?YtAgxeHJAWcfwGGf4tegX9VhFmKF5QAAR84gQVbFRgphlp1iEiBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,186,1488844800"; d="scan'208";a="231693316" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2017 18:17:20 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3BIHJDl005872 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2017 18:17:20 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Apr 2017 14:17:19 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 11 Apr 2017 14:17:19 -0400 From: "Acee Lindem (acee)" To: Vincent Roca , "Matthew A. Miller" CC: "rtgwg@ietf.org" Subject: Re: I-D Action: draft-ietf-rtgwg-yang-key-chain-18.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-yang-key-chain-18.txt Thread-Index: AQHSsu9T8GT1BpGI00OsgXRR+kG7yKHAedKA Date: Tue, 11 Apr 2017 18:17:19 +0000 Message-ID: References: <149193437885.15788.9995920650504218251@ietfa.amsl.com> In-Reply-To: <149193437885.15788.9995920650504218251@ietfa.amsl.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.116.152.197] Content-Type: text/plain; charset="us-ascii" Content-ID: <9C979B9D24CE9D4C93963A102E1E5D88@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 18:17:52 -0000 This version includes comments from Vincent Roca (Security Directorate Review) and Matthew Miller (GenART Review). We are still considering whether to remove the aes-key-wrap feature completely. On 4/11/17, 2:12 PM, "rtgwg on behalf of internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Routing Area Working Group of the IETF. > > Title : Routing Key Chain YANG Data Model > Authors : Acee Lindem > Yingzhen Qu > Derek Yeung > Ing-Wher Chen > Jeffrey Zhang > Filename : draft-ietf-rtgwg-yang-key-chain-18.txt > Pages : 25 > Date : 2017-04-11 > >Abstract: > This document describes the key chain YANG data model. Key chains > are commonly used for routing protocol authentication and other > applications requiring symmetric keys. A key chain is a list of > elements each containing a key string, send lifetime, accept > lifetime, and algorithm (authentication or encryption). By properly > overlapping the send and accept lifetimes of multiple key chain > elements, key strings and algorithms may be gracefully updated. By > representing them in a YANG data model, key distribution can be > automated. > > In some applications, the protocols do not use the key chain element > key directly, but rather a key derivation function is used to derive > a short-lived key from the key chain element key (e.g., the Master > Keys used in the TCP Authentication Option(TCP-AO)). > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ > >There are also htmlized versions available at: >https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-18 >https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-key-chain-18 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-yang-key-chain-18 > > >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/ > >_______________________________________________ >rtgwg mailing list >rtgwg@ietf.org >https://www.ietf.org/mailman/listinfo/rtgwg From nobody Tue Apr 11 12:23:09 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B366712EC98 for ; Tue, 11 Apr 2017 12:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=outer-planes-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Toi3G1k5vjjN for ; Tue, 11 Apr 2017 12:23:04 -0700 (PDT) Received: from mail-yb0-x242.google.com (mail-yb0-x242.google.com [IPv6:2607:f8b0:4002:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421FB12EC56 for ; Tue, 11 Apr 2017 12:23:04 -0700 (PDT) Received: by mail-yb0-x242.google.com with SMTP id k6so288139ybk.2 for ; Tue, 11 Apr 2017 12:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=+Fr0KD3qUMLTbQXzN9/NOtIv5RIWoLOJQaUayCHGBgs=; b=GrZdcZTy9nUwdGp0MPK3hkB6RPP1IXMJXoY0IhkFECTItZhgWQwn16OX9argVwheOp AFGrId9h471g3yK447xZ4w2TFRXhmQQr0LxEv8kmiLpXAzazUhvuifPpGExp6cq6quOl 6AVS+fcjKSwpLKueWUGTp+Pr9WQDWaHq7qf2BtOJ70ckpdG+IKvRFivdjDuZcF4AectS 5Q5gigOrIbqZceH5Tae4/wCX1BUt1PmHWpNjgt7aofxlckvNHCbhqxQkvpXE2CdD2xsy mdaaqWRgVw1Zb8rvcnpizUStw54AgyKkPUmOrSd+IH7TT5x7S1jRGMMvZAmS5CNbFMhA QOyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to; bh=+Fr0KD3qUMLTbQXzN9/NOtIv5RIWoLOJQaUayCHGBgs=; b=LJo0hOzUr/T1ogSqkFBfvGlKU4OU/19egTWPJ6aQ9uarZXhUNyOYIPcczrB9+odQos 6Cf2AcP00jR9TOG58Gk/8fd8QxZm7qq34wv4On5TvxahkH3dx1Rl4r30777ssl3MuZ9z DG4TnITKzv9LcGRV7IN9MoGZt6JjTQLQmvUXpCagaOOLq2Qa5Sj6/Szzfb1FXV+AakFD 0lYPgN9TqjGPYedYv4bBFV6VcL4VN0+n6grdwzKakzsUAHmBROI1SOO6x0sxR2815qQC J7vJmnjR7W+JvzyDWs2kchtVSFeMlbPu+DCXnDGdXJ3RwwqZxbfCHTCYw4fbddLRJn1V 3zcA== X-Gm-Message-State: AFeK/H0XIJ5LK+B+rQfB3fAV7Y6Wxcutp2sawlpG2pBXTnHfCmGzF0zabBuO1t8rM+XFBA== X-Received: by 10.37.104.11 with SMTP id d11mr23879431ybc.39.1491938583471; Tue, 11 Apr 2017 12:23:03 -0700 (PDT) Received: from [10.6.23.170] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id a129sm7768009ywg.59.2017.04.11.12.23.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 12:23:02 -0700 (PDT) Sender: Matthew Miller Subject: Re: I-D Action: draft-ietf-rtgwg-yang-key-chain-18.txt To: "Acee Lindem (acee)" , Vincent Roca Cc: "rtgwg@ietf.org" References: <149193437885.15788.9995920650504218251@ietfa.amsl.com> From: "Matthew A. Miller" Message-ID: <99e68bde-d438-3995-313c-cee991ddb827@outer-planes.net> Date: Tue, 11 Apr 2017 13:23:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="C2pSJXLRTOVn05S0nUADCJOPQT4VF1Rk4" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 19:23:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --C2pSJXLRTOVn05S0nUADCJOPQT4VF1Rk4 Content-Type: multipart/mixed; boundary="s7RGDxeTC75oslkg6olntnrcNp25sIReR"; protected-headers="v1" From: "Matthew A. Miller" To: "Acee Lindem (acee)" , Vincent Roca Cc: "rtgwg@ietf.org" Message-ID: <99e68bde-d438-3995-313c-cee991ddb827@outer-planes.net> Subject: Re: I-D Action: draft-ietf-rtgwg-yang-key-chain-18.txt References: <149193437885.15788.9995920650504218251@ietfa.amsl.com> In-Reply-To: --s7RGDxeTC75oslkg6olntnrcNp25sIReR Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I perused the diff, and I think all of my points have been addressed. Thanks for the quick update and notification. - m&m Matthew A. Miller On 17/04/11 12:17, Acee Lindem (acee) wrote: > This version includes comments from Vincent Roca (Security Directorate > Review) and Matthew Miller (GenART Review). We are still considering > whether to remove the aes-key-wrap feature completely. >=20 > On 4/11/17, 2:12 PM, "rtgwg on behalf of internet-drafts@ietf.org" > wrote: >=20 >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Routing Area Working Group of the IET= F. >> >> Title : Routing Key Chain YANG Data Model >> Authors : Acee Lindem >> Yingzhen Qu >> Derek Yeung >> Ing-Wher Chen >> Jeffrey Zhang >> Filename : draft-ietf-rtgwg-yang-key-chain-18.txt >> Pages : 25 >> Date : 2017-04-11 >> >> Abstract: >> This document describes the key chain YANG data model. Key chains >> are commonly used for routing protocol authentication and other >> applications requiring symmetric keys. A key chain is a list of >> elements each containing a key string, send lifetime, accept >> lifetime, and algorithm (authentication or encryption). By properly= >> overlapping the send and accept lifetimes of multiple key chain >> elements, key strings and algorithms may be gracefully updated. By >> representing them in a YANG data model, key distribution can be >> automated. >> >> In some applications, the protocols do not use the key chain element= >> key directly, but rather a key derivation function is used to derive= >> a short-lived key from the key chain element key (e.g., the Master >> Keys used in the TCP Authentication Option(TCP-AO)). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-18 >> https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-key-chain-= 18 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-yang-key-chain-18= >> >> >> 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/ >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >=20 --s7RGDxeTC75oslkg6olntnrcNp25sIReR-- --C2pSJXLRTOVn05S0nUADCJOPQT4VF1Rk4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY7S0WAAoJEOz0ck4QngW7eagIAL/J3bxYvktU4ggRmjDV6xZh r7fe19o5EQDSDcu8Z7jLVVRsLCu94pLfJQpMBcC7RjY9BpEUkDheTDMsFk/WQ63H 3pve66bGQKKAMRbpm8oOOEAKrvE/jATBOXNDGXpTZRRROrCg6dYp3sKyWNHuUew1 vSbDXeay3nz3Em1Q65RyFz631sbbsxlXplMTinmC+Y53jMLxpgklRUD67eZvq7T2 5oYoxztWFtcOJpdpJAnAJpszdBUTWrsgXh0J6UISy7vxU/8LKpM8+p9c1R2tVRC3 8UqnatkBIk9KacYVmhoSFxMAvykW5NSRQJgWvRTJrQrXURKjOf2QXZiZSkXp+g4= =iEuH -----END PGP SIGNATURE----- --C2pSJXLRTOVn05S0nUADCJOPQT4VF1Rk4-- From nobody Tue Apr 11 19:16:59 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828221250B8; Tue, 11 Apr 2017 19:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyFAvj0tCmrX; Tue, 11 Apr 2017 19:16:54 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39713120326; Tue, 11 Apr 2017 19:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16706; q=dns/txt; s=iport; t=1491963414; x=1493173014; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RnoM8PxL6sU6I/5QrVdue0DfpUx5KwoJdoq16uwAkeU=; b=JN3jDwoDOrWQtFC182DduJGBzz7/D3geh2Bnmnoy2y3Iu3gucGd2aiMK 6pkebqe2Z4cuI127erDZzpyxi94gZksHsmFWMC2toOXn6Io0AcVbJYaaP Fio8NFV6nLSGpu2Xcnjj6M1Ty7ww4WJS24+SwvPmcG67N7+kYhNJ3ALCm c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AxAwBije1Y/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KE5ExH4gajT6CDyEPhXQCGoNKPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBAQEbBhE4AgYFBQsCAQYCEQQBAQECAiMDAgICHwYLFAEICAIED?= =?us-ascii?q?gUbiWIDDQgOizKdXYImhy4Ngz0BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUW?= =?us-ascii?q?CBQmCYoJRRoERCwUCATKCby6CMQEEiRIFky07AYZ/hxyEQoF/hS6DXYUAgTqJB?= =?us-ascii?q?IF9iH8BHzh9CFsVQREBhEkcGYFKdQEBhm+BL4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,188,1488844800"; d="scan'208";a="410256631" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Apr 2017 02:16:52 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3C2Gqpg015661 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Apr 2017 02:16:52 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Apr 2017 22:16:51 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Tue, 11 Apr 2017 22:16:51 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: David Mozes , "Bocci, Matthew (Nokia - GB)" , NVO3 , "draft-ooamdt-rtgwg-ooam-header@ietf.org" , Fioccola Giuseppe , "sfc@ietf.org" , "bier@ietf.org" , "rtgwg@ietf.org" , "spring-chairs@ietf.org" Subject: Re: [nvo3] Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03 Thread-Topic: [nvo3] Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03 Thread-Index: AQHSsZ9BJbZPpRdrXkyy2+E4i4mIcKHBRYCA Date: Wed, 12 Apr 2017 02:16:51 +0000 Message-ID: <9BC52F60-6E9A-4594-AC95-4F0186BF81D4@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.243.186] Content-Type: text/plain; charset="utf-8" Content-ID: <7AB474E315B0044FB895D9DDBD152CC3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 02:16:58 -0000 R3JlZywNCg0KSSBhbSBwcm92aWRpbmcgc29tZSBmb2xsb3ctdXBzIGJlbG93LCBidXQgSSB3aWxs IHRvcC1wb3N0IG5vdGUgdGhhdCB5b3UgY29tcGxldGVseSBtaXNzZWQgcmVzcG9uZGluZyB0byB0 aGUga2V5IGlzc3VlcyByYWlzZWQ6IHdoYXQgcHJvYmxlbSBpcyB0aGlzIHJlYWxseSBhdHRlbXB0 aW5nIHRvIHNvbHZlPyB3aGF0IGlzIGdhaW5lZCBieSB0aGlzIGV4dHJhIG92ZXJoZWFkIGFuZCBp bmRpcmVjdGlvbj8gd2hhdCBpcyBvdmVybGF5LXNwZWNpZmljIGluIHRoaXMgaGVhZGVyPyANCg0K QWZ0ZXIgdGhpcyBlbWFpbCwgc2luY2UgSSBiZWxpZXZlIEkgbWFkZSBteSBwb2ludHMgYWxyZWFk eSwgSSB3aWxsIGxldCBvdGhlcnMgY29tbWVudC4NCg0KUGxlYXNlIHNlZSBpbmxpbmXigKYNCg0K PiBPbiBBcHIgOSwgMjAxNywgYXQgMTA6MDcgUE0sIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBn bWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgQ2FybG9zLA0KPiBpZiB3ZSBoYWQgdGhlIE9BTSBy ZXF1aXJlbWVudHMgdGhhdCBXR3MsIGkuZS4gTlZPMywgU0ZDLCBhbmQgQklFUiwgYWdyZWVkIG9u DQoNClRoaXMgc2hvd3MgYSBmdW5kYW1lbnRhbCBtaXN1bmRlcnN0YW5kaW5nIG9mIFdHIG9wZXJh dGlvbnMgYnkgeW91LCBpZiBJIGZvbGxvdyB5b3VyIGxvZ2ljIGNvcnJlY3RseS4NCg0KQW4gZXhp c3RpbmcgSW50ZXJuZXQtRHJhZnQgdW5kZXIgYSBXRyBjb250cm9sIG1lYW5zIHRoYXQgYXQgc29t ZSBwb2ludCB0aGUgV0cgdGhvdWdodCBpdCB1c2VmdWwgdG8gd29yayBvbiB0aGF0IHByb2JsZW0s IGFuZCB0aGUgV0cgY2hhcnRlciBhbGxvd2VkIGZvciB0aGF0IHNjb3BlLiBJdCBkb2VzICpub3Qq IG1lYW4gdGhhdCBldmVyeSB3b3JkIGFuZCBldmVyeSBzZW50ZW5jZSBpcyBhZ3JlZWQgYnkgdGhl IFdHLCBvciB0aGF0IHRoZXkgZXZlbiBtYWtlIHNlbnNlLiBbUkZDIDI0MThdLCBbUkZDIDcyMjFd IEFncmVlbWVudCBpcyB2aWEgY29uc2Vuc3VzLg0KDQpXaXRoIHRoYXQgY29udGV4dCBpbiBtaW5k Li4uDQoNCj4gLCB0aGVuLCBJIGJlbGlldmUsIHdlIG9ubHkgaGFkIHRvIGNoZWNrIGlmIHRoZSBw cm9wb3NlZCBzb2x1dGlvbiBhZGRyZXNzZXMgb25lIG9mIHRoZSByZXF1aXJlbWVudHMuIEkgc3Ry b25nbHkgYmVsaWV2ZSB0aGF0IGhhdmluZyBPQU0gcmVxdWlyZW1lbnRzIGFzIHdvcmtpbmcgZG9j dW1lbnQsIG5vdCBuZWNlc3NhcmlseSB0byBiZSBwdWJsaXNoZWQsIGlzIHZlcnkgaGVscGZ1bC4N Cj4gQnV0IEknbSBzdXJwcmlzZWQgdGhhdCB5b3Ugc3VnZ2VzdCB0aGF0IGRlZmVjdCBpbmRpY2F0 aW9uLCBpbiBwZWVyIGFuZCBtdWx0aS1sYXllciBPQU0gaW50ZXJ3b3JraW5nIGluIG5vdCByZXF1 aXJlZC4gWW91J3JlIGNvLWF1dGhvciBvZiBPQU0gcmVxdWlyZW1lbnRzIGRyYWZ0IGluIFNQUklO RyBXRyB0aGF0IGhhcyB0aGUgZm9sbG93aW5nIHJlcXVpcmVtZW50Og0KDQpJbnRlcmVzdGluZ2x5 LCBhZnRlciBhIGRpYWxvZ3VlIHdpdGggb25lIG9mIHRoZSBzcHJpbmcgY2hhaXJzIGluIENoaWNh Z28sIEkgZW1haWxlZCB0aGUgc3ByaW5nIGNoYWlycyAoQ2PigJllZCBvbiB0aGlzIG5vdGUpIGFu ZCBkcmFmdCBjb250cmlidXRvcnMgYWxpYXMgc3RhdGluZyB0aGF0IHRoZXJl4oCZcyByZWFsbHkg bm8gdmFsdWUgb24gdGhhdCBkb2N1bWVudC4gT24gdGhhdCBlbWFpbCB0aHJlYWQsIHlvdSB3ZXJl IHRoZSBvbmx5IGRpc3NlbnRpbmcgdm9pY2UgdHJ5aW5nIHRvIGhvbGQgb24gdG8gdGhhdCBkb2N1 bWVudC4NCg0KTm93LCBpcyBTUFJJTkcgYWxzbyBhbiBvdmVybGF5IGZvciB3aGljaCB5b3Ugc3Vn Z2VzdCBkcmFmdC1vb2FtZHQtcnRnd2ctb29hbS1oZWFkZXIgaGFzIGEgc29sdXRpb24/IFRoZSBN UExTLCBJUHY2IGVuY2FwLCBvciBib3RoPyBJ4oCZZCBsb3ZlIHRvIGtub3csIHNpbmNlIHlvdSBo YWQgcHJldmlvdXNseSBzYWlkIOKAnE5WTzMsIFNGQywgQklFUuKAnSAoYSByYXRoZXIgY2Fwcmlj aW91cyBjaG9pY2UsIGFwcGFyZW50bHkpDQoNCllvdSBzZWVtIHRvIGhhdmUgbWlzc2VkIHRoZSBt YWluIHBvaW50IEkgd2FzIG1ha2luZyBoZXJlIHRob3VnaDogc2luY2Ugb3BlcmF0b3JzIHNhaWQg aW4gSUVURjk14oCZcyBydGd3ZyBtZWV0aW5nIHRoZXkgd2FudCBtb3JlIHRyYWNlcm91dGUtbGlr ZSBhbmQgbGVzcyB0cmFkaXRpb25hbC1saWtlIHRvb2xzLCBhcmUgeW91IGlnbm9yaW5nIG9wZXJh dGlvbmFsIG5lZWRzPw0KDQo+ICAgIFJFUSMxMTogIFdoZW4gU1IgT0FNIGlzIGluaXRpYWxpemVk IGZyb20gY2VudHJhbGl6ZWQgY29udHJvbGxlciwgaXQNCj4gICAgICAgICAgICAgTVVTVCBoYXZl IHRoZSBhYmlsaXR5IHRvIGFsZXJ0IGFueSBlZGdlIG5vZGUgaW4gU1IgZG9tYWluDQo+ICAgICAg ICAgICAgIGFib3V0IHRoZSBjb3JyZXNwb25kaW5nIHBhdGggb3Igc2VydmljZSBmYWlsdXJlLiAg VGhlIG5vZGUNCj4gICAgICAgICAgICAgb24gcmVjZWl2aW5nIHRoZSBhbGVydCBNQVkgdGFrZSBh IGxvY2FsIHByb3RlY3Rpb24gYWN0aW9uIG9yDQo+ICAgICAgICAgICAgIHBvcCBhbiBpbmZvcm1h dGlvbmFsIG1lc3NhZ2UuDQo+IA0KDQpJ4oCZdmUgcmFyZWx5IHNlZW4gc29sdXRpb25zIGV2YWx1 YXRlZCBhZ2FpbnN0IHJlcXVpcmVtZW50cywgdW5sZXNzIGhhbmQtcGlja2VkIHJlcXVpcmVtZW50 cyB3ZXJlIHJldmVyc2UtZW5naW5lZXJlZCBmcm9tIHNvbHV0aW9ucy4gDQoNCj4gSXNuJ3QgdGhh dCB0aGUgZnVuY3Rpb25hbGl0eSB0aGF0IGlzIGV4YWN0bHkgc3VwcG9ydGVkIGJ5IFJESSBhbmQg QUlTPw0KDQpBcyBpdCBpcyB0aGUgY2FzZSBoZXJlIGl0IHNlZW1zIHRvIG1lLg0KDQo+IFRoZW4g aW4gQklFUiBXRyBhZG9wdGVkIE9BTSBSZXF1aXJlbWVudHMsIHRoYXQgeW91IGFyZSBjby1hdXRo b3IgZWQsIEkgZmluZCB0aGlzOg0KDQpTaW1pbGFybHksIGl0IGlzIGZ1bm55IHRvIHNlZSB0aGUg KGxhY2sgb2YpIGRpZmZlcmVuY2VzIGFuZCBwcm9ncmVzcyBiZXR3ZWVuIDIwMTXigJlzIGRyYWZ0 LW1pcnNreS1iaWVyLW9hbS1yZXF1aXJlbWVudHMtMDAgYW5kIGRyYWZ0LWlldGYtYmllci1vYW0t cmVxdWlyZW1lbnRzLTAzOg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLWJpZXItb2FtLXJlcXVpcmVtZW50cy0wMy50eHQmdXJsMT1kcmFmdC1taXJza3kt Ymllci1vYW0tcmVxdWlyZW1lbnRzLTAwLnR4dA0KDQpDb250ZW50IGRpZmZlcmVuY2VzIGFyZSBl ZmZlY3RpdmVseSBudWxsLiBEbyB5b3UgcmVhbGx5IGluc2lzdCBpbiBjYWxsaW5nIHRoYXQgV0cg YWdyZWVtZW50Pw0KDQoNCj4gICAgMTAuICBCSUVSIE9BTSBNVVNUIHN1cHBvcnQgUmV2ZXJzZSBE ZWZlY3QgSW5kaWNhdGlvbiAoUkRJKQ0KPiAgICAgICAgIG5vdGlmaWNhdGlvbiBvZiB0aGUgc291 cmNlIG9mIGNvbnRpbnVpdHkgY2hlY2tpbmcgQkZSIGJ5IEJpdC0NCj4gICAgICAgICBGb3J3YXJk aW5nIEVncmVzcyBSb3V0ZXJzIChCRkVScyksIGUuZy4gYnkgdXNpbmcgRGlhZyBpbiBwMm1wDQo+ ICAgICAgICAgQkZEIHdpdGggYWN0aXZlIHRhaWwgc3VwcG9ydC4NCj4gDQo+IGFuZCB0aGlzDQo+ ICAgIDEzLiAgQklFUiBPQU0gTVVTVCBzdXBwb3J0IGRlZmVjdCBub3RpZmljYXRpb24gbWVjaGFu aXNtLCBsaWtlIEFsYXJtDQo+ICAgICAgICAgSW5kaWNhdGlvbiBTaWduYWwuICBBbnkgQkZSIGlu IHRoZSBnaXZlbiBCSUVSIGRvbWFpbiBNQVkNCj4gICAgICAgICBvcmlnaW5hdGUgYSBkZWZlY3Qg bm90aWZpY2F0aW9uIGFkZHJlc3NlZCB0byBhbnkgc3Vic2V0IG9mIEJGUnMNCj4gICAgICAgICB3 aXRoaW4gdGhlIGRvbWFpbi4NCj4gDQo+IFlvdSBkb24ndCBhZ3JlZSB3aXRoIHRoZXNlIHJlcXVp cmVtZW50cz8NCj4gDQoNCkl04oCZcyBvZGQsIHRob3NlIHJlcXVpcmVtZW50cyByZWFkIHRvIG1l IGxpa2Ug4oCcSSByZXF1aXJlIHRoaXMgc29sdXRpb27igJ3igKYgbm90IHJlYWwgcmVxdWlyZW1l bnRz4oCmIA0KDQpBbmQgdGhlc2UgYXJlIG5vdCB0aGUgdGhpbmdzIEkgaGVhciBvcGVyYXRvcnMg bmVlZC4gTm8uDQoNCkJlc3QsDQoNCuKAlCBDYXJsb3MuDQoNCj4gUmVnYXJkcywNCj4gR3JlZw0K PiANCj4gT24gVGh1LCBBcHIgNiwgMjAxNyBhdCA3OjU1IFBNLCBDYXJsb3MgUGlnbmF0YXJvIChj cGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbT4gd3JvdGU6DQo+IERhdmlkIHJlc3BvbmRlZCB0 byB0aGlzLCB0aG91Z2ggSeKAmWQgbGlrZSB0byBhZGQgYSBjb3VwbGUgdGhvdWdodHMsIGlubGlu ZS4NCj4gDQo+ID4gT24gQXByIDUsIDIwMTcsIGF0IDM6NDMgUE0sIEdyZWcgTWlyc2t5IDxncmVn aW1pcnNreUBnbWFpbC5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgRGF2aWQsDQo+ID4gdGhhbmsg eW91IGZvciB5b3VyIGRldGFpbGVkIGZvbGxvdy11cCBjb21tZW50cy4gUGxlYXNlIGZpbmQgbXkg bm90ZXMgaW4tbGluZSBhbmQgdGFnZ2VkIEdJTT4+Lg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBH cmVnDQo+ID4NCj4gPiBPbiBXZWQsIEFwciA1LCAyMDE3IGF0IDEwOjU0IEFNLCBEYXZpZCBNb3pl cyA8ZGF2aWRtQG1lbGxhbm94LmNvbT4gd3JvdGU6DQo+ID4gSGkgR3JlZyAgLA0KPiA+DQo+ID4g UFNCDQo+ID4NCj4gPg0KPiA+DQo+ID4gRnJvbTogR3JlZyBNaXJza3kgW21haWx0bzpncmVnaW1p cnNreUBnbWFpbC5jb21dDQo+ID4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwNSwgMjAxNyAyOjIz IEFNDQo+ID4gVG86IERhdmlkIE1vemVzIDxkYXZpZG1AbWVsbGFub3guY29tPg0KPiA+IENjOiBG aW9jY29sYSBHaXVzZXBwZSA8Z2l1c2VwcGUuZmlvY2NvbGFAdGVsZWNvbWl0YWxpYS5pdD47IEJv Y2NpLCBNYXR0aGV3IChOb2tpYSAtIEdCKSA8bWF0dGhldy5ib2NjaUBub2tpYS5jb20+OyBOVk8z IDxudm8zQGlldGYub3JnPjsgZHJhZnQtb29hbWR0LXJ0Z3dnLW9vYW0taGVhZGVyQGlldGYub3Jn DQo+ID4gU3ViamVjdDogUmU6IFBvbGwgZm9yIE5WTzMgV0cgYWRvcHRpb24gYW5kIElQUiBjYWxs IGZvciBkcmFmdC1vb2FtZHQtcnRnd2ctb29hbS1oZWFkZXItMDMNCj4gPg0KPiA+DQo+ID4NCj4g PiBIaSBEYXZpZCwNCj4gPg0KPiA+IHRoYW5rIHlvdSBmb3Igc2hhcmluZyB5b3VyIG9waW5pb24u DQo+ID4NCj4gPiBDb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnkgeW91ciBwb3NpdGlvbi4gWW91IHBy b3Bvc2UgdG8gdXNlIGV4dGVuc2lvbnMvb3B0aW9ucyBmb3IgZW5kLXRvLWVuZCBhY3RpdmUgT0FN Pw0KPiA+DQo+ID4gRGF2aWQ+IHllcw0KPiA+DQo+ID4gIExldCB1cyBsb29rIGF0IHByb2FjdGl2 ZSBjb250aW51aXR5IGNoZWNrIGJldHdlZW4gTlZFcy4gV2h5IHlvdSB0aGluayBhIG1pZGRsZWJv eCBuZWVkcyB0byBiZSBhd2FyZSBvZiB0aGUgT0FNIHBheWxvYWQ/DQo+ID4NCj4gPiBJIGJlbGll dmUgdGhhdCBhIHRyYW5zaWVudCBOVk8zIG5vZGUgc2hvdWxkIG5vdCBsb29rIGludG8gcGF5bG9h ZCBpZiBpdCBpcyBub3QgYWRkcmVzc2VkIHRvIGl0IGF0IGFsbC4NCj4gPg0KPiA+IERhdmlkPiBB cmUgeW91IGxpbWl0IHRoZSBoZWFkZXIganVzdCBmb3IgcHJvYWN0aXZlIE9BTSA/ICBzbyBjaGFu Z2UgdGhlIGRyYWZ0IHRvIGluY2x1ZGUganVzdCB0aGF0IC4gT24gdGhlIGN1cnJlbnQgIGRyYWZ0 IEkgc2VlIGFsbCBraW5kcyBvZiBPQU0NCj4gPg0KPiA+IEdJTT4+IEkgd2FudCB0byBwb2ludCB0 aGF0IHRoZSBkcmFmdCBpbnRyb2R1Y2VzIEFzc29jaWF0ZWQgQ2hhbm5lbCBmb3IgYW4gb3Zlcmxh eSBuZXR3b3JrLiBBc3NvY2lhdGVkIENoYW5uZWwgbWF5IGJlIHVzZWQgZm9yIHNpZ25hbGxpbmcg b3IgT0FNLg0KPiANCj4gV2hvYeKApiB3aGF0IHByb2JsZW0gYXJlIHdlIHNvbHZpbmc/IElubGlu ZSBzaWduYWxpbmcgb2YgT0FNLCBvbiBhIGNvdmVydCBjaGFubmVsPyBBcyBpZiB3ZSBkbyBub3Qg aGF2ZSBlbm91Z2ggd2F5cyBhbHJlYWR5IHRvIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50cz8NCj4g DQo+ID4gT0FNIG1ldGhvZHMgZW5hYmxlIG9wZXJhdG9ycyB0byBwZXJmb3JtIEZhdWx0IE1hbmFn ZW1lbnQgYW5kIFBlcmZvcm1hbmNlIE1vbml0b3JpbmcuIEFtb25nIGZ1bmN0aW9ucyByZXF1aXJl ZCB0byBwZXJmb3JtIGNvbXByZWhlbnNpdmUgRmF1bHQgTWFuYWdlbWVudCBhcmU6DQo+ID4gICAg ICAg4oCiIGZhaWx1cmUgZGV0ZWN0aW9uLCB1c3VhbGx5IGRldGVjdGlvbiBvZiBMb3NzIG9mIENv bnRpbnVpdHkgYnV0IG1heSBpbmNsdWRlIE1pcy1jb25uZWN0aW9uIGRlZmVjdCBhcyB3ZWxsIGZv ciBjb25uZWN0aW9uLW9yaWVudGVkIG5ldHdvcms7DQo+ID4gICAgICAg4oCiIGRlZmVjdCBsb2Nh bGl6YXRpb247DQo+ID4gICAgICAg4oCiIEFsYXJtIEluZGljYXRpb24gU2lnbmFsOw0KPiA+ICAg ICAgIOKAoiBSZW1vdGUgRGVmZWN0IEluZGljYXRpb24uDQo+IA0KPiBJIHRob3VnaHQgb25lIHN0 cm9uZyBwb2ludCBtYWRlIHF1aXRlIGEgZmV3IHRpbWVzIGJ5IG9wZXJhdG9ycyBpcyB0byBtb3Zl IGludG8gbGVzcy1BVE0tbGlrZSBPQU1zIGFuZCBtb3JlIGludG8gdHJhY2Vyb3V0ZS1saWtlIHRv b2xzLiBMZXNzIEFJUyAvIFJESXMgYW5kIG1vcmUgdHJlZXRyYWNlIGFuZCB1ZHAgc2luZ2Vycy4N Cj4gDQo+ID4gRGVwZW5kaW5nIG9uIHRoZSByZXF1aXJlbWVudHMgdG93YXJkcyByZXNpbGllbmN5 IGFuZCByZXN0b3JhdGlvbiwgUHJvdGVjdGlvbiBTd2l0Y2hvdmVyIENvb3JkaW5hdGlvbiBwcm90 b2NvbCBtYXkgYmUgcmVxdWlyZWQuDQo+ID4gUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgdXN1YWxs eSBzdXBwb3J0cyB0aGUgZm9sbG93aW5nOg0KPiA+ICAgICAgIOKAoiBvbmUtd2F5IGFuZCB0d28t d2F5IFBhY2tldCBMb3NzIG1lYXN1cmVtZW50Ow0KPiA+ICAgICAgIOKAoiBvbmUtd2F5IGFuZCB0 d28td2F5IFBhY2tldCBEZWxheSBtZWFzdXJlbWVudDsNCj4gPiAgICAgICDigKIgU3ludGhldGlj IExvc3MgTWVhc3VyZW1lbnQuDQo+ID4gU2VydmljZSBBY3RpdmF0aW9uIFByb3RvY29sLCBhcyBw YXJ0IG9mIGFjdGl2ZSBPQU0gdG9vbHNldCwgdXN1YWxseSBjb21iaW5lcyBPQU0gZnVuY3Rpb25z IGZyb20gRk0gYW5kIFBNIG9wZXJhdGlvbnMuDQo+ID4gVGhlIGdvYWwgb2YgT3ZlcmxheSBPQU0g d29yaywgYXMgSSB1bmRlcnN0YW5kLCBpcyB0byBjcmVhdGUgY29tbW9uIHNldCBvZiBPQU0gcHJv dG9jb2xzIHRoYXQgc3VwcG9ydHMgYWxsIG9mIGxpc3RlZCBhYm92ZSBGTSBhbmQgUE0gb3BlcmF0 aW9ucy4gSSBzZWUgc3VjaCBzZXQgYXMgY29tYmluYXRpb24gb2YgYWN0aXZlLCBoeWJyaWQgYW5k IHBhc3NpdmUgT0FNIG1ldGhvZHMuIEkgYmVsaWV2ZSB0aGF0IHRoZSBkcmFmdCBzdGF0ZXMgdGhh dCBjbGVhcmx5LiBUaGUgcHJvYWN0aXZlIE9BTSBpcyB1c3VhbGx5IHVzZWQgdG8gcGVyZm9ybSBt b25pdG9yIG5ldHdvcmsgZm9yIGRlZmVjdHMgYW5kIHBlcmZvcm1hbmNlIGRlZ3JhZGF0aW9uLiBP bi1kZW1hbmQgT0FNIHRvb2xzIG1heSBiZSB1c2VkIHRvIGxvY2FsaXplIHRoZSBkZWZlY3RzLg0K PiA+DQo+IA0KPiBUaGUgdGVtcGVyYXR1cmUgb2YgdGhlIG9jZWFuIGRvZXMgbm90IHNlZW0gdG8g Y2hhbmdlLi4uDQo+IA0KPiA+DQo+ID4gPiBXaGlsZSAgSSBhZ3JlZSB3aXRoIHlvdSByZWdhcmRp bmcgIE1pZGRsZSBib3ggYW5kIHByb2FjdGl2ZSBPQU0gLlRoZSBzYW1lIGNhbiBiZSBhY2hpZXZl IHdpdGggdGhlIHByb3RvY29sIGV4dGVuc2lvbnMNCj4gPg0KPiA+IFRodXMgSSBkb24ndCBhZ3Jl ZSB0aGF0IHRoZSByZXF1aXJlbWVudCB5b3UgcmVmZXIgdG8gaXMgYXBwbGljYWJsZSB0byB1c2Ug b2YgYWN0aXZlIE9BTS4NCj4gPg0KPiA+IERhdmlkPiBJIHRoaW5rIGlmIHRoZSBXRyBkZWNpZGUg b24gTlZPMyBlbmNhcCBwcm90b2NvbCB0aGF0IGluY2x1ZGUgIGV4dGVuc2lvbiAoTGlrZSBHVUUg YW5kIEdlbmV2ZSkgd2UgaGF2ZSB0byB1c2UgdGhlIGJ1aWxkIGluIGV4dGVuc2lvbnMgZm9yIHN1 Y2ggcHJvdG9jb2wgYW5kIG5vdCBpbm5vdmF0ZSAgZXh0cmEgaGVhZGVyICB0aGF0IHVzZSBmb3Ig cHJvdG9jb2xzIHdpdGhvdXQgZXh0ZW5zaW9ucy4NCj4gPg0KPiA+IEdJTT4+IEkgcXVlc3Rpb24g eW91ciBhc3N1bXB0aW9uIHRoYXQgdXNlIG9mIHZhcmlhYmxlIGxlbmd0aCBoZWFkZXIgbWFuZGF0 ZXMgaG93IE9BTSwgYWN0aXZlIE9BTSwgbXVzdCBiZSBpbXBsZW1lbnRlZC4gQW5kIHNpbmNlIHNv bWUgbmV0d29ya3MgY2hvb3NlIHRvIHVzZSBmaXhlZCBzaXplIGhlYWRlciwgdXNpbmcgT3Zlcmxh eSBBc3NvY2lhdGVkIENoYW5uZWwgaGVhZGVyIHdpdGggbXVsdGlwbGV4ZWQgT3ZlcmxheSBPQU0g ZnVuY3Rpb25hbGl0eSBhcHBlYXJzLCBpbiBteSBvcGluaW9uLCBhcyBjb21tb24gc29sdXRpb24g Zm9yIGVpdGhlciB0eXBlIG9mIG92ZXJsYXkgZW5jYXBzdWxhdGlvbi4NCj4gPg0KPiA+DQo+IA0K PiBJIHN0aWxsIGRvIG5vdCBzZWUgaG93IGFuIG92ZXJsYXkgbGF5ZXIgYmVuZWZpdHMgZnJvbSB0 aGlzIHVubmVjZXNzYXJ5IG92ZXJoZWFkLg0KPiANCj4gU3VwcG9ydC0tDQo+IA0KPiBDYXJsb3Mu DQo+IA0KPiA+DQo+ID4gRGF2aWQNCj4gPg0KPiA+IEdyZWcNCj4gPg0KPiA+DQo+ID4NCj4gPiBP biBNb24sIEFwciAzLCAyMDE3IGF0IDExOjE5IEFNLCBEYXZpZCBNb3plcyA8ZGF2aWRtQG1lbGxh bm94LmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSAsDQo+ID4NCj4gPiBJIGFtIG5vdCBzdXBwb3J0 aW5nIHRoZSBhZG9wdGlvbg0KPiA+DQo+ID4gSSB0aGluayB3aGlsZSB0aGUgd29ya2luZyBncm91 cCBkZWNpZGVkIG9uIEdlbmV2ZSBhcyB0aGUgZW5jYXAgcHJvdG9jb2wNCj4gPg0KPiA+DQo+ID4N Cj4gPiBUaGlzIE9BTSBuZWVkIHRvIGJlIHZpYSBvbmUgb2YgdGhlIGV4dGVuc2lvbnMvb3B0aW9u cyAgdGhlIHByb3RvY29sICAgaXMgc3VwcG9ydGluZyENCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGlz IGhlYWRlciBhbHNvIHZpb2xhdGUgdGhlIG51bWJlciAxIHJlcXVpcmVtZW50cyBmcm9tIHRoZSBl eHRlbnNpb25zL29wdGlvbnMNCj4gPg0KPiA+IFRoYXQgbm9kZS9taWRkbGJveCAgZG9uIG5vdCAg bmVlZCB0byBiZSBwYXJ0IG9mIHRoZSBleHRlbnNpb25zLyBvcHRpb24gY2FuIGp1bXAgZGlyZWN0 bHkgIHRvIHRoZSBvdmVybGF5IGJ5IHJlYWRpbmcgdGhlIGJhc2UgaGVhZGVyIGxlbmd0aCBvbmx5 DQo+ID4NCj4gPg0KPiA+DQo+ID4gVGh4DQo+ID4NCj4gPiBEYXZpZA0KPiA+DQo+ID4NCj4gPg0K PiA+IEZyb206IG52bzMgW21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBGaW9jY29sYSBHaXVzZXBwZQ0KPiA+IFNlbnQ6IE1vbmRheSwgQXByaWwgMDMsIDIwMTcgNTo0 MCBQTQ0KPiA+IFRvOiBCb2NjaSwgTWF0dGhldyAoTm9raWEgLSBHQikgPG1hdHRoZXcuYm9jY2lA bm9raWEuY29tPjsgTlZPMyA8bnZvM0BpZXRmLm9yZz47IGRyYWZ0LW9vYW1kdC1ydGd3Zy1vb2Ft LWhlYWRlckBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFtudm8zXSBSOiBQb2xsIGZvciBOVk8zIFdH IGFkb3B0aW9uIGFuZCBJUFIgY2FsbCBmb3IgZHJhZnQtb29hbWR0LXJ0Z3dnLW9vYW0taGVhZGVy LTAzDQo+ID4NCj4gPg0KPiA+DQo+ID4gSGkgQWxsLA0KPiA+DQo+ID4gSSBoYXZlIHJlYWQgdGhl IGRyYWZ0IGFuZCBzdXBwb3J0IGl0cyBhZG9wdGlvbi4NCj4gPg0KPiA+DQo+ID4NCj4gPiBSZWdh cmRzLA0KPiA+DQo+ID4NCj4gPg0KPiA+IEdpdXNlcHBlDQo+ID4NCj4gPg0KPiA+DQo+ID4gRGE6 IG52bzMgW21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddIFBlciBjb250byBkaSBCb2NjaSwg TWF0dGhldyAoTm9raWEgLSBHQikNCj4gPiBJbnZpYXRvOiB2ZW5lcmTDrCAzMSBtYXJ6byAyMDE3 IDE3OjM1DQo+ID4gQTogTlZPMzsgZHJhZnQtb29hbWR0LXJ0Z3dnLW9vYW0taGVhZGVyQGlldGYu b3JnDQo+ID4gT2dnZXR0bzogW252bzNdIFBvbGwgZm9yIE5WTzMgV0cgYWRvcHRpb24gYW5kIElQ UiBjYWxsIGZvciBkcmFmdC1vb2FtZHQtcnRnd2ctb29hbS1oZWFkZXItMDMNCj4gPg0KPiA+DQo+ ID4NCj4gPiBUaGlzIGVtYWlsIGJlZ2lucyBhIHR3byB3ZWVrIHBvbGwgZm9yIGFkb3B0aW9uIG9m IGRyYWZ0LW9vYW1kdC1ydGd3Zy1vb2FtLWhlYWRlci0wMyBpbiB0aGUgTlZPMyB3b3JraW5nIGdy b3VwLg0KPiA+DQo+ID4NCj4gPg0KPiA+IFBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBzZW5k IGFueSBjb21tZW50cyB0byB0aGUgTlZPMyBsaXN0Lg0KPiA+DQo+ID4gUGxlYXNlIGFsc28gaW5k aWNhdGUgd2hldGhlciB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGUgZHJhZnQgYXMgYW4gTlZP MyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPiA+DQo+ID4NCj4gPg0KPiA+IFNpbXVsdGFuZW91 c2x5LCB3ZSBhcmUgYWxzbyBwb2xpbmcgZm9yIGFueSBJUFIgdGhhdCBtYXkgYXBwbHkgdG8gdGhl IGRyYWZ0Lg0KPiA+DQo+ID4NCj4gPg0KPiA+IEF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycywgYXJl IHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Pw0KPiA+DQo+ ID4NCj4gPg0KPiA+IElmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxp YW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1 Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KPiA+DQo+ID4NCj4gPg0KPiA+IElmIHlvdSBhcmUgbGlz dGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCBwbGVhc2UgcmVzcG9uZCB0 bw0KPiA+DQo+ID4gdGhpcyBlbWFpbCBzdGF0aW5nIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUg YXdhcmUgb2YgYW55IHJlbGV2YW50DQo+ID4NCj4gPiBJUFIuIFRoZSByZXNwb25zZSBuZWVkcyB0 byBiZSBzZW50IHRvIHRoZSBOVk8zIFdHIG1haWxpbmcgbGlzdC4gVGhlDQo+ID4NCj4gPiBkb2N1 bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UN Cj4gPg0KPiA+IGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGVhY2ggY29u dHJpYnV0b3IuDQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhpcyBwb2xsIGNsb3NlcyBvbiBGcmlkYXkg MTR0aCBBcHJpbCAyMDE3Lg0KPiA+DQo+ID4NCj4gPg0KPiA+IFJlZ2FyZHMNCj4gPg0KPiA+DQo+ ID4NCj4gPiBNYXR0aGV3IGFuZCBTYW0NCj4gPg0KPiA+IFF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1 b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUg aW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBk ZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmln b3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3Vt ZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVk aWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBk aXN0cnV6aW9uZSwgR3JhemllLg0KPiA+DQo+ID4gVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29w eWluZywgcHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVy biBlLW1haWwsIFRoYW5rcy4NCj4gPg0KPiA+IDxpbWFnZTAwMS5naWY+UmlzcGV0dGEgbCdhbWJp ZW50ZS4gTm9uIHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiDDqCBuZWNlc3NhcmlvLg0KPiA+ DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gbnZvMyBtYWlsaW5nIGxpc3QNCj4gPiBudm8zQGll dGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo+ IA0KPiANCg0K From nobody Tue Apr 11 20:11:16 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088BE127241; Tue, 11 Apr 2017 20:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OVUMC9PGfxc; Tue, 11 Apr 2017 20:11:10 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147D71242F5; Tue, 11 Apr 2017 20:11:10 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id f22so18028718oib.2; Tue, 11 Apr 2017 20:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LNaUwXEJCTGJMDdV6W5oayECYel2/o0lyswoQsVd0Gg=; b=qhX6DT/XBRg6nvkzNyCg5mkAEEkJ9p6X2U3StE792dkAan8MjRU6nkO84DGNjd49rZ U457RvStxJ+0RAq98eKGW43gDMvpbsMknCoemEd+8gTrkvrnAPMcmUHR+to+uEW91FEG QNv7Nw9jiyRW03B5arJNB+GYGVBQ8iboGq4wRKu5DCf7cQtPFGA1srni+O2sVJrFcFhd cRs1RqgFLTHxhW1/gmi+Rgtar4M9bLuRwuy37JYao/qFYzt4TW3vAqN4qblm+DkM6Yde zz61FNjf5bjFtIrz6T7cHavB3+n/ngcfiKozb7pdlk4HxpGHu0NwtEVjobOQO1FIauxT MUKQ== 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=LNaUwXEJCTGJMDdV6W5oayECYel2/o0lyswoQsVd0Gg=; b=OxlPEBcmWDKarYpP2ORQxD1BJOLC/SwSAqJ8hKc/+XE1wNKpVGhNlIZP/6XcS2n6yx GD16UQHURNRSGpsMuwu430wPK4CvAMINiADgUWaXUXPxVepLS9kvoiw7oN80SyasL2tR BiOtlFoMghI19k/sQ7Qw941YhcQy7fobBmvYqp3u5B//cC98JUMN4r4zp8Kk2K1JwDaZ t5LnxBYvYnMdzTyTnNf04XO2mCcyp3pygFMftzWp/bWK3frBYJItft/Jb69kcoUljmk/ hM40IWx0spfQ+lPAiqESJN+SroDWBcee9JkcSMy0e+7s2cc6P0Kt/MNMXUm9R1HWXmF9 80nw== X-Gm-Message-State: AN3rC/7hTWZzuc/EcY5/eHvKMdCxSdwWustD6AG2/Wyk1N8i/rV/vPWctIkAX3kDo57gTuoN0aVBWVGS+Ltq9Q== X-Received: by 10.157.12.42 with SMTP id 39mr6143830otr.35.1491966669388; Tue, 11 Apr 2017 20:11:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.165 with HTTP; Tue, 11 Apr 2017 20:11:08 -0700 (PDT) In-Reply-To: <9BC52F60-6E9A-4594-AC95-4F0186BF81D4@cisco.com> References: <9BC52F60-6E9A-4594-AC95-4F0186BF81D4@cisco.com> From: Greg Mirsky Date: Tue, 11 Apr 2017 20:11:08 -0700 Message-ID: Subject: Re: [nvo3] Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03 To: "Carlos Pignataro (cpignata)" Cc: David Mozes , "Bocci, Matthew (Nokia - GB)" , NVO3 , "draft-ooamdt-rtgwg-ooam-header@ietf.org" , Fioccola Giuseppe , "sfc@ietf.org" , "bier@ietf.org" , "rtgwg@ietf.org" , spring-chairs@ietf.org Content-Type: multipart/alternative; boundary=94eb2c04f09c58828f054cef8fb5 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 03:11:14 -0000 --94eb2c04f09c58828f054cef8fb5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, as you've noted, this is WG adoption call, not WG last call. I'll let others to decide whether the proposed Overlay Associated Channel which, borrowing from RFC 7212, "provides an auxiliary logical data channel associated with" an instance of the overlay network "over which a variety of protocols may flow" enables design and development of Overlay OAM protocols to be re-useable among Overlay networks. Regards, Greg On Tue, Apr 11, 2017 at 7:16 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Greg, > > I am providing some follow-ups below, but I will top-post note that you > completely missed responding to the key issues raised: what problem is th= is > really attempting to solve? what is gained by this extra overhead and > indirection? what is overlay-specific in this header? > > After this email, since I believe I made my points already, I will let > others comment. > > Please see inline=E2=80=A6 > > > On Apr 9, 2017, at 10:07 PM, Greg Mirsky wrote: > > > > Hi Carlos, > > if we had the OAM requirements that WGs, i.e. NVO3, SFC, and BIER, > agreed on > > This shows a fundamental misunderstanding of WG operations by you, if I > follow your logic correctly. > > An existing Internet-Draft under a WG control means that at some point th= e > WG thought it useful to work on that problem, and the WG charter allowed > for that scope. It does *not* mean that every word and every sentence is > agreed by the WG, or that they even make sense. [RFC 2418], [RFC 7221] > Agreement is via consensus. > > With that context in mind... > > > , then, I believe, we only had to check if the proposed solution > addresses one of the requirements. I strongly believe that having OAM > requirements as working document, not necessarily to be published, is ver= y > helpful. > > But I'm surprised that you suggest that defect indication, in peer and > multi-layer OAM interworking in not required. You're co-author of OAM > requirements draft in SPRING WG that has the following requirement: > > Interestingly, after a dialogue with one of the spring chairs in Chicago, > I emailed the spring chairs (Cc=E2=80=99ed on this note) and draft contri= butors > alias stating that there=E2=80=99s really no value on that document. On t= hat email > thread, you were the only dissenting voice trying to hold on to that > document. > > Now, is SPRING also an overlay for which you suggest > draft-ooamdt-rtgwg-ooam-header has a solution? The MPLS, IPv6 encap, or > both? I=E2=80=99d love to know, since you had previously said =E2=80=9CNV= O3, SFC, BIER=E2=80=9D (a > rather capricious choice, apparently) > > You seem to have missed the main point I was making here though: since > operators said in IETF95=E2=80=99s rtgwg meeting they want more tracerout= e-like and > less traditional-like tools, are you ignoring operational needs? > > > REQ#11: When SR OAM is initialized from centralized controller, it > > MUST have the ability to alert any edge node in SR domain > > about the corresponding path or service failure. The node > > on receiving the alert MAY take a local protection action o= r > > pop an informational message. > > > > I=E2=80=99ve rarely seen solutions evaluated against requirements, unless > hand-picked requirements were reverse-engineered from solutions. > > > Isn't that the functionality that is exactly supported by RDI and AIS? > > As it is the case here it seems to me. > > > Then in BIER WG adopted OAM Requirements, that you are co-author ed, I > find this: > > Similarly, it is funny to see the (lack of) differences and progress > between 2015=E2=80=99s draft-mirsky-bier-oam-requirements-00 and > draft-ietf-bier-oam-requirements-03: > > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-bier- > oam-requirements-03.txt&url1=3Ddraft-mirsky-bier-oam-requirements-00.txt > > Content differences are effectively null. Do you really insist in calling > that WG agreement? > > > > 10. BIER OAM MUST support Reverse Defect Indication (RDI) > > notification of the source of continuity checking BFR by Bit- > > Forwarding Egress Routers (BFERs), e.g. by using Diag in p2mp > > BFD with active tail support. > > > > and this > > 13. BIER OAM MUST support defect notification mechanism, like Alarm > > Indication Signal. Any BFR in the given BIER domain MAY > > originate a defect notification addressed to any subset of BFRs > > within the domain. > > > > You don't agree with these requirements? > > > > It=E2=80=99s odd, those requirements read to me like =E2=80=9CI require t= his solution=E2=80=9D=E2=80=A6 > not real requirements=E2=80=A6 > > And these are not the things I hear operators need. No. > > Best, > > =E2=80=94 Carlos. > > > Regards, > > Greg > > > > On Thu, Apr 6, 2017 at 7:55 PM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > > David responded to this, though I=E2=80=99d like to add a couple though= ts, > inline. > > > > > On Apr 5, 2017, at 3:43 PM, Greg Mirsky wrote= : > > > > > > Hi David, > > > thank you for your detailed follow-up comments. Please find my notes > in-line and tagged GIM>>. > > > > > > Regards, > > > Greg > > > > > > On Wed, Apr 5, 2017 at 10:54 AM, David Mozes > wrote: > > > Hi Greg , > > > > > > PSB > > > > > > > > > > > > From: Greg Mirsky [mailto:gregimirsky@gmail.com] > > > Sent: Wednesday, April 05, 2017 2:23 AM > > > To: David Mozes > > > Cc: Fioccola Giuseppe ; Bocci, > Matthew (Nokia - GB) ; NVO3 ; > draft-ooamdt-rtgwg-ooam-header@ietf.org > > > Subject: Re: Poll for NVO3 WG adoption and IPR call for > draft-ooamdt-rtgwg-ooam-header-03 > > > > > > > > > > > > Hi David, > > > > > > thank you for sharing your opinion. > > > > > > Could you please clarify your position. You propose to use > extensions/options for end-to-end active OAM? > > > > > > David> yes > > > > > > Let us look at proactive continuity check between NVEs. Why you thin= k > a middlebox needs to be aware of the OAM payload? > > > > > > I believe that a transient NVO3 node should not look into payload if > it is not addressed to it at all. > > > > > > David> Are you limit the header just for proactive OAM ? so change > the draft to include just that . On the current draft I see all kinds of > OAM > > > > > > GIM>> I want to point that the draft introduces Associated Channel fo= r > an overlay network. Associated Channel may be used for signalling or OAM. > > > > Whoa=E2=80=A6 what problem are we solving? Inline signaling of OAM, on = a covert > channel? As if we do not have enough ways already to address the > requirements? > > > > > OAM methods enable operators to perform Fault Management and > Performance Monitoring. Among functions required to perform comprehensive > Fault Management are: > > > =E2=80=A2 failure detection, usually detection of Loss of Conti= nuity but > may include Mis-connection defect as well for connection-oriented network= ; > > > =E2=80=A2 defect localization; > > > =E2=80=A2 Alarm Indication Signal; > > > =E2=80=A2 Remote Defect Indication. > > > > I thought one strong point made quite a few times by operators is to > move into less-ATM-like OAMs and more into traceroute-like tools. Less AI= S > / RDIs and more treetrace and udp singers. > > > > > Depending on the requirements towards resiliency and restoration, > Protection Switchover Coordination protocol may be required. > > > Performance Measurement usually supports the following: > > > =E2=80=A2 one-way and two-way Packet Loss measurement; > > > =E2=80=A2 one-way and two-way Packet Delay measurement; > > > =E2=80=A2 Synthetic Loss Measurement. > > > Service Activation Protocol, as part of active OAM toolset, usually > combines OAM functions from FM and PM operations. > > > The goal of Overlay OAM work, as I understand, is to create common se= t > of OAM protocols that supports all of listed above FM and PM operations. = I > see such set as combination of active, hybrid and passive OAM methods. I > believe that the draft states that clearly. The proactive OAM is usually > used to perform monitor network for defects and performance degradation. > On-demand OAM tools may be used to localize the defects. > > > > > > > The temperature of the ocean does not seem to change... > > > > > > > > > While I agree with you regarding Middle box and proactive OAM .Th= e > same can be achieve with the protocol extensions > > > > > > Thus I don't agree that the requirement you refer to is applicable to > use of active OAM. > > > > > > David> I think if the WG decide on NVO3 encap protocol that include > extension (Like GUE and Geneve) we have to use the build in extensions fo= r > such protocol and not innovate extra header that use for protocols > without extensions. > > > > > > GIM>> I question your assumption that use of variable length header > mandates how OAM, active OAM, must be implemented. And since some network= s > choose to use fixed size header, using Overlay Associated Channel header > with multiplexed Overlay OAM functionality appears, in my opinion, as > common solution for either type of overlay encapsulation. > > > > > > > > > > I still do not see how an overlay layer benefits from this unnecessary > overhead. > > > > Support-- > > > > Carlos. > > > > > > > > David > > > > > > Greg > > > > > > > > > > > > On Mon, Apr 3, 2017 at 11:19 AM, David Mozes > wrote: > > > > > > Hi , > > > > > > I am not supporting the adoption > > > > > > I think while the working group decided on Geneve as the encap protoc= ol > > > > > > > > > > > > This OAM need to be via one of the extensions/options the protocol > is supporting! > > > > > > > > > > > > This header also violate the number 1 requirements from the > extensions/options > > > > > > That node/middlbox don not need to be part of the extensions/ optio= n > can jump directly to the overlay by reading the base header length only > > > > > > > > > > > > Thx > > > > > > David > > > > > > > > > > > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Fioccola > Giuseppe > > > Sent: Monday, April 03, 2017 5:40 PM > > > To: Bocci, Matthew (Nokia - GB) ; NVO3 < > nvo3@ietf.org>; draft-ooamdt-rtgwg-ooam-header@ietf.org > > > Subject: [nvo3] R: Poll for NVO3 WG adoption and IPR call for > draft-ooamdt-rtgwg-ooam-header-03 > > > > > > > > > > > > Hi All, > > > > > > I have read the draft and support its adoption. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Giuseppe > > > > > > > > > > > > Da: nvo3 [mailto:nvo3-bounces@ietf.org] Per conto di Bocci, Matthew > (Nokia - GB) > > > Inviato: venerd=C3=AC 31 marzo 2017 17:35 > > > A: NVO3; draft-ooamdt-rtgwg-ooam-header@ietf.org > > > Oggetto: [nvo3] Poll for NVO3 WG adoption and IPR call for > draft-ooamdt-rtgwg-ooam-header-03 > > > > > > > > > > > > This email begins a two week poll for adoption of > draft-ooamdt-rtgwg-ooam-header-03 in the NVO3 working group. > > > > > > > > > > > > Please review the draft and send any comments to the NVO3 list. > > > > > > Please also indicate whether you support adoption of the draft as an > NVO3 working group document. > > > > > > > > > > > > Simultaneously, we are also poling for any IPR that may apply to the > draft. > > > > > > > > > > > > Authors and contributors, are you aware of any IPR that applies to > this draft? > > > > > > > > > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > > > > > > > > > > > If you are listed as a document author or contributor, please respond > to > > > > > > this email stating of whether or not you are aware of any relevant > > > > > > IPR. The response needs to be sent to the NVO3 WG mailing list. The > > > > > > document will not advance to the next stage until a response > > > > > > has been received from each author and each contributor. > > > > > > > > > > > > This poll closes on Friday 14th April 2017. > > > > > > > > > > > > Regards > > > > > > > > > > > > Matthew and Sam > > > > > > 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. > > > > > > 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 an= d > advise the sender by return e-mail, Thanks. > > > > > > Rispetta l'ambiente. Non stampare questa mail se non = =C3=A8 > necessario. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > nvo3 mailing list > > > nvo3@ietf.org > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > --94eb2c04f09c58828f054cef8fb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos,
as you've noted, this is WG adoption ca= ll, not WG last call.
I'll let others to decide whether the p= roposed Overlay Associated Channel which, borrowing from RFC 7212, "provides an auxiliary=C2= =A0logical data= channel associated with" an instance of the overlay network "over which a varie= ty of protocols may=C2=A0flow" enables design and development of Overlay OAM protocol= s to be re-useable among Overlay networks.

Regards,
Greg

On Tue, Apr 11, 2017 at 7:1= 6 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrot= e:
Greg,

I am providing some follow-ups below, but I will top-post note that you com= pletely missed responding to the key issues raised: what problem is this re= ally attempting to solve? what is gained by this extra overhead and indirec= tion? what is overlay-specific in this header?

After this email, since I believe I made my points already, I will let othe= rs comment.

Please see inline=E2=80=A6

> On Apr 9, 2017, at 10:07 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Carlos,
> if we had the OAM requirements that WGs, i.e. NVO3, SFC, and BIER, agr= eed on

This shows a fundamental misunderstanding of WG operations by you, i= f I follow your logic correctly.

An existing Internet-Draft under a WG control means that at some point the = WG thought it useful to work on that problem, and the WG charter allowed fo= r that scope. It does *not* mean that every word and every sentence is agre= ed by the WG, or that they even make sense. [RFC 2418], [RFC 7221] Agreemen= t is via consensus.

With that context in mind...

> , then, I believe, we only had to check if the proposed solution addre= sses one of the requirements. I strongly believe that having OAM requiremen= ts as working document, not necessarily to be published, is very helpful. > But I'm surprised that you suggest that defect indication, in peer= and multi-layer OAM interworking in not required. You're co-author of = OAM requirements draft in SPRING WG that has the following requirement:

Interestingly, after a dialogue with one of the spring chairs in Chi= cago, I emailed the spring chairs (Cc=E2=80=99ed on this note) and draft co= ntributors alias stating that there=E2=80=99s really no value on that docum= ent. On that email thread, you were the only dissenting voice trying to hol= d on to that document.

Now, is SPRING also an overlay for which you suggest draft-ooamdt-rtgwg-ooa= m-header has a solution? The MPLS, IPv6 encap, or both? I=E2=80=99d love to= know, since you had previously said =E2=80=9CNVO3, SFC, BIER=E2=80=9D (a r= ather capricious choice, apparently)

You seem to have missed the main point I was making here though: since oper= ators said in IETF95=E2=80=99s rtgwg meeting they want more traceroute-like= and less traditional-like tools, are you ignoring operational needs?

>=C2=A0 =C2=A0 REQ#11:=C2=A0 When SR OAM is initialized from centralized= controller, it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST have the ability t= o alert any edge node in SR domain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0about the corresponding= path or service failure.=C2=A0 The node
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on receiving the alert = MAY take a local protection action or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pop an informational me= ssage.
>

I=E2=80=99ve rarely seen solutions evaluated against requirements, u= nless hand-picked requirements were reverse-engineered from solutions.

> Isn't that the functionality that is exactly supported by RDI and = AIS?

As it is the case here it seems to me.

> Then in BIER WG adopted OAM Requirements, that you are co-author ed, I= find this:

Similarly, it is funny to see the (lack of) differences and progress= between 2015=E2=80=99s draft-mirsky-bier-oam-requirements-00 and draf= t-ietf-bier-oam-requirements-03:

https://tools.ietf.org/rfcdiff?url2=3Ddr= aft-ietf-bier-oam-requirements-03.txt&url1=3Ddraft-mirsky-bie= r-oam-requirements-00.txt

Content differences are effectively null. Do you really insist in calling t= hat WG agreement?


>=C2=A0 =C2=A0 10.=C2=A0 BIER OAM MUST support Reverse Defect Indication= (RDI)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notification of the source of continu= ity checking BFR by Bit-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Forwarding Egress Routers (BFERs), e.= g. by using Diag in p2mp
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD with active tail support.
>
> and this
>=C2=A0 =C2=A0 13.=C2=A0 BIER OAM MUST support defect notification mecha= nism, like Alarm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Indication Signal.=C2=A0 Any BFR in t= he given BIER domain MAY
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0originate a defect notification addre= ssed to any subset of BFRs
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0within the domain.
>
> You don't agree with these requirements?
>

It=E2=80=99s odd, those requirements read to me like =E2=80=9CI requ= ire this solution=E2=80=9D=E2=80=A6 not real requirements=E2=80=A6

And these are not the things I hear operators need. No.

Best,

=E2=80=94 Carlos.

> Regards,
> Greg
>
> On Thu, Apr 6, 2017 at 7:55 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
> David responded to this, though I=E2=80=99d like to add a couple thoug= hts, inline.
>
> > On Apr 5, 2017, at 3:43 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
> >
> > Hi David,
> > thank you for your detailed follow-up comments. Please find my no= tes in-line and tagged GIM>>.
> >
> > Regards,
> > Greg
> >
> > On Wed, Apr 5, 2017 at 10:54 AM, David Mozes <davidm@mellanox.com> wrote:
> > Hi Greg=C2=A0 ,
> >
> > PSB
> >
> >
> >
> > From: Greg Mirsky [mailto:gregimirsky@gmail.com]
> > Sent: Wednesday, April 05, 2017 2:23 AM
> > To: David Mozes <davidm= @mellanox.com>
> > Cc: Fioccola Giuseppe <giuseppe.fioccola@telecomitalia.it>; Bocci, Matt= hew (Nokia - GB) <matthew.boc= ci@nokia.com>; NVO3 <nvo3@ietf.o= rg>; draf= t-ooamdt-rtgwg-ooam-header@ietf.org
> > Subject: Re: Poll for NVO3 WG adoption and IPR call for draft-ooa= mdt-rtgwg-ooam-header-03
> >
> >
> >
> > Hi David,
> >
> > thank you for sharing your opinion.
> >
> > Could you please clarify your position. You propose to use extens= ions/options for end-to-end active OAM?
> >
> > David> yes
> >
> >=C2=A0 Let us look at proactive continuity check between NVEs. Why= you think a middlebox needs to be aware of the OAM payload?
> >
> > I believe that a transient NVO3 node should not look into payload= if it is not addressed to it at all.
> >
> > David> Are you limit the header just for proactive OAM ?=C2=A0= so change the draft to include just that . On the current=C2=A0 draft I se= e all kinds of OAM
> >
> > GIM>> I want to point that the draft introduces Associated = Channel for an overlay network. Associated Channel may be used for signalli= ng or OAM.
>
> Whoa=E2=80=A6 what problem are we solving? Inline signaling of OAM, on= a covert channel? As if we do not have enough ways already to address the = requirements?
>
> > OAM methods enable operators to perform Fault Management and Perf= ormance Monitoring. Among functions required to perform comprehensive Fault= Management are:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 failure detection, usually de= tection of Loss of Continuity but may include Mis-connection defect as well= for connection-oriented network;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 defect localization;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Alarm Indication Signal;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Remote Defect Indication.
>
> I thought one strong point made quite a few times by operators is to m= ove into less-ATM-like OAMs and more into traceroute-like tools. Less AIS /= RDIs and more treetrace and udp singers.
>
> > Depending on the requirements towards resiliency and restoration,= Protection Switchover Coordination protocol may be required.
> > Performance Measurement usually supports the following:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 one-way and two-way Packet Lo= ss measurement;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 one-way and two-way Packet De= lay measurement;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Synthetic Loss Measurement. > > Service Activation Protocol, as part of active OAM toolset, usual= ly combines OAM functions from FM and PM operations.
> > The goal of Overlay OAM work, as I understand, is to create commo= n set of OAM protocols that supports all of listed above FM and PM operatio= ns. I see such set as combination of active, hybrid and passive OAM methods= . I believe that the draft states that clearly. The proactive OAM is usuall= y used to perform monitor network for defects and performance degradation. = On-demand OAM tools may be used to localize the defects.
> >
>
> The temperature of the ocean does not seem to change...
>
> >
> > > While=C2=A0 I agree with you regarding=C2=A0 Middle box and = proactive OAM .The same can be achieve with the protocol extensions
> >
> > Thus I don't agree that the requirement you refer to is appli= cable to use of active OAM.
> >
> > David> I think if the WG decide on NVO3 encap protocol that in= clude=C2=A0 extension (Like GUE and Geneve) we have to use the build in ext= ensions for such protocol and not innovate=C2=A0 extra header=C2=A0 that us= e for protocols without extensions.
> >
> > GIM>> I question your assumption that use of variable lengt= h header mandates how OAM, active OAM, must be implemented. And since some = networks choose to use fixed size header, using Overlay Associated Channel = header with multiplexed Overlay OAM functionality appears, in my opinion, a= s common solution for either type of overlay encapsulation.
> >
> >
>
> I still do not see how an overlay layer benefits from this unnecessary= overhead.
>
> Support--
>
> Carlos.
>
> >
> > David
> >
> > Greg
> >
> >
> >
> > On Mon, Apr 3, 2017 at 11:19 AM, David Mozes <davidm@mellanox.com> wrote:
> >
> > Hi ,
> >
> > I am not supporting the adoption
> >
> > I think while the working group decided on Geneve as the encap pr= otocol
> >
> >
> >
> > This OAM need to be via one of the extensions/options=C2=A0 the p= rotocol=C2=A0 =C2=A0is supporting!
> >
> >
> >
> > This header also violate the number 1 requirements from the exten= sions/options
> >
> > That node/middlbox=C2=A0 don not=C2=A0 need to be part of the ext= ensions/ option can jump directly=C2=A0 to the overlay by reading the base = header length only
> >
> >
> >
> > Thx
> >
> > David
> >
> >
> >
> > From: nvo3 [mailto:nvo3-= bounces@ietf.org] On Behalf Of Fioccola Giuseppe
> > Sent: Monday, April 03, 2017 5:40 PM
> > To: Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>; NVO3 <nvo3@ietf.org>; draft-ooamdt-rtgwg-ooam-header@ietf.org
> > Subject: [nvo3] R: Poll for NVO3 WG adoption and IPR call for dra= ft-ooamdt-rtgwg-ooam-header-03
> >
> >
> >
> > Hi All,
> >
> > I have read the draft and support its adoption.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Giuseppe
> >
> >
> >
> > Da: nvo3 [mailto:nvo3-bo= unces@ietf.org] Per conto di Bocci, Matthew (Nokia - GB)
> > Inviato: venerd=C3=AC 31 marzo 2017 17:35
> > A: NVO3; draft-ooamdt-rtgwg-ooam-header@ietf.org
> > Oggetto: [nvo3] Poll for NVO3 WG adoption and IPR call for draft-= ooamdt-rtgwg-ooam-header-03
> >
> >
> >
> > This email begins a two week poll for adoption of draft-ooamdt-rt= gwg-ooam-header-03 in the NVO3 working group.
> >
> >
> >
> > Please review the draft and send any comments to the NVO3 list. > >
> > Please also indicate whether you support adoption of the draft as= an NVO3 working group document.
> >
> >
> >
> > Simultaneously, we are also poling for any IPR that may apply to = the draft.
> >
> >
> >
> > Authors and contributors, are you aware of any IPR that applies t= o this draft?
> >
> >
> >
> > If so, has this IPR been disclosed in compliance with IETF IPR ru= les (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> >
> >
> >
> > If you are listed as a document author or contributor, please res= pond to
> >
> > this email stating of whether or not you are aware of any relevan= t
> >
> > IPR. The response needs to be sent to the NVO3 WG mailing list. T= he
> >
> > document will not advance to the next stage until a response
> >
> > has been received from each author and each contributor.
> >
> >
> >
> > This poll closes on Friday 14th April 2017.
> >
> >
> >
> > Regards
> >
> >
> >
> > Matthew and Sam
> >
> > Questo messaggio e i suoi allegati sono indirizzati esclusivament= e alle persone indicate. La diffusione, copia o qualsiasi altra azione deri= vante dalla conoscenza di queste informazioni sono rigorosamente vietate. Q= ualora abbiate ricevuto questo documento per errore siete cortesemente preg= ati di darne immediata comunicazione al mittente e di provvedere alla sua d= istruzione, Grazie.
> >
> > This e-mail and any attachments is confidential and may contain p= rivileged information intended for the addressee(s) only. Dissemination, co= pying, printing or use by anybody else is unauthorised. If you are not the = intended recipient, please delete this message and any attachments and advi= se the sender by return e-mail, Thanks.
> >
> > <image001.gif>Rispetta l'ambiente. Non stampare questa = mail se non =C3=A8 necessario.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > nvo3 mailing list
> > nvo3@ietf.org
> > https://www.ietf.org/mailman/listinfo/nvo3<= /a>
>
>


--94eb2c04f09c58828f054cef8fb5-- From nobody Tue Apr 11 23:46:09 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75387127275; Tue, 11 Apr 2017 23:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mellanox.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 Z521yL5TEsXR; Tue, 11 Apr 2017 23:45:21 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0056.outbound.protection.outlook.com [104.47.0.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA951289C3; Tue, 11 Apr 2017 23:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3W6+pIxAGqi6ptT79BYEqV5rVgGzIEzvjDxZXu+x3Xc=; b=nf/S8N/Ps4cRGn4CNtyYKGSkWAwbXT9CQRz4Rebrxs/++ZgCsZw0FrQDZbcrE2xeFKaf4Y+pIaoTjVAzIIuabdUDS7gSg2NhgeuJRQNCSW8+4Hg1QwCPvDL5BsBsYXyZfFDE+s0dTRiBK2BjHsEftZo/UwTdsy8QdpBApwe57yM= Received: from HE1PR0501MB2138.eurprd05.prod.outlook.com (10.167.246.22) by HE1PR0501MB2139.eurprd05.prod.outlook.com (10.167.246.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.17; Wed, 12 Apr 2017 06:45:10 +0000 Received: from HE1PR0501MB2138.eurprd05.prod.outlook.com ([10.167.246.22]) by HE1PR0501MB2138.eurprd05.prod.outlook.com ([10.167.246.22]) with mapi id 15.01.1019.025; Wed, 12 Apr 2017 06:45:10 +0000 From: David Mozes To: Greg Mirsky , "rtgwg@ietf.org" , "sfc@ietf.org" , "bier@ietf.org" CC: Fioccola Giuseppe , "Bocci, Matthew (Nokia - GB)" , NVO3 , "draft-ooamdt-rtgwg-ooam-header@ietf.org" Subject: RE: Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03 Thread-Topic: Poll for NVO3 WG adoption and IPR call for draft-ooamdt-rtgwg-ooam-header-03 Thread-Index: AQHSqjRYbg//IKWPRkqoeTAyBPoVj6GzTg6AgACrO4CAAecRAIABLtEAgAAmSgCAALlzoIACf6YAgAbnJCA= Date: Wed, 12 Apr 2017 06:45:10 +0000 Message-ID: References: <16320f45864d445f9a1bc3463d0c6352@TELMBXB02RM001.telecomitalia.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=davidm@mellanox.com; x-originating-ip: [193.47.165.251] x-microsoft-exchange-diagnostics: 1; HE1PR0501MB2139; 7:YaPXcDeG10Q76pMq0ZFark1EOjiXIOxQs1gr8+fZaGXP/henP0vUCYVXBDTvzw/GP+PS2b/1E5PxDZUhzzvqd03Z0j4ssvNVa0CuDlY8XUoneKP4wS5zrrpA7pU4X1xmuMtb6yzwqGs8AlkvHf5Vmja0J0TdD3SVXEdei99UWG+z3eAA0b/WK90xVHYZXHrbuPn/+lGEoocHIJlOC01LanMsx3oOAOAX16qKTxnxinI0ZPNTw1wiHsHOYk4i/RmX/gHd3RHL5ewB2YbhmS4dcgBEUjMDTiq8c3GOt2lfF7afixvF1ZsQW1QEDNroI1yBad6B0KQNwF8PbxtXRfooRw== x-ms-office365-filtering-correlation-id: 2e5319cd-a171-4c1d-d03f-08d4816f76f0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:HE1PR0501MB2139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(82608151540597)(43073073696351)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:HE1PR0501MB2139; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0501MB2139; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39450400003)(39850400002)(39400400002)(39410400002)(53754006)(377454003)(24454002)(733005)(6506006)(55016002)(66066001)(7696004)(7736002)(2501003)(2900100001)(8936002)(77096006)(2950100002)(81166006)(5890100001)(74316002)(86362001)(2201001)(8676002)(54896002)(53546009)(236005)(99936001)(50986999)(230783001)(25786009)(5660300001)(76176999)(6436002)(790700001)(3660700001)(93886004)(54356999)(6116002)(3846002)(102836003)(189998001)(6246003)(2906002)(99286003)(53936002)(54906002)(9686003)(4326008)(54556002)(345774005)(39060400002)(122556002)(38730400002)(33656002)(3280700002)(561944003)(19613025002)(19609705001)(53946003)(6306002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0501MB2139; H:HE1PR0501MB2138.eurprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_HE1PR0501MB213870DA8642B96DB45F9A97B6030HE1PR0501MB2138_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2017 06:45:10.1988 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0501MB2139 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 06:45:28 -0000 --_004_HE1PR0501MB213870DA8642B96DB45F9A97B6030HE1PR0501MB2138_ Content-Type: multipart/alternative; boundary="_000_HE1PR0501MB213870DA8642B96DB45F9A97B6030HE1PR0501MB2138_" --_000_HE1PR0501MB213870DA8642B96DB45F9A97B6030HE1PR0501MB2138_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RiBHcmVnICwNCjEpIEkgYW0gYXdhcmUgdGhhdCB5b3UgYXJlIGFpbWluZyBpdCB0byBvdGhlciBX RyAgcmF0aGVyIHRoYW4gb25seSBOVk8zDQpUaGF0ICB3YXkgeW91IGhhdmUgdG8gYmUgZm9jdXNl ZCBvbiB0aGUgY29tbW9uIHBhcnRzICB3aGljaCBpcyAgdGhlIE9BTSByZWxhdGVkICBkYXRhICBh bmQgdGhlIE9BTSBtZWNoYW5pc20uDQpZb3UgY2FuIGNvbWUgd2l0aCByZXF1aXJlbWVudHMgZm9y IHRoZSBlbmNhcHN1bGF0aW9uIHByb3RvY29scy4gSG93ZXZlciB5b3Ugc2hvdWxkIGxldCB0aGVt IHRvIGRlYWwgd2l0aCBob3cgdG8gZW5jYXAgdGhlIE9BTSAgYW5kIG5vdCByZWRlc2lnbiB0aGVt IHlvdXJzZWxmIC4NCjIpIEkgYW0gY29uZnVzaW5nIHNpbmNlIHlvdSB3aXRoIG9uZSBoYW5kIHNw ZWFraW5nIG9uIHRoZSBlbnRpcmUgT0FNICBzcGVjdHJ1bSAsYnV0IGZyb20gdGhlIG90aGVyIGhh bmQgeW91IGJyaW5nIGp1c3QgdGhlIGFjdGl2ZSBPQU0gdG8gdGhlIGRpc2N1c3Npb24gd2l0aCBt ZSAuDQpTbyB3aGF0IGlzIHRoZSBzY29wZSA/DQozKSBJIHRoaW5rIEkgbWFkZSBteSBwb2ludHMg YWxyZWFkeSAsIEkgd2lsbCBsZXRzIG90aGVyIHRvIGNvbW1lbnRzDQoNClRoeA0KRGF2aWQNCg0K ZnJvbTogR3JlZyBNaXJza3kgW21haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb21dDQpTZW50OiBG cmlkYXksIEFwcmlsIDA3LCAyMDE3IDExOjU3IFBNDQpUbzogRGF2aWQgTW96ZXMgPGRhdmlkbUBt ZWxsYW5veC5jb20+OyBydGd3Z0BpZXRmLm9yZzsgc2ZjQGlldGYub3JnOyBiaWVyQGlldGYub3Jn DQpDYzogRmlvY2NvbGEgR2l1c2VwcGUgPGdpdXNlcHBlLmZpb2Njb2xhQHRlbGVjb21pdGFsaWEu aXQ+OyBCb2NjaSwgTWF0dGhldyAoTm9raWEgLSBHQikgPG1hdHRoZXcuYm9jY2lAbm9raWEuY29t PjsgTlZPMyA8bnZvM0BpZXRmLm9yZz47IGRyYWZ0LW9vYW1kdC1ydGd3Zy1vb2FtLWhlYWRlckBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFBvbGwgZm9yIE5WTzMgV0cgYWRvcHRpb24gYW5kIElQUiBj YWxsIGZvciBkcmFmdC1vb2FtZHQtcnRnd2ctb29hbS1oZWFkZXItMDMNCg0KSGkgRGF2aWQsDQpw bGVhc2UgZmluZCBteSBub3RlcyBpbi1saW5lIHRhZ2dlZCBHSU0yPj4uDQoNClJlZ2FyZHMsDQpH cmVnDQoNCk9uIFRodSwgQXByIDYsIDIwMTcgYXQgMTI6MzIgQU0sIERhdmlkIE1vemVzIDxkYXZp ZG1AbWVsbGFub3guY29tPG1haWx0bzpkYXZpZG1AbWVsbGFub3guY29tPj4gd3JvdGU6DQpHcmVn ICwNCkkgaGF2ZSBhIGxvdCB0byBzYXkgb24gd2hhdCB5b3Ugd3JpdGUgYmVsb3cgLCBidXQgbGV0 IHB1dCB0aGUgZGlzY3Vzc2lvbiBpbiB0aGUgcmlnaHQgY29udGVudC4NClRoZSBtYWluIHRoaW5n IGlzOg0KSSB0aGluayB5b3VycyB3b3JrIGFuZCB0aGUgT0FNIGRlc2lnbiB0ZWFtIHNob3VsZCBi ZSBmb2N1cyB0byBkZWZpbmUgdGhlIE9BTSByZWxhdGVkIGRhdGEgYW5kICB0aGUgT0FNIG1lY2hh bmlzbSBhbmQgdGhlcmUgaXMgYSBsb3QgdG8gZG8gb24gdGhpcyBhcmVhIC5hbmQgdHJ5IHRvIG1h a2UgaXQgdW5pZm9ybSBvbiBhbGwgdGhlIGRpZmZlbmV0IGVuY2Fwc3VsYXRpb25zIChOVk8zLEJF SVIsU0ZDKSBhbmQgbm90IGRlYWxpbmcgd2l0aCB0aGUgZW5jYXBzdWxhdGlvbiBpdHNlbGYuIEJ5 IHRoaXMgeW91IG1peGVkIGFsbCB0aGluZ3MgdXAgYW5kIHdlIHdpbGwgYWNoaWV2ZSBub3RoaW5n IC4NCkdJTTI+PiAgSSBmZWVsIHRoYXQgeW91IGFzc3VtZSB0aGF0IHRoZSBwcm9wb3NlZCBzb2x1 dGlvbiBpcyBmb3IgTlZPMyBvbmx5IGFuZCB0aHVzIGhhZCBub3QgdGhvdWdodCBhYm91dCBTRkMg YW5kIEJJRVIuIERhdmUgRG9sc29uIGhhZCBwb2ludGVkIG91dCB0aGF0IHRoZSBwcm9wb3NlZCBz b2x1dGlvbiBpcyBiZW5lZmljaWFsIGZvciBTRkMuDQoNCg0KU3BlY2lmaWNhbGx5Og0KMSlUaGUg ZXh0ZW5zaW9uIGhlYWRlciAoY29udGFpbmVyKSBjb25jZXB0IHdhcyBkaXNjdXNzZWQgb24gdGhl IGVuY2FwIGRlc2lnbiB0ZWFtIC4gdGhlIGNvbnRlbnQgd2FzIHRvIG1ha2UgVlhMTi1HUEUgZXh0 ZW5kYWJsZSAoV2hpbGUgaXQgaXMgbm90IGJ5IGFkZGluZyBOU0ggIGhlYWRlciB0byBpdCBhbmQg d2FzIHJlamVjdGVkIGJlY2F1c2Ugb2YgdGhlIGJ5dGVzIG92ZXJoZWFkIChsZXNzIGJ5dGVzIHRo YW4geW91ciBwcm9wb3NhbCkuDQpOb3cgeW91IGxpa2UgdG8gdGFrZSBlbmNhcCBwcm90b2NvbCB3 aXRoIGJ1aWxkICBpbiBleHRlbnNpb24gYW5kIGFkZCB0byBpdCBleHRlbnNpb24gaGVhZGVyID8g IHdoYXQgd2Ugd2lsbCBkbyB3aXRoIG90aGVyIGV4dGVuc2lvbnMgbGlrZSBzZWN1cml0eSBhZGQg ZXh0ZW5zaW9uIGhlYWRlciBhcyB3ZWxsICA/IFRoaXMgZG9lc27igJl0IG1ha2Ugc2Vuc2UgYW5k IG5vdCBuZWVkZWQgaW4gYWxsIHRoZSBjYXNlcw0KR0lNMj4+IFdoYXQgYXJlIHRoZXNlIGNhc2Vz IHRoYXQgZG9uJ3QgcmVxdWlyZSBhY3RpdmUgT0FNPw0KMikgdGhlIHRvdGFsIGhlYWRlciBsZW5n dGggb24gdGhlIGJhc2UgaGVhZGVyIGlzIGltcG9ydGFudCBhbmQgaGVscCBmb3IgcGFyc2luZyBp biBhbGwgdGhlIGNhc2VzIGVzcGVjaWFsbHkgd2hlbiB5b3UgZG9u4oCZdCBsaWtlIHRvIGRlYWwg d2l0aCB0aGUgZXh0ZW5zaW9ucyAuDQozKSA4IGJ5dGVzIG92ZXJoZWFkIGlzIGltcG9ydGFudA0K R0lNMj4+IFRvIGJlIHByZWNpc2UsIGlmIEkgbG9vayBhdCBUTFYtYmFzZWQgYXBwcm9hY2ggdGhl biB0aGUgZGlmZmVyZW5jZSBpcywgYXQgbW9zdCwgNCBieXRlcy4NCjQpYW5kIGFkZGluZyBldGhl ciB0eXBlIHRvIHRoZSBwYXJzaW5nIGdyYXBoIGlzIGNvc3RseSBhbmQgY2FuIGNvbXBsaWNhdGUg dGhpbmdzIGVzcGVjaWFsbHkgaWYgeW91IG5lZWQgdG8gcGFyc2Ugb3B0aW9ucyhUTFYpICBiZWZv cmUNCkdJTTI+PiBXaGF0IEV0aGVyVHlwZT8gV2hvIHNheXMgdGhhdCBhY3RpdmUgT0FNIG11c3Qg YmUgY29tYmluZWQgd2l0aCBUTFZzPyBUaGUgYmVuZWZpdCwgaW4gbXkgb3Bpbmlvbiwgb2YgdXNp bmcgT3ZlcmxheSBBc3NvY2lhdGVkIENoYW5uZWwsIGlzIHRoYXQgaXQgaXMgc2VsZi1jb250YWlu ZWQgYW5kIHByb2Nlc3NpbmcgY2FuIGJlIG9mZmxvYWRlZCBvbmNlIHRoZSBwYWNrZXQgd2FzIGlk ZW50aWZpZWQgYXMgT0FDIHBhY2tldC4NCg0KVGh4DQpEYXZpZA0KDQpGcm9tOiBHcmVnIE1pcnNr eSBbbWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwu Y29tPl0NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMDUsIDIwMTcgMTA6NDQgUE0NCg0KVG86IERh dmlkIE1vemVzIDxkYXZpZG1AbWVsbGFub3guY29tPG1haWx0bzpkYXZpZG1AbWVsbGFub3guY29t Pj4NCkNjOiBGaW9jY29sYSBHaXVzZXBwZSA8Z2l1c2VwcGUuZmlvY2NvbGFAdGVsZWNvbWl0YWxp YS5pdDxtYWlsdG86Z2l1c2VwcGUuZmlvY2NvbGFAdGVsZWNvbWl0YWxpYS5pdD4+OyBCb2NjaSwg TWF0dGhldyAoTm9raWEgLSBHQikgPG1hdHRoZXcuYm9jY2lAbm9raWEuY29tPG1haWx0bzptYXR0 aGV3LmJvY2NpQG5va2lhLmNvbT4+OyBOVk8zIDxudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGll dGYub3JnPj47IGRyYWZ0LW9vYW1kdC1ydGd3Zy1vb2FtLWhlYWRlckBpZXRmLm9yZzxtYWlsdG86 ZHJhZnQtb29hbWR0LXJ0Z3dnLW9vYW0taGVhZGVyQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFBv bGwgZm9yIE5WTzMgV0cgYWRvcHRpb24gYW5kIElQUiBjYWxsIGZvciBkcmFmdC1vb2FtZHQtcnRn d2ctb29hbS1oZWFkZXItMDMNCg0KSGkgRGF2aWQsDQp0aGFuayB5b3UgZm9yIHlvdXIgZGV0YWls ZWQgZm9sbG93LXVwIGNvbW1lbnRzLiBQbGVhc2UgZmluZCBteSBub3RlcyBpbi1saW5lIGFuZCB0 YWdnZWQgR0lNPj4uDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFdlZCwgQXByIDUsIDIwMTcgYXQg MTA6NTQgQU0sIERhdmlkIE1vemVzIDxkYXZpZG1AbWVsbGFub3guY29tPG1haWx0bzpkYXZpZG1A bWVsbGFub3guY29tPj4gd3JvdGU6DQpIaSBHcmVnICAsDQpQU0INCg0KRnJvbTogR3JlZyBNaXJz a3kgW21haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWls LmNvbT5dDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA1LCAyMDE3IDI6MjMgQU0NClRvOiBEYXZp ZCBNb3plcyA8ZGF2aWRtQG1lbGxhbm94LmNvbTxtYWlsdG86ZGF2aWRtQG1lbGxhbm94LmNvbT4+ DQpDYzogRmlvY2NvbGEgR2l1c2VwcGUgPGdpdXNlcHBlLmZpb2Njb2xhQHRlbGVjb21pdGFsaWEu aXQ8bWFpbHRvOmdpdXNlcHBlLmZpb2Njb2xhQHRlbGVjb21pdGFsaWEuaXQ+PjsgQm9jY2ksIE1h dHRoZXcgKE5va2lhIC0gR0IpIDxtYXR0aGV3LmJvY2NpQG5va2lhLmNvbTxtYWlsdG86bWF0dGhl dy5ib2NjaUBub2tpYS5jb20+PjsgTlZPMyA8bnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRm Lm9yZz4+OyBkcmFmdC1vb2FtZHQtcnRnd2ctb29hbS1oZWFkZXJAaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LW9vYW1kdC1ydGd3Zy1vb2FtLWhlYWRlckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBQb2xs IGZvciBOVk8zIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2FsbCBmb3IgZHJhZnQtb29hbWR0LXJ0Z3dn LW9vYW0taGVhZGVyLTAzDQoNCkhpIERhdmlkLA0KdGhhbmsgeW91IGZvciBzaGFyaW5nIHlvdXIg b3Bpbmlvbi4NCkNvdWxkIHlvdSBwbGVhc2UgY2xhcmlmeSB5b3VyIHBvc2l0aW9uLiBZb3UgcHJv cG9zZSB0byB1c2UgZXh0ZW5zaW9ucy9vcHRpb25zIGZvciBlbmQtdG8tZW5kIGFjdGl2ZSBPQU0/ DQpEYXZpZD4geWVzDQogTGV0IHVzIGxvb2sgYXQgcHJvYWN0aXZlIGNvbnRpbnVpdHkgY2hlY2sg YmV0d2VlbiBOVkVzLiBXaHkgeW91IHRoaW5rIGEgbWlkZGxlYm94IG5lZWRzIHRvIGJlIGF3YXJl IG9mIHRoZSBPQU0gcGF5bG9hZD8NCkkgYmVsaWV2ZSB0aGF0IGEgdHJhbnNpZW50IE5WTzMgbm9k ZSBzaG91bGQgbm90IGxvb2sgaW50byBwYXlsb2FkIGlmIGl0IGlzIG5vdCBhZGRyZXNzZWQgdG8g aXQgYXQgYWxsLg0KRGF2aWQ+IEFyZSB5b3UgbGltaXQgdGhlIGhlYWRlciBqdXN0IGZvciBwcm9h Y3RpdmUgT0FNID8gIHNvIGNoYW5nZSB0aGUgZHJhZnQgdG8gaW5jbHVkZSBqdXN0IHRoYXQgLiBP biB0aGUgY3VycmVudCAgZHJhZnQgSSBzZWUgYWxsIGtpbmRzIG9mIE9BTQ0KR0lNPj4gSSB3YW50 IHRvIHBvaW50IHRoYXQgdGhlIGRyYWZ0IGludHJvZHVjZXMgQXNzb2NpYXRlZCBDaGFubmVsIGZv ciBhbiBvdmVybGF5IG5ldHdvcmsuIEFzc29jaWF0ZWQgQ2hhbm5lbCBtYXkgYmUgdXNlZCBmb3Ig c2lnbmFsbGluZyBvciBPQU0uIE9BTSBtZXRob2RzIGVuYWJsZSBvcGVyYXRvcnMgdG8gcGVyZm9y bSBGYXVsdCBNYW5hZ2VtZW50IGFuZCBQZXJmb3JtYW5jZSBNb25pdG9yaW5nLiBBbW9uZyBmdW5j dGlvbnMgcmVxdWlyZWQgdG8gcGVyZm9ybSBjb21wcmVoZW5zaXZlIEZhdWx0IE1hbmFnZW1lbnQg YXJlOg0KDQogICogICBmYWlsdXJlIGRldGVjdGlvbiwgdXN1YWxseSBkZXRlY3Rpb24gb2YgTG9z cyBvZiBDb250aW51aXR5IGJ1dCBtYXkgaW5jbHVkZSBNaXMtY29ubmVjdGlvbiBkZWZlY3QgYXMg d2VsbCBmb3IgY29ubmVjdGlvbi1vcmllbnRlZCBuZXR3b3JrOw0KICAqICAgZGVmZWN0IGxvY2Fs aXphdGlvbjsNCiAgKiAgIEFsYXJtIEluZGljYXRpb24gU2lnbmFsOw0KICAqICAgUmVtb3RlIERl ZmVjdCBJbmRpY2F0aW9uLg0KRGVwZW5kaW5nIG9uIHRoZSByZXF1aXJlbWVudHMgdG93YXJkcyBy ZXNpbGllbmN5IGFuZCByZXN0b3JhdGlvbiwgUHJvdGVjdGlvbiBTd2l0Y2hvdmVyIENvb3JkaW5h dGlvbiBwcm90b2NvbCBtYXkgYmUgcmVxdWlyZWQuDQpQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCB1 c3VhbGx5IHN1cHBvcnRzIHRoZSBmb2xsb3dpbmc6DQoNCiAgKiAgIG9uZS13YXkgYW5kIHR3by13 YXkgUGFja2V0IExvc3MgbWVhc3VyZW1lbnQ7DQogICogICBvbmUtd2F5IGFuZCB0d28td2F5IFBh Y2tldCBEZWxheSBtZWFzdXJlbWVudDsNCiAgKiAgIFN5bnRoZXRpYyBMb3NzIE1lYXN1cmVtZW50 Lg0KU2VydmljZSBBY3RpdmF0aW9uIFByb3RvY29sLCBhcyBwYXJ0IG9mIGFjdGl2ZSBPQU0gdG9v bHNldCwgdXN1YWxseSBjb21iaW5lcyBPQU0gZnVuY3Rpb25zIGZyb20gRk0gYW5kIFBNIG9wZXJh dGlvbnMuDQpUaGUgZ29hbCBvZiBPdmVybGF5IE9BTSB3b3JrLCBhcyBJIHVuZGVyc3RhbmQsIGlz IHRvIGNyZWF0ZSBjb21tb24gc2V0IG9mIE9BTSBwcm90b2NvbHMgdGhhdCBzdXBwb3J0cyBhbGwg b2YgbGlzdGVkIGFib3ZlIEZNIGFuZCBQTSBvcGVyYXRpb25zLiBJIHNlZSBzdWNoIHNldCBhcyBj b21iaW5hdGlvbiBvZiBhY3RpdmUsIGh5YnJpZCBhbmQgcGFzc2l2ZSBPQU0gbWV0aG9kcy4gSSBi ZWxpZXZlIHRoYXQgdGhlIGRyYWZ0IHN0YXRlcyB0aGF0IGNsZWFybHkuIFRoZSBwcm9hY3RpdmUg T0FNIGlzIHVzdWFsbHkgdXNlZCB0byBwZXJmb3JtIG1vbml0b3IgbmV0d29yayBmb3IgZGVmZWN0 cyBhbmQgcGVyZm9ybWFuY2UgZGVncmFkYXRpb24uIE9uLWRlbWFuZCBPQU0gdG9vbHMgbWF5IGJl IHVzZWQgdG8gbG9jYWxpemUgdGhlIGRlZmVjdHMuDQoNCj4gV2hpbGUgIEkgYWdyZWUgd2l0aCB5 b3UgcmVnYXJkaW5nICBNaWRkbGUgYm94IGFuZCBwcm9hY3RpdmUgT0FNIC5UaGUgc2FtZSBjYW4g YmUgYWNoaWV2ZSB3aXRoIHRoZSBwcm90b2NvbCBleHRlbnNpb25zDQpUaHVzIEkgZG9uJ3QgYWdy ZWUgdGhhdCB0aGUgcmVxdWlyZW1lbnQgeW91IHJlZmVyIHRvIGlzIGFwcGxpY2FibGUgdG8gdXNl IG9mIGFjdGl2ZSBPQU0uDQpEYXZpZD4gSSB0aGluayBpZiB0aGUgV0cgZGVjaWRlIG9uIE5WTzMg ZW5jYXAgcHJvdG9jb2wgdGhhdCBpbmNsdWRlICBleHRlbnNpb24gKExpa2UgR1VFIGFuZCBHZW5l dmUpIHdlIGhhdmUgdG8gdXNlIHRoZSBidWlsZCBpbiBleHRlbnNpb25zIGZvciBzdWNoIHByb3Rv Y29sIGFuZCBub3QgaW5ub3ZhdGUgIGV4dHJhIGhlYWRlciAgdGhhdCB1c2UgZm9yIHByb3RvY29s cyB3aXRob3V0IGV4dGVuc2lvbnMuDQpHSU0+PiBJIHF1ZXN0aW9uIHlvdXIgYXNzdW1wdGlvbiB0 aGF0IHVzZSBvZiB2YXJpYWJsZSBsZW5ndGggaGVhZGVyIG1hbmRhdGVzIGhvdyBPQU0sIGFjdGl2 ZSBPQU0sIG11c3QgYmUgaW1wbGVtZW50ZWQuIEFuZCBzaW5jZSBzb21lIG5ldHdvcmtzIGNob29z ZSB0byB1c2UgZml4ZWQgc2l6ZSBoZWFkZXIsIHVzaW5nIE92ZXJsYXkgQXNzb2NpYXRlZCBDaGFu bmVsIGhlYWRlciB3aXRoIG11bHRpcGxleGVkIE92ZXJsYXkgT0FNIGZ1bmN0aW9uYWxpdHkgYXBw ZWFycywgaW4gbXkgb3BpbmlvbiwgYXMgY29tbW9uIHNvbHV0aW9uIGZvciBlaXRoZXIgdHlwZSBv ZiBvdmVybGF5IGVuY2Fwc3VsYXRpb24uDQoNCkRhdmlkDQpHcmVnDQoNCk9uIE1vbiwgQXByIDMs IDIwMTcgYXQgMTE6MTkgQU0sIERhdmlkIE1vemVzIDxkYXZpZG1AbWVsbGFub3guY29tPG1haWx0 bzpkYXZpZG1AbWVsbGFub3guY29tPj4gd3JvdGU6DQpIaSAsDQpJIGFtIG5vdCBzdXBwb3J0aW5n IHRoZSBhZG9wdGlvbg0KSSB0aGluayB3aGlsZSB0aGUgd29ya2luZyBncm91cCBkZWNpZGVkIG9u IEdlbmV2ZSBhcyB0aGUgZW5jYXAgcHJvdG9jb2wNCg0KVGhpcyBPQU0gbmVlZCB0byBiZSB2aWEg b25lIG9mIHRoZSBleHRlbnNpb25zL29wdGlvbnMgIHRoZSBwcm90b2NvbCAgIGlzIHN1cHBvcnRp bmchDQoNClRoaXMgaGVhZGVyIGFsc28gdmlvbGF0ZSB0aGUgbnVtYmVyIDEgcmVxdWlyZW1lbnRz IGZyb20gdGhlIGV4dGVuc2lvbnMvb3B0aW9ucw0KVGhhdCBub2RlL21pZGRsYm94ICBkb24gbm90 ICBuZWVkIHRvIGJlIHBhcnQgb2YgdGhlIGV4dGVuc2lvbnMvIG9wdGlvbiBjYW4ganVtcCBkaXJl Y3RseSAgdG8gdGhlIG92ZXJsYXkgYnkgcmVhZGluZyB0aGUgYmFzZSBoZWFkZXIgbGVuZ3RoIG9u bHkNCg0KVGh4DQpEYXZpZA0KDQpGcm9tOiBudm8zIFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRmlvY2NvbGEg R2l1c2VwcGUNClNlbnQ6IE1vbmRheSwgQXByaWwgMDMsIDIwMTcgNTo0MCBQTQ0KVG86IEJvY2Np LCBNYXR0aGV3IChOb2tpYSAtIEdCKSA8bWF0dGhldy5ib2NjaUBub2tpYS5jb208bWFpbHRvOm1h dHRoZXcuYm9jY2lAbm9raWEuY29tPj47IE5WTzMgPG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNA aWV0Zi5vcmc+PjsgZHJhZnQtb29hbWR0LXJ0Z3dnLW9vYW0taGVhZGVyQGlldGYub3JnPG1haWx0 bzpkcmFmdC1vb2FtZHQtcnRnd2ctb29hbS1oZWFkZXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbbnZv M10gUjogUG9sbCBmb3IgTlZPMyBXRyBhZG9wdGlvbiBhbmQgSVBSIGNhbGwgZm9yIGRyYWZ0LW9v YW1kdC1ydGd3Zy1vb2FtLWhlYWRlci0wMw0KDQpIaSBBbGwsDQpJIGhhdmUgcmVhZCB0aGUgZHJh ZnQgYW5kIHN1cHBvcnQgaXRzIGFkb3B0aW9uLg0KDQpSZWdhcmRzLA0KDQpHaXVzZXBwZQ0KDQpE YTogbnZvMyBbbWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIEJvY2Np LCBNYXR0aGV3IChOb2tpYSAtIEdCKQ0KSW52aWF0bzogdmVuZXJkw6wgMzEgbWFyem8gMjAxNyAx NzozNQ0KQTogTlZPMzsgZHJhZnQtb29hbWR0LXJ0Z3dnLW9vYW0taGVhZGVyQGlldGYub3JnPG1h aWx0bzpkcmFmdC1vb2FtZHQtcnRnd2ctb29hbS1oZWFkZXJAaWV0Zi5vcmc+DQpPZ2dldHRvOiBb bnZvM10gUG9sbCBmb3IgTlZPMyBXRyBhZG9wdGlvbiBhbmQgSVBSIGNhbGwgZm9yIGRyYWZ0LW9v YW1kdC1ydGd3Zy1vb2FtLWhlYWRlci0wMw0KDQpUaGlzIGVtYWlsIGJlZ2lucyBhIHR3byB3ZWVr IHBvbGwgZm9yIGFkb3B0aW9uIG9mIGRyYWZ0LW9vYW1kdC1ydGd3Zy1vb2FtLWhlYWRlci0wMyBp biB0aGUgTlZPMyB3b3JraW5nIGdyb3VwLg0KDQpQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQg c2VuZCBhbnkgY29tbWVudHMgdG8gdGhlIE5WTzMgbGlzdC4NClBsZWFzZSBhbHNvIGluZGljYXRl IHdoZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRpb24gb2YgdGhlIGRyYWZ0IGFzIGFuIE5WTzMgd29y a2luZyBncm91cCBkb2N1bWVudC4NCg0KU2ltdWx0YW5lb3VzbHksIHdlIGFyZSBhbHNvIHBvbGlu ZyBmb3IgYW55IElQUiB0aGF0IG1heSBhcHBseSB0byB0aGUgZHJhZnQuDQoNCkF1dGhvcnMgYW5k IGNvbnRyaWJ1dG9ycywgYXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0 aGlzIGRyYWZ0Pw0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBs aWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQg NTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVu dCBhdXRob3Igb3IgY29udHJpYnV0b3IsIHBsZWFzZSByZXNwb25kIHRvDQp0aGlzIGVtYWlsIHN0 YXRpbmcgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQNCklQ Ui4gVGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIE5WTzMgV0cgbWFpbGluZyBs aXN0LiBUaGUNCmRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50 aWwgYSByZXNwb25zZQ0KaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgZWFj aCBjb250cmlidXRvci4NCg0KVGhpcyBwb2xsIGNsb3NlcyBvbiBGcmlkYXkgMTR0aCBBcHJpbCAy MDE3Lg0KDQpSZWdhcmRzDQoNCk1hdHRoZXcgYW5kIFNhbQ0KUXVlc3RvIG1lc3NhZ2dpbyBlIGkg c3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29u ZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25l IGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyBy aWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9j dW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1t ZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3Vh IGRpc3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg aXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGlu dGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcs IHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1t YWlsLCBUaGFua3MuDQpbcmlzcGV0dGEgbCdhbWJpZW50ZV1SaXNwZXR0YSBsJ2FtYmllbnRlLiBO b24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQoNCg0KDQoNCg0K --_000_HE1PR0501MB213870DA8642B96DB45F9A97B6030HE1PR0501MB2138_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJ IjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4ubTY0NTU4MDgyNDg3 NDI3MzEwODBtNjAzOTI1NTY3Nzk5NzU1MjczNW0tMzcyMDIxNDM0MTk0Njc0NDIxNW1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bV82NDU1ODA4MjQ4NzQyNzMxMDgwbTYwMzkyNTU2Nzc5OTc1 NTI3MzVtLTM3MjAyMTQzNDE5NDY3NDQyMTVtc29ub3JtYWwwO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEy NDE0NDkxMTU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEyNzI5ODIzODI7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNzk0MjUxNzA3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMTYwMzc5MjI4O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Rjwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+R3JlZyAsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4xKSBJIGFtIGF3YXJlIHRoYXQgeW91IGFyZSBhaW1pbmcgaXQgdG8gb3Ro ZXIgV0cmbmJzcDsgcmF0aGVyIHRoYW4gb25seSBOVk8zJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYXQmbmJzcDsg d2F5IHlvdSBoYXZlIHRvIGJlIGZvY3VzZWQgb24gdGhlIGNvbW1vbiBwYXJ0cyZuYnNwOyB3aGlj aCBpcyZuYnNwOyB0aGUgT0FNIHJlbGF0ZWQmbmJzcDsgZGF0YSZuYnNwOyBhbmQgdGhlIE9BTSBt ZWNoYW5pc20uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPllvdSBjYW4gY29tZSB3aXRoIHJlcXVpcmVtZW50cyBmb3IgdGhlIGVu Y2Fwc3VsYXRpb24gcHJvdG9jb2xzLiBIb3dldmVyIHlvdSBzaG91bGQgbGV0IHRoZW0gdG8gZGVh bCB3aXRoIGhvdyB0byBlbmNhcCB0aGUgT0FNJm5ic3A7IGFuZCBub3QgcmVkZXNpZ24gdGhlbSB5 b3Vyc2VsZiAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4yKSBJIGFtIGNvbmZ1c2luZyBzaW5jZSB5b3Ugd2l0aCBvbmUgaGFuZCBz cGVha2luZyBvbiB0aGUgZW50aXJlIE9BTSZuYnNwOyBzcGVjdHJ1bSAsYnV0IGZyb20gdGhlIG90 aGVyIGhhbmQgeW91IGJyaW5nIGp1c3QgdGhlIGFjdGl2ZSBPQU0gdG8gdGhlIGRpc2N1c3Npb24g d2l0aCBtZSAuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNvIHdoYXQgaXMgdGhlIHNjb3BlID8NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MykgSSB0 aGluayBJIG1hZGUgbXkgcG9pbnRzIGFscmVhZHkgLCBJIHdpbGwgbGV0cyBvdGhlciB0byBjb21t ZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5UaHgNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGF2aWQNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+ZnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEdyZWcgTWlyc2t5IFttYWls dG86Z3JlZ2ltaXJza3lAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXBy aWwgMDcsIDIwMTcgMTE6NTcgUE08YnI+DQo8Yj5Ubzo8L2I+IERhdmlkIE1vemVzICZsdDtkYXZp ZG1AbWVsbGFub3guY29tJmd0OzsgcnRnd2dAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzsgYmllckBp ZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gRmlvY2NvbGEgR2l1c2VwcGUgJmx0O2dpdXNlcHBlLmZp b2Njb2xhQHRlbGVjb21pdGFsaWEuaXQmZ3Q7OyBCb2NjaSwgTWF0dGhldyAoTm9raWEgLSBHQikg Jmx0O21hdHRoZXcuYm9jY2lAbm9raWEuY29tJmd0OzsgTlZPMyAmbHQ7bnZvM0BpZXRmLm9yZyZn dDs7IGRyYWZ0LW9vYW1kdC1ydGd3Zy1vb2FtLWhlYWRlckBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogUG9sbCBmb3IgTlZPMyBXRyBhZG9wdGlvbiBhbmQgSVBSIGNhbGwgZm9yIGRy YWZ0LW9vYW1kdC1ydGd3Zy1vb2FtLWhlYWRlci0wMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIERhdmlkLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnBsZWFzZSBmaW5kIG15IG5vdGVzIGluLWxpbmUgdGFnZ2VkIEdJTTImZ3Q7Jmd0 Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkdyZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFRodSwgQXByIDYsIDIwMTcgYXQgMTI6MzIgQU0sIERhdmlkIE1vemVzICZsdDs8YSBocmVmPSJt YWlsdG86ZGF2aWRtQG1lbGxhbm94LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhdmlkbUBtZWxsYW5v eC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5HcmVnICw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+SSBoYXZlIGEgbG90IHRvIHNheSBvbiB3aGF0IHlvdSB3cml0ZSBiZWxvdyAsIGJ1dCBsZXQg cHV0IHRoZSBkaXNjdXNzaW9uIGluIHRoZSByaWdodCBjb250ZW50Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgbWFpbiB0 aGluZyBpczoNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5JIHRoaW5rIHlvdXJzIHdvcmsgYW5kIHRoZSBPQU0gZGVzaWduIHRl YW0gc2hvdWxkIGJlIGZvY3VzIHRvIGRlZmluZSB0aGUgT0FNIHJlbGF0ZWQgZGF0YSBhbmQmbmJz cDsgdGhlIE9BTSBtZWNoYW5pc20NCiBhbmQgdGhlcmUgaXMgYSBsb3QgdG8gZG8gb24gdGhpcyBh cmVhIC5hbmQgdHJ5IHRvIG1ha2UgaXQgdW5pZm9ybSBvbiBhbGwgdGhlIGRpZmZlbmV0IGVuY2Fw c3VsYXRpb25zIChOVk8zLEJFSVIsU0ZDKSBhbmQgbm90IGRlYWxpbmcgd2l0aCB0aGUgZW5jYXBz dWxhdGlvbiBpdHNlbGYuIEJ5IHRoaXMgeW91IG1peGVkIGFsbCB0aGluZ3MgdXAgYW5kIHdlIHdp bGwgYWNoaWV2ZSBub3RoaW5nIC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdJTTImZ3Q7Jmd0 OyAmbmJzcDtJIGZlZWwgdGhhdCB5b3UgYXNzdW1lIHRoYXQgdGhlIHByb3Bvc2VkIHNvbHV0aW9u IGlzIGZvciBOVk8zIG9ubHkgYW5kIHRodXMgaGFkIG5vdCB0aG91Z2h0IGFib3V0IFNGQyBhbmQg QklFUi4gRGF2ZSBEb2xzb24gaGFkIHBvaW50ZWQgb3V0IHRoYXQgdGhlIHByb3Bvc2VkIHNvbHV0 aW9uIGlzIGJlbmVmaWNpYWwgZm9yIFNGQy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U3BlY2lmaWNhbGx5Ojwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4xKVRoZSBl eHRlbnNpb24gaGVhZGVyIChjb250YWluZXIpIGNvbmNlcHQgd2FzIGRpc2N1c3NlZCBvbiB0aGUg ZW5jYXAgZGVzaWduIHRlYW0gLiB0aGUgY29udGVudCB3YXMgdG8gbWFrZSBWWExOLUdQRQ0KIGV4 dGVuZGFibGUgKFdoaWxlIGl0IGlzIG5vdCBieSBhZGRpbmcgTlNIJm5ic3A7IGhlYWRlciB0byBp dCBhbmQgd2FzIHJlamVjdGVkIGJlY2F1c2Ugb2YgdGhlIGJ5dGVzIG92ZXJoZWFkIChsZXNzIGJ5 dGVzIHRoYW4geW91ciBwcm9wb3NhbCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ob3cgeW91IGxpa2UgdG8gdGFrZSBlbmNh cCBwcm90b2NvbCB3aXRoIGJ1aWxkJm5ic3A7IGluIGV4dGVuc2lvbiBhbmQgYWRkIHRvIGl0IGV4 dGVuc2lvbiBoZWFkZXIgPyZuYnNwOyB3aGF0IHdlIHdpbGwgZG8gd2l0aA0KIG90aGVyIGV4dGVu c2lvbnMgbGlrZSBzZWN1cml0eSBhZGQgZXh0ZW5zaW9uIGhlYWRlciBhcyB3ZWxsJm5ic3A7ID8g VGhpcyBkb2VzbuKAmXQgbWFrZSBzZW5zZSBhbmQgbm90IG5lZWRlZCBpbiBhbGwgdGhlIGNhc2Vz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HSU0yJmd0OyZndDsgV2hhdCBhcmUgdGhlc2UgY2Fz ZXMgdGhhdCBkb24ndCByZXF1aXJlIGFjdGl2ZSBPQU0/Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4yKSB0aGUgdG90YWwgaGVhZGVyIGxlbmd0aCBvbiB0aGUgYmFzZSBo ZWFkZXIgaXMgaW1wb3J0YW50IGFuZCBoZWxwIGZvciBwYXJzaW5nIGluIGFsbCB0aGUgY2FzZXMg ZXNwZWNpYWxseSB3aGVuDQogeW91IGRvbuKAmXQgbGlrZSB0byBkZWFsIHdpdGggdGhlIGV4dGVu c2lvbnMgLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4zKSA4IGJ5dGVzIG92ZXJoZWFkIGlzIGltcG9ydGFudDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+R0lNMiZndDsmZ3Q7IFRvIGJlIHByZWNpc2UsIGlmIEkgbG9vayBhdCBU TFYtYmFzZWQgYXBwcm9hY2ggdGhlbiB0aGUgZGlmZmVyZW5jZSBpcywgYXQgbW9zdCwgNCBieXRl cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjQpYW5kIGFkZGluZyBldGhlciB0 eXBlIHRvIHRoZSBwYXJzaW5nIGdyYXBoIGlzIGNvc3RseSBhbmQgY2FuIGNvbXBsaWNhdGUgdGhp bmdzIGVzcGVjaWFsbHkgaWYgeW91IG5lZWQgdG8gcGFyc2UNCiBvcHRpb25zKFRMVikmbmJzcDsg YmVmb3JlJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HSU0yJmd0OyZndDsgV2hhdCBF dGhlclR5cGU/IFdobyBzYXlzIHRoYXQgYWN0aXZlIE9BTSBtdXN0IGJlIGNvbWJpbmVkIHdpdGgg VExWcz8gVGhlIGJlbmVmaXQsIGluIG15IG9waW5pb24sIG9mIHVzaW5nIE92ZXJsYXkgQXNzb2Np YXRlZCBDaGFubmVsLCBpcyB0aGF0IGl0IGlzIHNlbGYtY29udGFpbmVkIGFuZCBwcm9jZXNzaW5n IGNhbiBiZSBvZmZsb2FkZWQgb25jZSB0aGUgcGFja2V0IHdhcyBpZGVudGlmaWVkIGFzDQogT0FD IHBhY2tldC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5U aHgNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5EYXZpZA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gR3JlZyBNaXJza3kgW21haWx0bzo8YSBocmVmPSJtYWlsdG86Z3Jl Z2ltaXJza3lAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3JlZ2ltaXJza3lAZ21haWwuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDA1LCAyMDE3IDEwOjQ0 IFBNPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8Yj5Ubzo8L2I+IERhdmlkIE1vemVzICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2 aWRtQG1lbGxhbm94LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhdmlkbUBtZWxsYW5veC5jb208L2E+ Jmd0Ozxicj4NCjxiPkNjOjwvYj4gRmlvY2NvbGEgR2l1c2VwcGUgJmx0OzxhIGhyZWY9Im1haWx0 bzpnaXVzZXBwZS5maW9jY29sYUB0ZWxlY29taXRhbGlhLml0IiB0YXJnZXQ9Il9ibGFuayI+Z2l1 c2VwcGUuZmlvY2NvbGFAdGVsZWNvbWl0YWxpYS5pdDwvYT4mZ3Q7OyBCb2NjaSwgTWF0dGhldyAo Tm9raWEgLSBHQikgJmx0OzxhIGhyZWY9Im1haWx0bzptYXR0aGV3LmJvY2NpQG5va2lhLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1hdHRoZXcuYm9jY2lAbm9raWEuY29tPC9hPiZndDs7IE5WTzMNCiAm bHQ7PGEgaHJlZj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5udm8zQGll dGYub3JnPC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1vb2FtZHQtcnRnd2ctb29hbS1o ZWFkZXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LW9vYW1kdC1ydGd3Zy1vb2Ft LWhlYWRlckBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBvbGwgZm9yIE5W TzMgV0cgYWRvcHRpb24gYW5kIElQUiBjYWxsIGZvciBkcmFmdC1vb2FtZHQtcnRnd2ctb29hbS1o ZWFkZXItMDM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5IaSBEYXZpZCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPnRoYW5rIHlvdSBmb3IgeW91ciBkZXRhaWxlZCBmb2xsb3ctdXAgY29t bWVudHMuIFBsZWFzZSBmaW5kIG15IG5vdGVzIGluLWxpbmUgYW5kIHRhZ2dlZCBHSU0mZ3Q7Jmd0 Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkdyZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBXZWQsIEFwciA1LCAyMDE3IGF0IDEwOjU0IEFNLCBEYXZpZCBNb3plcyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRhdmlkbUBtZWxsYW5veC5jb20iIHRhcmdldD0iX2JsYW5rIj5kYXZp ZG1AbWVsbGFub3guY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgR3Jl ZyZuYnNwOyAsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UFNCPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBHcmVnIE1pcnNr eSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgQXByaWwgMDUsIDIwMTcgMjoyMyBBTTxicj4NCjxiPlRvOjwvYj4gRGF2aWQgTW96 ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZG1AbWVsbGFub3guY29tIiB0YXJnZXQ9Il9ibGFu ayI+ZGF2aWRtQG1lbGxhbm94LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBGaW9jY29sYSBH aXVzZXBwZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdpdXNlcHBlLmZpb2Njb2xhQHRlbGVjb21pdGFs aWEuaXQiIHRhcmdldD0iX2JsYW5rIj5naXVzZXBwZS5maW9jY29sYUB0ZWxlY29taXRhbGlhLml0 PC9hPiZndDs7IEJvY2NpLCBNYXR0aGV3IChOb2tpYSAtIEdCKSAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1hdHRoZXcuYm9jY2lAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWF0dGhldy5ib2NjaUBu b2tpYS5jb208L2E+Jmd0OzsgTlZPMw0KICZsdDs8YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm52bzNAaWV0Zi5vcmc8L2E+Jmd0OzsgPGEgaHJlZj0ibWFpbHRv OmRyYWZ0LW9vYW1kdC1ydGd3Zy1vb2FtLWhlYWRlckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0KZHJhZnQtb29hbWR0LXJ0Z3dnLW9vYW0taGVhZGVyQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogUG9sbCBmb3IgTlZPMyBXRyBhZG9wdGlvbiBhbmQgSVBSIGNhbGwgZm9y IGRyYWZ0LW9vYW1kdC1ydGd3Zy1vb2FtLWhlYWRlci0wMzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5IaSBEYXZpZCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPnRoYW5rIHlvdSBmb3Igc2hhcmluZyB5b3VyIG9waW5pb24uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvdWxk IHlvdSBwbGVhc2UgY2xhcmlmeSB5b3VyIHBvc2l0aW9uLiBZb3UgcHJvcG9zZSB0byB1c2UgZXh0 ZW5zaW9ucy9vcHRpb25zIGZvciBlbmQtdG8tZW5kIGFjdGl2ZSBPQU0/PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5E YXZpZCZndDsgeWVzDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwO0xldCB1cyBsb29rIGF0IHByb2FjdGl2ZSBjb250aW51aXR5IGNoZWNrIGJldHdl ZW4gTlZFcy4gV2h5IHlvdSB0aGluayBhIG1pZGRsZWJveCBuZWVkcyB0byBiZSBhd2FyZSBvZiB0 aGUgT0FNIHBheWxvYWQ/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SSBiZWxpZXZlIHRoYXQgYSB0cmFuc2llbnQgTlZPMyBub2RlIHNob3VsZCBub3QgbG9vayBpbnRv IHBheWxvYWQgaWYgaXQgaXMgbm90IGFkZHJlc3NlZCB0byBpdCBhdCBhbGwuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5EYXZpZCZndDsgQXJlIHlvdSBsaW1pdCB0aGUgaGVhZGVyIGp1c3QgZm9yIHByb2FjdGl2ZSBP QU0gPyAmbmJzcDtzbyBjaGFuZ2UgdGhlIGRyYWZ0IHRvIGluY2x1ZGUganVzdCB0aGF0DQogLiBP biB0aGUgY3VycmVudCAmbmJzcDtkcmFmdCBJIHNlZSBhbGwga2luZHMgb2YgT0FNPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5HSU0mZ3Q7Jmd0OyBJIHdhbnQgdG8g cG9pbnQgdGhhdCB0aGUgZHJhZnQgaW50cm9kdWNlcyBBc3NvY2lhdGVkIENoYW5uZWwgZm9yIGFu IG92ZXJsYXkgbmV0d29yay4gQXNzb2NpYXRlZCBDaGFubmVsIG1heSBiZSB1c2VkIGZvciBzaWdu YWxsaW5nIG9yIE9BTS4gT0FNIG1ldGhvZHMgZW5hYmxlIG9wZXJhdG9ycyB0bw0KIHBlcmZvcm0g RmF1bHQgTWFuYWdlbWVudCBhbmQgUGVyZm9ybWFuY2UgTW9uaXRvcmluZy4gQW1vbmcgZnVuY3Rp b25zIHJlcXVpcmVkIHRvIHBlcmZvcm0gY29tcHJlaGVuc2l2ZSBGYXVsdCBNYW5hZ2VtZW50IGFy ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KZmFpbHVyZSBkZXRl Y3Rpb24sIHVzdWFsbHkgZGV0ZWN0aW9uIG9mIExvc3Mgb2YgQ29udGludWl0eSBidXQgbWF5IGlu Y2x1ZGUgTWlzLWNvbm5lY3Rpb24gZGVmZWN0IGFzIHdlbGwgZm9yIGNvbm5lY3Rpb24tb3JpZW50 ZWQgbmV0d29yazs8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMSBsZXZlbDEgbGZvMSI+DQpkZWZlY3QgbG9jYWxpemF0aW9uOzxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCkFsYXJtIElu ZGljYXRpb24gU2lnbmFsOzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwxIGxldmVsMSBsZm8xIj4NClJlbW90ZSBEZWZlY3QgSW5kaWNhdGlvbi48bzpwPjwv bzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RGVwZW5kaW5nIG9uIHRoZSBy ZXF1aXJlbWVudHMgdG93YXJkcyByZXNpbGllbmN5IGFuZCByZXN0b3JhdGlvbiwgUHJvdGVjdGlv biBTd2l0Y2hvdmVyIENvb3JkaW5hdGlvbiBwcm90b2NvbCBtYXkgYmUgcmVxdWlyZWQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlBlcmZvcm1h bmNlIE1lYXN1cmVtZW50IHVzdWFsbHkgc3VwcG9ydHMgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0Kb25lLXdheSBhbmQgdHdvLXdheSBQYWNr ZXQgTG9zcyBtZWFzdXJlbWVudDs8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpvbmUtd2F5IGFuZCB0d28td2F5IFBhY2tldCBE ZWxheSBtZWFzdXJlbWVudDs8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpTeW50aGV0aWMgTG9zcyBNZWFzdXJlbWVudC48bzpw PjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2VydmljZSBBY3RpdmF0 aW9uIFByb3RvY29sLCBhcyBwYXJ0IG9mIGFjdGl2ZSBPQU0gdG9vbHNldCwgdXN1YWxseSBjb21i aW5lcyBPQU0gZnVuY3Rpb25zIGZyb20gRk0gYW5kIFBNIG9wZXJhdGlvbnMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBnb2FsIG9mIE92 ZXJsYXkgT0FNIHdvcmssIGFzIEkgdW5kZXJzdGFuZCwgaXMgdG8gY3JlYXRlIGNvbW1vbiBzZXQg b2YgT0FNIHByb3RvY29scyB0aGF0IHN1cHBvcnRzIGFsbCBvZiBsaXN0ZWQgYWJvdmUgRk0gYW5k IFBNIG9wZXJhdGlvbnMuIEkgc2VlIHN1Y2ggc2V0IGFzIGNvbWJpbmF0aW9uIG9mDQogYWN0aXZl LCBoeWJyaWQgYW5kIHBhc3NpdmUgT0FNIG1ldGhvZHMuIEkgYmVsaWV2ZSB0aGF0IHRoZSBkcmFm dCBzdGF0ZXMgdGhhdCBjbGVhcmx5LiBUaGUgcHJvYWN0aXZlIE9BTSBpcyB1c3VhbGx5IHVzZWQg dG8gcGVyZm9ybSBtb25pdG9yIG5ldHdvcmsgZm9yIGRlZmVjdHMgYW5kIHBlcmZvcm1hbmNlIGRl Z3JhZGF0aW9uLiBPbi1kZW1hbmQgT0FNIHRvb2xzIG1heSBiZSB1c2VkIHRvIGxvY2FsaXplIHRo ZSBkZWZlY3RzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jmd0OyBXaGlsZSZuYnNwOyBJIGFncmVlIHdpdGggeW91IHJlZ2FyZGluZyAmbmJzcDtNaWRkbGUg Ym94IGFuZCBwcm9hY3RpdmUgT0FNIC5UaGUgc2FtZSBjYW4gYmUgYWNoaWV2ZSB3aXRoIHRoZQ0K IHByb3RvY29sIGV4dGVuc2lvbnMgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaHVzIEkgZG9uJ3QgYWdyZWUgdGhhdCB0aGUgcmVxdWlyZW1lbnQgeW91IHJl ZmVyIHRvIGlzIGFwcGxpY2FibGUgdG8gdXNlIG9mIGFjdGl2ZSBPQU0uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5EYXZpZCZndDsgSSB0aGluayBpZiB0aGUgV0cgZGVjaWRlIG9uIE5WTzMgZW5j YXAgcHJvdG9jb2wgdGhhdCBpbmNsdWRlICZuYnNwO2V4dGVuc2lvbiAoTGlrZSBHVUUgYW5kIEdl bmV2ZSkgd2UgaGF2ZSB0byB1c2UgdGhlIGJ1aWxkIGluIGV4dGVuc2lvbnMgZm9yIHN1Y2gNCiBw cm90b2NvbCBhbmQgbm90IGlubm92YXRlICZuYnNwO2V4dHJhIGhlYWRlciAmbmJzcDt0aGF0IHVz ZSBmb3IgcHJvdG9jb2xzIHdpdGhvdXQgZXh0ZW5zaW9ucy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkdJTSZndDsmZ3Q7IEkgcXVlc3Rpb24geW91ciBhc3N1bXB0 aW9uIHRoYXQgdXNlIG9mIHZhcmlhYmxlIGxlbmd0aCBoZWFkZXIgbWFuZGF0ZXMgaG93IE9BTSwg YWN0aXZlIE9BTSwgbXVzdCBiZSBpbXBsZW1lbnRlZC4gQW5kIHNpbmNlIHNvbWUgbmV0d29ya3Mg Y2hvb3NlIHRvIHVzZSBmaXhlZCBzaXplIGhlYWRlciwgdXNpbmcNCiBPdmVybGF5IEFzc29jaWF0 ZWQgQ2hhbm5lbCBoZWFkZXIgd2l0aCBtdWx0aXBsZXhlZCBPdmVybGF5IE9BTSBmdW5jdGlvbmFs aXR5IGFwcGVhcnMsIGluIG15IG9waW5pb24sIGFzIGNvbW1vbiBzb2x1dGlvbiBmb3IgZWl0aGVy IHR5cGUgb2Ygb3ZlcmxheSBlbmNhcHN1bGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5EYXZpZA0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5H cmVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgQXByIDMsIDIwMTcgYXQgMTE6MTkgQU0sIERhdmlk IE1vemVzICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWRtQG1lbGxhbm94LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmRhdmlkbUBtZWxsYW5veC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0QiPkhpICw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Qi PkkgYW0gbm90IHN1cHBvcnRpbmcgdGhlIGFkb3B0aW9uDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOiMxRjQ5N0QiPkkgdGhpbmsgd2hpbGUgdGhlIHdvcmtpbmcgZ3JvdXAgZGVjaWRlZCBvbiBH ZW5ldmUgYXMgdGhlIGVuY2FwIHByb3RvY29sDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhpcyBPQU0g bmVlZCB0byBiZSB2aWEgb25lIG9mIHRoZSBleHRlbnNpb25zL29wdGlvbnMmbmJzcDsgdGhlIHBy b3RvY29sJm5ic3A7Jm5ic3A7IGlzIHN1cHBvcnRpbmchPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlRoaXMg aGVhZGVyIGFsc28gdmlvbGF0ZSB0aGUgbnVtYmVyIDEgcmVxdWlyZW1lbnRzIGZyb20gdGhlIGV4 dGVuc2lvbnMvb3B0aW9ucyZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdE Ij5UaGF0IG5vZGUvbWlkZGxib3gmbmJzcDsgZG9uIG5vdCZuYnNwOyBuZWVkIHRvIGJlIHBhcnQg b2YgdGhlIGV4dGVuc2lvbnMvIG9wdGlvbiBjYW4ganVtcCBkaXJlY3RseSZuYnNwOyB0byB0aGUg b3ZlcmxheSBieSByZWFkaW5nIHRoZSBiYXNlIGhlYWRlcg0KIGxlbmd0aCBvbmx5IDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEIj5UaHg8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPkRhdmlkDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiBudm8zIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm52bzMtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkZpb2Njb2xhIEdpdXNlcHBlPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMDMsIDIwMTcgNTo0MCBQTTxicj4NCjxiPlRvOjwv Yj4gQm9jY2ksIE1hdHRoZXcgKE5va2lhIC0gR0IpICZsdDs8YSBocmVmPSJtYWlsdG86bWF0dGhl dy5ib2NjaUBub2tpYS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXR0aGV3LmJvY2NpQG5va2lhLmNv bTwvYT4mZ3Q7OyBOVk8zICZsdDs8YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm52bzNAaWV0Zi5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1v b2FtZHQtcnRnd2ctb29hbS1oZWFkZXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1v b2FtZHQtcnRnd2ctb29hbS1oZWFkZXJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFtudm8zXSBSOiBQb2xsIGZvciBOVk8zIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2FsbCBmb3IgZHJh ZnQtb29hbWR0LXJ0Z3dnLW9vYW0taGVhZGVyLTAzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SGkgQWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RCI+SSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBzdXBwb3J0IGl0cyBhZG9wdGlv bi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+R2l1c2VwcGU8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5EYTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IklUIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSZxdW90OyxzYW5zLXNlcmlmIj4gbnZvMyBbPGEgaHJlZj0ibWFpbHRvOm52bzMtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XQ0KPGI+UGVyIGNvbnRvIGRpIDwvYj5Cb2NjaSwgTWF0dGhldyAoTm9raWEgLSBHQik8YnI+ DQo8Yj5JbnZpYXRvOjwvYj4gdmVuZXJkw6wgMzEgbWFyem8gMjAxNyAxNzozNTxicj4NCjxiPkE6 PC9iPiBOVk8zOyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtb29hbWR0LXJ0Z3dnLW9vYW0taGVhZGVy QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1vb2FtZHQtcnRnd2ctb29hbS1oZWFk ZXJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2dnZXR0bzo8L2I+IFtudm8zXSBQb2xsIGZvciBOVk8z IFdHIGFkb3B0aW9uIGFuZCBJUFIgY2FsbCBmb3IgZHJhZnQtb29hbWR0LXJ0Z3dnLW9vYW0taGVh ZGVyLTAzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iSVQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5UaGlzIGVtYWlsIGJlZ2lucyBhIHR3byB3ZWVrIHBvbGwgZm9yIGFkb3B0aW9u IG9mIGRyYWZ0LW9vYW1kdC1ydGd3Zy1vb2FtLWhlYWRlci0wMyBpbiB0aGUgTlZPMyB3b3JraW5n IGdyb3VwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHNlbmQg YW55IGNvbW1lbnRzIHRvIHRoZSBOVk8zIGxpc3QuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+UGxlYXNlIGFsc28gaW5kaWNhdGUgd2hldGhlciB5b3Ugc3VwcG9ydCBhZG9wdGlv biBvZiB0aGUgZHJhZnQgYXMgYW4gTlZPMyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+U2ltdWx0YW5lb3VzbHksIHdlIGFyZSBhbHNvIHBvbGluZyBmb3IgYW55IElQUiB0 aGF0IG1heSBhcHBseSB0byB0aGUgZHJhZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BdXRob3JzIGFuZCBj b250cmlidXRvcnMsIGFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp cyBkcmFmdD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9z ZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5 LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SWYgeW91 IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IsIHBsZWFzZSBy ZXNwb25kIHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPnRoaXMgZW1haWwgc3Rh dGluZyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JUFIuIFRoZSByZXNwb25zZSBuZWVkcyB0byBi ZSBzZW50IHRvIHRoZSBOVk8zIFdHIG1haWxpbmcgbGlzdC4gVGhlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPmRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3Rh Z2UgdW50aWwgYSByZXNwb25zZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5oYXMg YmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBlYWNoIGNvbnRyaWJ1dG9yLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+VGhpcyBwb2xsIGNsb3NlcyBvbiBGcmlkYXkgMTQ8c3VwPnRoPC9zdXA+IEFw cmlsIDIwMTcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NYXR0aGV3 IGFuZCBTYW08L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRh YmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNjAwIiBzdHlsZT0id2lkdGg6 Ni4yNWluIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCB3aWR0aD0iNTg1IiBzdHlsZT0id2lkdGg6NDM4 Ljc1cHQ7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO3RleHQtYWxpZ246anVzdGlmeSI+DQo8c3BhbiBjbGFzcz0ibTY0NTU4MDgy NDg3NDI3MzEwODBtNjAzOTI1NTY3Nzk5NzU1MjczNW0tMzcyMDIxNDM0MTk0Njc0NDIxNW1zb25v cm1hbDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5RdWVzdG8gbWVzc2FnZ2lvIGUgaSBz dW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25l IGluZGljYXRlLiBMYSBkaWZmdXNpb25lLA0KIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9u ZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8g cmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRv Y3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGlt bWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1 YQ0KIGRpc3RydXppb25lLCBHcmF6aWUuIDwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIGNsYXNzPSJtNjQ1NTgw ODI0ODc0MjczMTA4MG02MDM5MjU1Njc3OTk3NTUyNzM1bS0zNzIwMjE0MzQxOTQ2NzQ0MjE1bXNv bm9ybWFsMCI+PGk+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGlz IGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwgYW5k DQogbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFk ZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2Ug YnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2ht ZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuDQogZS1tYWlsLCBUaGFua3MuPC9z cGFuPjwvaT48L3NwYW4+PHNwYW4gY2xhc3M9Im02NDU1ODA4MjQ4NzQyNzMxMDgwbTYwMzkyNTU2 Nzc5OTc1NTI3MzVtLTM3MjAyMTQzNDE5NDY3NDQyMTVtc29ub3JtYWwwIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPg0KPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmp1c3RpZnkiPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjYiIGhlaWdodD0i NDAiIGlkPSJtXzY0NTU4MDgyNDg3NDI3MzEwODBtXzYwMzkyNTU2Nzc5OTc1NTI3MzVtXy0zNzIw MjE0MzQxOTQ2NzQ0MjE1X3gwMDVmX3gwMDAwX2kxMDI1IiBzcmM9ImNpZDppbWFnZTAwMS5naWZA MDFEMkIzNkUuOUUzQkNGNjAiIGFsdD0icmlzcGV0dGEgbCdhbWJpZW50ZSI+UmlzcGV0dGENCiBs J2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8u PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+DQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_HE1PR0501MB213870DA8642B96DB45F9A97B6030HE1PR0501MB2138_-- --_004_HE1PR0501MB213870DA8642B96DB45F9A97B6030HE1PR0501MB2138_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=677; creation-date="Wed, 12 Apr 2017 06:45:09 GMT"; modification-date="Wed, 12 Apr 2017 06:45:09 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_004_HE1PR0501MB213870DA8642B96DB45F9A97B6030HE1PR0501MB2138_-- From nobody Wed Apr 12 05:48:33 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AF5126C2F; Wed, 12 Apr 2017 05:48:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-yang-key-chain-19.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149200130413.15678.15357169884789389752@ietfa.amsl.com> Date: Wed, 12 Apr 2017 05:48:24 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 12:48:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Routing Key Chain YANG Data Model Authors : Acee Lindem Yingzhen Qu Derek Yeung Ing-Wher Chen Jeffrey Zhang Filename : draft-ietf-rtgwg-yang-key-chain-19.txt Pages : 26 Date : 2017-04-12 Abstract: This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. In some applications, the protocols do not use the key chain element key directly, but rather a key derivation function is used to derive a short-lived key from the key chain element key (e.g., the Master Keys used in the TCP Authentication Option(TCP-AO)). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-19 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-key-chain-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-yang-key-chain-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 12 07:19:01 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B7A129B62 for ; Wed, 12 Apr 2017 07:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H4hD1rZ921s for ; Wed, 12 Apr 2017 07:18:57 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325FC129B75 for ; Wed, 12 Apr 2017 07:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3490; q=dns/txt; s=iport; t=1492006737; x=1493216337; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Kcvuh/cyvsBJQnXZRhUzs2bb76F+yujA1aLpdDoQ7Hw=; b=GNyTGXJRzIojJzXjavso7NyCnRLsuCqyXxG2bER6qDDrDHqvXZ4NLR1w DMyu3aKrBYavphl2PHuBie9vK9lDgE24MxgokCQLoJjBVkEB6GSdGj4dF dbXQCWgCGLXi7ZyrP7XeQHExZ2GsR/LFMQ110WByn7rDDYqYnUIq4utbE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5AQDzNe5Y/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHg1+KE6cqgg8hDYV2AhqDXz8YAQIBAQEBAQEBayiFFgI?= =?us-ascii?q?BAwEBIRE6CxACAQgaAiYCAgIlCxUQAgQOBYoWDqhDgiaKeQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2BC4o6gxeERYJfBZ0KAYcBi1+Bf1WEWYoXlAEBHziBBVsVGCm?= =?us-ascii?q?GWnWIFYENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,191,1488844800"; d="scan'208";a="232054114" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2017 14:18:56 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3CEIu47009464 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Apr 2017 14:18:56 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Apr 2017 10:18:55 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 12 Apr 2017 10:18:55 -0400 From: "Acee Lindem (acee)" To: Vincent Roca CC: "rtgwg@ietf.org" Subject: Re: I-D Action: draft-ietf-rtgwg-yang-key-chain-19.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-yang-key-chain-19.txt Thread-Index: AQHSs5e3ptk5rySHLEaaAqbEvMTDjQ== Date: Wed, 12 Apr 2017 14:18:55 +0000 Message-ID: References: <149200130413.15678.15357169884789389752@ietfa.amsl.com> In-Reply-To: <149200130413.15678.15357169884789389752@ietfa.amsl.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.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <61E05DCDFFFDE44FAE1E769DEB1383B9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 14:19:00 -0000 VGhpcyB2ZXJzaW9uIGluY2x1ZGVzIFZpbmNlbnQgUm9jYeKAmXMgc3VnZ2VzdGlvbiB0aGF0IHRo ZSBYTUwgZXhhbXBsZXMNCnNob3VsZCByZWZlcmVuY2UgdGhlIHNlY3VyZSBhdXRoZW50aWNhdGlv biBhbGdvcml0aG1zLg0KVGhhbmtzLA0KQWNlZQ0KDQpPbiA0LzEyLzE3LCA4OjQ4IEFNLCAicnRn d2cgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyINCjxydGd3Zy1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0K DQo+DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzDQo+ZGlyZWN0b3JpZXMuDQo+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgUm91dGluZyBBcmVhIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+ICAg ICAgICBUaXRsZSAgICAgICAgICAgOiBSb3V0aW5nIEtleSBDaGFpbiBZQU5HIERhdGEgTW9kZWwN Cj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IEFjZWUgTGluZGVtDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICBZaW5nemhlbiBRdQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgRGVyZWsg WWV1bmcNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEluZy1XaGVyIENoZW4NCj4gICAgICAg ICAgICAgICAgICAgICAgICAgIEplZmZyZXkgWmhhbmcNCj4JRmlsZW5hbWUgICAgICAgIDogZHJh ZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbi0xOS50eHQNCj4JUGFnZXMgICAgICAgICAgIDog MjYNCj4JRGF0ZSAgICAgICAgICAgIDogMjAxNy0wNC0xMg0KPg0KPkFic3RyYWN0Og0KPiAgIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBrZXkgY2hhaW4gWUFORyBkYXRhIG1vZGVsLiAgS2V5 IGNoYWlucw0KPiAgIGFyZSBjb21tb25seSB1c2VkIGZvciByb3V0aW5nIHByb3RvY29sIGF1dGhl bnRpY2F0aW9uIGFuZCBvdGhlcg0KPiAgIGFwcGxpY2F0aW9ucyByZXF1aXJpbmcgc3ltbWV0cmlj IGtleXMuICBBIGtleSBjaGFpbiBpcyBhIGxpc3Qgb2YNCj4gICBlbGVtZW50cyBlYWNoIGNvbnRh aW5pbmcgYSBrZXkgc3RyaW5nLCBzZW5kIGxpZmV0aW1lLCBhY2NlcHQNCj4gICBsaWZldGltZSwg YW5kIGFsZ29yaXRobSAoYXV0aGVudGljYXRpb24gb3IgZW5jcnlwdGlvbikuICBCeSBwcm9wZXJs eQ0KPiAgIG92ZXJsYXBwaW5nIHRoZSBzZW5kIGFuZCBhY2NlcHQgbGlmZXRpbWVzIG9mIG11bHRp cGxlIGtleSBjaGFpbg0KPiAgIGVsZW1lbnRzLCBrZXkgc3RyaW5ncyBhbmQgYWxnb3JpdGhtcyBt YXkgYmUgZ3JhY2VmdWxseSB1cGRhdGVkLiAgQnkNCj4gICByZXByZXNlbnRpbmcgdGhlbSBpbiBh IFlBTkcgZGF0YSBtb2RlbCwga2V5IGRpc3RyaWJ1dGlvbiBjYW4gYmUNCj4gICBhdXRvbWF0ZWQu DQo+DQo+ICAgSW4gc29tZSBhcHBsaWNhdGlvbnMsIHRoZSBwcm90b2NvbHMgZG8gbm90IHVzZSB0 aGUga2V5IGNoYWluIGVsZW1lbnQNCj4gICBrZXkgZGlyZWN0bHksIGJ1dCByYXRoZXIgYSBrZXkg ZGVyaXZhdGlvbiBmdW5jdGlvbiBpcyB1c2VkIHRvIGRlcml2ZQ0KPiAgIGEgc2hvcnQtbGl2ZWQg a2V5IGZyb20gdGhlIGtleSBjaGFpbiBlbGVtZW50IGtleSAoZS5nLiwgdGhlIE1hc3Rlcg0KPiAg IEtleXMgdXNlZCBpbiB0aGUgVENQIEF1dGhlbnRpY2F0aW9uIE9wdGlvbihUQ1AtQU8pKS4NCj4N Cj4NCj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Z3dnLXlhbmct a2V5LWNoYWluLw0KPg0KPlRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJs ZSBhdDoNCj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGd3Zy15YW5n LWtleS1jaGFpbi0xOQ0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbi0xOQ0KPg0KPkEgZGlmZiBmcm9tIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbi0xOQ0KPg0KPg0KPlBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mDQo+c3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5ydGd3ZyBtYWlsaW5nIGxpc3QNCj5ydGd3Z0BpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCg0K From auerswald@fg-networking.de Wed Apr 12 01:50:47 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99BC13146D; Wed, 12 Apr 2017 01:50:47 -0700 (PDT) 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] 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 G3e5wCTYhy0u; Wed, 12 Apr 2017 01:50:43 -0700 (PDT) Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (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 F064D131460; Wed, 12 Apr 2017 01:50:32 -0700 (PDT) Received: from mail.fg-networking.de (mail.fg-networking.de [IPv6:2001:638:208:cd01::23]) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v3C8oSoN018217 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Apr 2017 10:50:28 +0200 Received: from fgn-t61 (unknown [10.122.4.15]) by mail.fg-networking.de (Postfix) with ESMTP id 52EE92007A; Wed, 12 Apr 2017 10:50:19 +0200 (CEST) Received: by fgn-t61 (Postfix, from userid 1000) id EAB95100445; Wed, 12 Apr 2017 10:50:18 +0200 (CEST) Date: Wed, 12 Apr 2017 10:50:18 +0200 From: Erik Auerswald To: Russ White <7riw77@gmail.com>, rtgwg@ietf.org, isis-wg@ietf.org Cc: Erik Auerswald Subject: Some comments on draft-white-openfabric-02 Message-ID: <20170412085018.GA29441@fg-networking.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Wed, 12 Apr 2017 11:32:24 -0700 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 08:53:30 -0000 Hi all, I have read draft-white-openfabric-02 and would like to comment on a few points. I'll start at the top of the draft and continue through the text. Please keep my e-mail address in replies, because I am not subscribed to the isis-wg and rtgwg mailing lists. 1. The abstract states "[...]topology information is extracted through broad based connections." I do not understand that sentence. 2. Section 1.1., Goals, mentions large scale data centers. Would it be appropriate to reference RFC 7938, Use of BGP for Routing in Large-Scale Data Centers, here? Said RFC proposes a Clos topology for the network, which seems to be similar to the spine and leaf topology of openfabric. 3. In section 1.3., Simplification, I noticed a spelling mistake: mutliaccess (should be multiaccess). 4. In section 1.5., Sample Network, a spine and leaf network is shown in figure 1. The topology shown in that figure is different from the 5-stage Clos topology shown in RFC 7938, figure 3. The 5-stage Clos topology from RFC 7938 represents the network topology used by Facebook for the Altoona data center, as publicized in https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the-next-generation-facebook-data-center-network/. Another generalization of the 3-stage Clos network to more than 3 stages called Beneš network can be found on Wikipedia: https://en.wikipedia.org/wiki/Clos_network#Clos_networks_with_more_than_three_stages Both of these 5-stage networks differ from figure 1 of the openfabric draft insofar as each T2 switch is connected to a proper subset of T1 switches (openfabric designation) in both the RFC 7938 "Clos" topology and the Beneš network. This is crucial for increasing the amount of input- and output ports without using bigger switches. Since this is important for later comments, I have adapted figure 3 from RFC 7938 into the following drawing: +----+ +----+ |L1.1| |L1.2| (T0) +----+ +----+ | \________________ / | | ________________\/ | | / \ | +----+ +----+ |F1.1| |F1.2| (T1) +----+ +----+ / \ / \ / \ / \ +----+ +----+ +----+ +----+ |S1.1| |S1.2| |S2.1| |S2.2| (T2) +----+ +----+ +----+ +----+ \ / \ / \ / \ / +----+ +----+ |F2.1| |F2.2| (T1) +----+ +----+ | \________________ / | | ________________\/ | | / \ | +----+ +----+ |L2.1| |L2.2| (T0) +----+ +----+ Legend: Lx.y: Leaf switches (a.k.a. Top of Rack (ToR) switches) Fx.y: Fabric switches Sx.y: Spine switches Inter-switch connections: Lx.y is connected to Fx.* Fx.y is connected to Lx.* and Sy.* Sx.y is connected to F*.x Figure 2: 5-Stage Clos Topology (adapted from [RFC7938], Figure 3) I have used the name "Fabric switch" similar to Facebook's use of that name in the above referenced blog post, just to have distinct names and single letter abbreviations for each tier. A reference to RFC 7938, section 3.2, Clos Network Topology, would fit into this section. 5. It might be appropriate to mention the use of timeouts and exponential back-off for initial adjacency formation in section 2. Something like sequentially trying all discovered neighbors and using exponentially increasing random timeouts for subsequent rounds until the first adjacency is formed. A "Happy Eyeballs" (RFC 6555) like approach of trying to form two adjacencies with a slight delay in-between might be nice as well. 6. Section 3., Determining Location on the Fabric, relies on the special topology from figure 1 of the openfaric draft. In both Beneš networks and the topology shown in figure 2 (of this mail), FD == TD and TD == 4 holds for non-T0 switches. One example is S1.1 from figure 2. It can be easily seen from that figure that for all switches in that topology FD == TD == 4. Thus the algorithms from sections 3.1., Determining T0, and 3.2., Determining T1 and above, do not work for general fabric topologies. 7. The algorithm described in section 4, Flooding Optimization, does not work for the 5-stage "Clos" topology (see figure 2). An example for this is a change that pertains just switches S1.1 and F1.1 in figure 2 (e.g. a link between these two switches fails). Because the T0 switches Lx.y receive the LSPs as DNR, the LSPs do not reach switches Fx.2 and S2.y during flooding. The failure recovery mechanism of section 4.1., Flooding Failures, is needed to propagate the LSPs by design, but this is clearly thought of as a backup mechanism that is not needed for normal operation. 8. Section 5.1., Transit Link Reachability, would benefit from a reference to RFC 5837, Extending ICMP for Interface and Next-Hop Identification. 9. Section 6., Openfabric and Route Aggregation, should disallow route summarization. Otherwise the failure of a single link will result in traffic black-holing without intra-tier links. See e.g. RFC 7839, sections 8.2. and 8.2.1. But intra-tier links are disallowed in section 1.5, Sample Network. Since the reason for disallowing intra-tier links, topology auto- detection, is not yet solved (see comment 6. above), you might allow the combination of intra-tier links and route summarization. I would prefer disallwoing both for openfabric, because the added complexity of route summarization and its effects on resiliency in the case of failures seem a bad trade-off for the reduced routing table size. Thanks for reading this far. :-) Best regards, Erik -- Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald@fg-networking.de T:+49-631-4149988-0 M:+49-176-64228513 Gesellschaft für Fundamental Generic Networking mbH Geschäftsführung: Volker Bauer, Jörg Mayer Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630 From nobody Wed Apr 12 11:34:01 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2DE12EB4C for ; Wed, 12 Apr 2017 11:33:59 -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, MIME_QP_LONG_LINE=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 JBPr_PdGfFQz for ; Wed, 12 Apr 2017 11:33:57 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::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 3FF32127444 for ; Wed, 12 Apr 2017 11:33:57 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id i5so6568778pfc.3 for ; Wed, 12 Apr 2017 11:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=BiahpOsYy9795jLxYcBonxcM96FB5oDu90uSB0uNZqg=; b=RFtQ10BR9UIj+yoXMUgM/ajMfDdlZAzXrhNFvDgOF3+j2a+IibldFoMcaj185+b0w5 hwC1qNub3/+Z04Z4vy7w6mg4qfJc3aegIIJ3cRe/Xgv/6Hd/oEGupMqxmZjh2sk7q5VG KvXbZtodBvHofWBovKx5km9+tQFyJRmfiRBm+DB8FNLLmNSoP6aJznQwWhsa3vyjmYzl JnmG4oR2IKJkZip0s8c5vAOr3YBhqvklxtrjJtXnF5HrhoqcgpRNxehTTNIbxgtTCOpE 55QeoyDIY6gAeSxaAA3PDXqbVX9LYh9KNW2ZYS1qVI4zcggljHprK7TUh8A1joXsa5n6 24gA== 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:references:in-reply-to:mime-version :content-transfer-encoding; bh=BiahpOsYy9795jLxYcBonxcM96FB5oDu90uSB0uNZqg=; b=BAFVIUqiDfZuyCQ0bDOZXMBDYm1gGpGt8l/mFK6TtWfNjd3i0f2ulu6l5jM6EMwbY+ HkEca6ECMrOd8BGCuApsPcJs0Qh7OiQ+w8YyeyIjmiqQ7nYqOt0gTKr9xgHZnL2xYwDn hfx9OZlqlcUUbjq8p0EhZPVroXgmbd9hfmBEeCql7W0xaa/d3oJgB+zvPz9smMMObWQz o9cAmYPwylGH/IO3E1Jey8rNbW1rudAp/TKsAjyXlDECS31iwFDKnpP3ZVcXYMH23NEH TIQr8kIDT2jlffvpZqmE6XBGGAMSpjGLts065kCN6vMI2vkDo8UvHZKRFusfN13ARnJA eLMQ== X-Gm-Message-State: AFeK/H2GQPNSPxx9bPTP3ZZSMw8J4Xrfw+Zg+ZSTghwAyeuIDP5jw3n/aLLC5HIKUv4/xQ== X-Received: by 10.99.225.5 with SMTP id z5mr69075001pgh.145.1492022036732; Wed, 12 Apr 2017 11:33:56 -0700 (PDT) Received: from [10.24.45.80] ([68.65.169.228]) by smtp.gmail.com with ESMTPSA id s21sm38106436pgg.65.2017.04.12.11.33.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 11:33:55 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Wed, 12 Apr 2017 11:33:54 -0700 Subject: Re: [Isis-wg] Some comments on draft-white-openfabric-02 From: Jeff Tantsura To: Erik Auerswald , Russ White <7riw77@gmail.com>, Message-ID: <8C49C6EC-C129-452E-AF3B-35C74611F51E@gmail.com> Thread-Topic: [Isis-wg] Some comments on draft-white-openfabric-02 References: <20170412085018.GA29441@fg-networking.de> In-Reply-To: <20170412085018.GA29441@fg-networking.de> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:34:00 -0000 Erik, I have added your email to RTGWG list, so now you are allowed to post there= .=20 Cheers, Jeff =20 On 4/12/17, 01:50, "Isis-wg on behalf of Erik Auerswald" wrote: Hi all, =20 I have read draft-white-openfabric-02 and would like to comment on a few points. I'll start at the top of the draft and continue through the text. =20 Please keep my e-mail address in replies, because I am not subscribed to the isis-wg and rtgwg mailing lists. =20 1. The abstract states "[...]topology information is extracted through broad based connections." I do not understand that sentence. =20 2. Section 1.1., Goals, mentions large scale data centers. Would it be appropriate to reference RFC 7938, Use of BGP for Routing in Large-Scale Data Centers, here? Said RFC proposes a Clos topology for the network, which seems to be similar to the spine and leaf topology of openfabric. =20 3. In section 1.3., Simplification, I noticed a spelling mistake: mutliaccess (should be multiaccess). =20 4. In section 1.5., Sample Network, a spine and leaf network is shown in figure 1. The topology shown in that figure is different from the 5-stage Clos topology shown in RFC 7938, figure 3. The 5-stage Clos topology from RFC 7938 represents the network topology used by Facebook for the Altoona data center, as publicized in https://code.facebook.com/posts/360346274145943/introducing-data-center= -fabric-the-next-generation-facebook-data-center-network/. =20 Another generalization of the 3-stage Clos network to more than 3 stages called Bene=C5=A1 network can be found on Wikipedia: https://en.wikipedia.org/wiki/Clos_network#Clos_networks_with_more_than= _three_stages =20 Both of these 5-stage networks differ from figure 1 of the openfabric draft insofar as each T2 switch is connected to a proper subset of T1 switches (openfabric designation) in both the RFC 7938 "Clos" topology and the Bene=C5=A1 network. This is crucial for increasing the amount of input- and output ports without using bigger switches. =20 Since this is important for later comments, I have adapted figure 3 from RFC 7938 into the following drawing: =20 =20 +----+ +----+ |L1.1| |L1.2| (T0) +----+ +----+ | \________________ / | | ________________\/ | | / \ | +----+ +----+ |F1.1| |F1.2| (T1) +----+ +----+ / \ / \ / \ / \ +----+ +----+ +----+ +----+ |S1.1| |S1.2| |S2.1| |S2.2| (T2) +----+ +----+ +----+ +----+ \ / \ / \ / \ / +----+ +----+ |F2.1| |F2.2| (T1) +----+ +----+ | \________________ / | | ________________\/ | | / \ | +----+ +----+ |L2.1| |L2.2| (T0) +----+ +----+ =20 Legend: Lx.y: Leaf switches (a.k.a. Top of Rack (ToR) switches) Fx.y: Fabric switches Sx.y: Spine switches =20 Inter-switch connections: Lx.y is connected to Fx.* Fx.y is connected to Lx.* and Sy.* Sx.y is connected to F*.x=20 =20 Figure 2: 5-Stage Clos Topology (adapted from [RFC7938], Figure 3) =20 I have used the name "Fabric switch" similar to Facebook's use of that name in the above referenced blog post, just to have distinct names and single letter abbreviations for each tier. =20 A reference to RFC 7938, section 3.2, Clos Network Topology, would fit into this section. =20 5. It might be appropriate to mention the use of timeouts and exponential back-off for initial adjacency formation in section 2. Something like sequentially trying all discovered neighbors and using exponentially increasing random timeouts for subsequent rounds until the first adjacency is formed. A "Happy Eyeballs" (RFC 6555) like approach of trying to form two adjacencies with a slight delay in-between might be nice as well. =20 6. Section 3., Determining Location on the Fabric, relies on the special topology from figure 1 of the openfaric draft. In both Bene=C5=A1 networks and the topology shown in figure 2 (of this mail), FD =3D=3D TD and TD =3D=3D 4 holds for non-T0 switches. One example is S1.1 from figure 2. It can be easily seen from that figure that for all switches in that topology FD =3D=3D TD =3D=3D 4. Thus the algorithms from sections 3.1., Determining T0, and 3.2., Determining T1 and above, do not work for general fabric topologies. =20 7. The algorithm described in section 4, Flooding Optimization, does not work for the 5-stage "Clos" topology (see figure 2). An example for this is a change that pertains just switches S1.1 and F1.1 in figure 2 (e.g. a link between these two switches fails). Because the T0 switches Lx.y receive the LSPs as DNR, the LSPs do not reach switches Fx.2 and S2.y during flooding. The failure recovery mechanism of section 4.1., Flooding Failures, is needed to propagate the LSPs by design, but this is clearly thought of as a backup mechanism that is not needed for normal operation. =20 8. Section 5.1., Transit Link Reachability, would benefit from a reference to RFC 5837, Extending ICMP for Interface and Next-Hop Identification. =20 9. Section 6., Openfabric and Route Aggregation, should disallow route summarization. Otherwise the failure of a single link will result in traffic black-holing without intra-tier links. See e.g. RFC 7839, sections 8.2. and 8.2.1. But intra-tier links are disallowed in section 1.5, Sample Network. =20 Since the reason for disallowing intra-tier links, topology auto- detection, is not yet solved (see comment 6. above), you might allow the combination of intra-tier links and route summarization. I would prefer disallwoing both for openfabric, because the added complexity of route summarization and its effects on resiliency in the case of failures seem a bad trade-off for the reduced routing table size. =20 Thanks for reading this far. :-) =20 Best regards, Erik --=20 Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald@fg-networking.de T:+49-631-4149988-0 M:+49-176-64228513 =20 Gesellschaft f=C3=BCr Fundamental Generic Networking mbH Gesch=C3=A4ftsf=C3=BChrung: Volker Bauer, J=C3=B6rg Mayer Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630 =20 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg =20 From nobody Thu Apr 13 16:08:53 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42694129AA3 for ; Thu, 13 Apr 2017 16:08:52 -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, 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 FWTOtlrxFGSJ for ; Thu, 13 Apr 2017 16:08:50 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB8A1204DA for ; Thu, 13 Apr 2017 16:08:50 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id c198so34445039pfc.1 for ; Thu, 13 Apr 2017 16:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=sT8cQkxCZUzwOENDT0wINCk9zkWfZ/8AcV+gcYL3jIc=; b=krl23oWKjx3H304ehHMOSc6Lz3gIMi8p6CK78pz/QFqzjjG9hxvHNteg7CpoM/h+Q3 osprWofwZy/9e+0FB0NZ2eJVzf0SFB9Rcsv9gegsQHlVPHScLBbWVtXOvP1rmMcJmHPV vPW2Cygf0Kf6LD76MTEoy0ZGe0vxlZ2EcqmzBxtjrXet4Lnre/ElUe2KDdN1uMxnJF4R tBbZ5Rhs7tNzXDOAsxZlpzme4bm88/bW6P86LXsza6gQ8e/bKwgADEqoGkIDGatVAtze w9qBzsfYMqTSEmAVThNy0EfV8b0il7ITZ08cka0tv3pIOAaWrCGlXQn6fRFWLh/xlBT6 7p3g== 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:cc:message-id :thread-topic:mime-version:content-transfer-encoding; bh=sT8cQkxCZUzwOENDT0wINCk9zkWfZ/8AcV+gcYL3jIc=; b=pxIXF52Epw2eeEW7+Rf10e2mUK8pleKGS62l2gPDFuIigYKlywR6X6jOFSGM9KxQw4 9mKeuKo6WlWpQZQkNs2vNYzZESPr2ETWPuGnfG+t15iwltYseNl0KN0Z++1TH+C8c/Ra IWbuTqz82Lva3xYTQvfKUKCLJKm/sqg9RVSaXe8RtTjf4YLgdCYhXHAtWHc/b7Xyktt0 jCgyPhzjRegQpuETzxNsjvN8qw3J3I/Moi22boIG8fUdrq5xFh4bznM/cfS0wjjvS5yN RdWg4MZ/ymKYjH8CmcOOBEX2lifeTsT4MwmLQqX6faSrnOfO2fqCvdjWLn173Ho2OsOc 2Ocg== X-Gm-Message-State: AN3rC/4fd0XUVpLTVXL2jlHVS+u32XtP3rNX/LiflYUSWzzN42PP+F6k JBb1vhp9oqAZrg== X-Received: by 10.99.175.66 with SMTP id s2mr4532919pgo.30.1492124930510; Thu, 13 Apr 2017 16:08:50 -0700 (PDT) Received: from [192.168.254.233] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id b77sm143009pfl.2.2017.04.13.16.08.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 16:08:49 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Thu, 13 Apr 2017 16:08:43 -0700 Subject: RTGWG minutes IETF98 From: Jeff Tantsura To: RTGWG CC: rtgwg-chairs Message-ID: Thread-Topic: RTGWG minutes IETF98 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 23:08:52 -0000 Hi, The minutes have been published at: https://datatracker.ietf.org/doc/minutes-98-rtgwg/ Please provide your comments. Thanks! Jeff & Chris From nobody Mon Apr 17 10:44:22 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFD713170D; Mon, 17 Apr 2017 10:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz4zuiFMhQvb; Mon, 17 Apr 2017 10:44:20 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15EE4131706; Mon, 17 Apr 2017 10:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2927; q=dns/txt; s=iport; t=1492451060; x=1493660660; h=from:to:cc:subject:date:message-id:mime-version; bh=ZEAXSmz9Kzkh3Xdebt5lPriqX0JRCQgQ5xcVZYDtVXA=; b=kbx0g53oeu9956m+QHsjAGxsmcq0iRnAXJvjf8FZsZrgRTFnfKVQ5DX5 uhLj3OYXAlTGVkr+KzwAZoqm5AJJrL4CIM5XTjquWM9IN3gOpJXHfndI/ gm2V8ALH5UcGdWF45QWYHZ9Kf1SDRKN8yVikP9Z5SVIlJ8NR47w8tFuBB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/AgBN/vRY/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5lYYELB4NfihWiCIU0gg8shXgcg2g/GAECAQEBAQEBAWsohT9?= =?us-ascii?q?WEgEMAQ0wAgQwFxAEDoocDqsCgiaLFwEBAQEBAQEBAQEBAQEBAQEBARsFiC+EZ?= =?us-ascii?q?4YOgl8FnRsBgVWRD5FGlAkBHzhYLWMVhyl1AYgNgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,215,1488844800"; d="scan'208,217";a="411457328" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2017 17:44:17 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3HHiHJZ017558 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Apr 2017 17:44:17 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Apr 2017 13:44:16 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 17 Apr 2017 13:44:16 -0400 From: "Acee Lindem (acee)" To: Routing WG CC: "netmod@ietf.org" Subject: Impact of "Network Management Datastore Architecture" (NMDA) on ietf-key-chain Thread-Topic: Impact of "Network Management Datastore Architecture" (NMDA) on ietf-key-chain Thread-Index: AQHSt6I8WwCYI94mMEy+O1Ae6VizeQ== Date: Mon, 17 Apr 2017 17:44:16 +0000 Message-ID: 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.116.152.197] Content-Type: multipart/alternative; boundary="_000_D51A772BA8ED9aceeciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:44:22 -0000 --_000_D51A772BA8ED9aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIHRob3NlIHdobyBhcmUgbm90IGZvbGxvd2luZyB0aGUgZHJhZnQgb3IgZGlzY3Vzc2lvbiwg SeKAmW0gcmVmZXJyaW5nIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtbmV0 bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy0wMS50eHQNCg0KQWZ0ZXIgbnVtZXJvdXMgbWVldGluZ3Mg b24gdGhlIE5NREEsIEkgd291bGQgYXNzZXJ0IHRoYXQgdGhlIGlldGYta2V5LWNoYWluIG1vZGVs IGlzIGluIHRoZSBjYXRlZ29yeSB3aGljaCBjYW4gZ28gZGlyZWN0bHkgdG8gTk1EQSB3aXRob3V0 IGFueSBtaWdyYXRpb24uIEkgYmFzZSB0aGlzIG9uIHRoZSBmYWN0IHRoYXQgZ2l2ZW4gdGhhdCBr ZXktY2hhaW5zIGFyZSBtZXJlbHkgYSBkYXRhYmFzZSBvZiBsaXN0cyBvZiBrZXlzIHRoYXQgY2Fu IGJlIHVwZGF0ZWQgaW1tZWRpYXRlbHksIHRoZXJlIHNob3VsZCBiZSBsaXR0bGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIHRoZSDigJhydW5uaW5n4oCZIGFuZCDigJhpbnRlbmRlZOKAmSBkYXRhc3RvcmVz LiBOb3RlIHRoYXQgdGhpcyBpcyBjb25zaXN0ZW50IHdpdGggdGhlIEFDTCBtb2RlbDogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEwLnR4dA0KDQpE b2VzIGFueW9uZSBkaXNhZ3JlZSB3aXRoIHRoaXMgYXNzZXJ0aW9uPw0KDQpUaGFua3MsDQpBY2Vl DQoNCg== --_000_D51A772BA8ED9aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5Gb3IgdGhvc2Ug d2hvIGFyZSBub3QgZm9sbG93aW5nIHRoZSBkcmFmdCBvciBkaXNjdXNzaW9uLCBJ4oCZbSByZWZl cnJpbmcgdG8mbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRm LW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMtMDEudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMtMDEudHh0PC9hPjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QWZ0ZXIgbnVtZXJvdXMgbWVldGluZ3Mgb24gdGhlIE5N REEsIEkgd291bGQgYXNzZXJ0IHRoYXQgdGhlIGlldGYta2V5LWNoYWluIG1vZGVsIGlzIGluIHRo ZSBjYXRlZ29yeSB3aGljaCBjYW4gZ28gZGlyZWN0bHkgdG8gTk1EQSB3aXRob3V0IGFueSBtaWdy YXRpb24uIEkgYmFzZSB0aGlzIG9uIHRoZSBmYWN0IHRoYXQgZ2l2ZW4gdGhhdCBrZXktY2hhaW5z IGFyZSBtZXJlbHkgYSBkYXRhYmFzZSBvZiBsaXN0cyBvZiBrZXlzIHRoYXQgY2FuDQogYmUgdXBk YXRlZCBpbW1lZGlhdGVseSwgdGhlcmUgc2hvdWxkIGJlIGxpdHRsZSBkaWZmZXJlbmNlIGJldHdl ZW4gdGhlIOKAmHJ1bm5pbmfigJkgYW5kIOKAmGludGVuZGVk4oCZIGRhdGFzdG9yZXMuIE5vdGUg dGhhdCB0aGlzIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgQUNMIG1vZGVsOiBodHRwczovL3d3dy5p ZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTAudHh0PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5Eb2VzIGFueW9uZSBkaXNhZ3JlZSB3aXRoIHRoaXMgYXNzZXJ0 aW9uPyZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0K PGRpdj5BY2VlICZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_D51A772BA8ED9aceeciscocom_-- From nobody Mon Apr 17 17:56:12 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4786D126C2F for ; Mon, 17 Apr 2017 17:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO13l6yjfFJB for ; Mon, 17 Apr 2017 17:56:09 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35DC128D44 for ; Mon, 17 Apr 2017 17:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1611; q=dns/txt; s=iport; t=1492476969; x=1493686569; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RJ3DtG/YQF2uYlHp8bUNtpkCfCmtPDDP2LrNvTy+5og=; b=Wys59XaLQNmuuj4abiOIn2vBuhFsJ5+iEVqvuCZfR7Y5X8Zius8r42jA 0k/PdvLbB/liFt6qO0QN5vupP96gtQJPL0EYGqnFA6TwlKoz0MjC89ok/ tIPqt/rSWCEzNMLKsQ8a5jr05iKQnpQuiCZ//7u2bfenABc9jn8UtyEr/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQDZY/VY/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygrYYELB410kV+VX4IPIQuFeAKEBT8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQEDAQE4NAsMBAIBCBEEAQEfCQcnCxQJCAIEAQ0FCIoPDq0WiyEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYZShHWKPAWdGwGHA4tYggiFMIoXiGmLIAEfOIEFYxV?= =?us-ascii?q?EhGYcgWN1iA6BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,217,1488844800"; d="scan'208";a="413093624" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2017 00:56:08 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3I0u8pb008487 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Apr 2017 00:56:08 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Apr 2017 19:56:08 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Mon, 17 Apr 2017 19:56:07 -0500 From: "Les Ginsberg (ginsberg)" To: Jeff Tantsura , RTGWG CC: rtgwg-chairs Subject: RE: RTGWG minutes IETF98 Thread-Topic: RTGWG minutes IETF98 Thread-Index: AQHStKrxPZh9YFJAGky1ljoTrEjPlqHKUZ8g Date: Tue, 18 Apr 2017 00:56:07 +0000 Message-ID: <9b018c290f1c4d6196006f0fc0ae05a7@XCH-ALN-001.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.71.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 00:56:11 -0000 In regards to the discussion regarding " draft-ietf-rtgwg-spf-uloop-pb-stat= ement" I am quoted as saying: " Les: most of the analysis that I am aware of - the largest contributor is the control plane." In actuality what I said (or at least intended to say :-) ) was that the la= rgest contributor is the data plane (NOT the control plane). The point of the exchange between Bruno and myself was to emphaisze the poi= nt that demonstrating the real world benefits of the standardized backoff a= lgorithm should include cases where forwarding plane update speeds are diff= erent on different nodes in the topology. It is possible that better synchr= onization of the control plane execution times (which is what use of a con= sistent backoff algorithm is likely to provide) may not mean much in cases = where forwarding plane update speeds are significantly different on differe= nt nodes and/or when forwarding plane update speeds consume much more time = than the control plane SPF/RIB updates. The latter case is quite common. Les > -----Original Message----- > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Jeff Tantsura > Sent: Thursday, April 13, 2017 4:09 PM > To: RTGWG > Cc: rtgwg-chairs > Subject: RTGWG minutes IETF98 >=20 > Hi, >=20 > The minutes have been published at: > https://datatracker.ietf.org/doc/minutes-98-rtgwg/ > Please provide your comments. >=20 > Thanks! > Jeff & Chris >=20 >=20 >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From nobody Tue Apr 18 07:42:42 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FEB131798 for ; Tue, 18 Apr 2017 07:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxKmRqSjED4D for ; Tue, 18 Apr 2017 07:42:39 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2F1131795 for ; Tue, 18 Apr 2017 07:42:38 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id EC3C0603D1; Tue, 18 Apr 2017 16:42:36 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id D02E518006C; Tue, 18 Apr 2017 16:42:36 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 16:42:36 +0200 From: To: "Les Ginsberg (ginsberg)" CC: RTGWG Subject: draft-ietf-rtgwg-spf-uloop-pb-statement Thread-Topic: draft-ietf-rtgwg-spf-uloop-pb-statement Thread-Index: AdK4TvWsFJesfB3VR0O6fiH/OAGmKg== Date: Tue, 18 Apr 2017 14:42:36 +0000 Message-ID: <25494_1492526556_58F625DC_25494_1788_1_53C29892C857584299CBF5D05346208A31CBAD4A@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 14:42:41 -0000 Changing the subject of the thread. Hi Les, As a follow up on the discussion > From: Les Ginsberg (ginsberg) > Sent: Tuesday, April 18, 2017 2:56 AM >=20 > In regards to the discussion regarding " draft-ietf-rtgwg-spf-uloop-pb-s= tatement" I am > quoted as saying: >=20 > " Les: most of the analysis that I am aware of - > the largest contributor is the control plane." >=20 > In actuality what I said (or at least intended to say :-) ) was that the= largest contributor is the > data plane (NOT the control plane). >=20 > The point of the exchange between Bruno and myself was to emphaisze the = point that > demonstrating the real world benefits of the standardized backoff algori= thm should include > cases where forwarding plane update speeds are different on different no= des in the > topology. It is possible that better synchronization of the control pla= ne execution times > (which is what use of a consistent backoff algorithm is likely to provid= e) may not mean much > in cases where forwarding plane update speeds are significantly differen= t on different > nodes and/or when forwarding plane update speeds consume much more time = than the > control plane SPF/RIB updates. The latter case is quite common. A few points/comments, - IMHO, your request seems more related to the problem statement draft. htt= ps://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-03 If you = could comment the draft in order to improve it, this would probably speed u= p the discussion. - You are right that the IGP fast convergence, following a single failure, = is mostly due to the time needed to update the FIB on line cards. However, = as the SPF back-off algo kicks in, this is changing, and differences in spf= delay algo brings a significant delta. cf slide 6 of the slides presented = in IETF 90=20 https://www.ietf.org/proceedings/90/slides/slides-90-rtgwg-2.pdf You may a= lso review the whole presentation; not because you would learn anything, bu= t may be to ease the identification of the parts where we may have a differ= ent opinion. (at this point, I'm not seeing real disagreement). - Do we agree that having different SPF delay algo across one network, is n= ot a feature but a bug? IOW, there is value in standardizing one.=20 Regards, --Bruno =20 > Les >=20 >=20 > > -----Original Message----- > > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Jeff Tantsura > > Sent: Thursday, April 13, 2017 4:09 PM > > To: RTGWG > > Cc: rtgwg-chairs > > Subject: RTGWG minutes IETF98 > > > > Hi, > > > > The minutes have been published at: > > https://datatracker.ietf.org/doc/minutes-98-rtgwg/ > > Please provide your comments. > > > > Thanks! > > Jeff & Chris > > > > > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Apr 18 08:55:44 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DC0120727 for ; Tue, 18 Apr 2017 08:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ri5rt0N1IMC for ; Tue, 18 Apr 2017 08:55:41 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE1D12EBFA for ; Tue, 18 Apr 2017 08:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6599; q=dns/txt; s=iport; t=1492530941; x=1493740541; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h/5A+pZy8TliwV5RvAm8+ZUnD3HS0zB3XKG1y3rEyUk=; b=PAs3m2TJfGXvH/soYHjAAynvh+JiK9yId2VLveec4i6h4C6sFKNdvleX 5l5mbk/+qDjKXlZNTEROOi8tJxbIKSF+7bEfdpLFWzjPMih19L5wJRtvV qoqBVjYP86EWk5Uj4MBaj91u03Vn8rVWbtiQXPz1wgA18tp7YDpJ/w4xg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAADMNfZY/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygrYYELB410kWOVYYIPIQuFeAKDdD8YAQIBAQEBAQEBax0LhRU?= =?us-ascii?q?BAQEBAQIBATg0CwwEAgEIEQQBAR8JBycLFAkIAQEEDgUIihEOrS+LIwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFhlKBXYMYhCkRAYYBBZ0iAYcDgy2IMIIJhTGKF4h?= =?us-ascii?q?riyIBHzh9CGMVRIRmHIFjdQGGXIEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="scan'208";a="412283509" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Apr 2017 15:55:40 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3IFteE7014482 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Apr 2017 15:55:40 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Apr 2017 10:55:39 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 18 Apr 2017 10:55:39 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" CC: RTGWG Subject: RE: draft-ietf-rtgwg-spf-uloop-pb-statement Thread-Topic: draft-ietf-rtgwg-spf-uloop-pb-statement Thread-Index: AdK4TvWsFJesfB3VR0O6fiH/OAGmKgACKmIg Date: Tue, 18 Apr 2017 15:55:39 +0000 Message-ID: <6b495d33c4e047b3adb87ff088beff7f@XCH-ALN-001.cisco.com> References: <25494_1492526556_58F625DC_25494_1788_1_53C29892C857584299CBF5D05346208A31CBAD4A@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <25494_1492526556_58F625DC_25494_1788_1_53C29892C857584299CBF5D05346208A31CBAD4A@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.152.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 15:55:43 -0000 Bruno - The discussion here is a pragmatic one. As draft-ietf-rtgwg-backoff-algo is a Standards track document the implicat= ion of it becoming an RFC is that everyone SHOULD/MUST implement it. Given that today vendors have implemented their own variations of SPF backo= ff, in order to justify requiring the use of a standardized algorithm it MU= ST be demonstrated that it makes a significant difference when used in real= world deployments with timer values that are consistent with existing depl= oyments. I think we agree on the following: 1)For a single topology change only the initial delay comes into play, so = no benefits are expected from having a standardized algorithm 2)For multiple topology changes in a short period of time (i.e. within SHOR= T_SPF_DELAY as defined in the draft) the benefits of syncing the start of a= second SPF in the control plane may be dwarfed by the time it takes to upd= ate the forwarding. In all the studies I am familiar with, the contribution of control plane wo= rk (routing update processing, SPF, RIB update) is under 30% of the total t= ime required for convergence. The remainder is the time it takes to actuall= y update the forwarding plane. So, what I am asking is that BEFORE the draft becomes an RFC that real worl= d data be gathered demonstrating the benefits of the standardized algorithm= in the cases where it might matter. I think the right set of test cases wo= uld include: o Timers in the range recommended by the draft - but also consistent wit= h fast convergence (INITIAL delay sub 50 ms, SHORT_DELAY on the order of 10= 0 ms or less) o Multiple topology changes which trigger multiple SPFs=20 o A mixture of forwarding plane updates speeds in the affected nodes in t= he network o Comparison of results using all standardized algorithm and a mixture of= vendor specific algorithms Based on these results we can then determine whether it is beneficial to pr= ogress the draft. Les > -----Original Message----- > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > Sent: Tuesday, April 18, 2017 7:43 AM > To: Les Ginsberg (ginsberg) > Cc: RTGWG > Subject: draft-ietf-rtgwg-spf-uloop-pb-statement >=20 > Changing the subject of the thread. >=20 > Hi Les, >=20 > As a follow up on the discussion >=20 > > From: Les Ginsberg (ginsberg) > Sent: Tuesday, April 18, 2017 2:56 AM > > > > In regards to the discussion regarding " draft-ietf-rtgwg-spf-uloop-pb= - > statement" I am > quoted as saying: > > > > " Les: most of the analysis that I am aware of - > the largest contri= butor is > the control plane." > > > > In actuality what I said (or at least intended to say :-) ) was that t= he largest > contributor is the > data plane (NOT the control plane). > > > > The point of the exchange between Bruno and myself was to emphaisze > the point that > demonstrating the real world benefits of the standardiz= ed > backoff algorithm should include > cases where forwarding plane update > speeds are different on different nodes in the > topology. It is possibl= e that > better synchronization of the control plane execution times > (which is= what > use of a consistent backoff algorithm is likely to provide) may not mean = much > > in cases where forwarding plane update speeds are significantly differe= nt > on different > nodes and/or when forwarding plane update speeds > consume much more time than the > control plane SPF/RIB updates. The > latter case is quite common. >=20 > A few points/comments, >=20 > - IMHO, your request seems more related to the problem statement draft. > https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-03 If > you could comment the draft in order to improve it, this would probably > speed up the discussion. > - You are right that the IGP fast convergence, following a single failure= , is > mostly due to the time needed to update the FIB on line cards. However, a= s > the SPF back-off algo kicks in, this is changing, and differences in spf = delay > algo brings a significant delta. cf slide 6 of the slides presented in IE= TF 90 > https://www.ietf.org/proceedings/90/slides/slides-90-rtgwg-2.pdf You may > also review the whole presentation; not because you would learn anything, > but may be to ease the identification of the parts where we may have a > different opinion. (at this point, I'm not seeing real disagreement). > - Do we agree that having different SPF delay algo across one network, is= not > a feature but a bug? IOW, there is value in standardizing one. >=20 > Regards, > --Bruno >=20 >=20 > > Les > > > > > > > -----Original Message----- > > > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Jeff Tantsu= ra > > > Sent: Thursday, April 13, 2017 4:09 PM > > To: RTGWG > > Cc: rtgwg- > chairs > > Subject: RTGWG minutes IETF98 > > > > Hi, > > > > The min= utes > have been published at: > > > https://datatracker.ietf.org/doc/minutes-98-rtgwg/ > > > Please provide your comments. > > > > > > Thanks! > > > Jeff & Chris > > > > > > > > > > > > _______________________________________________ > > > rtgwg mailing list > > > rtgwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. From nobody Tue Apr 18 09:41:10 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C995912EC18 for ; Tue, 18 Apr 2017 09:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk2DXEdMAKDf for ; Tue, 18 Apr 2017 09:41:04 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4471812EC9E for ; Tue, 18 Apr 2017 09:41:04 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id B310C120166; Tue, 18 Apr 2017 18:41:02 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 92ED816005E; Tue, 18 Apr 2017 18:41:02 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 18:41:02 +0200 From: To: "Les Ginsberg (ginsberg)" CC: RTGWG Subject: RE: draft-ietf-rtgwg-spf-uloop-pb-statement Thread-Topic: draft-ietf-rtgwg-spf-uloop-pb-statement Thread-Index: AdK4TvWsFJesfB3VR0O6fiH/OAGmKgACKmIgAAFjrzA= Date: Tue, 18 Apr 2017 16:41:02 +0000 Message-ID: <11399_1492533662_58F6419E_11399_16912_1_53C29892C857584299CBF5D05346208A31CBB091@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <25494_1492526556_58F625DC_25494_1788_1_53C29892C857584299CBF5D05346208A31CBAD4A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <6b495d33c4e047b3adb87ff088beff7f@XCH-ALN-001.cisco.com> In-Reply-To: <6b495d33c4e047b3adb87ff088beff7f@XCH-ALN-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 16:41:07 -0000 Les, > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Tuesda= y, April 18, 2017 5:56 PM >=20 > Bruno - >=20 > The discussion here is a pragmatic one. That would be good indeed. =20 > As draft-ietf-rtgwg-backoff-algo is a Standards track document the impli= cation of it becoming > an RFC is that everyone SHOULD/MUST implement it. No. I'm not aware that everyone SHOULD/MUST implement all IETF standard track R= FC. =20 > Given that today vendors have implemented their own variations of SPF ba= ckoff, in order to > justify requiring the use of a standardized algorithm it MUST be demonst= rated that it makes > a significant difference when used in real world deployments with timer = values that are > consistent with existing deployments. You are mixing implementation consideration with IETF considerations. >From an IETF standpoint, in order to maximize the chance to have all (link = state) IGP node to compute their SPF at the same time and using the same LS= DB, we need nodes to have a consistent SPF delay algo. >From an implementation standpoint, we this draft has 3 implementations. > I think we agree on the following: >=20 > 1)For a single topology change only the initial delay comes into play, = so no benefits are > expected from having a standardized algorithm =20 I agree for a single link failure. I disagree for other single failure, e.g. node failures and SRLG failures w= here multiple link state messages are involved from multiple nodes. Dependi= ng on differences in detection time, distance from the failure, flooding im= plementations long the way, SPF delay timers (..) multiple SPF may be invol= ved for a single topological change. (by "topology change" I assume that you mean the real/physical topology of = the network, note the possibly N topological change that the IGP can see, d= epending on the configured SPF delays) =20 > 2)For multiple topology changes in a short period of time (i.e. within S= HORT_SPF_DELAY as > defined in the draft) the benefits of syncing the start of a second SPF = in the control plane > may be dwarfed by the time it takes to update the forwarding. >=20 > In all the studies I am familiar with, the contribution of control plane= work (routing update > processing, SPF, RIB update) is under 30% of the total time required for= convergence. The > remainder is the time it takes to actually update the forwarding plane. =20 As already stated, I agree for some specific cases (e.g. first SPF) but not= in the general case: 1) FIB update time IMHO, the reference person for IGP Fast Convergence in the industry would b= e Clarence Filsfils. As a matter of luck for this discussion, both of you a= re in same organization and working on the same plateform, so this would ea= se similar point of view. - BTW, you can note that he co-auteurs this draft. - IMHO, a reasonable paper on this would be https://pdfs.semanticscholar.or= g/0deb/57cc07a36cf1ea5ba0b3482bf14f2e8bb60d.pdf (also from Clarence). Note also that the paper is a bit old, and in the meantime both hardware an= d software have improved. But even at this time, FIB update time for 1000 I= GP prefixes is/was around 300 ms (pecentil 90). Note that what matter are the "important" IGP prefixes which attract the cu= stomer's traffic. In short, this means the loopback of the router (used as = BGP Next-Hop). So here, I'm taking the example of a IGP with 1000 nodes, wh= ich is a significant scaling. 2) SPF delay A presented in slide 6 of the slides presented in IETF 90 (https://www.ietf= .org/proceedings/90/slides/slides-90-rtgwg-2.pdf ) SPF delay can easily be = higher than 300ms. =20 > So, what I am asking is that BEFORE the draft becomes an RFC that real w= orld data be > gathered demonstrating the benefits of the standardized algorithm in the= cases where it > might matter. I'm not aware that RTGWG WG requires deployment data are a prerequisite for= RFC publication. Even implementations is not a pre-requisite (this has bee= n discussed by the chairs a few month ago), but here, we do have 3 implemen= tations. That being said, IMHO the above data is real. > I think the right set of test cases would include: >=20 > o Timers in the range recommended by the draft - but also consistent = with fast > convergence (INITIAL delay sub 50 ms, SHORT_DELAY on the order of 100 ms= or less) > o Multiple topology changes which trigger multiple SPFs > o A mixture of forwarding plane updates speeds in the affected nodes i= n the network > o Comparison of results using all standardized algorithm and a mixture= of vendor specific > algorithms >=20 > Based on these results we can then determine whether it is beneficial to= progress the draft. Let me restate a question that you have not answered so far: - Do we agree that having different SPF delay algo across one network, is n= ot a feature but a bug? --Bruno >=20 > Les >=20 >=20 > > -----Original Message----- > > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > > Sent: Tuesday, April 18, 2017 7:43 AM > > To: Les Ginsberg (ginsberg) > > Cc: RTGWG > > Subject: draft-ietf-rtgwg-spf-uloop-pb-statement > > > > Changing the subject of the thread. > > > > Hi Les, > > > > As a follow up on the discussion > > > > > From: Les Ginsberg (ginsberg) > Sent: Tuesday, April 18, 2017 2:56 = AM > > > > > > In regards to the discussion regarding " draft-ietf-rtgwg-spf-uloop= -pb- > > statement" I am > quoted as saying: > > > > > > " Les: most of the analysis that I am aware of - > the largest con= tributor is > > the control plane." > > > > > > In actuality what I said (or at least intended to say :-) ) was tha= t the largest > > contributor is the > data plane (NOT the control plane). > > > > > > The point of the exchange between Bruno and myself was to emphaisze > > the point that > demonstrating the real world benefits of the standar= dized > > backoff algorithm should include > cases where forwarding plane update > > speeds are different on different nodes in the > topology. It is poss= ible that > > better synchronization of the control plane execution times > (which= is what > > use of a consistent backoff algorithm is likely to provide) may not me= an much > > > in cases where forwarding plane update speeds are significantly diff= erent > > on different > nodes and/or when forwarding plane update speeds > > consume much more time than the > control plane SPF/RIB updates. The > > latter case is quite common. > > > > A few points/comments, > > > > - IMHO, your request seems more related to the problem statement draft. > > https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-03= If > > you could comment the draft in order to improve it, this would probably > > speed up the discussion. > > - You are right that the IGP fast convergence, following a single fail= ure, is > > mostly due to the time needed to update the FIB on line cards. However= , as > > the SPF back-off algo kicks in, this is changing, and differences in s= pf delay > > algo brings a significant delta. cf slide 6 of the slides presented in= IETF 90 > > https://www.ietf.org/proceedings/90/slides/slides-90-rtgwg-2.pdf You = may > > also review the whole presentation; not because you would learn anythi= ng, > > but may be to ease the identification of the parts where we may have a > > different opinion. (at this point, I'm not seeing real disagreement). > > - Do we agree that having different SPF delay algo across one network,= is not > > a feature but a bug? IOW, there is value in standardizing one. > > > > Regards, > > --Bruno > > > > > > > Les > > > > > > > > > > -----Original Message----- > > > > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Jeff Tan= tsura > > > > Sent: Thursday, April 13, 2017 4:09 PM > > To: RTGWG > > Cc: rtg= wg- > > chairs > > Subject: RTGWG minutes IETF98 > > > > Hi, > > > > The = minutes > > have been published at: > > > > https://datatracker.ietf.org/doc/minutes-98-rtgwg/ > > > > Please provide your comments. > > > > > > > > Thanks! > > > > Jeff & Chris > > > > > > > > > > > > > > > > _______________________________________________ > > > > rtgwg mailing list > > > > rtgwg@ietf.org > > > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > > > _______________________________________________ > > > rtgwg mailing list > > > rtgwg@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > __________________________________________________________ > > __________________________________________________________ > > _____ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, = exploites > > ou copies sans autorisation. Si vous avez recu ce message par erreur, = veuillez > > le signaler a l'expediteur et le detruire ainsi que les pieces jointes= . Les > > messages electroniques etant susceptibles d'alteration, Orange decline= toute > > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > > information that may be protected by law; they should not be distribut= ed, > > used or copied without authorisation. > > If you have received this email in error, please notify the sender and= delete > > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have = been > > modified, changed or falsified. > > Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Apr 18 14:39:45 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDDA12EB22; Tue, 18 Apr 2017 14:39:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-yang-key-chain-20.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149255158352.29090.2884239698023485481@ietfa.amsl.com> Date: Tue, 18 Apr 2017 14:39:43 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 21:39:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Routing Key Chain YANG Data Model Authors : Acee Lindem Yingzhen Qu Derek Yeung Ing-Wher Chen Jeffrey Zhang Filename : draft-ietf-rtgwg-yang-key-chain-20.txt Pages : 23 Date : 2017-04-18 Abstract: This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. In some applications, the protocols do not use the key chain element key directly, but rather a key derivation function is used to derive a short-lived key from the key chain element key (e.g., the Master Keys used in the TCP Authentication Option(TCP-AO)). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-20 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-key-chain-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-yang-key-chain-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 18 14:41:24 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD94127A97 for ; Tue, 18 Apr 2017 14:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.502 X-Spam-Level: X-Spam-Status: No, score=-13.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7V22Bg8M8pn for ; Tue, 18 Apr 2017 14:41:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17CF127977 for ; Tue, 18 Apr 2017 14:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3482; q=dns/txt; s=iport; t=1492551680; x=1493761280; h=from:cc:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2vpXtR3oLXaHGazwCBjZXojiWRu/DOOBku6zs8Z7yMw=; b=dEFsOtKqoFOLkBEqmfya36DhtBZrRmAAZA2T3w4koDrvDdrJ53PHNZsR dRMXQMio3zCBXlCnmYy9mIxvaz2Bs18QKIq+yP53t/NBVrHO4u/2YemSW c6o5iCSwD+2mafOSZ81Jww5phr4zJDL7BmU2bpWC2SkG3Qyeaq9VNZUAX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AQAoh/ZY/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhfQ4Hg1+KFZEzlhCCDyENhXYCGgyDUD8YAQIBAQEBAQEBayi?= =?us-ascii?q?FDQkCAQMBASEROgsQAgEIEggCJgICAiULFQIOAhIFhXKEJw6sDYImiy8BAQEBA?= =?us-ascii?q?QEEAQEBAQEBASGBC4ckgxiDGIE/gwYSgk0FnSIBhwOLZoIAVYRciheUDQEfOIE?= =?us-ascii?q?FYxUaKmgMhXF1h36BDQEBBQ?= X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="scan'208";a="237549219" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2017 21:41:19 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v3ILfJYN010612 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Apr 2017 21:41:19 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Apr 2017 17:41:18 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 18 Apr 2017 17:41:18 -0400 From: "Acee Lindem (acee)" CC: "rtgwg@ietf.org" Subject: Re: I-D Action: draft-ietf-rtgwg-yang-key-chain-20.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-yang-key-chain-20.txt Thread-Index: AQHSuIyD4r+ZarfKRk2bCd6jNZqY6g== Date: Tue, 18 Apr 2017 21:41:18 +0000 Message-ID: References: <149255158352.29090.2884239698023485481@ietfa.amsl.com> In-Reply-To: <149255158352.29090.2884239698023485481@ietfa.amsl.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.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <9A849A0D04FAFB42BED2313A010E055B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 21:41:22 -0000 VGhpcyB2ZXJzaW9uIGNvbmZvcm1zIHRvIHRoZSBOZXR3b3JrIE1hbmFnZW1lbnQgRGF0YXN0b3Jl IEFyY2hpdGVjdHVyZQ0KKE5ETUEpIHJlY29tbWVuZGF0aW9ucyBmb3IgbW9kZWwgc3RydWN0dXJp bmcuDQoNClRoYW5rcywNCkFjZWUgDQoNCk9uIDQvMTgvMTcsIDU6MzkgUE0sICJydGd3ZyBvbiBi ZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIg0KPHJ0Z3dnLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCj4NCj5B IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMNCj5kaXJlY3Rvcmllcy4NCj5UaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBSb3V0aW5nIEFyZWEgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgIFRp dGxlICAgICAgICAgICA6IFJvdXRpbmcgS2V5IENoYWluIFlBTkcgRGF0YSBNb2RlbA0KPiAgICAg ICAgQXV0aG9ycyAgICAgICAgIDogQWNlZSBMaW5kZW0NCj4gICAgICAgICAgICAgICAgICAgICAg ICAgIFlpbmd6aGVuIFF1DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBEZXJlayBZZXVuZw0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgSW5nLVdoZXIgQ2hlbg0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgSmVmZnJleSBaaGFuZw0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LXJ0Z3dnLXlhbmcta2V5LWNoYWluLTIwLnR4dA0KPglQYWdlcyAgICAgICAgICAgOiAyMw0KPglE YXRlICAgICAgICAgICAgOiAyMDE3LTA0LTE4DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgdGhlIGtleSBjaGFpbiBZQU5HIGRhdGEgbW9kZWwuICBLZXkgY2hhaW5z DQo+ICAgYXJlIGNvbW1vbmx5IHVzZWQgZm9yIHJvdXRpbmcgcHJvdG9jb2wgYXV0aGVudGljYXRp b24gYW5kIG90aGVyDQo+ICAgYXBwbGljYXRpb25zIHJlcXVpcmluZyBzeW1tZXRyaWMga2V5cy4g IEEga2V5IGNoYWluIGlzIGEgbGlzdCBvZg0KPiAgIGVsZW1lbnRzIGVhY2ggY29udGFpbmluZyBh IGtleSBzdHJpbmcsIHNlbmQgbGlmZXRpbWUsIGFjY2VwdA0KPiAgIGxpZmV0aW1lLCBhbmQgYWxn b3JpdGhtIChhdXRoZW50aWNhdGlvbiBvciBlbmNyeXB0aW9uKS4gIEJ5IHByb3Blcmx5DQo+ICAg b3ZlcmxhcHBpbmcgdGhlIHNlbmQgYW5kIGFjY2VwdCBsaWZldGltZXMgb2YgbXVsdGlwbGUga2V5 IGNoYWluDQo+ICAgZWxlbWVudHMsIGtleSBzdHJpbmdzIGFuZCBhbGdvcml0aG1zIG1heSBiZSBn cmFjZWZ1bGx5IHVwZGF0ZWQuICBCeQ0KPiAgIHJlcHJlc2VudGluZyB0aGVtIGluIGEgWUFORyBk YXRhIG1vZGVsLCBrZXkgZGlzdHJpYnV0aW9uIGNhbiBiZQ0KPiAgIGF1dG9tYXRlZC4NCj4NCj4g ICBJbiBzb21lIGFwcGxpY2F0aW9ucywgdGhlIHByb3RvY29scyBkbyBub3QgdXNlIHRoZSBrZXkg Y2hhaW4gZWxlbWVudA0KPiAgIGtleSBkaXJlY3RseSwgYnV0IHJhdGhlciBhIGtleSBkZXJpdmF0 aW9uIGZ1bmN0aW9uIGlzIHVzZWQgdG8gZGVyaXZlDQo+ICAgYSBzaG9ydC1saXZlZCBrZXkgZnJv bSB0aGUga2V5IGNoYWluIGVsZW1lbnQga2V5IChlLmcuLCB0aGUgTWFzdGVyDQo+ICAgS2V5cyB1 c2VkIGluIHRoZSBUQ1AgQXV0aGVudGljYXRpb24gT3B0aW9uKFRDUC1BTykpLg0KPg0KPg0KPlRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hh aW4vDQo+DQo+VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0K Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNo YWluLTIwDQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LXJ0Z3dnLXlhbmcta2V5LWNoYWluLTIwDQo+DQo+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluLTIwDQo+DQo+DQo+UGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5z dWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy8NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPnJ0Z3dnIG1haWxpbmcgbGlzdA0KPnJ0Z3dnQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3Zw0KDQo= From nobody Tue Apr 18 20:05:41 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BC9129417 for ; Tue, 18 Apr 2017 20:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO8KooYWDiK4 for ; Tue, 18 Apr 2017 20:05:36 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F99E128D44 for ; Tue, 18 Apr 2017 20:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14317; q=dns/txt; s=iport; t=1492571121; x=1493780721; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=25Cwjb+AmRnYl852nZuAond+mRT6RL6xjv9W9DoK1e0=; b=lDP8DsURe3RfSjzTAhvkx1ZTdnAYO/vRQxo7YAMOHbabY0HeYQR5UVdh M7jUa/O4CnbegRIJJHIvHctkFhmMKUWv0llxU6SWZcJLVlA8/y45x4tfX ikV5ScgGbdWAlZxivhOAc9NecbiHHLbauKLC46rJGjWxeAlBkHeLF45Fs s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAADV0vZY/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgygrYYELB411kWKVYYIPIQuCQoM2AoN2PxgBAgEBAQEBAQFrHQu?= =?us-ascii?q?FFQEBAQEBAgEBODQLDAQCAQgRBAEBHwkHJwsUCQgBAQQOBQiKEQ6uG4swAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWGUoFdgxiEKREBhgEFnSIBhwODLYgwggmFMYo?= =?us-ascii?q?XiGuLIgEfOH0IYxVEgiSCQhyBY3UBBIZigSEBgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="scan'208";a="414366666" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 03:05:19 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3J35JiV015713 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Apr 2017 03:05:19 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Apr 2017 22:05:19 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 18 Apr 2017 22:05:19 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" CC: RTGWG Subject: RE: draft-ietf-rtgwg-spf-uloop-pb-statement Thread-Topic: draft-ietf-rtgwg-spf-uloop-pb-statement Thread-Index: AdK4TvWsFJesfB3VR0O6fiH/OAGmKgACKmIgAAFjrzAAFlHE0A== Date: Wed, 19 Apr 2017 03:05:18 +0000 Message-ID: References: <25494_1492526556_58F625DC_25494_1788_1_53C29892C857584299CBF5D05346208A31CBAD4A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <6b495d33c4e047b3adb87ff088beff7f@XCH-ALN-001.cisco.com> <11399_1492533662_58F6419E_11399_16912_1_53C29892C857584299CBF5D05346208A31CBB091@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <11399_1492533662_58F6419E_11399_16912_1_53C29892C857584299CBF5D05346208A31CBB091@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.146.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 03:05:39 -0000 Bruno - We have no disagreement regarding the content of draft-ietf-rtgwg-backoff-a= lgo - what I am concerned about is the intent of the draft. I see two possi= bilities. 1)This is an Informational draft which provides a discussion of what is nee= ded to achieve both fast convergence and stability - and defines an exampl= e set of configuration parameters and the method to use them in order to ac= hieve the goal. This is non-normative and allows that other means of achieving the same res= ult are both possible and allowed. If that were the case I would have no fu= rther concerns. 2)This is a Standards track draft whose intent is to - over time - require = all implementations to use the exact mechanisms defined in the draft. As the draft is positioned as a Standards track document I assume your inte= nt is the latter. In which case we have to consider the existence of multip= le long-lived implementations which are using a different set of parameters= /implementation (e.g. exponential backoff) to achieve the fast convergence = behavior described in the paper you reference below. These implementations = have been proven successful. Before we require them to be changed I think i= t is prudent to demonstrate empirically - not merely by analysis - that a d= eployment where some implementations use the mechanisms defined in the draf= t and some use a proven alternative will result in significantly degraded c= onvergence in real world failure scenarios. If we do not do this then we ar= e imposing requirements on vendors and customers alike which are not proven= to yield improvement. I therefore have suggested testing involving: o Timers in the range recommended by the draft - but also consistent wit= h fast convergence (INITIAL delay sub 50 ms, SHORT_DELAY on the order of 10= 0 ms or less) o Scenarios with multiple topology changes which trigger multiple SPFs in= a short period of time o A mixture of routers with varying forwarding plane update speeds on the= affected nodes in the network o Comparison of results using all standardized algorithm and a mixture of= vendor specific algorithms and standard algorithm This is not an argument against the content of the draft - just a request t= o do due diligence. Does anyone have such data? Les > -----Original Message----- > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of > bruno.decraene@orange.com > Sent: Tuesday, April 18, 2017 9:41 AM > To: Les Ginsberg (ginsberg) > Cc: RTGWG > Subject: RE: draft-ietf-rtgwg-spf-uloop-pb-statement >=20 > Les, >=20 > > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: > Tuesday, April 18, 2017 5:56 PM > > > > Bruno - > > > > The discussion here is a pragmatic one. >=20 > That would be good indeed. >=20 >=20 > > As draft-ietf-rtgwg-backoff-algo is a Standards track document the > implication of it becoming > > an RFC is that everyone SHOULD/MUST implement it. >=20 > No. > I'm not aware that everyone SHOULD/MUST implement all IETF standard > track RFC. >=20 >=20 > > Given that today vendors have implemented their own variations of SPF > backoff, in order to > > justify requiring the use of a standardized algorithm it MUST be > demonstrated that it makes > > a significant difference when used in real world deployments with time= r > values that are > > consistent with existing deployments. >=20 > You are mixing implementation consideration with IETF considerations. > >From an IETF standpoint, in order to maximize the chance to have all (li= nk > state) IGP node to compute their SPF at the same time and using the same > LSDB, we need nodes to have a consistent SPF delay algo. > >From an implementation standpoint, we this draft has 3 implementations. >=20 > > I think we agree on the following: > > > > 1)For a single topology change only the initial delay comes into play= , so no > benefits are > > expected from having a standardized algorithm >=20 > I agree for a single link failure. > I disagree for other single failure, e.g. node failures and SRLG failures= where > multiple link state messages are involved from multiple nodes. Depending = on > differences in detection time, distance from the failure, flooding > implementations long the way, SPF delay timers (..) multiple SPF may be > involved for a single topological change. >=20 > (by "topology change" I assume that you mean the real/physical topology o= f > the network, note the possibly N topological change that the IGP can see, > depending on the configured SPF delays) >=20 >=20 > > 2)For multiple topology changes in a short period of time (i.e. within > SHORT_SPF_DELAY as > > defined in the draft) the benefits of syncing the start of a second SP= F in > the control plane > > may be dwarfed by the time it takes to update the forwarding. > > > > In all the studies I am familiar with, the contribution of control pla= ne work > (routing update > > processing, SPF, RIB update) is under 30% of the total time required f= or > convergence. The > > remainder is the time it takes to actually update the forwarding plane= . >=20 > As already stated, I agree for some specific cases (e.g. first SPF) but n= ot in the > general case: >=20 > 1) FIB update time > IMHO, the reference person for IGP Fast Convergence in the industry would > be Clarence Filsfils. As a matter of luck for this discussion, both of yo= u are in > same organization and working on the same plateform, so this would ease > similar point of view. > - BTW, you can note that he co-auteurs this draft. > - IMHO, a reasonable paper on this would be > https://pdfs.semanticscholar.org/0deb/57cc07a36cf1ea5ba0b3482bf14f2e8b > b60d.pdf (also from Clarence). >=20 > Note also that the paper is a bit old, and in the meantime both hardware = and > software have improved. But even at this time, FIB update time for 1000 I= GP > prefixes is/was around 300 ms (pecentil 90). > Note that what matter are the "important" IGP prefixes which attract the > customer's traffic. In short, this means the loopback of the router (used= as > BGP Next-Hop). So here, I'm taking the example of a IGP with 1000 nodes, > which is a significant scaling. >=20 > 2) SPF delay > A presented in slide 6 of the slides presented in IETF 90 > (https://www.ietf.org/proceedings/90/slides/slides-90-rtgwg-2.pdf ) SPF > delay can easily be higher than 300ms. >=20 >=20 > > So, what I am asking is that BEFORE the draft becomes an RFC that real > world data be > > gathered demonstrating the benefits of the standardized algorithm in t= he > cases where it > > might matter. >=20 > I'm not aware that RTGWG WG requires deployment data are a prerequisite > for RFC publication. Even implementations is not a pre-requisite (this ha= s > been discussed by the chairs a few month ago), but here, we do have 3 > implementations. > That being said, IMHO the above data is real. >=20 > > I think the right set of test cases would include: > > > > o Timers in the range recommended by the draft - but also consisten= t > with fast > > convergence (INITIAL delay sub 50 ms, SHORT_DELAY on the order of 100 > ms or less) > > o Multiple topology changes which trigger multiple SPFs > > o A mixture of forwarding plane updates speeds in the affected nodes= in > the network > > o Comparison of results using all standardized algorithm and a mixtu= re of > vendor specific > > algorithms > > > > Based on these results we can then determine whether it is beneficial = to > progress the draft. >=20 > Let me restate a question that you have not answered so far: > - Do we agree that having different SPF delay algo across one network, is= not > a feature but a bug? >=20 > --Bruno >=20 > > > > Les > > > > > > > -----Original Message----- > > > From: bruno.decraene@orange.com > [mailto:bruno.decraene@orange.com] > > > Sent: Tuesday, April 18, 2017 7:43 AM > > > To: Les Ginsberg (ginsberg) > > > Cc: RTGWG > > > Subject: draft-ietf-rtgwg-spf-uloop-pb-statement > > > > > > Changing the subject of the thread. > > > > > > Hi Les, > > > > > > As a follow up on the discussion > > > > > > > From: Les Ginsberg (ginsberg) > Sent: Tuesday, April 18, 2017 2:5= 6 AM > > > > > > > > In regards to the discussion regarding " draft-ietf-rtgwg-spf-ulo= op-pb- > > > statement" I am > quoted as saying: > > > > > > > > " Les: most of the analysis that I am aware of - > the largest > contributor is > > > the control plane." > > > > > > > > In actuality what I said (or at least intended to say :-) ) was t= hat the > largest > > > contributor is the > data plane (NOT the control plane). > > > > > > > > The point of the exchange between Bruno and myself was to > emphaisze > > > the point that > demonstrating the real world benefits of the > standardized > > > backoff algorithm should include > cases where forwarding plane upd= ate > > > speeds are different on different nodes in the > topology. It is po= ssible > that > > > better synchronization of the control plane execution times > (whi= ch is > what > > > use of a consistent backoff algorithm is likely to provide) may not = mean > much > > > > in cases where forwarding plane update speeds are significantly > different > > > on different > nodes and/or when forwarding plane update speeds > > > consume much more time than the > control plane SPF/RIB updates. > The > > > latter case is quite common. > > > > > > A few points/comments, > > > > > > - IMHO, your request seems more related to the problem statement > draft. > > > https://tools.ietf.org/html/draft-ietf-rtgwg-spf-uloop-pb-statement-= 03 > If > > > you could comment the draft in order to improve it, this would proba= bly > > > speed up the discussion. > > > - You are right that the IGP fast convergence, following a single fa= ilure, is > > > mostly due to the time needed to update the FIB on line cards. Howev= er, > as > > > the SPF back-off algo kicks in, this is changing, and differences in= spf > delay > > > algo brings a significant delta. cf slide 6 of the slides presented = in IETF 90 > > > https://www.ietf.org/proceedings/90/slides/slides-90-rtgwg-2.pdf Yo= u > may > > > also review the whole presentation; not because you would learn > anything, > > > but may be to ease the identification of the parts where we may have= a > > > different opinion. (at this point, I'm not seeing real disagreement)= . > > > - Do we agree that having different SPF delay algo across one networ= k, is > not > > > a feature but a bug? IOW, there is value in standardizing one. > > > > > > Regards, > > > --Bruno > > > > > > > > > > Les > > > > > > > > > > > > > -----Original Message----- > > > > > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Jeff > Tantsura > > > > > Sent: Thursday, April 13, 2017 4:09 PM > > To: RTGWG > > Cc: r= tgwg- > > > chairs > > Subject: RTGWG minutes IETF98 > > > > Hi, > > > > Th= e > minutes > > > have been published at: > > > > > https://datatracker.ietf.org/doc/minutes-98-rtgwg/ > > > > > Please provide your comments. > > > > > > > > > > Thanks! > > > > > Jeff & Chris > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rtgwg mailing list > > > > > rtgwg@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > > > > > _______________________________________________ > > > > rtgwg mailing list > > > > rtgwg@ietf.org > > > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > > > > __________________________________________________________ > > > > __________________________________________________________ > > > _____ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses= , > exploites > > > ou copies sans autorisation. Si vous avez recu ce message par erreur= , > veuillez > > > le signaler a l'expediteur et le detruire ainsi que les pieces joint= es. Les > > > messages electroniques etant susceptibles d'alteration, Orange decli= ne > toute > > > responsabilite si ce message a ete altere, deforme ou falsifie. Merc= i. > > > > > > This message and its attachments may contain confidential or privile= ged > > > information that may be protected by law; they should not be > distributed, > > > used or copied without authorisation. > > > If you have received this email in error, please notify the sender a= nd > delete > > > this message and its attachments. > > > As emails may be altered, Orange is not liable for messages that hav= e > been > > > modified, changed or falsified. > > > Thank you. >=20 >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From nobody Thu Apr 20 20:43:29 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A569D126D85; Thu, 20 Apr 2017 20:43:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: akatlas@gmail.com, jefftant.ietf@gmail.com, rtgwg-chairs@ietf.org, rtgwg@ietf.org Subject: rtgwg - New Meeting Session Request for IETF 99 X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149274620758.22359.5208014587631494622.idtracker@ietfa.amsl.com> Date: Thu, 20 Apr 2017 20:43:27 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 03:43:28 -0000 A new meeting session request has just been submitted by Jeff Tantsura, a Chair of the rtgwg working group. --------------------------------------------------------- Working Group Name: Routing Area Working Group Area Name: Routing Area Session Requester: Jeff Tantsura Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: isis mpls ospf pce idr spring Second Priority: bess bier teas ccamp i2rs Third Priority: bfd detnet lime nvo3 pim netmod netconf People who must be present: Alia Atlas Jeff Tantsura Chris Bowers Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Apr 21 08:30:13 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFCA12954A for ; Fri, 21 Apr 2017 08:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkwDAasIjW9l for ; Fri, 21 Apr 2017 08:30:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14B212954B for ; Fri, 21 Apr 2017 08:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13111; q=dns/txt; s=iport; t=1492788607; x=1493998207; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ET4NkbVcZnhj8VS/4WKD/+2tpRnTh69im4Gs4np6SlU=; b=XSsplyO4lld/R/VCSmA1C2cqK6Lp1UZADNw2kvhvwApgGyvqPIUnfQ/R FQrSy9xX5ztnf3NrvH0PlhXfQZ28kNhOpMELFq6HB17MEBHqlDscDFgPX SGz9Pj8bUsk70d4HVasrkcAuXjNPnqRC0839D6yOy0Qw7fVpbNQJjKoW9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAQAVJfpY/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm47K2GBDAeDYIoVkWmQL4U1gg8hAQqFeAIag3E/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAwEBIQpBGwIBCA4DAwEBASgDAgICJQsUCQgBAQQBEoocDqlEg?= =?us-ascii?q?iaLIQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2LFTSEbgkWglCCXwWdQQGHFotvggB?= =?us-ascii?q?VjwKIb4spAR84gQZjFUSEaRyBY3WIKYENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,230,1488844800"; d="scan'208,217";a="233651060" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2017 15:30:06 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3LFU6L8018178 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Apr 2017 15:30:06 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 21 Apr 2017 11:30:05 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 21 Apr 2017 11:30:05 -0400 From: "Acee Lindem (acee)" To: Susan Hares , "'Lou Berger'" , "rtgwg@ietf.org" Subject: Re: Question on draft-ietf-rtgwg-routing-types Thread-Topic: Question on draft-ietf-rtgwg-routing-types Thread-Index: AdKonyE6FQw1FFh9RqeyVcySd3MfCA== Date: Fri, 21 Apr 2017 15:30:05 +0000 Message-ID: References: <009201d2a8a2$2a9ac4c0$7fd04e40$@ndzh.com> <15b2f3d76e8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00bd01d2ae0e$b9fb1220$2df13660$@ndzh.com> In-Reply-To: <00bd01d2ae0e$b9fb1220$2df13660$@ndzh.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.116.152.197] Content-Type: multipart/alternative; boundary="_000_D51F9D15AA568aceeciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:30:12 -0000 --_000_D51F9D15AA568aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlLA0KDQpTaW5jZSB5b3UgYXJlIHJlZmVycmluZyB0byBSRkMgNDc2MCwgaXMgaXQgdGhl IFNBRklzIHRoYXQgeW91IHdvdWxkIGxpa2UgdG8gc2VlIGRlZmluZWQgaGVyZT8gT25lIHRoaW5n IHRoYXQgaXMgZGlmZmVyZW50IGZyb20gdGhlIElFVEYgc3R5bGUgaXMgdGhhdCBpZiBJIGFkZCB0 aGVzZSB0aGV5IHdpbGwgbm90IGJlIGFsbCB1cHBlciBjYXNlIGxpa2UgdGhleSBhcmUgaW4gdGhl IE9DIEJHUCB0eXBlcyBtb2RlbC4NCg0KQlRXLCB3aGF0IGlzIHRoZSB0YXJnZXQgdGltZWZyYW1l IGZvciBhbiB1cGRhdGUgb2YgdGhlIEJHUCBZQU5HIG1vZGVsPyBJIGtub3cgeW91IGhhZCBtZW50 aW9uZWQgaXQgd2FzIGluIHRoZSB3b3JrcyBpbiB0aGUgSURSIG1lZXRpbmcuDQoNClRoYW5rcywN CkFjZWUNCg0KRnJvbTogcnRnd2cgPHJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dn LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpo LmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgQXByaWwgNSwg MjAxNyBhdCA5OjE1IEFNDQpUbzogJ0xvdSBCZXJnZXInIDxsYmVyZ2VyQGxhYm4ubmV0PG1haWx0 bzpsYmVyZ2VyQGxhYm4ubmV0Pj4sIFJvdXRpbmcgV0cgPHJ0Z3dnQGlldGYub3JnPG1haWx0bzpy dGd3Z0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogUXVlc3Rpb24gb24gZHJhZnQtaWV0Zi1ydGd3 Zy1yb3V0aW5nLXR5cGVzDQoNCkxvdToNCg0KTGV0IG1lIHJlY2hlY2suICBJIHRob3VnaHQgdGhl cmUgd2FzIHNvbWV0aGluZyByZWxhdGluZyB0byB0aGUgTVAtQkdQIHRoYXQgd2FzIG5vdCBjb3Zl cmVkLiAgIEnigJlsbCBnZXQgYmFjayB0byB5b3UgYnkgVGh1cnNkYXkgYW0uDQoNClN1ZQ0KDQpG cm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0NClNlbnQ6IFN1bmRheSwg QXByaWwgMiwgMjAxNyAxMToxNyBBTQ0KVG86IFN1c2FuIEhhcmVzOyBydGd3Z0BpZXRmLm9yZzxt YWlsdG86cnRnd2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUXVlc3Rpb24gb24gZHJhZnQtaWV0 Zi1ydGd3Zy1yb3V0aW5nLXR5cGVzDQoNCg0KSGkgU3VlLA0KDQpJIHRvb2sgYW5vdGhlciBsb29r IGF0IGJncCB0eXBlcyBhbmQgdGhlIG9ubHkgdGhpbmcgdGhhdCBqdW1wcyBvdXQgYXQgbWUgYXMg Y29tbW9uIHRoYXQgaXNuJ3QgYWxyZWFkeSBjb3ZlcmVkIGlzIGVudW1lcmF0aW9uIG9mIHByb3Rv Y29scyAgKGZvciBwb3RlbnRpYWwgdXNlIGluIHJvdXRlIHJlZGlzdHJpYnV0aW9uIGFuZCBpbnRl cmZhY2UgY29uZmlnKS4gIFdlIGNhbiBjZXJ0YWlubHkgY29uc2lkZXIgdGhpcyBpZiB0aGlzIHdo YXQgeW91IHdlcmUgdGhpbmtpbmcgYWJvdXQuDQoNCkFyZSB0aGVyZSBhcmUgdHlwZXMgeW91IHRo aW5rIHdlIG92ZXJsb29rZWQ/DQoNCkxvdQ0KDQpPbiBNYXJjaCAyOSwgMjAxNyAxMTo0MToyNSBB TSAiU3VzYW4gSGFyZXMiIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+ IHdyb3RlOg0KUlRHV0cgRFQ6DQoNCkp1c3QgY3VyaW91cywgZGlkIHRoZSBEVCBjb25zaWRlciBC R1Agcm91dGluZyB0eXBlcz8gIElmIHNvLCB3aGVyZSBkaWQgeW91IGRlY2lkZSBCR1Agcm91dGlu ZyB0eXBlcyB3ZXJlIG5vdCBjb21tb24gcm91dGluZyB0eXBlcz8NCg0KU3VlDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Z3dnIG1haWxpbmcg bGlzdA0KcnRnd2dAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnJTQwaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQo= --_000_D51F9D15AA568aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <86133F8DF37A3944B56F65026CDA4414@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBTdWUsJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TaW5jZSB5b3UgYXJlIHJlZmVycmlu ZyB0byBSRkMgNDc2MCwgaXMgaXQgdGhlIFNBRklzIHRoYXQgeW91IHdvdWxkIGxpa2UgdG8gc2Vl IGRlZmluZWQgaGVyZT8gT25lIHRoaW5nIHRoYXQgaXMgZGlmZmVyZW50IGZyb20gdGhlIElFVEYg c3R5bGUgaXMgdGhhdCBpZiBJIGFkZCB0aGVzZSB0aGV5IHdpbGwgbm90IGJlIGFsbCB1cHBlciBj YXNlIGxpa2UgdGhleSBhcmUgaW4gdGhlIE9DIEJHUCB0eXBlcyBtb2RlbC4mbmJzcDs8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJUVywgd2hhdCBpcyB0aGUgdGFyZ2V0IHRpbWVmcmFt ZSBmb3IgYW4gdXBkYXRlIG9mIHRoZSBCR1AgWUFORyBtb2RlbD8gSSBrbm93IHlvdSBoYWQgbWVu dGlvbmVkIGl0IHdhcyBpbiB0aGUgd29ya3MgaW4gdGhlIElEUiBtZWV0aW5nLiZuYnNwOzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9O Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0 LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9S REVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6 IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsg Qk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPnJ0Z3dnICZsdDs8YSBocmVmPSJtYWls dG86cnRnd2ctYm91bmNlc0BpZXRmLm9yZyI+cnRnd2ctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpo LmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSwgQXByaWwgNSwgMjAxNyBhdCA5OjE1IEFN PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+J0xvdSBCZXJn ZXInICZsdDs8YSBocmVmPSJtYWlsdG86bGJlcmdlckBsYWJuLm5ldCI+bGJlcmdlckBsYWJuLm5l dDwvYT4mZ3Q7LCBSb3V0aW5nIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cnRnd2dAaWV0Zi5vcmci PnJ0Z3dnQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+U3ViamVjdDogPC9zcGFuPlJFOiBRdWVzdGlvbiBvbiBkcmFmdC1pZXRmLXJ0Z3dnLXJvdXRp bmctdHlwZXM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0i TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAj YjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYg eG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVD LWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3Jk IDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25z ICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TG91 OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TGV0IG1lIHJlY2hlY2suJm5i c3A7IEkgdGhvdWdodCB0aGVyZSB3YXMgc29tZXRoaW5nIHJlbGF0aW5nIHRvIHRoZSBNUC1CR1Ag dGhhdCB3YXMgbm90IGNvdmVyZWQuJm5ic3A7Jm5ic3A7IEnigJlsbCBnZXQgYmFjayB0byB5b3Ug YnkgVGh1cnNkYXkgYW0uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlN1 ZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 IFRhaG9tYSwgc2Fucy1zZXJpZjsiPiBMb3UgQmVyZ2VyIFs8YSBocmVmPSJtYWlsdG86bGJlcmdl ckBsYWJuLm5ldCI+bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ8L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFN1bmRheSwgQXByaWwgMiwgMjAxNyAxMToxNyBBTTxicj4NCjxiPlRvOjwvYj4gU3VzYW4g SGFyZXM7IDxhIGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+cnRnd2dAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBRdWVzdGlvbiBvbiBkcmFmdC1pZXRmLXJ0Z3dnLXJv dXRpbmctdHlwZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGkg U3VlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGlu Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSB0b29rIGFub3RoZXIgbG9vayBhdCBiZ3Ag dHlwZXMgYW5kIHRoZSBvbmx5IHRoaW5nIHRoYXQganVtcHMgb3V0IGF0IG1lIGFzIGNvbW1vbiB0 aGF0IGlzbid0IGFscmVhZHkgY292ZXJlZCBpcyBlbnVtZXJhdGlvbiBvZiBwcm90b2NvbHMmbmJz cDsgKGZvciBwb3RlbnRpYWwgdXNlIGluIHJvdXRlIHJlZGlzdHJpYnV0aW9uIGFuZCBpbnRlcmZh Y2UgY29uZmlnKS4mbmJzcDsgV2UgY2FuIGNlcnRhaW5seSBjb25zaWRlcg0KIHRoaXMgaWYgdGhp cyB3aGF0IHlvdSB3ZXJlIHRoaW5raW5nIGFib3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ QXJlIHRoZXJlIGFyZSB0eXBlcyB5b3UgdGhpbmsgd2Ugb3Zlcmxvb2tlZD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbiI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkxvdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MTAuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbToxMC4wcHQ7bWFyZ2luLWxlZnQ6MGluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+T24g TWFyY2ggMjksIDIwMTcgMTE6NDE6MjUgQU0gJnF1b3Q7U3VzYW4gSGFyZXMmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJlc0BuZHpoLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBncmF5IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNS4wcHQ7 bWFyZ2luLWxlZnQ6NC41cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJUR1dHIERUOiA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+SnVzdCBjdXJpb3VzLCBkaWQgdGhlIERUIGNvbnNpZGVyIEJHUCByb3V0 aW5nIHR5cGVzPyZuYnNwOyBJZiBzbywgd2hlcmUgZGlkIHlvdSBkZWNpZGUgQkdQIHJvdXRpbmcg dHlwZXMgd2VyZSBub3QgY29tbW9uIHJvdXRpbmcgdHlwZXM/ICZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5TdWUgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGd3ZyBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRnd2clNDBpZXRmLm9yZyI+cnRnd2dAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGd3ZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGd3Zzwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_D51F9D15AA568aceeciscocom_-- From nobody Fri Apr 21 10:59:44 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34359129B2F for ; Fri, 21 Apr 2017 10:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oitOglafyxfy for ; Fri, 21 Apr 2017 10:59:40 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10118.outbound.protection.outlook.com [40.107.1.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376C5128854 for ; Fri, 21 Apr 2017 10:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6yVOi7/2xoQueax7KfIn4AT8pL33IHLY0mmBZGOQj0Y=; b=fWjVf70AS1F7iGHqQ6E7tHzZveH2/rKPh+7ay87XQUuamaNl35kWuqcnQ/Fa6FX2Vctfia7yoR4Y4VaVlIUBdPYPyRcoOW2owctA8B/W8Rt15146SnZCv3wKt83iUzIOMq2jjel4qqrrYqzrEkrbJZt9aGc1+MwPZnVJEdom5g4= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by VI1PR0701MB2765.eurprd07.prod.outlook.com (10.173.81.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Fri, 21 Apr 2017 17:59:37 +0000 Message-ID: <037a01d2bac8$b8f42800$4001a8c0@gateway.2wire.net> From: t.petch To: Jeff Tantsura , RTGWG CC: rtgwg-chairs References: Subject: Query on Re: RTGWG minutes IETF98 Date: Fri, 21 Apr 2017 16:55:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: DB6P193CA0020.EURP193.PROD.OUTLOOK.COM (10.175.237.30) To VI1PR0701MB2765.eurprd07.prod.outlook.com (10.173.81.137) X-MS-Office365-Filtering-Correlation-Id: 4e9729dc-279f-43d7-0797-08d488e02d1f X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:VI1PR0701MB2765; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2765; 3:zlK9YI/Ew/AtbR4fGaOHo4PgalIsN+YpKL4Yc2UHAbT/vpw1lamFn/eo+k0h2cm08zFM8/dGeqXo30qBEdq822h/IMzQXXDdxSaHXu2eJHL2t0xYmfylgG27969gx8xsCnSb6YKr2GjGZM7k6KO4IoqumhFLXN1EEieX6IG3cswfWrUixCToeWKQV6PiWGSR6sqGbdVNotQe51kcVkWD5aQQwwet2eT/iXlXkDpew/ZpfTylYckHM4/o++w6ZY0TopNBwkBnDVRNVO6+j/2es8Xj/Hi4yT7SWigzge1J8qUFD/TSmYP2VZQkWmoI86TeQzJMmq1qYeZpNwuB1gyz2g==; 25:Xu1njmXasYRAEZAnp8RjhdRVJx3p7DiPxLKqpWFIjNbuLezidku7kCb0x2eXXbwF4NLBC11GwlrzsO3ySeYhELSPp9ZYN6UOYy/BM8imQJ5qwniUUJMAc4YmVltamPc6UvizPMOsPkpooIp74oSzW20ZqMHNoPhCGXTiRyABtxKZDdKk2hcjBGUchvFCqT+CSCrmh7qpM19WqeUrW8SzWNa6Ut8fuODATNLfP2j+lM8+NR+6COYoXjUZzH6qt5j0irmaJU4bkQLba3yHZdzaHRFDJA0htlcCPd+g3+iTr3JmYUDNxE9dTIg5F14+8S2KbA4Xa7353h+aaA3iQLicINGXSEXNtP4slhz1vcfmj189mLBxo3W23rel9IWQInQnm6WV+CJZKfo/ichsbuIpeOwBHAfcQqDrCRvBP64ap5KOqczal4tVQRrvLqFJk416ig5GxxScMFRVMVmMJwUYEOqUk819jyMst0raOIpwgE8= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2765; 31:xT59YcdDuuUBg0/G6UM3uYhaavQYc134uj/cKQ4tj+w2dilwS57EBrGsq3v4UGqiLc8bdQKyttqgbseM6iUJ+awKrgIu4mW0WgNdqDWeUDfQedGylvPyCF092ig6lEphxSNbU0kPSvSrNcXFc+4rfabz7ges5MbjTdUr/xmf3XEJ9l5rKex3jqZy3UgISYfUbY9dL0CtjAWb4nDWx43g8xcHAkuZFkTAhO2qQRXvh5A5uZABb6GhiQ8VfLjzi8Gn X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(6072148); SRVR:VI1PR0701MB2765; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2765; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2765; 4:GZDblZbLgROTFaAHqBYHzepdmPCDdEp6ddPujt+sHCY10SjFHYPL4VqmU3m9SRJwt9cyYN/6QQdChkx+OG3nD7lThg3gvuSvsW7u/xMSOfr/X6REwjl117CeZA/FMoFqA+cE+UvmsaYWijyk4Tcecp8skNc/UIUDZwOQ5zrNhom8lo8+iUJQ+q2wJ9Jvp3tkozRWumuup4Gz854nfd96Fbek/8xN2xw76hHGYh7FFDkoiSBlu31dzLZ2ARxOf9Y8H5DXTavgtCDj+oD6U/h58+tA5KAMLyMTH9FyfBnKuyextAwua+HcYBGoAC9ZQNBZ14ASAsvnkFgMyGc59ymUnaoYHKKmkIWObU7maPgG46vDouTB6jY1jWafQnm6fK9c6gtSwjvWeakrrd8ip6gAJbOcrT1GTgPfGx23KUwxc+k2Dt5UsngxeYXnaFtEIrsDYjqE/tj4hTUuDagEVaRG6Evem3JFzzKTnkZpz6DqxkLZKsYlwWG3ZLcugkJJi9ucz+NmZxKdoi1Jf8GCR0VQ8nt45t4qfFdpX4R41Mf6RJIy32K0bhyMBjGi31EmrNqgRB982dKe1xQ0XbfKdUmwiaoK78YlYnT36gDjqLPoT4uKl9wTsOcWfpR3FsPtlWJT9U3BYkr3dBpCCCK6jHpU1qTn0+/GRVfq0if8h0JVRN1Zb4ljtQhEGXd4yhMpF+W5OBzwid1Z5d53B1J4LLl7bfDCVFBCGssmSLxL13huPMWDvfCAhGMpXoZn2kMIF8es X-Forefront-PRVS: 02843AA9E0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39860400002)(39840400002)(39450400003)(39850400002)(39400400002)(39410400002)(377454003)(13464003)(6486002)(81166006)(6306002)(44736005)(1456003)(4720700003)(66066001)(81816999)(81156014)(6666003)(62236002)(116806002)(23756003)(9686003)(50986999)(8676002)(76176999)(86362001)(189998001)(305945005)(50226002)(230700001)(81686999)(7736002)(2906002)(5660300001)(44716002)(47776003)(6116002)(3846002)(84392002)(14496001)(97736004)(33646002)(42186005)(1556002)(6496005)(25786009)(61296003)(4326008)(53936002)(50466002)(38730400002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2765; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB2765; 23:IGaO4/8kR+pwPIMJFQOdccneOcr2YaMJC8OW+?= =?iso-8859-1?Q?tXTRGilotdTfR2bFPv5ikQ4CBzhHUncshf8LJXe0iBpGtkWcAgxtQTjBwg?= =?iso-8859-1?Q?ZphricovTIKdHd4u40+iZiEqPlHANLYjdMZm1qwv5H3+Ll/v7mtdlE0ge6?= =?iso-8859-1?Q?cnBdNjFBhNzNdg20qLyEZoMd3JCaIw4dK6XqnhgP6u0VHDFQF8JIIbq4a1?= =?iso-8859-1?Q?7bmLEN91KSIyp0V5DYuqt5ykxPF5UMuXXWhCX7vY5vNLWR7oED1HYnFGyZ?= =?iso-8859-1?Q?Bl6v3jVipjgm9i+eS8saf1vHUM41f4bIvreF/usJsk44hsgscsFul9pj/+?= =?iso-8859-1?Q?PNPfD+7yXjLGv/d2PvL7/QWKSmflQ27Ks/Nh4xr8QEL3Uu6+7w1OeY3ZYW?= =?iso-8859-1?Q?MPsAwikLk10aBQAeLCbnsO/q6hTz1O+SCK3tbW7RVizTEfj4X6o3wfA3Rl?= =?iso-8859-1?Q?GUq0Meoy07NQT8piLAJW8u/b2clppRU96BVLtXyfFiHxLL26Jm41qptmN1?= =?iso-8859-1?Q?eaXfPxMa0fLfCWdxS2GbGOIY105NVkw4jtvyv9QkJUe3eNG+p5Ok+ieuYL?= =?iso-8859-1?Q?lABthoZZevvWYBP2ZqVUB+rM+a6s1M+xp7sldXBkqu9Zb94QBWqB0F8UgA?= =?iso-8859-1?Q?BUaTM0HjoaAHKubW5Vixq1L0GquqIgEklT6Or67Xt140LTkllI/yDT4+A6?= =?iso-8859-1?Q?j4bpfsanxdZHEX93fuNDseJnm0nzGiapWR66+10Mw+XrSYJ5w3oks7YLXz?= =?iso-8859-1?Q?Lk2MKkkSlEVWLcvgYGBtU9/aiJxi6cO8hzdWkWjtMs7WToiKQQt7srme7G?= =?iso-8859-1?Q?E89+v7xcdpXdtqsg2tbF8fU+FJ5z9ycu2kG3LDaO1sHXXTMJzoAXZopx30?= =?iso-8859-1?Q?mrZ5+qVZQSWtdYXsV4SK9I3/dLU5iGMXX6be0MaTxvz3AW9HA6BSFn0rl3?= =?iso-8859-1?Q?pkShpwS+pivLx5QB7uGpYOJ+mthF6//XCZbZrtEaJ8aNKOv4BP6nKzPZ35?= =?iso-8859-1?Q?TkOxPOFMDI8+nF2EfYa3qinmywxbN2hGx4Q7L0oIANXbWl6nk2OPBeOwFm?= =?iso-8859-1?Q?AY902yBHYe66NaJaPPOKBRZiTUBD/tuetCgyTmjdohsmlWdKcwMMWW/fJA?= =?iso-8859-1?Q?SwPfEOOZcNBQnwQiz+fVycpS0yhSXFMhltZFSp//7CPW43N6c4PS1pOTBt?= =?iso-8859-1?Q?Q0K4F3d/3vIRLdpk1FspSA6Uwa1DAkAU0jdxOLsF88SmP2MG4d3NjVwVLA?= =?iso-8859-1?Q?MutwGILPMX01J1R91x+55YD+5jClJQKRCtPJt4ZWp93VtOjxhjr9N+7jng?= =?iso-8859-1?Q?wqkzR+lUePAU8toKtbG+AZYGM3EJYdkueyBfzHfs8AnG3tttA9zPlFy/RC?= =?iso-8859-1?Q?YqqjGCy/Z9zx+Y52sPyToawqQDpUVA1?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2765; 6:8SczGflSBddTGMPdHzzGf5oX3Lqy4Z2hqy+XTThaAWIkIioLfosl7ABud/EF28A0yhGqja0baX1MKRVOx5nANClCtv+7pN38KoYKkaBJ2v23vOQlpe0JKMau+vOVMu1wrD+qAB3k6pRnMcsbNfjvfCEzs2tupDzJF3LKY7pOZ11Zt0cI5RzlYdhZ0XGorLKahOLoB6ihx0tF36j6hFGVCidg2+I10Kgc+yW0ElbmLqwDex5nU75gwXXRXZ6Cvc+VLUEP2IeoiHMZFtMoz0Gzyr98AWqhl4Rp/LEI77I8SazPmm/PrWrEntNG/5gWJpY+MekOxmRpkSNNUPSfbTpBjTx2ymJt84SVBnxrjroZ6RWFl+Hy+YHOxRivODrkv3hUJ2dd1SMkIn6/tPHOJ12MSVxLxkJK4gZj2s7r+46WK0eK5cX9nohiSDQiKv1TfSSXVzUY3x7GT7fnrXEXHafAKyttCOMJfOheGS9Ykzg7is9R/5gWasUPUaYPQ6Rt5vEwBGnK8H7+odhs7US3kIrpJg==; 5:0aGWxcZZ26lm2XKzy4F6DNraspOe491fu9bzpQF2SBfWo/VAen4bcRSvWe6Fz1EXwBkElAE4mMQuFXsUR0EgPlxOSWYZeasEo0u+wLcnFOyPpwyPOZBGhbDDf6xD8OXV3sybmGtrGdDMXuf8e7SPYw==; 24:lK2+sRxcjtaachIBamRwEymxJUzV05Ok7ONKKvLw5OnCdqDOlkOfg8Mqq+B/Cf40UAljp1sobvtOLzxqlhZzZoJ26mzO8uOw8LOfIxEkEs8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2765; 7:/8BZm63mZ38yMxeJNeIP6u259xDym/PC5NTsIJHfkLFtxKTAI/vsVqXLnlPLPqARBB2ZEtr+ezKnJpklFn77iFd4rOQP59PLc5dI0Nu+hIPvJenp8dsQkdhWo7vLNiyUPp22suQNRuOgbxB/iBzUf0SjS3Xqo8vj1hsrpalOhu1kVQtUkQi5GPB4mlnmh4GDvH85A/rMrG4T+L4V3Pv/bOSt9TxluUx4SmU9kt3XsxtX0BEKk8pqj4u52mIKWzf0duGFmgZHv+l3haQ1ZwfoYypRi7BkaIqwCWYWPJfM7Yj0fxQw0s/2OArFssRnhDaAe0dqFCrJh+cm/y1bWGboAQ== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2017 17:59:37.2798 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2765 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 17:59:43 -0000 "JT: Xufeng presented 4 considerations yesterday on how to proceed, please take a look." Do you have a reference for that, preferrably an I-D and not PowerPoint? Tom Petch ----- Original Message ----- From: "Jeff Tantsura" To: "RTGWG" Cc: "rtgwg-chairs" Sent: Friday, April 14, 2017 12:08 AM > > The minutes have been published at: https://datatracker.ietf.org/doc/minutes-98-rtgwg/ > Please provide your comments. > > Thanks! > Jeff & Chris > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From nobody Sun Apr 23 02:47:11 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBED128D40; Sun, 23 Apr 2017 02:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFDzXmdsdA-f; Sun, 23 Apr 2017 02:47:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5577512869B; Sun, 23 Apr 2017 02:47:08 -0700 (PDT) Received: from localhost (h-13-92.a165.priv.bahnhof.se [155.4.13.92]) by mail.tail-f.com (Postfix) with ESMTPSA id 925261AE028F; Sun, 23 Apr 2017 11:47:06 +0200 (CEST) Date: Sun, 23 Apr 2017 11:47:06 +0200 (CEST) Message-Id: <20170423.114706.2035453647296311737.mbj@tail-f.com> To: rtgwg@ietf.org Cc: yang-doctors@ietf.org Subject: YANG doctor review of draft-ietf-rtgwg-lne-model-02 From: Martin Bjorklund X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 09:47:10 -0000 Hi, I am the assigned YANG doctor for draft-ietf-rtgwg-lne-model, and here are my review comments, based on -02: 1) Add reference to import statements. import ietf-interfaces { prefix if; reference "RFC 7223: A YANG Data Model for Interface Management"; } 2) IETF boilerplate Use IETF boilerplate with contact, description w/ copyright etc. 3) feature bind-lne-name feature bind-lne-name { description "Logical network element to which an interface is bound"; } This description doesn't make much sense. Also, this feature is not used in the model. Should the feature be removed or used? 4) leaf managed leaf managed { type boolean; description "True if the host can manage the LNE using the root mount point"; } This description needs to be expanded. This is a config leaf, so what happens if a client sets this to 'true' for a certain LNE? The text in the document says: In addition to standard management interfaces, a host device implementation may support accessing LNE configuration and operational YANG models directly from the host system. When supported, such access is accomplished through a yang-schema-mount mount point So are there three cases involved? 1. The host device does NOT support accessing LNE data from the host system => in this case no modules will be mounted. 2. The host device supports reading LNE data from the host system => in this case the modules are mounted read-only. 3. The host device supports reading/writing LNE data from the host system => in this case the modules are mounted read-write. I _think_ the idea is that if the server supports 2 or 3, a client can choose to set 'managed' to "false", in which case it turns into case 1. Is this correct? If so, would it be useful to allow a client to turn case 3 into 2? The text in the document in section 3 has more details on the "managed" leaf. I suggest you add text from the document to the YANG module. 5) leaf bind-lne-name This leaf is a string. Shouldn't it be a leafref? leaf bind-lne-name { type leafref { path "/logical-network-elements/logical-network-element/name"; } ... } 6) inconsistent formatting I suggest you run pyang -f yang [--keep-comments] and possibly edit the result add/remove comments. The following comment doesn't add much and should be removed: // namespace namespace "urn:ietf:params:xml:ns:yang:ietf-logical-network-element"; Also remove the comments about rpcs and notifications. Also add period ('.') at the end of all sentences in the descriptions. 7) YANG tree The document should explain the tree diagram syntax. Section 2 has this tree diagram: +--rw interfaces | +--rw interface* [name] | +--rw name string | +--rw lne:bind-lne-name? string | +--rw ethernet | | +--rw ni:bind-network-instance-name? string | | +--rw aggregates | | +--rw rstp | | +--rw lldp | | +--rw ptp | +--rw vlans | +--rw tunnels | +--rw ipv4 | | +--rw ni:bind-network-instance-name? string | | +--rw arp | | +--rw icmp | | +--rw vrrp | | +--rw dhcp-client | +--rw ipv6 | +--rw ni:bind-network-instance-name? string | +--rw vrrp | +--rw icmpv6 | +--rw nd | +--rw dhcpv6-client This diagram is not correct; it seems to indicate that there are nodes 'ethernet', 'vlans', 'ipv4', etc in the ietf-interfaces module. I suggest you remove the nodes that do not exist, and change 'ipv4' to 'ip:ipv4' (and add a reference to RFC 7277). 8) YANG tree (2) Section 3 has this diagram: module: ietf-logical-network-element +--rw logical-network-inventory +--rw logical-network-element* [name] +--rw name? string +--rw description? string +--rw managed? boolean +--rw root? yang-schema-mount augment /if:interfaces/if:interface: +--rw bind-lne-name? string It needs to be updated to match the YANG model (rename logical-network-inventory), and the 'root' should not be shown as a leaf. (Yes I know that there currently is no syntax defined for a mount point in a tree) 9) YANG tree (3) Section 3.1 uses a tree diagram to show instance data. I think this is confusing, and you should use XML or JSON instead. 10) typo s/The interface management model [RFC7223] is and existing model/ The interface management model [RFC7223] is an existing model/ /martin From nobody Sun Apr 23 02:48:41 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBE3128D40; Sun, 23 Apr 2017 02:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeGdg236bClD; Sun, 23 Apr 2017 02:48:39 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AD4A01200C1; Sun, 23 Apr 2017 02:48:39 -0700 (PDT) Received: from localhost (h-13-92.a165.priv.bahnhof.se [155.4.13.92]) by mail.tail-f.com (Postfix) with ESMTPSA id 005FB1AE028F; Sun, 23 Apr 2017 11:48:38 +0200 (CEST) Date: Sun, 23 Apr 2017 11:48:38 +0200 (CEST) Message-Id: <20170423.114838.190354600276418424.mbj@tail-f.com> To: rtgwg@ietf.org Cc: yang-doctors@ietf.org Subject: YANG doctor review of draft-ietf-rtgwg-ni-model-02 From: Martin Bjorklund X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 09:48:40 -0000 Hi, I am the assigned YANG doctor for draft-ietf-rtgwg-ni-model, and here are my review comments, based on -02: 1) Add reference to import statements. import ietf-interfaces { prefix if; reference "RFC 7223: A YANG Data Model for Interface Management"; } 2) IETF boilerplate Use IETF boilerplate with contact, description w/ copyright etc. 3) feature bind-network-instance-name feature bind-network-instance-name { description "Network Instance to which an interface instance is bound"; } This description doesn't make much sense. Also, this feature is not used in the model. Should the feature be removed or used? 4) unused groupings The module defines 3 groupings that are not used: interface-ip-common ipv4-interface-protocols ipv6-interface-protocols Either they should be removed, or the text needs to explain how they are supposed to be used by other modules. 5) network-instances The module has this: container network-instances { description "Network instances each of which have an independent IP/IPv6 addressing space and protocol instantiations. For layer 3, this consistent with the routing-instance definition in ietf-routing"; There is no "routing-instance" in "ietf-routing". This description needs to be updated. 6) leaf type leaf type { type identityref { base network-instance-type; } description "The network instance type -- details TBD Likely types include core, L3-VRF, VPLS, L2-cross-connect, L2-VSI, etc."; } "details TBD" - needs to be fixed. Should this leaf be mandatory? If not, it needs to be specified what it means if this leaf is not present. 7) container network-instance-policy container network-instance-policy { description "Network Instance Policy -- details TBD, perhaps based on BESS model"; } "details TBD" - needs to be fixed. 8) augments augment "/if:interfaces/if:interface" { description "Add a node for the identification of the logical network instance (which is within the interface's identified logical network element) associated with the IP information configured on an interface"; Does this mean that this model cannot be used without the LNE model? augment "/if:interfaces/if:interface/ip:ipv4" { description "Add a node for the identification of the logical network instance (which is within the interface's identified physical or virtual device) associated with the IP information configured on an interface"; What does "which is within the interface's identified physical or virtual device" mean? 9) leaf bind-network-instance-name This leaf is a string. Shouldn't it be a leafref? leaf bind-network-instance-name { type leafref { path "/network-instances/network-instance/name"; } ... } 10) inconsistent formatting I suggest you run pyang -f yang [--keep-comments] and possibly edit the result add/remove comments. The following comment doesn't add much and should be removed: // namespace namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; Also remove the comments about rpcs and notifications. Also add period ('.') at the end of all sentences in the descriptions. 11) section 2 Align with section 2 in the LNE document. 12) section 3 Can the same interface be bound to both an LNE and an NI? If not, this needs to be explained. 13) YANG tree Section 3.2 uses a tree diagram to show instance data. I think this is confusing, and you should use XML or JSON instead. (see my comments on YANG tree in the LNE review as well) /martin From nobody Mon Apr 24 00:42:04 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4D7128CFF for ; Mon, 24 Apr 2017 00:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1uMkYNF76dF for ; Mon, 24 Apr 2017 00:42:00 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 30653128CB9 for ; Mon, 24 Apr 2017 00:41:59 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id y63so80720055qkd.1 for ; Mon, 24 Apr 2017 00:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EndnOXH2EwF8xzr/ZUxruzxLsYOZKIlEbLJcqsYeoJw=; b=Pz6dz6SKw3UFTr6R3tIAPFnJH0W48XcGPNA2pKBwQtodHh9Z9Z/iCtj8g0D/zX+pUm JVollqLI9f595pspZuXFpaKbPrV3ZA2qfhJTNZSvOrC0m2eq3S4IldteUZPitWlat/GX qbmJ8M/3rJENhbSIziJzwjdk1jWnrFt5CZWtndet7recNnfcjlPE9DQtGIBSdLdIUOct MUcavLc3xn1pt9ducCupHBr2Ha63ZmDEEfk1eyO65vvl0Dt8ruY6mjkTjWhIvGHaxhsO O9SSTeEBviX8Yds+gUOKK4viIdUTj+JXbfW6/RUsH+4nkix6A0favfoTb5K51zdZGdw/ SmKQ== 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=EndnOXH2EwF8xzr/ZUxruzxLsYOZKIlEbLJcqsYeoJw=; b=D/UWutzBe7SBtm80vavxynT0q9sfxldsytJfa7iSihiGEwZawNnQcBI3sJnZdtYN5s nNUm/015g12PyTx6XSy8RC0P2SAEE5gYA41waMR05UHHL+QRpudfLUaaQ1qetqz9iwCD I6Q6/uCnFAddLtcUIFuX4n4+skVy88nmDOwf9JN/Lc8AErFss11iA+zvrubTgfWvJMcO hkgy93kt+XsE72GE6CMEajczmP+GCA6m/5dHtyCF2SGXH5nryRzJnT4neJeUyoDA6nzb DMULF0a3w+C3FhfU9bQXAnwRpci8xp3ky72HZgJj8K9JWZUkS/XWO+0aO4uO8TpGfX3Z olSA== X-Gm-Message-State: AN3rC/47nRjPHyrO0JnJNLICqigRa3aLnj+SM3zWxk9t+MtzeypoHG1q xJDT2wvxLqzMfNh9XV/sZsRQ+tSFoQ== X-Received: by 10.55.94.1 with SMTP id s1mr22984115qkb.83.1493019718354; Mon, 24 Apr 2017 00:41:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.47.129 with HTTP; Mon, 24 Apr 2017 00:41:27 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Mon, 24 Apr 2017 09:41:27 +0200 Message-ID: Subject: Re: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp To: Jonathan Hardwick , Xufeng_Liu@jabil.com, Athanasios_Kyparlis@jabil.com, parikhr@vmware.com, zhangmingui@huawei.com Cc: Routing WG Content-Type: multipart/alternative; boundary=001a114c8f38f48ede054de4bd26 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 07:42:02 -0000 --001a114c8f38f48ede054de4bd26 Content-Type: text/plain; charset=UTF-8 Hi, Jonathan Hardwick asked me to do an early review of the draft-ietf-rtgwg-yang-vrrp document (currently revision 02) for the routing directorate. The draft itself is pretty straight forward and compact, especially when you consider that a lot of text has to be repeated two or four times (IPv4/IPv6, config vs. read-only state). But I had quite a bit of trouble mapping the phrases from the new draft-ietf-rtgwg-yang-vrrp-02 document to the existing VRRP documents (e.g. RFC5798). This might come from my unfamilarity with VRRP. The draft YANG model allows to read (if:interfaces-state) and configure (if:interfaces) virtual IP addresses, but this does not seem to be a common phrase from the RFCs. Is it the same as "address of the virtual router" often mentioned in RFC5798? In addition to this, I found (I think) a typo or inconsistency in Appendix A: the ascii art says "eth0" but tree says "eth1". Henning Rogge On Mon, Mar 27, 2017 at 5:43 PM, Jonathan Hardwick < Jonathan.Hardwick@metaswitch.com> wrote: > Hi Henning > > > > Please would you do a routing directorate early review of this draft? > Would you be able to do it in 2 to 3 weeks? > > > > Many thanks > > Jon > > > > > > Please would you do a routing directorate QA review of this draft? > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-vrrp/ > > > > The draft is still in the RTGWG and is ready for WG last call. The WG > chairs have asked for a QA review from the directorate. The following link > provides guidance on QA reviews. > > https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa > > > > > --001a114c8f38f48ede054de4bd26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Jonathan Hardwick asked = me to do an early review of the draft-ietf-rtgwg-yang-vrrp document (curren= tly revision 02) for the routing directorate.

The = draft itself is pretty straight forward and compact, especially when you co= nsider that a lot of text has to be repeated two or four times (IPv4/IPv6, = config vs. read-only state).

But I had quite a bit= of trouble mapping the phrases from the new draft-ietf-rtgwg-yang-vrrp-02 = document to the existing VRRP documents (e.g. RFC5798). This might come fro= m my unfamilarity with VRRP.

The draft YANG model = allows to read (if:interfaces-state) and configure (if:interfaces) virtual = IP addresses, but this does not seem to be a common phrase from the RFCs. I= s it the same as "address of the virtual router" often mentioned = in RFC5798?

In addition to this, I found (I think)= a typo or inconsistency in Appendix A:
the ascii art says "= eth0" but tree says "eth1".

Henning= Rogge

On Mo= n, Mar 27, 2017 at 5:43 PM, Jonathan Hardwick <Jonathan.Har= dwick@metaswitch.com> wrote:

Hi Henning

=C2=A0

Please would you do a = routing directorate early review of this draft?=C2=A0 Would you be able to = do it in 2 to 3 weeks?

=C2=A0

Many thanks<= /u>

Jon

=C2=A0

=C2=A0

Please would you do a routing directorate QA review = of this draft?

https:= //datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-vrrp/

=C2=A0

The draft is still in the RTGWG and is ready for WG = last call.=C2=A0 The WG chairs have asked for a QA review from the director= ate.=C2=A0 The following link provides guidance on QA reviews.

https://trac.ietf.org/trac/rtg/wiki/RtgDirDo= cQa

=C2=A0

=C2=A0


--001a114c8f38f48ede054de4bd26-- From nobody Mon Apr 24 14:02:47 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B3E129502; Mon, 24 Apr 2017 14:02:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-rtgwg-yang-key-chain@ietf.org, Jeff Tantsura , rtgwg-chairs@ietf.org, jefftant.ietf@gmail.com, rtgwg@ietf.org Subject: Warren Kumari's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149306775810.25799.5569626168750928300.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 14:02:38 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:02:38 -0000 Warren Kumari has entered the following ballot position for draft-ietf-rtgwg-yang-key-chain-20: 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-rtgwg-yang-key-chain/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I had a few minor comments, mainly on the explanatory text -- I'm not a YANG expert (that's Benoit's job :-)): 1: "A key chain can be used by any service or application requiring authentication or encryption." - from my reading, this only symmetric keys; should this be "A key chain can be used by any service or application requiring authentication or encryption using symmetric keys"? 2: "They are also used to support of security requirements (e.g., TCP-AO Algorithms [TCP-AO-ALGORITHMS]) not implemented by vendors or only a single vendor." -- if it is not implemented, why put a key string on a device? Perhaps this was intended to be "not **yet** implemented..." ? From nobody Mon Apr 24 14:28:26 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FA01294A6; Mon, 24 Apr 2017 14:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mr7hUXqSdCx7; Mon, 24 Apr 2017 14:28:15 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E551205F0; Mon, 24 Apr 2017 14:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2616; q=dns/txt; s=iport; t=1493069295; x=1494278895; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aAJn53iLUPyKoImFpO5G1l8WOTKRK/6/hJyd9UJcj7M=; b=Zo/p9294Zuop+d0Hwc5JbP8e0JIBqtxVT83fD68XXaDMFf5R8jFDxoyj e2zef/YfxPhKCTOcdMm2crpHz4rR22pQId6pBleRtBy6fk6+g4evOcHnG p2ULhWyg1Q4DD8xjb5O0M4/x31XOH0or0t9vQ5WP47Hm5l+2vk+dmurM6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQCHbf5Y/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQwHg2CKFadRgg8shXgCGoN6PxgBAgEBAQEBAQFrKIUWBiM?= =?us-ascii?q?RNw4QAgEIGgImAgICMBUQAgQBDQWKHA6rUoImix0BAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEYBYELij6EKREBHIMGgl8FiTqUBwGHFotvggCFM4oklBgBHzh+CGMVhWK?= =?us-ascii?q?BSnUBhweBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,246,1488844800"; d="scan'208";a="414097532" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Apr 2017 21:28:14 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3OLSEca010089 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Apr 2017 21:28:14 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Apr 2017 17:28:13 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 24 Apr 2017 17:28:13 -0400 From: "Acee Lindem (acee)" To: Warren Kumari , The IESG CC: "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" Subject: Re: Warren Kumari's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Warren Kumari's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvT4cE+nnGFSFwEiV6iKkU1zk1aHVCNqA Date: Mon, 24 Apr 2017 21:28:13 +0000 Message-ID: References: <149306775810.25799.5569626168750928300.idtracker@ietfa.amsl.com> In-Reply-To: <149306775810.25799.5569626168750928300.idtracker@ietfa.amsl.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.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <984538C64CBC904E86DF02954DB95123@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:28:17 -0000 SGkgV2FycmVuLCANCg0KU2VlIGlubGluZS4gDQoNCg0KT24gNC8yNC8xNywgNTowMiBQTSwgIldh cnJlbiBLdW1hcmkiIDx3YXJyZW5Aa3VtYXJpLm5ldD4gd3JvdGU6DQoNCj5XYXJyZW4gS3VtYXJp IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPmRyYWZ0LWll dGYtcnRnd2cteWFuZy1rZXktY2hhaW4tMjA6IE5vIE9iamVjdGlvbg0KPg0KPldoZW4gcmVzcG9u ZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFs bA0KPmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVl bCBmcmVlIHRvIGN1dCB0aGlzDQo+aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ DQo+DQo+UGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50 L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cg RElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+DQo+DQo+VGhlIGRvY3VtZW50LCBhbG9u ZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hh aW4vDQo+DQo+DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pg0KPg0KPkkgaGFkIGEgZmV3IG1pbm9yIGNvbW1lbnRzLCBtYWlubHkgb24gdGhlIGV4cGxhbmF0 b3J5IHRleHQgLS0gSSdtIG5vdCBhDQo+WUFORyBleHBlcnQgKHRoYXQncyBCZW5vaXQncyBqb2Ig Oi0pKToNCj4NCj4xOiAiQSBrZXkgY2hhaW4gY2FuIGJlIHVzZWQgYnkgYW55IHNlcnZpY2Ugb3Ig YXBwbGljYXRpb24gcmVxdWlyaW5nDQo+YXV0aGVudGljYXRpb24gb3IgZW5jcnlwdGlvbi4iIC0g ZnJvbSBteSByZWFkaW5nLCB0aGlzIG9ubHkgc3ltbWV0cmljDQo+a2V5czsgc2hvdWxkIHRoaXMg YmUgIkEga2V5IGNoYWluIGNhbiBiZSB1c2VkIGJ5IGFueSBzZXJ2aWNlIG9yDQo+YXBwbGljYXRp b24gcmVxdWlyaW5nIGF1dGhlbnRpY2F0aW9uIG9yIGVuY3J5cHRpb24gdXNpbmcgc3ltbWV0cmlj IGtleXMiPw0KDQpZZXMgLSBJIGJlbGlldmUgSSBhZGRlZCDigJxzeW1tZXRyaWPigJ0gaW4gb25l IG90aGVyIHBsYWNlIGFuZCB3b3VsZCBiZSBmaW5lDQp3aXRoIGFkZGluZyBpdCBoZXJlIGFzIHdl bGwuDQo+DQo+DQo+MjogIlRoZXkgYXJlIGFsc28gdXNlZCB0byBzdXBwb3J0IG9mIHNlY3VyaXR5 IHJlcXVpcmVtZW50cyAoZS5nLiwgVENQLUFPDQo+QWxnb3JpdGhtcyBbVENQLUFPLUFMR09SSVRI TVNdKSBub3QgaW1wbGVtZW50ZWQgYnkgdmVuZG9ycyBvciBvbmx5IGENCj5zaW5nbGUgdmVuZG9y LiIgLS0gaWYgaXQgaXMgbm90IGltcGxlbWVudGVkLCB3aHkgcHV0IGEga2V5IHN0cmluZyBvbiBh DQo+ZGV2aWNlPyBQZXJoYXBzIHRoaXMgd2FzIGludGVuZGVkIHRvIGJlICJub3QgKip5ZXQqKiBp bXBsZW1lbnRlZC4uLiIgPw0KDQpWZW5kb3JzIHN1cHBvcnRpbmcgVENQIGJhc2VkIHByb3RvY29s cywgbW9zdCBub3RhYmx5IFRDUCwgY3VycmVudGx5DQpzdXBwb3J0IG90aGVyIGxlc3Mtc2VjdXJl IGFsZ29yaXRobXMuIEl0IGlzIHRoZSBnb2FsIHRvIHN1cHBvcnQgVENQLUFPIGluDQp0aGUgbW9k ZWwgc28gdGhhdCBhIHJldmlzaW9uIGlzIG5vdCByZXF1aXJlZCB0byByb2xsIG91dCBUQ1AtQU8u DQoNClRoYW5rcywNCkFjZWUgDQo+DQo+DQoNCg== From nobody Mon Apr 24 14:30:09 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7067D1294A6; Mon, 24 Apr 2017 14:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tyWZHZERHeu; Mon, 24 Apr 2017 14:29:58 -0700 (PDT) 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 7BDCB13193D; Mon, 24 Apr 2017 14:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2842; q=dns/txt; s=iport; t=1493069398; x=1494278998; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9Tc/ZJ6ktB8DJd65kipF0HYuArD4+YJnIWsKGutfXWI=; b=S1UrqOQyZHt04Ivbom7CPHuMjxD0fZAHntL254jD2a6DTxsZt9PMHIxj X6fe9tj2hufB51VPMXoy41VO1cMdRERMQUDK2RaxbxYXfFpqyK9RgAmOT ODkTqlYpX6dCGvKaTDSAWoauQGQ5JU0UKVY1sf/9hMOvURik/BtUscEt3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQAabv5Y/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhexEHg2CKFZFslWWCDyyFeAIag3o/GAECAQEBAQEBAWsohRY?= =?us-ascii?q?BBSMRNw4QAgEGAhgCAiYCAgIwFRACBAENBYocDo1wnV6CJosdAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWBC4o+hCkRAYMigl8BBIk6lAcBhxaLb4IAhTOKJJQYAR8?= =?us-ascii?q?4fghjFYVigUp1AYcHgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,246,1488844800"; d="scan'208";a="235194233" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Apr 2017 21:29:55 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3OLTt5d024366 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Apr 2017 21:29:55 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Apr 2017 17:29:54 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 24 Apr 2017 17:29:54 -0400 From: "Acee Lindem (acee)" To: "Acee Lindem (acee)" , Warren Kumari , The IESG CC: "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" Subject: Re: Warren Kumari's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Warren Kumari's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvT4cE+nnGFSFwEiV6iKkU1zk1aHVCNqAgAAAd4A= Date: Mon, 24 Apr 2017 21:29:54 +0000 Message-ID: References: <149306775810.25799.5569626168750928300.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <53EDC0DBC1C0544C97A47E8BBD351D95@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:30:01 -0000 DQoNCk9uIDQvMjQvMTcsIDU6MjggUE0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2Nv LmNvbT4gd3JvdGU6DQoNCj5IaSBXYXJyZW4sIA0KPg0KPlNlZSBpbmxpbmUuIA0KPg0KPg0KPk9u IDQvMjQvMTcsIDU6MDIgUE0sICJXYXJyZW4gS3VtYXJpIiA8d2FycmVuQGt1bWFyaS5uZXQ+IHdy b3RlOg0KPg0KPj5XYXJyZW4gS3VtYXJpIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90 IHBvc2l0aW9uIGZvcg0KPj5kcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluLTIwOiBObyBP YmplY3Rpb24NCj4+DQo+PldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3Qg bGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPj5lbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQg aW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPj5pbnRyb2R1 Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4+DQo+Pg0KPj5QbGVhc2UgcmVmZXIgdG8gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ PmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3Np dGlvbnMuDQo+Pg0KPj4NCj4+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBw b3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluLw0KPj4NCj4+DQo+Pg0KPj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+PkNPTU1FTlQ6DQo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+Pg0KPj5JIGhh ZCBhIGZldyBtaW5vciBjb21tZW50cywgbWFpbmx5IG9uIHRoZSBleHBsYW5hdG9yeSB0ZXh0IC0t IEknbSBub3QgYQ0KPj5ZQU5HIGV4cGVydCAodGhhdCdzIEJlbm9pdCdzIGpvYiA6LSkpOg0KPj4N Cj4+MTogIkEga2V5IGNoYWluIGNhbiBiZSB1c2VkIGJ5IGFueSBzZXJ2aWNlIG9yIGFwcGxpY2F0 aW9uIHJlcXVpcmluZw0KPj5hdXRoZW50aWNhdGlvbiBvciBlbmNyeXB0aW9uLiIgLSBmcm9tIG15 IHJlYWRpbmcsIHRoaXMgb25seSBzeW1tZXRyaWMNCj4+a2V5czsgc2hvdWxkIHRoaXMgYmUgIkEg a2V5IGNoYWluIGNhbiBiZSB1c2VkIGJ5IGFueSBzZXJ2aWNlIG9yDQo+PmFwcGxpY2F0aW9uIHJl cXVpcmluZyBhdXRoZW50aWNhdGlvbiBvciBlbmNyeXB0aW9uIHVzaW5nIHN5bW1ldHJpYyBrZXlz Ij8NCj4NCj5ZZXMgLSBJIGJlbGlldmUgSSBhZGRlZCDigJxzeW1tZXRyaWPigJ0gaW4gb25lIG90 aGVyIHBsYWNlIGFuZCB3b3VsZCBiZSBmaW5lDQo+d2l0aCBhZGRpbmcgaXQgaGVyZSBhcyB3ZWxs Lg0KPj4NCj4+DQo+PjI6ICJUaGV5IGFyZSBhbHNvIHVzZWQgdG8gc3VwcG9ydCBvZiBzZWN1cml0 eSByZXF1aXJlbWVudHMgKGUuZy4sIFRDUC1BTw0KPj5BbGdvcml0aG1zIFtUQ1AtQU8tQUxHT1JJ VEhNU10pIG5vdCBpbXBsZW1lbnRlZCBieSB2ZW5kb3JzIG9yIG9ubHkgYQ0KPj5zaW5nbGUgdmVu ZG9yLiIgLS0gaWYgaXQgaXMgbm90IGltcGxlbWVudGVkLCB3aHkgcHV0IGEga2V5IHN0cmluZyBv biBhDQo+PmRldmljZT8gUGVyaGFwcyB0aGlzIHdhcyBpbnRlbmRlZCB0byBiZSAibm90ICoqeWV0 KiogaW1wbGVtZW50ZWQuLi4iID8NCj4NCj5WZW5kb3JzIHN1cHBvcnRpbmcgVENQIGJhc2VkIHBy b3RvY29scywgbW9zdCBub3RhYmx5IFRDUCwgY3VycmVudGx5DQo+c3VwcG9ydCBvdGhlciBsZXNz LXNlY3VyZSBhbGdvcml0aG1zLiBJdCBpcyB0aGUgZ29hbCB0byBzdXBwb3J0IFRDUC1BTyBpbg0K PnRoZSBtb2RlbCBzbyB0aGF0IGEgcmV2aXNpb24gaXMgbm90IHJlcXVpcmVkIHRvIHJvbGwgb3V0 IFRDUC1BTy4NCg0KSSBtZWFuLCDigJxtb3N0IG5vdGFibHkgQkdQ4oCd4oCmDQo+DQo+VGhhbmtz LA0KPkFjZWUgDQo+Pg0KPj4NCj4NCg0K From nobody Mon Apr 24 15:07:30 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE81126B71 for ; Mon, 24 Apr 2017 15:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnAX2LqBTdCj for ; Mon, 24 Apr 2017 15:07:26 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2D4126E01 for ; Mon, 24 Apr 2017 15:07:26 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id y33so126212801qta.2 for ; Mon, 24 Apr 2017 15:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5vkIOkJYoXNQg/IJmSAdt4jQhBtMKBjBbjAObYK2v0g=; b=iloBL+gaBfdIvVYj3FO8dObgX31zSu9iqepG9ZAiibMO77gQUpSNfXnyME8CSu7nNG 7LaI3buZq47UefeyN9AuJTVvQE/OvFdUEedo9xlR+75rO1f3IgUm7CkISkyymmFxnfkL TKb9sVWfvXHhrXpmzAKGgmAnugoq7BbX4c3GDNDNflP9pz/uIZKXRI+Bs+LJbR33rNYQ hCA0Wx6EB9W6LnOrKsXTCk3/aleJ72J023gwoOgfAtrZ/sxT4gwqMdbRjpAZqOgG9gh3 FE1sbh/wc97yRgaEIGc/xYTaKcW6MzMHtazem/DCD/HsRZQatjgOugE+6R6KbpT1/+Wt gTLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5vkIOkJYoXNQg/IJmSAdt4jQhBtMKBjBbjAObYK2v0g=; b=WW9DqMm8JhpUPrfuRS8XSZduNYorBN/XJYZOQ07fbi/EvHP33KXkoYpZKjhwJGCrib ZamM6aAqHI+/ooIg14nj4wVU89wDQRkhKg5i9fRccUuGZyoskUNsbQjJGTFU/gQHZ++l 4SC6n5mhtGrHiupJU3+nQyA+TWLA+YLWotHOXaruillnAOPSehuzo5AhghymREHfgcJ2 aYOfrrcKgXbPiv1h+iqeZOjcrymvd3Ykk0Oy28/kfycev/VhikHgEJLU86JGlFrOCnlQ s7QZpAWB+h2gcZ0gmJTWmHTA4VHLYdEIn9JolEaB0w+nW+UDt/d+zHfVxDEQUa08Tifh e4Ow== X-Gm-Message-State: AN3rC/6Hd9Vk17wmWP81HBfZGNS6ZVKP/PSBjQlBH7wYiYSD7OWOJVJj U6v3IHBsNdm3ld0pWL9vuQyw5OuRIg9V X-Received: by 10.200.55.13 with SMTP id o13mr29639189qtb.57.1493071645687; Mon, 24 Apr 2017 15:07:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.158.154 with HTTP; Mon, 24 Apr 2017 15:06:45 -0700 (PDT) In-Reply-To: References: <149306775810.25799.5569626168750928300.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Mon, 24 Apr 2017 18:06:45 -0400 Message-ID: Subject: Re: Warren Kumari's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) To: "Acee Lindem (acee)" Cc: The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 22:07:29 -0000 On Mon, Apr 24, 2017 at 5:29 PM, Acee Lindem (acee) wrote: > > > On 4/24/17, 5:28 PM, "Acee Lindem (acee)" wrote: > >>Hi Warren, >> >>See inline. >> >> >>On 4/24/17, 5:02 PM, "Warren Kumari" wrote: >> >>>Warren Kumari has entered the following ballot position for >>>draft-ietf-rtgwg-yang-key-chain-20: 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.htm= l >>>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-rtgwg-yang-key-chain/ >>> >>> >>> >>>---------------------------------------------------------------------- >>>COMMENT: >>>---------------------------------------------------------------------- >>> >>> >>>I had a few minor comments, mainly on the explanatory text -- I'm not a >>>YANG expert (that's Benoit's job :-)): >>> >>>1: "A key chain can be used by any service or application requiring >>>authentication or encryption." - from my reading, this only symmetric >>>keys; should this be "A key chain can be used by any service or >>>application requiring authentication or encryption using symmetric keys"= ? >> >>Yes - I believe I added =E2=80=9Csymmetric=E2=80=9D in one other place an= d would be fine >>with adding it here as well. >>> >>> >>>2: "They are also used to support of security requirements (e.g., TCP-AO >>>Algorithms [TCP-AO-ALGORITHMS]) not implemented by vendors or only a >>>single vendor." -- if it is not implemented, why put a key string on a >>>device? Perhaps this was intended to be "not **yet** implemented..." ? >> >>Vendors supporting TCP based protocols, most notably TCP, currently >>support other less-secure algorithms. It is the goal to support TCP-AO in >>the model so that a revision is not required to roll out TCP-AO. Yeah, cool, fully agree -- but I still think having the "yet" in there would make it clearer (e.g: "They are also used to support of security requirements (e.g., TCP-AOAlgorithms [TCP-AO-ALGORITHMS]) not yet implemented by vendors or only implemented by a single vendor.") But, 'tis just a comment... Oh, I just noticed: "used to support of security requirements" -- perhaps "used in support of" or "use to support security..."? W > > I mean, =E2=80=9Cmost notably BGP=E2=80=9D=E2=80=A6 >> >>Thanks, >>Acee >>> >>> >> > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Apr 24 15:18:01 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A159126CD8; Mon, 24 Apr 2017 15:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzhbS6YtHj20; Mon, 24 Apr 2017 15:17:58 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66EEA126B71; Mon, 24 Apr 2017 15:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4562; q=dns/txt; s=iport; t=1493072278; x=1494281878; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lc79w/Kds9fhO5a2C5kkrX7fkKoUnZ7MMpvkW8sOsjY=; b=JtySu4BFF4wjTcessaUgWBIkXwVHC0CjFy+xObx/3vNhTfnl7Hhg8v1T J7Xn4JKNle2oy5bVSgtNV6C+fPCBBInAN6DkqUaOy9pL5m5xhWD7+zB1t XV0bSpxSrpovMoY2YP4PNJB9GvNykVjmxlqn71Q4/ZfiQrRp8IbY5sIsV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQDkeP5Y/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQwHg2CKFZFslWWCDyyFeAIag3o/GAECAQEBAQEBAWsohRY?= =?us-ascii?q?BBSMRNw4QAgEGAhgCAiYCAgIwFRACBA4FihwOjVmdXoImix0BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYELij6EKREBHIMGgl8FiTqUBwGHFotvggCFM4okiG+LKQE?= =?us-ascii?q?fOH4IYxWFYoFKdQGHB4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,246,1488844800"; d="scan'208";a="237040445" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Apr 2017 22:17:57 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3OMHvPe021129 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Apr 2017 22:17:57 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 24 Apr 2017 18:17:56 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 24 Apr 2017 18:17:56 -0400 From: "Acee Lindem (acee)" To: Warren Kumari CC: The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" Subject: Re: Warren Kumari's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Warren Kumari's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvT4cE+nnGFSFwEiV6iKkU1zk1aHVCNqAgAAAd4CAAE1ggP//wA6A Date: Mon, 24 Apr 2017 22:17:56 +0000 Message-ID: References: <149306775810.25799.5569626168750928300.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <7EDD971473ABF74795C41EF0E18DA12F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 22:18:00 -0000 SGkgV2FycmVuLCANCg0KT24gNC8yNC8xNywgNjowNiBQTSwgIldhcnJlbiBLdW1hcmkiIDx3YXJy ZW5Aa3VtYXJpLm5ldD4gd3JvdGU6DQoNCj5PbiBNb24sIEFwciAyNCwgMjAxNyBhdCA1OjI5IFBN LCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPg0KPndyb3RlOg0KPj4NCj4+DQo+ PiBPbiA0LzI0LzE3LCA1OjI4IFBNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5j b20+IHdyb3RlOg0KPj4NCj4+PkhpIFdhcnJlbiwNCj4+Pg0KPj4+U2VlIGlubGluZS4NCj4+Pg0K Pj4+DQo+Pj5PbiA0LzI0LzE3LCA1OjAyIFBNLCAiV2FycmVuIEt1bWFyaSIgPHdhcnJlbkBrdW1h cmkubmV0PiB3cm90ZToNCj4+Pg0KPj4+PldhcnJlbiBLdW1hcmkgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+Pj4+ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtl eS1jaGFpbi0yMDogTm8gT2JqZWN0aW9uDQo+Pj4+DQo+Pj4+V2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQo+Pj4+ZW1h aWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUg dG8gY3V0IHRoaXMNCj4+Pj5pbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4+Pj4N Cj4+Pj4NCj4+Pj5QbGVhc2UgcmVmZXIgdG8NCj4+Pj5odHRwczovL3d3dy5pZXRmLm9yZy9pZXNn L3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4+Pj5mb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPj4+Pg0KPj4+Pg0K Pj4+PlRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCj4+Pj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluLw0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+Pj5DT01NRU5UOg0KPj4+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4NCj4+Pj4NCj4+ Pj5JIGhhZCBhIGZldyBtaW5vciBjb21tZW50cywgbWFpbmx5IG9uIHRoZSBleHBsYW5hdG9yeSB0 ZXh0IC0tIEknbSBub3QgYQ0KPj4+PllBTkcgZXhwZXJ0ICh0aGF0J3MgQmVub2l0J3Mgam9iIDot KSk6DQo+Pj4+DQo+Pj4+MTogIkEga2V5IGNoYWluIGNhbiBiZSB1c2VkIGJ5IGFueSBzZXJ2aWNl IG9yIGFwcGxpY2F0aW9uIHJlcXVpcmluZw0KPj4+PmF1dGhlbnRpY2F0aW9uIG9yIGVuY3J5cHRp b24uIiAtIGZyb20gbXkgcmVhZGluZywgdGhpcyBvbmx5IHN5bW1ldHJpYw0KPj4+PmtleXM7IHNo b3VsZCB0aGlzIGJlICJBIGtleSBjaGFpbiBjYW4gYmUgdXNlZCBieSBhbnkgc2VydmljZSBvcg0K Pj4+PmFwcGxpY2F0aW9uIHJlcXVpcmluZyBhdXRoZW50aWNhdGlvbiBvciBlbmNyeXB0aW9uIHVz aW5nIHN5bW1ldHJpYw0KPj4+PmtleXMiPw0KPj4+DQo+Pj5ZZXMgLSBJIGJlbGlldmUgSSBhZGRl ZCDigJxzeW1tZXRyaWPigJ0gaW4gb25lIG90aGVyIHBsYWNlIGFuZCB3b3VsZCBiZSBmaW5lDQo+ Pj53aXRoIGFkZGluZyBpdCBoZXJlIGFzIHdlbGwuDQo+Pj4+DQo+Pj4+DQo+Pj4+MjogIlRoZXkg YXJlIGFsc28gdXNlZCB0byBzdXBwb3J0IG9mIHNlY3VyaXR5IHJlcXVpcmVtZW50cyAoZS5nLiwN Cj4+Pj5UQ1AtQU8NCj4+Pj5BbGdvcml0aG1zIFtUQ1AtQU8tQUxHT1JJVEhNU10pIG5vdCBpbXBs ZW1lbnRlZCBieSB2ZW5kb3JzIG9yIG9ubHkgYQ0KPj4+PnNpbmdsZSB2ZW5kb3IuIiAtLSBpZiBp dCBpcyBub3QgaW1wbGVtZW50ZWQsIHdoeSBwdXQgYSBrZXkgc3RyaW5nIG9uIGENCj4+Pj5kZXZp Y2U/IFBlcmhhcHMgdGhpcyB3YXMgaW50ZW5kZWQgdG8gYmUgIm5vdCAqKnlldCoqIGltcGxlbWVu dGVkLi4uIiA/DQo+Pj4NCj4+PlZlbmRvcnMgc3VwcG9ydGluZyBUQ1AgYmFzZWQgcHJvdG9jb2xz LCBtb3N0IG5vdGFibHkgVENQLCBjdXJyZW50bHkNCj4+PnN1cHBvcnQgb3RoZXIgbGVzcy1zZWN1 cmUgYWxnb3JpdGhtcy4gSXQgaXMgdGhlIGdvYWwgdG8gc3VwcG9ydCBUQ1AtQU8NCj4+PmluDQo+ Pj50aGUgbW9kZWwgc28gdGhhdCBhIHJldmlzaW9uIGlzIG5vdCByZXF1aXJlZCB0byByb2xsIG91 dCBUQ1AtQU8uDQo+DQo+WWVhaCwgY29vbCwgZnVsbHkgYWdyZWUgLS0gYnV0IEkgc3RpbGwgdGhp bmsgaGF2aW5nIHRoZSAieWV0IiBpbiB0aGVyZQ0KPndvdWxkIG1ha2UgaXQgY2xlYXJlciAoZS5n OiAiVGhleSBhcmUgYWxzbyB1c2VkIHRvIHN1cHBvcnQgb2Ygc2VjdXJpdHkNCj5yZXF1aXJlbWVu dHMgKGUuZy4sIFRDUC1BT0FsZ29yaXRobXMgW1RDUC1BTy1BTEdPUklUSE1TXSkgbm90IHlldA0K PmltcGxlbWVudGVkIGJ5IHZlbmRvcnMgb3Igb25seSBpbXBsZW1lbnRlZCBieSBhIHNpbmdsZSB2 ZW5kb3IuIikNCj5CdXQsICd0aXMganVzdCBhIGNvbW1lbnQuLi4gT2gsIEkganVzdCBub3RpY2Vk OiAidXNlZCB0byBzdXBwb3J0IG9mDQo+c2VjdXJpdHkgcmVxdWlyZW1lbnRzIiAtLSBwZXJoYXBz ICJ1c2VkIGluIHN1cHBvcnQgb2YiIG9yICJ1c2UgdG8NCj5zdXBwb3J0IHNlY3VyaXR5Li4uIj8N Cg0KSSBhZ3JlZSBhbmQgd2lsbCB1cGRhdGUgdGhlIHRleHQgdG8gYWRkIOKAnHlldOKAnS4gQXMg eW91IHN1cm1pc2VkLCBJIGRpZG7igJl0DQpmdWxseSB1bmRlcnN0YW5kIHRoZSBzdWJ0bGV0eSBv ZiB5b3VyIG9yaWdpbmFsIGNvbW1lbnQuIFdpbGwgYWxzbyBmaXggdGhlDQp3b3JraW5nIHByb2Js ZW0geW91IGp1c3Qgbm90aWNlZC4NCg0KVGhhbmtzLA0KQWNlZQ0KDQo+DQo+DQo+Vw0KPg0KPj4N Cj4+IEkgbWVhbiwg4oCcbW9zdCBub3RhYmx5IEJHUOKAneKApg0KPj4+DQo+Pj5UaGFua3MsDQo+ Pj5BY2VlDQo+Pj4+DQo+Pj4+DQo+Pj4NCj4+DQo+DQo+DQo+DQo+LS0gDQo+SSBkb24ndCB0aGlu ayB0aGUgZXhlY3V0aW9uIGlzIHJlbGV2YW50IHdoZW4gaXQgd2FzIG9idmlvdXNseSBhIGJhZA0K PmlkZWEgaW4gdGhlIGZpcnN0IHBsYWNlLg0KPlRoaXMgaXMgbGlrZSBwdXR0aW5nIHJhYmlkIHdl YXNlbHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyIGV4cHJlc3NpbmcNCj5yZWdyZXQgYXQgaGF2 aW5nIGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFpcg0K Pm9mIHBhbnRzLg0KPiAgIC0tLW1hZg0KDQo= From nobody Mon Apr 24 19:15:48 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5C51270B4; Mon, 24 Apr 2017 19:15:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-rtgwg-yang-key-chain@ietf.org, Jeff Tantsura , rtgwg-chairs@ietf.org, jefftant.ietf@gmail.com, rtgwg@ietf.org Subject: Ben Campbell's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149308654029.6988.16576150880916114905.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 19:15:40 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 02:15:40 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtgwg-yang-key-chain-20: 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-rtgwg-yang-key-chain/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a couple of editorial comments: -2.2: "This MAY be accomplished by accepting all the keys that have a valid accept lifetime and sending the key with the most recent send lifetime." As written, that MAY sounds like a statement of fact rather than a normative requirement. If it's intended as normative, please consider restating in terms of actual procedure (e.g. "The receiver MAY accept ...") -3, first paragraph: "Is a "key chain key" a key in the keychain, or something else? (maybe a key _for_ the keychain)? From nobody Mon Apr 24 23:45:23 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D92CC126B6D; Mon, 24 Apr 2017 23:45:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-rtgwg-yang-key-chain@ietf.org, Jeff Tantsura , rtgwg-chairs@ietf.org, jefftant.ietf@gmail.com, rtgwg@ietf.org Subject: =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ietf-rtgw?= =?utf-8?q?g-yang-key-chain-20=3A_=28with_COMMENT=29?= X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149310271488.7096.4956898183982418315.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 23:45:14 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 06:45:15 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-rtgwg-yang-key-chain-20: 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-rtgwg-yang-key-chain/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Fully editorial comment: section 1 is just a copy of the abstract… this could be removed and section 2 could be used as section 1/intro (with sections 1.1, 1.2, and 2.1 as subsections; and section 2.2. could become the new section 2) From nobody Tue Apr 25 02:11:49 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7273C129B25 for ; Tue, 25 Apr 2017 02:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWs-ECD3hFhc for ; Tue, 25 Apr 2017 02:11:45 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0098.outbound.protection.outlook.com [104.47.1.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8A612950E for ; Tue, 25 Apr 2017 02:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=luTdaNVHInnrmEbJcj1o8TQF4WLpJCF9eDEJDf2UEPM=; b=Mru6tWuB/r6OZ+0Y1kjgxkwmd2qRHzS2ROlXvGoVPtTrD+pE9WHJiauut/36bXpcCtQY84TysiSy1DftL6OKZzig90Z4iaCy40h/N/TlBEcoVcViQpdYjgHeuyyyv81KuG1Ln7ybvzWYF/s8oIuXqifjJdzkPzlZhA1tp+aLqio= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by DB6PR0701MB2757.eurprd07.prod.outlook.com (10.169.215.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Tue, 25 Apr 2017 09:11:41 +0000 Message-ID: <032e01d2bda3$9fa252e0$4001a8c0@gateway.2wire.net> From: t.petch To: Jeff Tantsura , RTGWG CC: rtgwg-chairs Subject: exim grey listing does not work was Re: Query on Re: RTGWG minutes IETF98 Date: Tue, 25 Apr 2017 09:49:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: VI1PR09CA0054.eurprd09.prod.outlook.com (10.174.49.22) To DB6PR0701MB2757.eurprd07.prod.outlook.com (10.169.215.143) X-MS-Office365-Filtering-Correlation-Id: c48da600-f291-4ebd-a988-08d48bbb16ee X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:DB6PR0701MB2757; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2757; 3:ar73RJ99i0Y0Avy83RItTm+16j6PkpVzwHPOOzqN0pdP9RM1Aq8jYXQS3hebZJXkt0+Dk1qLIjhSj/QI3+/yrbbnW9Y15wSgQKBiz9wSXj9xZG9dYu+D1tWmZyPaC1pxFXayGnEfOkVSrMZuhGRXv2XkzDmB+aWKDZbt6fI/ZrMEpeQZ6SNlh1oE/tra13MibSUMQjVyaEvge3AKx/B5L9ia8RSxHzeF5cmRAJCw6KMJ6splPzhkDIoqzUFFivBrGiBcZchEY2a7aqNaS+kNU9V7VO91Z3alNCPaIntclDsBm6JE7PAP0cwQo8r2dnb9aAs+hFJ2X5/+jxRXRf0Wqw==; 25:vc8ZJy5OB5jAJN3Reb74m5CuLboC6QrRjVdX9n3Qw3wRn+VHZufTdflfHXhrqZszkfaWV6hnJWfcM1kvR6DAv/66pdT9HgmThxP63U04iGnOYHcWsvvtrlWkGddJM41FSFonLx6/WtNAsXtjTwF4juSThdA6k/0rNEBLa1fxhmmZYeaK4vWLmQeb4sujO9Fds6upEZRrO7ZLNhN87SMHljqAtL+OGim/P3n6nkJTrX8+2YcwWuUMdqZwVkBdZfl5lk28zS/urJVjq3Cyi0HMeDiO7otxvHWzZyCA4BGCj4tZCmODUnsJC7ZmSDI+oUuHyAxwFTSyhq4Mb6xEXBzFxr/8X3jVbspH66ziP6uMZu7HLziQHpTO3f2uNjuhSZlhouZY4E8V1p22E2QA5sqYqkQMjmxKW6jOhzPQ0D44Rr4XFS2qOZLnmsM3kE5SZxJcIeFSZaCVGQpkmoWXGwMsbW2xUfe+zrwEhSi4nfosZCs= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2757; 31:lHfLodyhf1qOAKCrnCQHbICHq7dyNS08deFNiJbca/ISz6HGxiyX0VHOeVAu1yVFiBIH0j7HRicVzRSCHV4mzFyF9Gj1OV6Z7FFkzyw75V6T6JESuYxlfj6ciqGWDu+rhZ1G9U+NQn+GyCh7fJQiRxANjy5zdYwLbmFb/iJLamIzB/BW2RgnLk0z9puBrRXymPNOYXhukOfHt8MZnpRZVw0wMPPxSaAsH42yiHruD2i+dmcahcrMOg446Mj9PKhUtQ7N89cVYFJmYrpWEbF2rg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:DB6PR0701MB2757; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2757; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2757; 4:YuwX3KCMW/kUasp+HL9hbaMtnvydWEnnqZwXEbLlLgteMvuEvF6Fky2bHrIBtNfefSXA/deNBLWSXRjx4LFk1scEdCNEZlGt0Rb1DiGQ+wfHb1VNOI/sgWgDrgIf53NxlbdLyk/ErOmnubSs9zGOjSoHxjtfR5ZVyiijG0Bs5IZeqk/SxPpMweggwD/CU4v/9XOp1ju6jpFCOG9qMQjGbEndNjJQMOpXoS3t3iZ2zqh6tNRz5KWpIUzKpxZIMza2KsDfzEw0JwV/26sx1GmgGcQ84nmUWWik75+A+2PkmY6gRJXHnlQPLmZ0s/UADsisgo4KBY91mknMDPOAW5hlT9ITRbheS6QQ40f4hMiH18SLAIAFaofHPoZsX+X1YHZz9ZFRZLhrq5fv7ti7aST7DmDDmW1xGGwXX8LwzI206iyHqdvQIyEZVvhspn2wGc99s5wySxhghqi5L0h6bOUwOo3tsP38G0N8UYIJIdFvYl4h9H/TSZig+Dtv4hZLMhl2/etw8Ux2AVJQreDG2CoK0t0jCbiZPF4qrKgi9vLoLu86jDGU48t787IPubz1Y66wepJmJ2kOqAPUkKBxCYqV2WLfbTBwUDMf2c/ZaRm0aHs+2TvCsgW/mGvayzoHibdzKDJNgWlTjs8vxibKIRIJJEZ2FCc1Fa9kVxlMHhdZ+76UrJsIpPYo9WOkT3UXP9lFo95gCEbV9lrbVYZK3aCKFQwt0wEK4sXlf9p4jBT/Eo0yensRa4lYJH3Wcxf4oxEavk6Sp+YQeCRgtQCAsbGNKd8lD1enXLpC+S4RFlM+P4cK+89DQVDRbA+h4Jnz73DLWMLClRsFrpFFYro70GP2DePxhGwDB8R+4rpn+9Ha7Qc= X-Forefront-PRVS: 0288CD37D9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39410400002)(39840400002)(39850400002)(39450400003)(39860400002)(39400400002)(13464003)(377454003)(61296003)(42186005)(5660300001)(6486002)(50226002)(305945005)(81166006)(7736002)(8676002)(23756003)(81686999)(1556002)(38730400002)(25786009)(81816999)(4326008)(50986999)(6306002)(9686003)(53936002)(6496005)(50466002)(4720700003)(62236002)(66066001)(47776003)(44716002)(1456003)(33646002)(116806002)(84392002)(44736005)(86362001)(6116002)(3846002)(189998001)(6666003)(2906002)(230700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2757; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB2757; 23:r5y9tbGWeJQkWwXu3xv3FsI3K3MgqVrqwwIU0?= =?iso-8859-1?Q?CsdODgsdd7F18nQrNssL4e5LZI8BhRI8YrO3RDNl4eqTyztXBe+KiH91PD?= =?iso-8859-1?Q?pGTcnrjfaw4PVX+gVl7OxVHPxDLgQWy0ORsZ3ne2LFS7P8Bexvm7Y+5Qde?= =?iso-8859-1?Q?bRTTy1JnEMM43UVn8hy19rOiFvkK0OZO++qZrHSfL1VP6cuT1W8B9hrNdg?= =?iso-8859-1?Q?b3Z5pa/FWajJ8lvz8xSLDcXYUMs4xzc8rK2SbTcNaT2ZQ70FnoFZ+OiWap?= =?iso-8859-1?Q?e3pRF1fhvMEv7knveKHiYSCQ8G7bALBpHoUxOn2mYtz3Wt0lxa+Kumqjlm?= =?iso-8859-1?Q?30L06WFEiuLluLAzLlALj069LmiCZ6e5Z1bA8w0wlO8Zy2VWFJc6oaa2Uc?= =?iso-8859-1?Q?48/XTmybysXkoAsNKE3Q5jZlaCUzQdlLmGM1fCPf/b1LAinbO6HNBLo5iX?= =?iso-8859-1?Q?aVXdOi1uUA9BapM7MyutNHMr526hBEIzacGTQt7D4DTEKJfil4gB6GwS4E?= =?iso-8859-1?Q?pDVfCh9UNiJfQaVVyyFahxzb+cgmU+iR6VF5FLXLW7fz7OCTZDmjHojYcN?= =?iso-8859-1?Q?z5YT/zhs/wv5WRgh+pR33ShnIB1rG0UwYdq/IFUiG5ZsWbidFcU7TiXeK8?= =?iso-8859-1?Q?5HFfzbMGKrl8YjVsxb0iEXFa9Zh9D99hiWjkkjs8LckF2q2WA3JyxUD7UJ?= =?iso-8859-1?Q?WE7CJsHF65/f+G5STyuHHxv/ZP9vaFZYfpWAnGqtxh+neUu3zNvXKliNEs?= =?iso-8859-1?Q?ME7X9vUA78+DjAbIT34pF+A5un0kQmdaikviQpdshID+JK5Y7JvfNUBL2X?= =?iso-8859-1?Q?PBL/MQMopgNlZSuzCM+8nhs5RbS3n9VS67ql3utEKZkeTbIZfKd+CLM6wI?= =?iso-8859-1?Q?WLiAA8qrrdJJWU88GVxgntNHzFUHUr7pBxW0U8Q8nMLbYR+5eNDmoywD6Z?= =?iso-8859-1?Q?gTlCkPpFOygjKh619WeSui0Nars5WK793SjTJvYbqoxABvxpra3tyinYnF?= =?iso-8859-1?Q?DYvfKjpPn/sRU6sKZZXjuPbDndW7NqSVau9mEhjS6T4OibKsi0/GA9jyGj?= =?iso-8859-1?Q?QedL1BltFMafEmrs+m8tO9z9xXq+LkpVpkJLDV0WAOHs7GDXaSpsFATgb9?= =?iso-8859-1?Q?3RoHPZwuxbscB/KynupGw2/kDpWkS8wMVTpzr12FsBRKjYuCEJjTPNjIBq?= =?iso-8859-1?Q?AxCHaSi+kZvLk0lRzC29KwD8b1T7WYwrLVkSc/xPUq6zhdenPRwMgsX8Au?= =?iso-8859-1?Q?HKp25FSisJ+IkNvKdcQ?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2757; 6:bxsY7h/N8miBl0s6AM/z8GDuzpUMoeaijPf6lfQuBwf8yZKYUl6DkWecpkgKcFJilxt6CTKNWPuNmbKoWba2VIiMCvsmIwk01zR5zHaq11HKpPT711dASFgjIjrsv1fy0keNGGgnuoZuS2JPlY7aafqf30PU3thLeg2XQMfLxQgVS6yG44AmOb22sX0QxwS6COYm1EnsA8Yn6ONBS0QIZDRPRcpdsMq+HyG6+9qwzooo1YNyJXDjrDCFpCx/7o4p/jr1bMbo3SiY+jLgYy+9WBaK3Acp2nX4Wfkw5oveq4SbQWOmgR6hu+l34MGpcf4V/lVOQbcPl28LOeqovBWtuh80PykPhrcOXufYGRIoH6BiDxhuu/ob2bOPUZIqka0cJ31MASvpMhhcsFyz6zxV0xjXOr4CDW2xE7Zxlqo0p882kcTRsnQjG1JOvLRYNqUI1n9FcRDcIMdG9JkyxJvUo4D1yefBLjo9K0T7J9c5LQoLXr4RL9suRcLp4U2eVDoSaeUUEOqVcN6OOL+035/szA==; 5:uZolZUcZTXxjdGVz9FfFUAjeD5h60OImpMnCEFGbFMobJCyyoVh2QWr7NbmKl/mihdvuYCEB5Ff3v6VvucCl37u8vKSzWEZ67qChvzxBNlmP5f+Vbzg9EWiIySqZK7sTF2AgwaAob5EVt8xDZZrtAA==; 24:LBLFL3A8+ZX9B6u2qiBLwAdLjkwOKVX6vu4lPaqQlhXDd6uCLJQDuKOVM6gOCILtQgMpnbCH0qaD348fUVVcx38uYHhd3S907Gf7dQUJAA4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2757; 7:swNs0B3trhF/dcmLXPSd2DwPLJq5AkIhJnLaI2rH/YqScoQDlh49BJduz6FM6q+D5D9ha8dthbs+WLCPcw7cl56jQ/cRLggTQkUWxmIm5nLVp2AXrrWJoZx0QlDIrgmDenw/M8JV2v4mLPcz8intzcfSPbjeA0SKMLp8lJ5c1RX5cg0qHSyApVo2pnnwdNYIINhFT5hVeLjku217cR33txfVj64+YVXhDcOlWEHDFFUhdaRPu2uULWoSfHG7im6ZnQYD73Wx4QgyHsCpIXZNy31vyp7T7INipUDALCBoECpH8Y2sZZgUcnzZEGtpKoXiulh+AgThvImrW283VhR4+g== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2017 09:11:41.9842 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2757 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 09:11:47 -0000 I just got a bounce for this message for the chairs alias. The same thing just happened on v6ops and the explanation is that when outlook (not something I want to use but have no choice about) resends a message, it can use one of 50 or more different addresses and grey listing cannot cope with that and the message bounces. This is a property of using ...@tools.ietf.org It is different when you use @ietf.org. I have Henrik's and Glen's replies on 13apr2017 but they are not on the v6ops list. Fred Baker was conducting a poll and set the reply address to the chairs alias so as not to clutter the list; he lost most of the replies. My (pessimistic) conclusion is that most mail to ...@tools.ietf.org will not get through, but then I am pessimistic:-( Tom Petch ----- Original Message ----- From: "t.petch" To: "Jeff Tantsura" ; "RTGWG" Cc: "rtgwg-chairs" Sent: Friday, April 21, 2017 4:55 PM > "JT: Xufeng presented 4 considerations yesterday on how to proceed, > please take a look." > > Do you have a reference for that, preferrably an I-D and not PowerPoint? > > Tom Petch > > > ----- Original Message ----- > From: "Jeff Tantsura" > To: "RTGWG" > Cc: "rtgwg-chairs" > Sent: Friday, April 14, 2017 12:08 AM > > > > The minutes have been published at: > https://datatracker.ietf.org/doc/minutes-98-rtgwg/ > > Please provide your comments. > > > > Thanks! > > Jeff & Chris From nobody Tue Apr 25 06:45:48 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD6512EB28; Tue, 25 Apr 2017 06:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKfcOYUdyPHw; Tue, 25 Apr 2017 06:45:37 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E0F12944A; Tue, 25 Apr 2017 06:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1820; q=dns/txt; s=iport; t=1493127937; x=1494337537; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TwBl4B+ljnSZnFnYPKPrE4Ik9K7YCZT1TX+PTx7PaGo=; b=RW/RY+RhVYPHs4KhYwXoIEQaJG32UZLW219gGZiH3phEQKAbQ/4sNK/p 1UQ+ixWqSKIp/ZVMEq//VAZ3u4zZepzGAd/dE2d5ZVTngGpqULiD/FPR9 i4Thdv789MCGw2+h7O8JEKhsjqy/Gf6BWrD2VMGecs8gHQx7zkEZhLINg c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQBBUv9Y/49dJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQwHg2CKFaJvhGSCDyyFeAIag3c/GAECAQEBAQEBAWsohRY?= =?us-ascii?q?GIxFFEAIBCBoCJgICAjAVBQsCBAENBYocDqpmgiaLGgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARgFgQuKPoQpEQGDIoJfBYk6lAcBhxaLb4IAhTODZYY/lBgBHzh+CGM?= =?us-ascii?q?VhWKBSnUBhweBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,249,1488844800"; d="scan'208";a="414460662" 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; 25 Apr 2017 13:45:36 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3PDjZ8n021260 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 13:45:36 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Apr 2017 09:45:35 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 25 Apr 2017 09:45:35 -0400 From: "Acee Lindem (acee)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" Subject: =?utf-8?B?UmU6IE1pcmphIEvDvGhsZXdpbmQncyBObyBPYmplY3Rpb24gb24gZHJhZnQt?= =?utf-8?Q?ietf-rtgwg-yang-key-chain-20:_(with_COMMENT)?= Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-rtgwg-yang-key-chain-20:_(with_COMMENT)?= Thread-Index: AQHSvY+AwASVRD+5OUOEsOIC+86Z3KHWGUyA Date: Tue, 25 Apr 2017 13:45:35 +0000 Message-ID: References: <149310271488.7096.4956898183982418315.idtracker@ietfa.amsl.com> In-Reply-To: <149310271488.7096.4956898183982418315.idtracker@ietfa.amsl.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.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <74A4F02A4625DA44B201CCDF2A48BE6F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 13:45:39 -0000 TWlyamEsDQoNCk9uIDQvMjUvMTcsIDI6NDUgQU0sICJNaXJqYSBLw7xobGV3aW5kIiA8aWV0ZkBr dWVobGV3aW5kLm5ldD4gd3JvdGU6DQoNCj5NaXJqYSBLw7xobGV3aW5kIGhhcyBlbnRlcmVkIHRo ZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPmRyYWZ0LWlldGYtcnRnd2cteWFuZy1r ZXktY2hhaW4tMjA6IE5vIE9iamVjdGlvbg0KPg0KPldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtl ZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPmVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0 aGlzDQo+aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+DQo+DQo+UGxlYXNlIHJl ZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVy aWEuaHRtbA0KPmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09N TUVOVCBwb3NpdGlvbnMuDQo+DQo+DQo+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJh bGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4vDQo+DQo+DQo+DQo+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPkZ1bGx5IGVkaXRv cmlhbCBjb21tZW50Og0KPnNlY3Rpb24gMSBpcyBqdXN0IGEgY29weSBvZiB0aGUgYWJzdHJhY3Ti gKYgdGhpcyBjb3VsZCBiZSByZW1vdmVkIGFuZA0KPnNlY3Rpb24gMiBjb3VsZCBiZSB1c2VkIGFz IHNlY3Rpb24gMS9pbnRybyAod2l0aCBzZWN0aW9ucyAxLjEsIDEuMiwgYW5kDQo+Mi4xIGFzIHN1 YnNlY3Rpb25zOyBhbmQgc2VjdGlvbiAyLjIuIGNvdWxkIGJlY29tZSB0aGUgbmV3IHNlY3Rpb24g MikNCg0KSeKAmW0gZGVjbGluaW5nIHRoZSBjb21tZW50LiBUaGUg4oCcQWJzdHJhY3TigJ0gYW5k IOKAnEludHJvZHVjdGlvbuKAnSBzZXJ2ZQ0KZW50aXJlbHkgZGlmZmVyZW50IHB1cnBvc2VzIGFu ZCBhcmUgbm90IGFsd2F5cyByZWFkIGluIHN1Y2Nlc3Npb24uIEZvciBvbmUNCnRoaW5nLCB0aGUg bGF0dGVyIGluY2x1ZGVzIHRoZSBhY3R1YWwgZG9jdW1lbnQgcmVmZXJlbmNlcy4NCg0KVGhhbmtz LA0KQWNlZSANCj4NCj4NCg0K From nobody Tue Apr 25 06:48:02 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5139D12F3D5 for ; Tue, 25 Apr 2017 06:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4Z-XI9zD9VL for ; Tue, 25 Apr 2017 06:47:58 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0119.outbound.protection.outlook.com [104.47.40.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4A012ECEF for ; Tue, 25 Apr 2017 06:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SGHcWd2cdl9Q8wQpsl/MTiVDB/JJxe7RXPRqVpSO3Y4=; b=hlUqcgTHVpQmITsOvzb19GccjA3zVo20WnZvyIRtSheGCA0Utt9BB6JebBB1IVJpPiFSwwGJe0qRuivkx+mkvGnGglg78Pq9D2h+9hnAXTJf55IpHpDiBqRK6b6vNbMByNwh5gDKLxfHAZPTG+EpjstNLUOGfVhhgZxKjR3OqCg= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by CY1PR02MB1368.namprd02.prod.outlook.com (10.161.171.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Tue, 25 Apr 2017 13:47:20 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1047.019; Tue, 25 Apr 2017 13:47:18 +0000 From: Xufeng Liu To: Henning Rogge , Jonathan Hardwick , Athanasios Kyparlis , "parikhr@vmware.com" , "zhangmingui@huawei.com" CC: Routing WG Subject: RE: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp Thread-Topic: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp Thread-Index: AQHSvM5DkWzkWiy5OUyGyrzZT7T+E6HWF3bA Date: Tue, 25 Apr 2017 13:47:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=jabil.com; x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR02MB1368; 7:v8qUWbKDnHUC1NJ6YX3V8a/emRk/D7RAFzWBKM7RdkQmVrIutHlsmc6/+lzynRmWMH87l3siKo4iDXHbSBLS6j0WwE+y0rTMEkgplO5bJE7RaReaw3o6mPWPRMrcrIz2utaFkNZkKxBAb5DNBGSfg/drywYh0SWDMyN+QePTPybec3xvzNUyiUJAUDRtyEeKeeDKJ8OvxE8H30Qqfe7woNUK7o0cE0Ugr+LRNoB9Ck/kWMTFudA9L7WWjH26LNOyls4AcX4XX72Xg+nQ/cTLYQCn3RZJrDE85mqL59f5TR+ugfVucA6GOwoQ92qq3BxJZvaLqb3JaV/8nZEDG954pA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39840400002)(39410400002)(39400400002)(39450400003)(39850400002)(39860400002)(24454002)(66654002)(377454003)(33656002)(50986999)(6436002)(189998001)(55016002)(606005)(6506006)(54356999)(7906003)(229853002)(86362001)(2950100002)(230783001)(76176999)(102836003)(6116002)(77096006)(790700001)(74316002)(81166006)(7696004)(2201001)(5660300001)(80792005)(3846002)(25786009)(8676002)(2501003)(8936002)(2906002)(2900100001)(9326002)(3660700001)(3280700002)(6246003)(53936002)(236005)(19609705001)(39060400002)(54896002)(99286003)(4326008)(122556002)(53546009)(9686003)(6306002)(38730400002)(7736002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR02MB1368; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 482032fd-0dd0-40a8-d6da-08d48be19756 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY1PR02MB1368; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(120809045254105)(50582790962513)(21748063052155)(21534305686606); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(6072148); SRVR:CY1PR02MB1368; BCL:0; PCL:0; RULEID:; SRVR:CY1PR02MB1368; x-forefront-prvs: 0288CD37D9 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB0867B806559292BC571E76DBF11E0BN3PR0201MB0867_" MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2017 13:47:18.6723 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR02MB1368 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 13:48:01 -0000 --_000_BN3PR0201MB0867B806559292BC571E76DBF11E0BN3PR0201MB0867_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGVubmluZywNCg0KVGhhbmsgeW91IG11Y2ggZm9yIHRoZSByZXZpZXcuDQoNCllvdSBhcmUg cmlnaHQgYWJvdXQgdGhlIG1hcHBpbmcgZm9yICJhZGRyZXNzIG9mIHRoZSB2aXJ0dWFsIHJvdXRl ciIuIFRoZSBleGlzdGluZyBZQU5HIGRhdGEgbW9kZWwgZm9yIGNvbmZpZ3VyaW5nIGFuZCBtYW5h Z2luZyBJUCBhZGRyZXNzZXMgaXMgUkZDNzI3Nywgd2hpY2ggYXVnbWVudHMgdGhlIGlldGYtaW50 ZXJmYWNlcyBtb2RlbCBzcGVjaWZpZWQgYnkgUkZDNzIyMy4gVGhpcyBWUlJQIG1vZGVsIGZvbGxv d3MgdGhlIHNhbWUgcGFyYWRpZ20uIFN1Y2ggYSBzdHJ1Y3R1cmUgaXMgYWxzbyBWUlJQIHByb3Rv Y29scyBhcmUgdXN1YWxseSBpbXBsZW1lbnRlZC4NCg0KV2Ugd2lsbCBmaXggdGhlIGVycm9yIGlu ICBBcHBlbmRpeCBBLiBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KUmVnYXJkcywNCi0gWHVmZW5n DQoNCkZyb206IEhlbm5pbmcgUm9nZ2UgW21haWx0bzpocm9nZ2VAZ21haWwuY29tXQ0KU2VudDog TW9uZGF5LCBBcHJpbCAyNCwgMjAxNyAzOjQxIEFNDQpUbzogSm9uYXRoYW4gSGFyZHdpY2sgPEpv bmF0aGFuLkhhcmR3aWNrQG1ldGFzd2l0Y2guY29tPjsgWHVmZW5nIExpdSA8WHVmZW5nX0xpdUBq YWJpbC5jb20+OyBBdGhhbmFzaW9zIEt5cGFybGlzIDxBdGhhbmFzaW9zX0t5cGFybGlzQGphYmls LmNvbT47IHBhcmlraHJAdm13YXJlLmNvbTsgemhhbmdtaW5ndWlAaHVhd2VpLmNvbQ0KQ2M6IFJv dXRpbmcgV0cgPHJ0Z3dnQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFJvdXRpbmcgZGlyZWN0b3Jh dGUgUUEgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRnd2cteWFuZy12cnJwDQoNCkhpLA0KDQpKb25h dGhhbiBIYXJkd2ljayBhc2tlZCBtZSB0byBkbyBhbiBlYXJseSByZXZpZXcgb2YgdGhlIGRyYWZ0 LWlldGYtcnRnd2cteWFuZy12cnJwIGRvY3VtZW50IChjdXJyZW50bHkgcmV2aXNpb24gMDIpIGZv ciB0aGUgcm91dGluZyBkaXJlY3RvcmF0ZS4NCg0KVGhlIGRyYWZ0IGl0c2VsZiBpcyBwcmV0dHkg c3RyYWlnaHQgZm9yd2FyZCBhbmQgY29tcGFjdCwgZXNwZWNpYWxseSB3aGVuIHlvdSBjb25zaWRl ciB0aGF0IGEgbG90IG9mIHRleHQgaGFzIHRvIGJlIHJlcGVhdGVkIHR3byBvciBmb3VyIHRpbWVz IChJUHY0L0lQdjYsIGNvbmZpZyB2cy4gcmVhZC1vbmx5IHN0YXRlKS4NCg0KQnV0IEkgaGFkIHF1 aXRlIGEgYml0IG9mIHRyb3VibGUgbWFwcGluZyB0aGUgcGhyYXNlcyBmcm9tIHRoZSBuZXcgZHJh ZnQtaWV0Zi1ydGd3Zy15YW5nLXZycnAtMDIgZG9jdW1lbnQgdG8gdGhlIGV4aXN0aW5nIFZSUlAg ZG9jdW1lbnRzIChlLmcuIFJGQzU3OTgpLiBUaGlzIG1pZ2h0IGNvbWUgZnJvbSBteSB1bmZhbWls YXJpdHkgd2l0aCBWUlJQLg0KDQpUaGUgZHJhZnQgWUFORyBtb2RlbCBhbGxvd3MgdG8gcmVhZCAo aWY6aW50ZXJmYWNlcy1zdGF0ZSkgYW5kIGNvbmZpZ3VyZSAoaWY6aW50ZXJmYWNlcykgdmlydHVh bCBJUCBhZGRyZXNzZXMsIGJ1dCB0aGlzIGRvZXMgbm90IHNlZW0gdG8gYmUgYSBjb21tb24gcGhy YXNlIGZyb20gdGhlIFJGQ3MuIElzIGl0IHRoZSBzYW1lIGFzICJhZGRyZXNzIG9mIHRoZSB2aXJ0 dWFsIHJvdXRlciIgb2Z0ZW4gbWVudGlvbmVkIGluIFJGQzU3OTg/DQoNCkluIGFkZGl0aW9uIHRv IHRoaXMsIEkgZm91bmQgKEkgdGhpbmspIGEgdHlwbyBvciBpbmNvbnNpc3RlbmN5IGluIEFwcGVu ZGl4IEE6DQp0aGUgYXNjaWkgYXJ0IHNheXMgImV0aDAiIGJ1dCB0cmVlIHNheXMgImV0aDEiLg0K DQpIZW5uaW5nIFJvZ2dlDQoNCk9uIE1vbiwgTWFyIDI3LCAyMDE3IGF0IDU6NDMgUE0sIEpvbmF0 aGFuIEhhcmR3aWNrIDxKb25hdGhhbi5IYXJkd2lja0BtZXRhc3dpdGNoLmNvbTxtYWlsdG86Sm9u YXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb20+PiB3cm90ZToNCkhpIEhlbm5pbmcNCg0KUGxl YXNlIHdvdWxkIHlvdSBkbyBhIHJvdXRpbmcgZGlyZWN0b3JhdGUgZWFybHkgcmV2aWV3IG9mIHRo aXMgZHJhZnQ/ICBXb3VsZCB5b3UgYmUgYWJsZSB0byBkbyBpdCBpbiAyIHRvIDMgd2Vla3M/DQoN Ck1hbnkgdGhhbmtzDQpKb24NCg0KDQpQbGVhc2Ugd291bGQgeW91IGRvIGEgcm91dGluZyBkaXJl Y3RvcmF0ZSBRQSByZXZpZXcgb2YgdGhpcyBkcmFmdD8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRnd2cteWFuZy12cnJwLw0KDQpUaGUgZHJhZnQgaXMgc3Rp bGwgaW4gdGhlIFJUR1dHIGFuZCBpcyByZWFkeSBmb3IgV0cgbGFzdCBjYWxsLiAgVGhlIFdHIGNo YWlycyBoYXZlIGFza2VkIGZvciBhIFFBIHJldmlldyBmcm9tIHRoZSBkaXJlY3RvcmF0ZS4gIFRo ZSBmb2xsb3dpbmcgbGluayBwcm92aWRlcyBndWlkYW5jZSBvbiBRQSByZXZpZXdzLg0KaHR0cHM6 Ly90cmFjLmlldGYub3JnL3RyYWMvcnRnL3dpa2kvUnRnRGlyRG9jUWENCg0KDQoNCg== --_000_BN3PR0201MB0867B806559292BC571E76DBF11E0BN3PR0201MB0867_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjMgMCA1IDkgMCAwIDAgMCAw IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5N c29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBp bjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0 Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5IaSBIZW5uaW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGFuayB5b3Ug bXVjaCBmb3IgdGhlIHJldmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WW91IGFyZSByaWdodCBhYm91dCB0 aGUNCjwvc3Bhbj5tYXBwaW5nIGZvciAmcXVvdDthZGRyZXNzIG9mIHRoZSB2aXJ0dWFsIHJvdXRl ciZxdW90OzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LiBUaGUgZXhpc3RpbmcgWUFORyBkYXRhIG1vZGVsIGZv ciBjb25maWd1cmluZyBhbmQgbWFuYWdpbmcgSVAgYWRkcmVzc2VzIGlzIFJGQzcyNzcsIHdoaWNo IGF1Z21lbnRzIHRoZSBpZXRmLWludGVyZmFjZXMgbW9kZWwgc3BlY2lmaWVkIGJ5IFJGQzcyMjMu DQogVGhpcyBWUlJQIG1vZGVsIGZvbGxvd3MgdGhlIHNhbWUgcGFyYWRpZ20uIFN1Y2ggYSBzdHJ1 Y3R1cmUgaXMgYWxzbyBWUlJQIHByb3RvY29scyBhcmUgdXN1YWxseSBpbXBsZW1lbnRlZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+V2Ugd2lsbCBmaXggdGhlIGVycm9yIGluJm5ic3A7DQo8L3NwYW4+QXBwZW5k aXggQS4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4NCmluIHRoZSBuZXh0IHJldmlzaW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+LSBYdWZlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSGVubmluZyBSb2dnZSBbbWFpbHRvOmhyb2dnZUBnbWFp bC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAyNCwgMjAxNyAzOjQxIEFN PGJyPg0KPGI+VG86PC9iPiBKb25hdGhhbiBIYXJkd2ljayAmbHQ7Sm9uYXRoYW4uSGFyZHdpY2tA bWV0YXN3aXRjaC5jb20mZ3Q7OyBYdWZlbmcgTGl1ICZsdDtYdWZlbmdfTGl1QGphYmlsLmNvbSZn dDs7IEF0aGFuYXNpb3MgS3lwYXJsaXMgJmx0O0F0aGFuYXNpb3NfS3lwYXJsaXNAamFiaWwuY29t Jmd0OzsgcGFyaWtockB2bXdhcmUuY29tOyB6aGFuZ21pbmd1aUBodWF3ZWkuY29tPGJyPg0KPGI+ Q2M6PC9iPiBSb3V0aW5nIFdHICZsdDtydGd3Z0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFJvdXRpbmcgZGlyZWN0b3JhdGUgUUEgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRn d2cteWFuZy12cnJwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Sm9uYXRoYW4gSGFyZHdpY2sgYXNrZWQgbWUgdG8gZG8gYW4gZWFy bHkgcmV2aWV3IG9mIHRoZSBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmctdnJycCBkb2N1bWVudCAoY3Vy cmVudGx5IHJldmlzaW9uIDAyKSBmb3IgdGhlIHJvdXRpbmcgZGlyZWN0b3JhdGUuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkcmFmdCBp dHNlbGYgaXMgcHJldHR5IHN0cmFpZ2h0IGZvcndhcmQgYW5kIGNvbXBhY3QsIGVzcGVjaWFsbHkg d2hlbiB5b3UgY29uc2lkZXIgdGhhdCBhIGxvdCBvZiB0ZXh0IGhhcyB0byBiZSByZXBlYXRlZCB0 d28gb3IgZm91ciB0aW1lcyAoSVB2NC9JUHY2LCBjb25maWcgdnMuIHJlYWQtb25seSBzdGF0ZSku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1 dCBJIGhhZCBxdWl0ZSBhIGJpdCBvZiB0cm91YmxlIG1hcHBpbmcgdGhlIHBocmFzZXMgZnJvbSB0 aGUgbmV3IGRyYWZ0LWlldGYtcnRnd2cteWFuZy12cnJwLTAyIGRvY3VtZW50IHRvIHRoZSBleGlz dGluZyBWUlJQIGRvY3VtZW50cyAoZS5nLiBSRkM1Nzk4KS4gVGhpcyBtaWdodCBjb21lIGZyb20g bXkgdW5mYW1pbGFyaXR5IHdpdGggVlJSUC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRyYWZ0IFlBTkcgbW9kZWwgYWxsb3dzIHRvIHJl YWQgKGlmOmludGVyZmFjZXMtc3RhdGUpIGFuZCBjb25maWd1cmUgKGlmOmludGVyZmFjZXMpIHZp cnR1YWwgSVAgYWRkcmVzc2VzLCBidXQgdGhpcyBkb2VzIG5vdCBzZWVtIHRvIGJlIGEgY29tbW9u IHBocmFzZSBmcm9tIHRoZSBSRkNzLiBJcyBpdCB0aGUgc2FtZSBhcyAmcXVvdDthZGRyZXNzIG9m IHRoZSB2aXJ0dWFsIHJvdXRlciZxdW90OyBvZnRlbiBtZW50aW9uZWQNCiBpbiBSRkM1Nzk4Pzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBh ZGRpdGlvbiB0byB0aGlzLCBJIGZvdW5kIChJIHRoaW5rKSBhIHR5cG8gb3IgaW5jb25zaXN0ZW5j eSBpbiBBcHBlbmRpeCBBOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+dGhlIGFzY2lpIGFydCBzYXlzICZxdW90O2V0aDAmcXVvdDsgYnV0IHRyZWUg c2F5cyAmcXVvdDtldGgxJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IZW5uaW5nIFJvZ2dlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciAyNywgMjAxNyBhdCA1OjQzIFBNLCBK b25hdGhhbiBIYXJkd2ljayAmbHQ7PGEgaHJlZj0ibWFpbHRvOkpvbmF0aGFuLkhhcmR3aWNrQG1l dGFzd2l0Y2guY29tIiB0YXJnZXQ9Il9ibGFuayI+Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRj aC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5IaSBIZW5uaW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UGxlYXNlIHdvdWxkIHlvdSBkbyBhIHJvdXRp bmcgZGlyZWN0b3JhdGUgZWFybHkgcmV2aWV3IG9mIHRoaXMgZHJhZnQ/Jm5ic3A7IFdvdWxkIHlv dSBiZSBhYmxlIHRvIGRvIGl0IGluIDIgdG8gMyB3ZWVrcz88L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5NYW55IHRoYW5rczwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkpvbjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpkb3VibGUgd2luZG93dGV4dCAyLjI1cHQ7cGFk ZGluZzowaW4gMGluIDEuMHB0IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlBsZWFzZSB3b3VsZCB5b3UgZG8gYSByb3V0 aW5nIGRpcmVjdG9yYXRlIFFBIHJldmlldyBvZiB0aGlzIGRyYWZ0PzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXJ0Z3dnLXlhbmctdnJycC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Z3dnLXlhbmctdnJycC88L2E+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGUgZHJhZnQgaXMgc3RpbGwgaW4g dGhlIFJUR1dHIGFuZCBpcyByZWFkeSBmb3IgV0cgbGFzdCBjYWxsLiZuYnNwOyBUaGUgV0cgY2hh aXJzIGhhdmUgYXNrZWQgZm9yIGEgUUEgcmV2aWV3IGZyb20gdGhlIGRpcmVjdG9yYXRlLiZuYnNw OyBUaGUgZm9sbG93aW5nIGxpbmsgcHJvdmlkZXMgZ3VpZGFuY2UNCiBvbiBRQSByZXZpZXdzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tR0IiPjxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3J0Zy93aWtpL1J0Z0Rp ckRvY1FhIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvcnRnL3dp a2kvUnRnRGlyRG9jUWE8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN3PR0201MB0867B806559292BC571E76DBF11E0BN3PR0201MB0867_-- From nobody Tue Apr 25 06:50:06 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBDF12F092 for ; Tue, 25 Apr 2017 06:50:04 -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, 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 gn-x_Jj4wPKQ for ; Tue, 25 Apr 2017 06:50:02 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793DE12ECEF for ; Tue, 25 Apr 2017 06:50:02 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id y33so139983677qta.2 for ; Tue, 25 Apr 2017 06:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iHGBE/SAC8Z2cZcQYZ/hwgji6ruspyDesuznY8If4aI=; b=jzfmm/brLIXCVY/BKpKtd+aH6cKwaZRquRbud1+qGGw+T/2Egk9t78W7rI/y/i5dWe zIAvisbCEhpa6Z+R+oe3kwUfS7yMY2bLTmRVqycGGfY31jUamsGt1Z2Gp+YMJR8IObKr jiYTb/vrNh3VLLXqlVVeYsRLqbJGHgQaH2SbOCC8hoyd+q/cAg6VhGoFWr5SfegIZZXE aoQiuq890i96mpv57XNJ1qvIfd2e/DfAl3u/h1L96wjUk0a9Eo4eE8lMJ8Bow66xEN9u DWg+6L1X05AKPX/kqfAmrQocFE3cCCTeYae6BPNwcfRunjhdjIwaRi4oQoY3tpgd8J7c Y2lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iHGBE/SAC8Z2cZcQYZ/hwgji6ruspyDesuznY8If4aI=; b=ipHGorV9rTYOvwADfHBPHVz/SoAzflifyY3iIlqYJyzwG+QZWclLGRYgi/1jkj+h7f q1NpBUpveN47oENfJ+SBu9oWgiBYYh1qtgrfInTqs8YphnvArxxEXJRze7ghJY1+l+hF lgIYOd347+cDUjMfVdeyIHVOOiH64vzuK10/vflNghFlUkzgVgSfoe77X+NEQe002sdj F8kxyllqofTc9iDq6iw7TkMKyyejqHyqrfCExeDwongOwUOJdtNlSuUFYjrewqnSgboK zC9vzR/os5DzPvl9oBh3F1dwF+B7bFW/nALVjp9ID3QmdlcjpZGjPcmINPFOaFUSf5kL 4c9g== X-Gm-Message-State: AN3rC/7+YE6SnNW4u8BE+vja3S8iqAg/FlEDXtBYzvDK4d3RmFqiLkJp CLlBbUyJN5KgTGGH+2MGsUh3lFe6yA== X-Received: by 10.200.44.205 with SMTP id 13mr29315542qtx.108.1493128201633; Tue, 25 Apr 2017 06:50:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.47.129 with HTTP; Tue, 25 Apr 2017 06:49:31 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Tue, 25 Apr 2017 15:49:31 +0200 Message-ID: Subject: Re: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp To: Xufeng Liu Cc: Jonathan Hardwick , Athanasios Kyparlis , "parikhr@vmware.com" , "zhangmingui@huawei.com" , Routing WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 13:50:05 -0000 On Tue, Apr 25, 2017 at 3:47 PM, Xufeng Liu wrote: > > Hi Henning, > > > > Thank you much for the review. > > > > You are right about the mapping for "address of the virtual router". The = existing YANG data model for configuring and managing IP addresses is RFC72= 77, which augments the ietf-interfaces model specified by RFC7223. This VRR= P model follows the same paradigm. Such a structure is also VRRP protocols = are usually implemented. Maybe the naming of the variables or the explanation of them could be improved to explicitly state this. Henning > > > > We will fix the error in Appendix A. in the next revision. > > > > Regards, > > - Xufeng > > > > From: Henning Rogge [mailto:hrogge@gmail.com] > Sent: Monday, April 24, 2017 3:41 AM > To: Jonathan Hardwick ; Xufeng Liu ; Athanasios Kyparlis ; pa= rikhr@vmware.com; zhangmingui@huawei.com > Cc: Routing WG > Subject: Re: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp > > > > Hi, > > > > Jonathan Hardwick asked me to do an early review of the draft-ietf-rtgwg-= yang-vrrp document (currently revision 02) for the routing directorate. > > > > The draft itself is pretty straight forward and compact, especially when = you consider that a lot of text has to be repeated two or four times (IPv4/= IPv6, config vs. read-only state). > > > > But I had quite a bit of trouble mapping the phrases from the new draft-i= etf-rtgwg-yang-vrrp-02 document to the existing VRRP documents (e.g. RFC579= 8). This might come from my unfamilarity with VRRP. > > > > The draft YANG model allows to read (if:interfaces-state) and configure (= if:interfaces) virtual IP addresses, but this does not seem to be a common = phrase from the RFCs. Is it the same as "address of the virtual router" oft= en mentioned in RFC5798? > > > > In addition to this, I found (I think) a typo or inconsistency in Appendi= x A: > > the ascii art says "eth0" but tree says "eth1". > > > > Henning Rogge > > > > On Mon, Mar 27, 2017 at 5:43 PM, Jonathan Hardwick wrote: > > Hi Henning > > > > Please would you do a routing directorate early review of this draft? Wo= uld you be able to do it in 2 to 3 weeks? > > > > Many thanks > > Jon > > > > > > Please would you do a routing directorate QA review of this draft? > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-vrrp/ > > > > The draft is still in the RTGWG and is ready for WG last call. The WG ch= airs have asked for a QA review from the directorate. The following link p= rovides guidance on QA reviews. > > https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa > > > > > > From nobody Tue Apr 25 07:12:17 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B19612ECA6; Tue, 25 Apr 2017 07:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJi_8kDDRi-N; Tue, 25 Apr 2017 07:12:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E362813010D; Tue, 25 Apr 2017 07:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3002; q=dns/txt; s=iport; t=1493129522; x=1494339122; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=a82kdi57Jn+lLSRNTE/owa4mwXS1tnpbJq+rBLW3sjU=; b=LhNBNawnS65vbmXkfDh/MbuXB4pibXhjK9rd18ixu3EVORK4LS0iWbQV fdCM4zhghTWTnQqpq8f7pOFl0B2ru79fTtbpS6ENq20nJDoaV6pWAu4rZ JndFchP8Tr0otp1v6+HlOMt+rCkBEdZkclAAMrWRvt040Uvr/lv6mcCAw 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQCXWP9Y/40NJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgykrYYEMB4NgihWnU4IPLIV4AhqDdz8YAQIBAQEBAQEBayiFFgY?= =?us-ascii?q?jEUUQAgEIGgImAgICMBUQAgQBDQWKHA6qZIImixoBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEYBYELij6EKREBgyKCXwWJOpQHAYcWi2+CAIUzg2WGP5QYAR84fghjFYV?= =?us-ascii?q?igUp1AYcHgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,249,1488844800"; d="scan'208";a="235515715" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2017 14:12:01 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3PEC0DX025613 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 14:12:00 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Apr 2017 10:12:00 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 25 Apr 2017 10:12:00 -0400 From: "Acee Lindem (acee)" To: Ben Campbell , The IESG CC: "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" Subject: Re: Ben Campbell's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Ben Campbell's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvWnZ3dEogGVv202j3BmJQ1ViQKHWIPYA Date: Tue, 25 Apr 2017 14:12:00 +0000 Message-ID: References: <149308654029.6988.16576150880916114905.idtracker@ietfa.amsl.com> In-Reply-To: <149308654029.6988.16576150880916114905.idtracker@ietfa.amsl.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.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <83761F981AE8674EBEDF8FE604A388F5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 14:12:15 -0000 SGkgQmVuLCANCg0KT24gNC8yNC8xNywgMTA6MTUgUE0sICJCZW4gQ2FtcGJlbGwiIDxiZW5Abm9z dHJ1bS5jb20+IHdyb3RlOg0KDQo+QmVuIENhbXBiZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPmRyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4t MjA6IE5vIE9iamVjdGlvbg0KPg0KPldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1 YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPmVtYWlsIGFkZHJlc3NlcyBpbmNs dWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+aW50 cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+DQo+DQo+UGxlYXNlIHJlZmVyIHRvIGh0 dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0K PmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3Np dGlvbnMuDQo+DQo+DQo+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4vDQo+DQo+DQo+DQo+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPkp1c3QgYSBjb3VwbGUgb2YgZWRp dG9yaWFsIGNvbW1lbnRzOg0KPg0KPi0yLjI6ICJUaGlzIE1BWSBiZSBhY2NvbXBsaXNoZWQgYnkg YWNjZXB0aW5nIGFsbCB0aGUga2V5cyB0aGF0IGhhdmUgYQ0KPnZhbGlkIGFjY2VwdCBsaWZldGlt ZSBhbmQgc2VuZGluZyB0aGUga2V5IHdpdGggdGhlIG1vc3QgcmVjZW50IHNlbmQNCj5saWZldGlt ZS4iDQo+QXMgd3JpdHRlbiwgdGhhdCBNQVkgc291bmRzIGxpa2UgYSBzdGF0ZW1lbnQgb2YgZmFj dCByYXRoZXIgdGhhbiBhDQo+bm9ybWF0aXZlIHJlcXVpcmVtZW50LiBJZiBpdCdzIGludGVuZGVk IGFzIG5vcm1hdGl2ZSwgcGxlYXNlIGNvbnNpZGVyDQo+cmVzdGF0aW5nIGluIHRlcm1zIG9mIGFj dHVhbCBwcm9jZWR1cmUgKGUuZy4gIlRoZSByZWNlaXZlciBNQVkgYWNjZXB0DQo+Li4uIikNCg0K SSBjb3VsZCBlaXRoZXIgcmVzdGF0ZSBpdCBvciBzaW1wbHkgcmVwbGFjZSB0aGUg4oCcTUFZ4oCd IHdpdGgg4oCcY2Fu4oCdLiBTaW5jZQ0Kd2hldGhlciBvciBub3QgZ3JhY2VmdWwga2V5IHJvbGwt b3ZlciBjYW4gYmUgYWNjb21wbGlzaGVkIHdpdGgga2V5LWNoYWlucw0KaGFzIGJlZW4gYW4gYXJl YSBvZiBvcGVyYXRvciBjb25mdXNpb24gYXMgd2VsbCBhcyB2ZW5kb3JzIG5vdCBpbXBsZW1lbnRp bmcNCml0IHByb3Blcmx5IGZvciBhbGwgYXBwbGljYXRpb25zLCBJ4oCZbSBnb2luZyB0byBhdHRl bXB0IHRoZSBmb3JtZXIuDQoNCiBUaGUgcmVjZWl2ZXIgTUFZIGFjY2VwdCBhbGwgdGhlIGtleXMg dGhhdCBoYXZlIGEgdmFsaWQgYWNjZXB0DQogbGlmZXRpbWUgYW5kIHRoZW4gTUFZIHNlbmQgdGhl IGtleSB3aXRoIHRoZSBtb3N0IHJlY2VudCBzZW5kDQogbGlmZXRpbWUgdG8gcGVyZm9ybSBncmFj ZWZ1bCBrZXkgcm9sbG92ZXIuDQoNCj4NCj4tMywgZmlyc3QgcGFyYWdyYXBoOiAiSXMgYSAia2V5 IGNoYWluIGtleSIgYSBrZXkgaW4gdGhlIGtleWNoYWluLCBvcg0KPnNvbWV0aGluZyBlbHNlPyAo bWF5YmUgYSBrZXkgX2Zvcl8gdGhlIGtleWNoYWluKT8NCg0KVGhpcyBpcyBvbmUga2V5IGZyb20g YSBrZXkgY2hhaW4uIEluIHRoZSBpZXRmLWtleS1jaGFpbiBtb2RlbCwgd2UgdXNlZCB0bw0KY2Fs bCB0aGVzZSBrZXktZW50cnkocykgcmF0aGVyIHRoYW4ga2V5KHMpLiBIb3dldmVyLCB0aGlzIHdh cyBzaW1wbGlmaWVkDQpiYXNlZCBvbiByZXZpZXdzLiBJIGJlbGlldmUgaXQgd2FzIE1hcnRpbiBC am9ya2x1bmQgd2hvIHN1Z2dlc3RlZCBqdXN0DQpjYWxsaW5nIHRoZW0ga2V5cy4gSWYgeW91IHJl YWQgdGhlIGVudGlyZSBwYXJhZ3JhcGgsIEkgYmVsaWV2ZSB0aGUgY29udGV4dA0KaXMgY2xlYXIu ICANCg0KVGhhbmtzLA0KQWNlZSANCj4NCg0K From nobody Tue Apr 25 07:33:37 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A257913166C; Tue, 25 Apr 2017 07:33:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?UmFkZWsgS3JlasSNw60=?= To: Cc: rtgwg@ietf.org, draft-ietf-rtgwg-routing-types.all@ietf.org Subject: Yangdoctors early review of draft-ietf-rtgwg-routing-types-02 X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149313081463.20674.12248799201489075415@ietfa.amsl.com> Date: Tue, 25 Apr 2017 07:33:34 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 14:33:35 -0000 Reviewer: Radek Krejčí Review result: Ready with Nits YANG module: - add reference to import statements (both imports are from RFC 6021) - use IETF boilerplate with contact and description with copyright - cleanup unnecessary comments (such as "address-family" before the address-family identity, in general those starting with // in typedefs section) - keep blank lines before and _after_ section comments (/*** ***/) to be consistent with other ietf-*-types documents - timer-multiplier - think about renaming this type. According to the description, the value should be interpreted as a kind of limit or threshold, multiplier is not commonly understood as kind of restriction/limitation, but maybe this is just my personal feeling, handle this as an input from a reader, not a YANG doctor. draft: - section 7.1 Normative references MUST contain references to all the imported modules, so you are missing references to RFC 6021. You also SHOULD/MAY add the references to the documents referenced in the module (such as RFC 4360 and others) to the appropriate Reference section in the draft. Radek From nobody Tue Apr 25 07:41:03 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31083131BB1; Tue, 25 Apr 2017 07:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 Qk_6Gyd58og0; Tue, 25 Apr 2017 07:40:53 -0700 (PDT) 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 96037131BA5; Tue, 25 Apr 2017 07:38:16 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3PEc5wM089128 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Apr 2017 09:38:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Ben Campbell's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) From: Ben Campbell In-Reply-To: Date: Tue, 25 Apr 2017 09:38:06 -0500 Cc: The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <820D181D-8AA7-49DB-87BC-1496B72C49E0@nostrum.com> References: <149308654029.6988.16576150880916114905.idtracker@ietfa.amsl.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 14:41:02 -0000 > On Apr 25, 2017, at 9:12 AM, Acee Lindem (acee) = wrote: >=20 > Hi Ben,=20 >=20 > On 4/24/17, 10:15 PM, "Ben Campbell" wrote: >=20 >> Ben Campbell has entered the following ballot position for >> draft-ietf-rtgwg-yang-key-chain-20: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Just a couple of editorial comments: >>=20 >> -2.2: "This MAY be accomplished by accepting all the keys that have a >> valid accept lifetime and sending the key with the most recent send >> lifetime." >> As written, that MAY sounds like a statement of fact rather than a >> normative requirement. If it's intended as normative, please consider >> restating in terms of actual procedure (e.g. "The receiver MAY accept >> ...") >=20 > I could either restate it or simply replace the =E2=80=9CMAY=E2=80=9D = with =E2=80=9Ccan=E2=80=9D. Since > whether or not graceful key roll-over can be accomplished with = key-chains > has been an area of operator confusion as well as vendors not = implementing > it properly for all applications, I=E2=80=99m going to attempt the = former. >=20 > The receiver MAY accept all the keys that have a valid accept > lifetime and then MAY send the key with the most recent send > lifetime to perform graceful key rollover. That works for me, except maybe =E2=80=9Creceiver=E2=80=9D doesn=E2=80=99t= make as much sense if we are talking about both accepting and sending. >=20 >>=20 >> -3, first paragraph: "Is a "key chain key" a key in the keychain, or >> something else? (maybe a key _for_ the keychain)? >=20 > This is one key from a key chain. In the ietf-key-chain model, we used = to > call these key-entry(s) rather than key(s). However, this was = simplified > based on reviews. I believe it was Martin Bjorklund who suggested just > calling them keys. If you read the entire paragraph, I believe the = context > is clear. =46rom the context, I guessed we were likely talking about a key in the = key chain. But I had to stop and think about it. Maybe =E2=80=9Cmember = of the keychain=E2=80=9D? > =20 >=20 > Thanks, > Acee=20 >>=20 >=20 From nobody Tue Apr 25 07:48:35 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF6C131521; Tue, 25 Apr 2017 07:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vX8mWJYyXQHp; Tue, 25 Apr 2017 07:48:22 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41CB1314B2; Tue, 25 Apr 2017 07:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4570; q=dns/txt; s=iport; t=1493131654; x=1494341254; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=10zNK/el4npXRnaZfmROjqsAkTBAYNi0mux/TJzXBYI=; b=fot58p9Y+tKlcoDYQyCgi7xITup8xPxbtn1CimXKW6TPzJ8RzcJa3FJP XdhDieRTqxjs49Ebpkmjb6mBU8JgXhWgVHIcZ+DAR8fSrXHy+q4ofn/p4 aLE5h3EGHpKb9D0iZXGtI5++OXCJu45EkuIBOnqz0sCj2Jxi5D2RhbdBO k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQAWYf9Y/5tdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQwHg2CKFZFulWWCDyyFeAIag3o/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEjEUUQAgEIGAICJgICAjAVEAIEDgWKFAgOqkKCJosZAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWBC4o+hCkRARyDBoJfBYk6lAcBhxaLb4IAhTODZYY/lBg?= =?us-ascii?q?BHzh+CGMVRIUegUp1AYcHgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,249,1488844800"; d="scan'208";a="417489965" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2017 14:47:33 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3PElX7Y013362 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 14:47:33 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Apr 2017 10:47:32 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 25 Apr 2017 10:47:32 -0400 From: "Acee Lindem (acee)" To: Ben Campbell CC: The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" Subject: Re: Ben Campbell's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Ben Campbell's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvWnZ3dEogGVv202j3BmJQ1ViQKHWIPYAgABKXgD//7+QAA== Date: Tue, 25 Apr 2017 14:47:32 +0000 Message-ID: References: <149308654029.6988.16576150880916114905.idtracker@ietfa.amsl.com> <820D181D-8AA7-49DB-87BC-1496B72C49E0@nostrum.com> In-Reply-To: <820D181D-8AA7-49DB-87BC-1496B72C49E0@nostrum.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.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <8B3EC0EB088F2C4DA616C8C99CEAD7DD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 14:48:25 -0000 DQoNCk9uIDQvMjUvMTcsIDEwOjM4IEFNLCAiQmVuIENhbXBiZWxsIiA8YmVuQG5vc3RydW0uY29t PiB3cm90ZToNCg0KPg0KPj4gT24gQXByIDI1LCAyMDE3LCBhdCA5OjEyIEFNLCBBY2VlIExpbmRl bSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+IA0KPj4gSGkgQmVuLCANCj4+IA0K Pj4gT24gNC8yNC8xNywgMTA6MTUgUE0sICJCZW4gQ2FtcGJlbGwiIDxiZW5Abm9zdHJ1bS5jb20+ IHdyb3RlOg0KPj4gDQo+Pj4gQmVuIENhbXBiZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcg YmFsbG90IHBvc2l0aW9uIGZvcg0KPj4+IGRyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4t MjA6IE5vIE9iamVjdGlvbg0KPj4+IA0KPj4+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPj4+IGVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0 aGlzDQo+Pj4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+Pj4gDQo+Pj4gDQo+ Pj4gUGxlYXNlIHJlZmVyIHRvDQo+Pj5odHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVu dC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4+PiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPj4+IA0KPj4+IA0KPj4+IFRoZSBk b2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQg aGVyZToNCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0 Z3dnLXlhbmcta2V5LWNoYWluLw0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4+PiBDT01NRU5UOg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiANCj4+PiBKdXN0IGEgY291cGxl IG9mIGVkaXRvcmlhbCBjb21tZW50czoNCj4+PiANCj4+PiAtMi4yOiAiVGhpcyBNQVkgYmUgYWNj b21wbGlzaGVkIGJ5IGFjY2VwdGluZyBhbGwgdGhlIGtleXMgdGhhdCBoYXZlIGENCj4+PiB2YWxp ZCBhY2NlcHQgbGlmZXRpbWUgYW5kIHNlbmRpbmcgdGhlIGtleSB3aXRoIHRoZSBtb3N0IHJlY2Vu dCBzZW5kDQo+Pj4gbGlmZXRpbWUuIg0KPj4+IEFzIHdyaXR0ZW4sIHRoYXQgTUFZIHNvdW5kcyBs aWtlIGEgc3RhdGVtZW50IG9mIGZhY3QgcmF0aGVyIHRoYW4gYQ0KPj4+IG5vcm1hdGl2ZSByZXF1 aXJlbWVudC4gSWYgaXQncyBpbnRlbmRlZCBhcyBub3JtYXRpdmUsIHBsZWFzZSBjb25zaWRlcg0K Pj4+IHJlc3RhdGluZyBpbiB0ZXJtcyBvZiBhY3R1YWwgcHJvY2VkdXJlIChlLmcuICJUaGUgcmVj ZWl2ZXIgTUFZIGFjY2VwdA0KPj4+IC4uLiIpDQo+PiANCj4+IEkgY291bGQgZWl0aGVyIHJlc3Rh dGUgaXQgb3Igc2ltcGx5IHJlcGxhY2UgdGhlIOKAnE1BWeKAnSB3aXRoIOKAnGNhbuKAnS4gU2lu Y2UNCj4+IHdoZXRoZXIgb3Igbm90IGdyYWNlZnVsIGtleSByb2xsLW92ZXIgY2FuIGJlIGFjY29t cGxpc2hlZCB3aXRoDQo+PmtleS1jaGFpbnMNCj4+IGhhcyBiZWVuIGFuIGFyZWEgb2Ygb3BlcmF0 b3IgY29uZnVzaW9uIGFzIHdlbGwgYXMgdmVuZG9ycyBub3QNCj4+aW1wbGVtZW50aW5nDQo+PiBp dCBwcm9wZXJseSBmb3IgYWxsIGFwcGxpY2F0aW9ucywgSeKAmW0gZ29pbmcgdG8gYXR0ZW1wdCB0 aGUgZm9ybWVyLg0KPj4gDQo+PiBUaGUgcmVjZWl2ZXIgTUFZIGFjY2VwdCBhbGwgdGhlIGtleXMg dGhhdCBoYXZlIGEgdmFsaWQgYWNjZXB0DQo+PiBsaWZldGltZSBhbmQgdGhlbiBNQVkgc2VuZCB0 aGUga2V5IHdpdGggdGhlIG1vc3QgcmVjZW50IHNlbmQNCj4+IGxpZmV0aW1lIHRvIHBlcmZvcm0g Z3JhY2VmdWwga2V5IHJvbGxvdmVyLg0KPg0KPlRoYXQgd29ya3MgZm9yIG1lLCBleGNlcHQgbWF5 YmUg4oCccmVjZWl2ZXLigJ0gZG9lc27igJl0IG1ha2UgYXMgbXVjaCBzZW5zZSBpZg0KPndlIGFy ZSB0YWxraW5nIGFib3V0IGJvdGggYWNjZXB0aW5nIGFuZCBzZW5kaW5nLg0KDQpUbyBhY2hpZXZl IGdyYWNlZnVsIGtleSByb2xsb3ZlciwgdGhlIHJlY2VpdmVyIE1BWSBhY2NlcHQgYWxsDQp0aGUg a2V5cyB0aGF0IGhhdmUgYSB2YWxpZCBhY2NlcHQgbGlmZXRpbWUgYW5kIHRoZSBzZW5kZXIgTUFZ DQpzZW5kIHRoZSBrZXkgd2l0aCB0aGUgbW9zdCByZWNlbnQgc2VuZCBsaWZldGltZS4NCg0KDQo+ DQo+PiANCj4+PiANCj4+PiAtMywgZmlyc3QgcGFyYWdyYXBoOiAiSXMgYSAia2V5IGNoYWluIGtl eSIgYSBrZXkgaW4gdGhlIGtleWNoYWluLCBvcg0KPj4+IHNvbWV0aGluZyBlbHNlPyAobWF5YmUg YSBrZXkgX2Zvcl8gdGhlIGtleWNoYWluKT8NCj4+IA0KPj4gVGhpcyBpcyBvbmUga2V5IGZyb20g YSBrZXkgY2hhaW4uIEluIHRoZSBpZXRmLWtleS1jaGFpbiBtb2RlbCwgd2UgdXNlZA0KPj50bw0K Pj4gY2FsbCB0aGVzZSBrZXktZW50cnkocykgcmF0aGVyIHRoYW4ga2V5KHMpLiBIb3dldmVyLCB0 aGlzIHdhcyBzaW1wbGlmaWVkDQo+PiBiYXNlZCBvbiByZXZpZXdzLiBJIGJlbGlldmUgaXQgd2Fz IE1hcnRpbiBCam9ya2x1bmQgd2hvIHN1Z2dlc3RlZCBqdXN0DQo+PiBjYWxsaW5nIHRoZW0ga2V5 cy4gSWYgeW91IHJlYWQgdGhlIGVudGlyZSBwYXJhZ3JhcGgsIEkgYmVsaWV2ZSB0aGUNCj4+Y29u dGV4dA0KPj4gaXMgY2xlYXIuDQo+DQo+RnJvbSB0aGUgY29udGV4dCwgSSBndWVzc2VkIHdlIHdl cmUgbGlrZWx5IHRhbGtpbmcgYWJvdXQgYSBrZXkgaW4gdGhlIGtleQ0KPmNoYWluLiBCdXQgSSBo YWQgdG8gc3RvcCBhbmQgdGhpbmsgYWJvdXQgaXQuIE1heWJlIOKAnG1lbWJlciBvZiB0aGUNCj5r ZXljaGFpbuKAnT8NCg0KVGhlIHJlYXNvbiBJIHVzZSDigJxrZXnigJ0gaXMgdGhhdCBpcyB3aGF0 IHRoZSBsaXN0IGRhdGEgbm9kZSBpcyByZWZlcnJlZCB0bw0KYXMuIFRoZSBhbHRlcm5hdGl2ZSB3 b3VsZCBiZSB0byB1c2Ug4oCca2V5IGxpc3QgZWxlbWVudOKAnSBzbyBpdCBpcyBjbGVhciB0aGF0 DQp0aGUg4oCcTW9kZWwgRGVzaWdu4oCdIHNlY3Rpb24gaXMgcmVmZXJyaW5nIHRvIHRoaXMgZGF0 YSBub2RlIGluIHRoZSBtb2RlbC4gT2YNCmNvdXJzZSwgSSB0aGluayB0aGlzIGlzIGNsZWFyIHdp dGhvdXQgdGhpcy4NCg0KVGhhbmtzLA0KQWNlZSANCg0KDQoNCj4NCj4+ICANCj4+IA0KPj4gVGhh bmtzLA0KPj4gQWNlZSANCj4+PiANCj4+IA0KPg0KDQo= From nobody Tue Apr 25 07:53:39 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9734C1314C1; Tue, 25 Apr 2017 07:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 3yIUDEqN0WFq; Tue, 25 Apr 2017 07:53:28 -0700 (PDT) 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 A3B8B129497; Tue, 25 Apr 2017 07:53:28 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3PErNHf090708 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Apr 2017 09:53:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Ben Campbell's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) From: Ben Campbell In-Reply-To: Date: Tue, 25 Apr 2017 09:53:24 -0500 Cc: The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <24F1B4CB-2439-49DB-AB59-F9B71AA9DDC4@nostrum.com> References: <149308654029.6988.16576150880916114905.idtracker@ietfa.amsl.com> <820D181D-8AA7-49DB-87BC-1496B72C49E0@nostrum.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 14:53:31 -0000 > On Apr 25, 2017, at 9:47 AM, Acee Lindem (acee) = wrote: >=20 >=20 >=20 > On 4/25/17, 10:38 AM, "Ben Campbell" wrote: >=20 >>=20 >>> On Apr 25, 2017, at 9:12 AM, Acee Lindem (acee) = wrote: >>>=20 >>> Hi Ben,=20 >>>=20 >>> On 4/24/17, 10:15 PM, "Ben Campbell" wrote: >>>=20 >>>> Ben Campbell has entered the following ballot position for >>>> draft-ietf-rtgwg-yang-key-chain-20: No Objection >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> Just a couple of editorial comments: >>>>=20 >>>> -2.2: "This MAY be accomplished by accepting all the keys that have = a >>>> valid accept lifetime and sending the key with the most recent send >>>> lifetime." >>>> As written, that MAY sounds like a statement of fact rather than a >>>> normative requirement. If it's intended as normative, please = consider >>>> restating in terms of actual procedure (e.g. "The receiver MAY = accept >>>> ...") >>>=20 >>> I could either restate it or simply replace the =E2=80=9CMAY=E2=80=9D = with =E2=80=9Ccan=E2=80=9D. Since >>> whether or not graceful key roll-over can be accomplished with >>> key-chains >>> has been an area of operator confusion as well as vendors not >>> implementing >>> it properly for all applications, I=E2=80=99m going to attempt the = former. >>>=20 >>> The receiver MAY accept all the keys that have a valid accept >>> lifetime and then MAY send the key with the most recent send >>> lifetime to perform graceful key rollover. >>=20 >> That works for me, except maybe =E2=80=9Creceiver=E2=80=9D doesn=E2=80=99= t make as much sense if >> we are talking about both accepting and sending. >=20 > To achieve graceful key rollover, the receiver MAY accept all > the keys that have a valid accept lifetime and the sender MAY > send the key with the most recent send lifetime. Looks good to me. >=20 >=20 >>=20 >>>=20 >>>>=20 >>>> -3, first paragraph: "Is a "key chain key" a key in the keychain, = or >>>> something else? (maybe a key _for_ the keychain)? >>>=20 >>> This is one key from a key chain. In the ietf-key-chain model, we = used >>> to >>> call these key-entry(s) rather than key(s). However, this was = simplified >>> based on reviews. I believe it was Martin Bjorklund who suggested = just >>> calling them keys. If you read the entire paragraph, I believe the >>> context >>> is clear. >>=20 >> =46rom the context, I guessed we were likely talking about a key in = the key >> chain. But I had to stop and think about it. Maybe =E2=80=9Cmember of = the >> keychain=E2=80=9D? >=20 > The reason I use =E2=80=9Ckey=E2=80=9D is that is what the list data = node is referred to > as. The alternative would be to use =E2=80=9Ckey list element=E2=80=9D = so it is clear that > the =E2=80=9CModel Design=E2=80=9D section is referring to this data = node in the model. Of > course, I think this is clear without this. Okay, I=E2=80=99m convinced. Thanks! Ben. From nobody Tue Apr 25 13:10:39 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E791317B4; Tue, 25 Apr 2017 13:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyczBdNe5adk; Tue, 25 Apr 2017 13:10:35 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC791294D8; Tue, 25 Apr 2017 13:10:32 -0700 (PDT) Received: from localhost (h-13-92.a165.priv.bahnhof.se [155.4.13.92]) by mail.tail-f.com (Postfix) with ESMTPSA id 8F13D1AE047F; Tue, 25 Apr 2017 22:10:28 +0200 (CEST) Date: Tue, 25 Apr 2017 22:10:28 +0200 (CEST) Message-Id: <20170425.221028.1553756754016183420.mbj@tail-f.com> To: rkrejci@cesnet.cz Cc: yang-doctors@ietf.org, draft-ietf-rtgwg-routing-types.all@ietf.org, rtgwg@ietf.org Subject: Re: [yang-doctors] Yangdoctors early review of draft-ietf-rtgwg-routing-types-02 From: Martin Bjorklund In-Reply-To: <149313081463.20674.12248799201489075415@ietfa.amsl.com> References: <149313081463.20674.12248799201489075415@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 20:10:37 -0000 SGksDQoNCkkgYWN0dWFsbHkganVzdCByZWFkIHRoaXMgbW9kdWxlIGFzIHdlbGwsIGFuZCBJIHdh cyB3b25kZXJpbmcgYWJvdXQNCnRoZSAnYWRkcmVzcy1mYW1pbHknIGlkZW50aXR5LiAgU2luY2Ug aXQgaXMgYmFzZWQgb24gYW4gSUFOQSByZWdpc3RyeSwNCnNob3VsZCBpdCBiZSBpbiBhIHNlcGFy YXRlIElBTkEtbWFpbnRhaW5lZCBtb2R1bGUsIGxpa2UgaWFuYS1pZi10eXBlDQppbiBSRkMgNzIy ND8NCg0KDQovbWFydGluDQoNCg0KDQpSYWRlayBLcmVqxI3DrSA8cmtyZWpjaUBjZXNuZXQuY3o+ IHdyb3RlOg0KPiBSZXZpZXdlcjogUmFkZWsgS3JlasSNw60NCj4gUmV2aWV3IHJlc3VsdDogUmVh ZHkgd2l0aCBOaXRzDQo+IA0KPiBZQU5HIG1vZHVsZToNCj4gDQo+IC0gYWRkIHJlZmVyZW5jZSB0 byBpbXBvcnQgc3RhdGVtZW50cyAoYm90aCBpbXBvcnRzIGFyZSBmcm9tIFJGQyA2MDIxKQ0KPiAN Cj4gLSB1c2UgSUVURiBib2lsZXJwbGF0ZSB3aXRoIGNvbnRhY3QgYW5kIGRlc2NyaXB0aW9uIHdp dGggY29weXJpZ2h0DQo+IA0KPiAtIGNsZWFudXAgdW5uZWNlc3NhcnkgY29tbWVudHMgKHN1Y2gg YXMgImFkZHJlc3MtZmFtaWx5IiBiZWZvcmUgdGhlDQo+IGFkZHJlc3MtZmFtaWx5IGlkZW50aXR5 LCBpbiBnZW5lcmFsIHRob3NlIHN0YXJ0aW5nIHdpdGggLy8gaW4gdHlwZWRlZnMNCj4gc2VjdGlv bikNCj4gDQo+IC0ga2VlcCBibGFuayBsaW5lcyBiZWZvcmUgYW5kIF9hZnRlcl8gc2VjdGlvbiBj b21tZW50cyAoLyoqKiAqKiovKSB0bw0KPiBiZSBjb25zaXN0ZW50IHdpdGggb3RoZXIgaWV0Zi0q LXR5cGVzIGRvY3VtZW50cw0KPiANCj4gLSB0aW1lci1tdWx0aXBsaWVyIC0gdGhpbmsgYWJvdXQg cmVuYW1pbmcgdGhpcyB0eXBlLiBBY2NvcmRpbmcgdG8gdGhlDQo+IGRlc2NyaXB0aW9uLCB0aGUg dmFsdWUgc2hvdWxkIGJlIGludGVycHJldGVkIGFzIGEga2luZCBvZiBsaW1pdCBvcg0KPiB0aHJl c2hvbGQsIG11bHRpcGxpZXIgaXMgbm90IGNvbW1vbmx5IHVuZGVyc3Rvb2QgYXMga2luZCBvZg0K PiByZXN0cmljdGlvbi9saW1pdGF0aW9uLCBidXQgbWF5YmUgdGhpcyBpcyBqdXN0IG15IHBlcnNv bmFsIGZlZWxpbmcsDQo+IGhhbmRsZSB0aGlzIGFzIGFuIGlucHV0IGZyb20gYSByZWFkZXIsIG5v dCBhIFlBTkcgZG9jdG9yLg0KPiANCj4gZHJhZnQ6DQo+IA0KPiAtIHNlY3Rpb24gNy4xIE5vcm1h dGl2ZSByZWZlcmVuY2VzIE1VU1QgY29udGFpbiByZWZlcmVuY2VzIHRvIGFsbCB0aGUNCj4gaW1w b3J0ZWQgbW9kdWxlcywgc28geW91IGFyZSBtaXNzaW5nIHJlZmVyZW5jZXMgdG8gUkZDIDYwMjEu IFlvdSBhbHNvDQo+IFNIT1VMRC9NQVkgYWRkIHRoZSByZWZlcmVuY2VzIHRvIHRoZSBkb2N1bWVu dHMgcmVmZXJlbmNlZCBpbiB0aGUNCj4gbW9kdWxlIChzdWNoIGFzIFJGQyA0MzYwIGFuZCBvdGhl cnMpIHRvIHRoZSBhcHByb3ByaWF0ZSBSZWZlcmVuY2UNCj4gc2VjdGlvbiBpbiB0aGUgZHJhZnQu DQo+IA0KPiANCj4gUmFkZWsNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IHlhbmctZG9jdG9ycyBtYWlsaW5nIGxpc3QNCj4geWFuZy1kb2N0 b3JzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8veWFu Zy1kb2N0b3JzDQo= From nobody Tue Apr 25 14:27:47 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CED1200F1; Tue, 25 Apr 2017 14:27:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-rtgwg-yang-key-chain@ietf.org, Jeff Tantsura , rtgwg-chairs@ietf.org, jefftant.ietf@gmail.com, rtgwg@ietf.org Subject: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> Date: Tue, 25 Apr 2017 14:27:40 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:27:40 -0000 Adam Roach has entered the following ballot position for draft-ietf-rtgwg-yang-key-chain-20: 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-rtgwg-yang-key-chain/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - The second paragraph in the Abstract seems very specific for an Abstract. Since this variation is covered in the Introduction, consider removing it from the Abstract. - Since the syntax in section 1.2 is used only in section 3.3 (from which I kept referring back to it), consider moving it down into section 3 somewhere. - Section 2.2 describes a scheme in which the key with the "most recent send lifetime" is used for sending. The data model allows for lifetimes to be indicated with "always." It seems that there should be treatment of the interaction between "most recent" and "always". - The second paragraph of section 3 is a bit non-obvious on first reading -- consider spelling out that one chain has a valid send key but invalid receive key, and vice-versa. - Copyright notice in the YANG file is 2015. Is that intentional? - On page 11, in "grouping lifetime", "case start-end-time", "choice end-time", "case infinite", "description", replace "end-time in infinite" with "end-time is infinite". - On page 14, there's a assertion that hex allows specification of "greater entropy with the same number of octets." It might be worth qualifying this as *stored* octets, since it's demonstrably more octets on the wire. - Section 5 discusses the use of a KEK, distributed out-of-band, to decrypt the keys stored in this format. There appears to be no affordance for indicating the identity of which KEK to use, which would come in handy for the types of key rotation schemes I'm familiar with. Mostly, I'm worried about the "try it and see if it works" approach when you have two valid KEKs (as during a transition), as it's not clear that you will be able to distinguish success from failure in all cases. - Section 5 also suggests keys be encrypted or obfuscated on the device that is to use them, presumably in a way that can be decrypted or unobfuscated using information also on the device. I don't know what the current security area thinking around this is, but given that the information needed to retrieve plaintext keys is necessarily present on the device, this seems like a fig-leaf that provides an illusion of security without providing any real benefit. That mis-impression seems potentially harmful. - The IANA considerations section gives the YANG module prefix as "ietf-key-chain". The YANG module itself defines the prefix as "key-chain". I assume these should match each other? From nobody Tue Apr 25 15:22:59 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AD71279E5; Tue, 25 Apr 2017 15:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7xZKtLbMOKf; Tue, 25 Apr 2017 15:22:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE61128D8B; Tue, 25 Apr 2017 15:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6090; q=dns/txt; s=iport; t=1493158969; x=1494368569; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XGv1qzGCAM9ATxKs5RAxx5ZWF7KOK7h0XEp8gzfz71I=; b=hHTunLWUXEIEavL4zmdw/cefqj/c56dazbUuxzSQ4aOK8LX8nvcN4IGg l1qHD9h0dZydNyOZdjs62iJlR817boqbtD4KniuOIF5JMz35Ua7n10UtI 80dlrP9QyS3ia7Zk9vbd5yRSt7+99H1ur1+7B72OAWupcLwaqLYN96Ave A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQCCy/9Y/4kNJK1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNUYYEMB4NgihWnVIIPLIV4AhqDez8YAQIBAQEBAQEBayiFFgY?= =?us-ascii?q?jEUUQAgEIGgImAgICMBUQAgQBDQUfiX0OqnKCJosqAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBGAWBC4clgxmEKQcKARyDBoJfBYk6BZQCAYcWhluFFIIAGYUaiiSIb4s?= =?us-ascii?q?pAR84fghjFYVigUp1AYcHgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,251,1488844800"; d="scan'208";a="240558236" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2017 22:22:48 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3PMMm6c010990 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Apr 2017 22:22:48 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Apr 2017 18:22:47 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 25 Apr 2017 18:22:47 -0400 From: "Acee Lindem (acee)" To: Adam Roach , The IESG CC: "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvgrQg2iqyhFsfkS24vnExw0B6KHWqNaA Date: Tue, 25 Apr 2017 22:22:47 +0000 Message-ID: References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> In-Reply-To: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.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.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <4912C86CBCE49342993B0D08AA3DEE2D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 22:22:52 -0000 SGkgQWRhbSwgDQoNCk9uIDQvMjUvMTcsIDU6MjcgUE0sICJBZGFtIFJvYWNoIiA8YWRhbUBub3N0 cnVtLmNvbT4gd3JvdGU6DQoNCj5BZGFtIFJvYWNoIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcg YmFsbG90IHBvc2l0aW9uIGZvcg0KPmRyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4tMjA6 IE5vIE9iamVjdGlvbg0KPg0KPldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRl ZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+aW50cm9k dWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+DQo+DQo+UGxlYXNlIHJlZmVyIHRvIGh0dHBz Oi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPmZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuDQo+DQo+DQo+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlv bnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4vDQo+DQo+DQo+DQo+LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPi0gVGhlIHNlY29uZCBwYXJhZ3JhcGgg aW4gdGhlIEFic3RyYWN0IHNlZW1zIHZlcnkgc3BlY2lmaWMgZm9yIGFuDQo+QWJzdHJhY3QuIFNp bmNlIHRoaXMgdmFyaWF0aW9uIGlzIGNvdmVyZWQgaW4gdGhlIEludHJvZHVjdGlvbiwgY29uc2lk ZXINCj5yZW1vdmluZyBpdCBmcm9tIHRoZSBBYnN0cmFjdC4NCg0KQWdyZWVkLiBNYXliZSB0aGlz IHdpbGwgcGFydGlhbGx5IHNhdGlzZnkgTWlyamHigJlzIHJlcXVlc3QgdGhhdCBJIHJlbW92ZQ0K dGhlIOKAnEludHJvZHVjdGlvbiIgYXMgd2VsbC4NCj4NCj4tIFNpbmNlIHRoZSBzeW50YXggaW4g c2VjdGlvbiAxLjIgaXMgdXNlZCBvbmx5IGluIHNlY3Rpb24gMy4zIChmcm9tIHdoaWNoDQo+SSBr ZXB0IHJlZmVycmluZyBiYWNrIHRvIGl0KSwgY29uc2lkZXIgbW92aW5nIGl0IGRvd24gaW50byBz ZWN0aW9uIDMNCj5zb21ld2hlcmUuDQoNCknigJltIGhlc2l0YW50IHRvIGRvIHRoaXMgc2luY2Ug YWxsIHRoZSBvdGhlciBZQU5HIGRvY3VtZW50cyBoYXZlIHRoZSB0cmVlDQpzeW50YXggYXMgYSBz dWItc2VjdGlvbiBvZiB0aGUg4oCcSW50cm9kdWN0aW9u4oCdLiBSZWZlciB0byBSRkMgNzIyMy4N Cj4NCj4tIFNlY3Rpb24gMi4yIGRlc2NyaWJlcyBhIHNjaGVtZSBpbiB3aGljaCB0aGUga2V5IHdp dGggdGhlICJtb3N0IHJlY2VudA0KPnNlbmQgbGlmZXRpbWUiIGlzIHVzZWQgZm9yIHNlbmRpbmcu IFRoZSBkYXRhIG1vZGVsIGFsbG93cyBmb3IgbGlmZXRpbWVzDQo+dG8gYmUgaW5kaWNhdGVkIHdp dGggImFsd2F5cy4iIEl0IHNlZW1zIHRoYXQgdGhlcmUgc2hvdWxkIGJlIHRyZWF0bWVudCBvZg0K PnRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuICJtb3N0IHJlY2VudCIgYW5kICJhbHdheXMiLg0KDQpJ ZiB5b3UgdXNlIOKAnGFsd2F5c+KAnSwgeW914oCZcmUgZ3JhY2VmdWwga2V5IHJvbGwtb3ZlciB3 b27igJl0IGJlIHZlcnkNCmVmZmVjdGl2ZS4gQ291bGQgSSBzYXRpc2Z5IHRoaXMgYnkgZGVmaW5p bmcg4oCcbW9zdCByZWNlbnTigJ0/IEl0IGlzIHRoZSBrZXkNCndpdGggdGhlIGxhdGVzdCBzdGFy dC10aW1l4oCdLg0KPg0KPi0gVGhlIHNlY29uZCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAzIGlzIGEg Yml0IG5vbi1vYnZpb3VzIG9uIGZpcnN0IHJlYWRpbmcNCj4tLSBjb25zaWRlciBzcGVsbGluZyBv dXQgdGhhdCBvbmUgY2hhaW4gaGFzIGEgdmFsaWQgc2VuZCBrZXkgYnV0IGludmFsaWQNCj5yZWNl aXZlIGtleSwgYW5kIHZpY2UtdmVyc2EuDQoNCk9rLiANCj4NCj4tIENvcHlyaWdodCBub3RpY2Ug aW4gdGhlIFlBTkcgZmlsZSBpcyAyMDE1LiBJcyB0aGF0IGludGVudGlvbmFsPw0KDQpXaWxsIHVw ZGF0ZS4gDQo+DQo+LSBPbiBwYWdlIDExLCBpbiAiZ3JvdXBpbmcgbGlmZXRpbWUiLCAiY2FzZSBz dGFydC1lbmQtdGltZSIsICJjaG9pY2UNCj5lbmQtdGltZSIsICJjYXNlIGluZmluaXRlIiwgImRl c2NyaXB0aW9uIiwgcmVwbGFjZSAiZW5kLXRpbWUgaW4gaW5maW5pdGUiDQo+d2l0aCAiZW5kLXRp bWUgaXMgaW5maW5pdGUiLg0KDQpHb29kIGNhdGNoLiBXaWxsIHVwZGF0ZS4NCj4NCj4tIE9uIHBh Z2UgMTQsIHRoZXJlJ3MgYSBhc3NlcnRpb24gdGhhdCBoZXggYWxsb3dzIHNwZWNpZmljYXRpb24g b2YNCj4iZ3JlYXRlciBlbnRyb3B5IHdpdGggdGhlIHNhbWUgbnVtYmVyIG9mIG9jdGV0cy4iIEl0 IG1pZ2h0IGJlIHdvcnRoDQo+cXVhbGlmeWluZyB0aGlzIGFzICpzdG9yZWQqIG9jdGV0cywgc2lu Y2UgaXQncyBkZW1vbnN0cmFibHkgbW9yZSBvY3RldHMNCj5vbiB0aGUgd2lyZS4NCg0KUmlnaHQg LSB3aWxsIGFkZCDigJxpbnRlcm5hbCBrZXktc3RyaW5n4oCdIHRvIHRoZSBhc3NlcnRpb24uDQo+ DQo+LSBTZWN0aW9uIDUgZGlzY3Vzc2VzIHRoZSB1c2Ugb2YgYSBLRUssIGRpc3RyaWJ1dGVkIG91 dC1vZi1iYW5kLCB0bw0KPmRlY3J5cHQgdGhlIGtleXMgc3RvcmVkIGluIHRoaXMgZm9ybWF0LiBU aGVyZSBhcHBlYXJzIHRvIGJlIG5vIGFmZm9yZGFuY2UNCj5mb3IgaW5kaWNhdGluZyB0aGUgaWRl bnRpdHkgb2Ygd2hpY2ggS0VLIHRvIHVzZSwgd2hpY2ggd291bGQgY29tZSBpbg0KPmhhbmR5IGZv ciB0aGUgdHlwZXMgb2Yga2V5IHJvdGF0aW9uIHNjaGVtZXMgSSdtIGZhbWlsaWFyIHdpdGguIE1v c3RseSwNCj5JJ20gd29ycmllZCBhYm91dCB0aGUgInRyeSBpdCBhbmQgc2VlIGlmIGl0IHdvcmtz IiBhcHByb2FjaCB3aGVuIHlvdSBoYXZlDQo+dHdvIHZhbGlkIEtFS3MgKGFzIGR1cmluZyBhIHRy YW5zaXRpb24pLCBhcyBpdCdzIG5vdCBjbGVhciB0aGF0IHlvdSB3aWxsDQo+YmUgYWJsZSB0byBk aXN0aW5ndWlzaCBzdWNjZXNzIGZyb20gZmFpbHVyZSBpbiBhbGwgY2FzZXMuDQoNCkFFUyBpcyBh biBhbGdvcml0aG0uIEkga25vdyB0aGVyZSBhcmUgMTI4LCAxOTIsIGFuZCAyNTYgYml0IHZhcmll dGllcy4gRG8NCnlvdSB3YW50IG1lIHRvIHNwZWNpZnkgdGhhbiBhbnkgdmFyaWV0eSBtYXkgYmUg dXNlZD8gSSBhbG1vc3QgcmVtb3ZlZCB0aGlzDQpvdXQtb2YtYmFuZCBrZXkgZW5jcnlwdGlvbiBv bmNlLg0KPg0KPi0gU2VjdGlvbiA1IGFsc28gc3VnZ2VzdHMga2V5cyBiZSBlbmNyeXB0ZWQgb3Ig b2JmdXNjYXRlZCBvbiB0aGUgZGV2aWNlDQo+dGhhdCBpcyB0byB1c2UgdGhlbSwgcHJlc3VtYWJs eSBpbiBhIHdheSB0aGF0IGNhbiBiZSBkZWNyeXB0ZWQgb3INCj51bm9iZnVzY2F0ZWQgdXNpbmcg aW5mb3JtYXRpb24gYWxzbyBvbiB0aGUgZGV2aWNlLiBJIGRvbid0IGtub3cgd2hhdCB0aGUNCj5j dXJyZW50IHNlY3VyaXR5IGFyZWEgdGhpbmtpbmcgYXJvdW5kIHRoaXMgaXMsIGJ1dCBnaXZlbiB0 aGF0IHRoZQ0KPmluZm9ybWF0aW9uIG5lZWRlZCB0byByZXRyaWV2ZSBwbGFpbnRleHQga2V5cyBp cyBuZWNlc3NhcmlseSBwcmVzZW50IG9uDQo+dGhlIGRldmljZSwgdGhpcyBzZWVtcyBsaWtlIGEg ZmlnLWxlYWYgdGhhdCBwcm92aWRlcyBhbiBpbGx1c2lvbiBvZg0KPnNlY3VyaXR5IHdpdGhvdXQg cHJvdmlkaW5nIGFueSByZWFsIGJlbmVmaXQuIFRoYXQgbWlzLWltcHJlc3Npb24gc2VlbXMNCj5w b3RlbnRpYWxseSBoYXJtZnVsLg0KDQpJIG9ubHkgYWRkZWQgdGhpcyBhdCB0aGUgYmVoZXN0IG9m IG9uZSBvZiB0aGUgb3RoZXIgcmV2aWV3cy4gVGhlIHByb2JsZW0NCndpdGggc2VjdXJpdHkgaXMg dGhhdCB0aGVyZSBjb25mbGljdGluZyBvcGluaW9ucywgYW5kIGFzIHRoZSBhZGFnZSBnb2VzDQri gJxldmVyeWJvZHnigJlzIGdvdCBvbmUu4oCdIEnigJlsbCBkZWZlciB0byB0aGUgU2VjdXJpdHkg QURzLg0KDQo+DQo+IC0gVGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBnaXZlcyB0aGUg WUFORyBtb2R1bGUgcHJlZml4IGFzDQo+ImlldGYta2V5LWNoYWluIi4gVGhlIFlBTkcgbW9kdWxl IGl0c2VsZiBkZWZpbmVzIHRoZSBwcmVmaXggYXMNCj4ia2V5LWNoYWluIi4gSSBhc3N1bWUgdGhl c2Ugc2hvdWxkIG1hdGNoIGVhY2ggb3RoZXI/DQoNClllcy4gR29vZCBjYXRjaCwgdGhlIElBTkEg Y29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyB3cm9uZy4gSSB0aGluayBoYXZlDQplbm91Z2ggY29t bWVudHMgbm93IHRvIGNvbnN0aXR1dGUgYW4gdXBkYXRlLg0KDQpUaGFua3MsDQpBY2VlIA0KPg0K DQo= From nobody Tue Apr 25 15:45:12 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17E2128D8B; Tue, 25 Apr 2017 15:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 wFKtLhOxsxdP; Tue, 25 Apr 2017 15:45:00 -0700 (PDT) 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 19F841205F0; Tue, 25 Apr 2017 15:45:00 -0700 (PDT) Received: from Orochi.local (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 v3PMiq52043605 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Apr 2017 17:44:53 -0500 (CDT) (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 Orochi.local Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) To: "Acee Lindem (acee)" , The IESG Cc: Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Tue, 25 Apr 2017 17:44:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 22:45:03 -0000 On 4/25/17 17:22, Acee Lindem (acee) wrote: > Hi Adam, > > On 4/25/17, 5:27 PM, "Adam Roach" wrote: > >> - Section 5 discusses the use of a KEK, distributed out-of-band, to >> decrypt the keys stored in this format. There appears to be no affordance >> for indicating the identity of which KEK to use, which would come in >> handy for the types of key rotation schemes I'm familiar with. Mostly, >> I'm worried about the "try it and see if it works" approach when you have >> two valid KEKs (as during a transition), as it's not clear that you will >> be able to distinguish success from failure in all cases. > AES is an algorithm. I know there are 128, 192, and 256 bit varieties. Do > you want me to specify than any variety may be used? I almost removed this > out-of-band key encryption once. This isn't about crypto-agility; it's about key rotation. This section posits a system in which you have some KEK, distributed out-of-band. Let's call the key we're using at this moment "Generation A." At some point -- let's say next week -- we decide that it's time to change the KEK to one we're going to call "Generation B." First, we need to get the "Generation B" KEKs to everyone before the switch-over (to avoid a period of time during which they can't decrypt the YANG-stored keys). The issue becomes: once you have both "Generation A" and "Generation B", how do you know which one to use to decrypt the YANG keys? If there were a place to store a key ID in the YANG model, it could identify which of the two keys to use. Lacking that, for some kinds of data, you can do a "try both and see which works," but it's not clear that doing so is possible in this case (since the thing you're decrypting is a key, and will simply look like random bits regardless of which KEK you use on it, you can't examine its structure to determine whether it is valid). This isn't a blocking comment; I'm just wondering whether this operational aspect occurred to the WG when this scheme was being discussed, and whether there's some trivial way to perform KEK rotation that could be described in the document. Without the ability to rotate the KEK, I'm not sure this scheme is all that useful. /a From nobody Tue Apr 25 15:51:39 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AA6126B71; Tue, 25 Apr 2017 15:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 uKm9isr_7fQT; Tue, 25 Apr 2017 15:51:36 -0700 (PDT) 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 4D12E1205F0; Tue, 25 Apr 2017 15:51:36 -0700 (PDT) Received: from Orochi.local (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 v3PMpWv8044443 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Apr 2017 17:51:33 -0500 (CDT) (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 Orochi.local Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) To: "Acee Lindem (acee)" , The IESG Cc: Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <21bc8763-1620-730e-35e3-cb0bc7995d57@nostrum.com> Date: Tue, 25 Apr 2017 17:51:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 22:51:38 -0000 I wanted to treat the KEK issue separately, since it has the possibility to turn into a larger conversation. Answering the remaining points in this email. Thanks for being so responsive! /a On 4/25/17 17:22, Acee Lindem (acee) wrote: > Hi Adam, > > On 4/25/17, 5:27 PM, "Adam Roach" wrote: > >> - The second paragraph in the Abstract seems very specific for an >> Abstract. Since this variation is covered in the Introduction, consider >> removing it from the Abstract. > Agreed. Maybe this will partially satisfy Mirja’s request that I remove > the “Introduction" as well. Sounds good to me. >> - Since the syntax in section 1.2 is used only in section 3.3 (from which >> I kept referring back to it), consider moving it down into section 3 >> somewhere. > I’m hesitant to do this since all the other YANG documents have the tree > syntax as a sub-section of the “Introduction”. Refer to RFC 7223. Consistency with other YANG documents seems reasonable motivation to keep this as-is. >> - Section 2.2 describes a scheme in which the key with the "most recent >> send lifetime" is used for sending. The data model allows for lifetimes >> to be indicated with "always." It seems that there should be treatment of >> the interaction between "most recent" and "always". > If you use “always”, you’re graceful key roll-over won’t be very > effective. Could I satisfy this by defining “most recent”? It is the key > with the latest start-time”. I think that part is clear. What probably needs to be said is that you can't use "always" if this scheme is in use (unless you want to resolve it some other way). [several resolved points elided] >> - Section 5 also suggests keys be encrypted or obfuscated on the device >> that is to use them, presumably in a way that can be decrypted or >> unobfuscated using information also on the device. I don't know what the >> current security area thinking around this is, but given that the >> information needed to retrieve plaintext keys is necessarily present on >> the device, this seems like a fig-leaf that provides an illusion of >> security without providing any real benefit. That mis-impression seems >> potentially harmful. > I only added this at the behest of one of the other reviews. The problem > with security is that there conflicting opinions, and as the adage goes > “everybody’s got one.” I’ll defer to the Security ADs. Right; that's what I meant by "I don't know what the current security area thinking around this is." I'd be curious to have EKR or Kathleen weigh in. /a From nobody Tue Apr 25 16:30:13 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57FD12EC2F for ; Tue, 25 Apr 2017 16:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 zUBR3OtN4z4H for ; Tue, 25 Apr 2017 16:30:04 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BA313175A for ; Tue, 25 Apr 2017 16:30:02 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l18so43943937ywh.3 for ; Tue, 25 Apr 2017 16:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x2OzWXl9qYUnfKCHPgqVf483JSDgFVm5KDqcgL8Qc18=; b=vLXq0CmVER1Cqtqm8O0l2ieG7pJAazBp06Fexmn7ABG/jJvjrPpA4c7LnQk9lmcR/U p8iKarmGdlr1Nu2ZU9Jkw6EaQrYsiubx8uoKlVK8ND1dhLF6f/oovPa/SF7ssewgb+JM VTfB7Ax6Eddln0knqVptCy/hhs8ZOQvk+KgWx+q3YfN/m/H6fW3u+twiKr5YYzW/LBcn j8h+9ldGTh1LwkjSk7tYUkHhaDVS0zn1Wf0rs4CWQDFfHD1Yl2SDGiQcir/kZj+UM8Jf 5uBX0PbejsR7YOnAjsS7V20QFtRRnLWMH6JWWM6PiV7gRetTeJnOF6J+nBnzC300Ihuy uDzA== 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=x2OzWXl9qYUnfKCHPgqVf483JSDgFVm5KDqcgL8Qc18=; b=cGhHfb/0KfghTJUYCLqhdBKixCGqdyIsiSNWHOSij6IiVBhBheSFKCtGUqd4VvQd6f PbR3FMP5qG5nnkLgOupQzSvD85xpDSXqZeF0nL0EwxpNulPLANAka3t3OKKgU0q5tUY+ LB0Ay/X5uaAhUsT/nGra0scpYpy0U0DKoee4zUAOLcJzpsOT4nkCRz8wtEo2oGTPbFlp TPwoVoR1GBCYI+I8Vv2h1L9pOysytLrM3yUtxA7qsFkVuXlWgEUQptkIMfwH7YCryKTC gCzFvrV74OXDYLxOEKqDcwoh37IFlTPx6LhN4HrbEVmLw7/GT5Vq01dJJbC7VdiHTZvV K4pA== X-Gm-Message-State: AN3rC/6gQQTdbFl+84zY9Q72ZJfx+RKDGarv9pFuWtLlcnKs5XeOK7xs PAqM5fZizVM4Se7KV+7lfM3xm2m10Q== X-Received: by 10.129.125.193 with SMTP id y184mr10941593ywc.120.1493163001765; Tue, 25 Apr 2017 16:30:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Tue, 25 Apr 2017 16:29:21 -0700 (PDT) In-Reply-To: <21bc8763-1620-730e-35e3-cb0bc7995d57@nostrum.com> References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> <21bc8763-1620-730e-35e3-cb0bc7995d57@nostrum.com> From: Eric Rescorla Date: Tue, 25 Apr 2017 16:29:21 -0700 Message-ID: Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) To: Adam Roach Cc: "Acee Lindem (acee)" , The IESG , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=001a11492bfc4ffecb054e061a4b Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 23:30:06 -0000 --001a11492bfc4ffecb054e061a4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 25, 2017 at 3:51 PM, Adam Roach wrote: > I wanted to treat the KEK issue separately, since it has the possibility > to turn into a larger conversation. Answering the remaining points in thi= s > email. Thanks for being so responsive! > > /a > > On 4/25/17 17:22, Acee Lindem (acee) wrote: > >> Hi Adam, >> >> On 4/25/17, 5:27 PM, "Adam Roach" wrote: >> >> - The second paragraph in the Abstract seems very specific for an >>> Abstract. Since this variation is covered in the Introduction, consider >>> removing it from the Abstract. >>> >> Agreed. Maybe this will partially satisfy Mirja=E2=80=99s request that I= remove >> the =E2=80=9CIntroduction" as well. >> > > Sounds good to me. > > - Since the syntax in section 1.2 is used only in section 3.3 (from which >>> I kept referring back to it), consider moving it down into section 3 >>> somewhere. >>> >> I=E2=80=99m hesitant to do this since all the other YANG documents have = the tree >> syntax as a sub-section of the =E2=80=9CIntroduction=E2=80=9D. Refer to = RFC 7223. >> > > Consistency with other YANG documents seems reasonable motivation to keep > this as-is. > > - Section 2.2 describes a scheme in which the key with the "most recent >>> send lifetime" is used for sending. The data model allows for lifetimes >>> to be indicated with "always." It seems that there should be treatment = of >>> the interaction between "most recent" and "always". >>> >> If you use =E2=80=9Calways=E2=80=9D, you=E2=80=99re graceful key roll-ov= er won=E2=80=99t be very >> effective. Could I satisfy this by defining =E2=80=9Cmost recent=E2=80= =9D? It is the key >> with the latest start-time=E2=80=9D. >> > > I think that part is clear. What probably needs to be said is that you > can't use "always" if this scheme is in use (unless you want to resolve i= t > some other way). > > > [several resolved points elided] > > - Section 5 also suggests keys be encrypted or obfuscated on the device >>> that is to use them, presumably in a way that can be decrypted or >>> unobfuscated using information also on the device. I don't know what th= e >>> current security area thinking around this is, but given that the >>> information needed to retrieve plaintext keys is necessarily present on >>> the device, this seems like a fig-leaf that provides an illusion of >>> security without providing any real benefit. That mis-impression seems >>> potentially harmful. >>> >> I only added this at the behest of one of the other reviews. The problem >> with security is that there conflicting opinions, and as the adage goes >> =E2=80=9Ceverybody=E2=80=99s got one.=E2=80=9D I=E2=80=99ll defer to the= Security ADs. >> > > Right; that's what I meant by "I don't know what the current security are= a > thinking around this is." I'd be curious to have EKR or Kathleen weigh in What I took home here was that you would encrypt them and display the encrypted version instead of showing asterisks. Is that not what the thinking was? -Ekr > /a > > --001a11492bfc4ffecb054e061a4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 25, 2017 at 3:51 PM, Adam Roach <adam@nostrum.com> wrote:
I wanted to treat the KEK is= sue separately, since it has the possibility to turn into a larger conversa= tion. Answering the remaining points in this email. Thanks for being so res= ponsive!

/a

On 4/25/17 17:22, Acee Lindem (acee) wrote:
Hi Adam,

On 4/25/17, 5:27 PM, "Adam Roach" <adam@nostrum.com> wrote:

- The second paragraph in the Abstract seems very specific for an
Abstract. Since this variation is covered in the Introduction, consider
removing it from the Abstract.
Agreed. Maybe this will partially satisfy Mirja=E2=80=99s request that I re= move
the =E2=80=9CIntroduction" as well.

Sounds good to me.

- Since the syntax in section 1.2 is used only in section 3.3 (from which I kept referring back to it), consider moving it down into section 3
somewhere.
I=E2=80=99m hesitant to do this since all the other YANG documents have the= tree
syntax as a sub-section of the =E2=80=9CIntroduction=E2=80=9D. Refer to RFC= 7223.

 Consistency with other YANG documents seems reasonable motivation to keep t= his as-is.

- Section 2.2 describes a scheme in which the key with the "most recen= t
send lifetime" is used for sending. The data model allows for lifetime= s
to be indicated with "always." It seems that there should be trea= tment of
the interaction between "most recent" and "always".
If you use =E2=80=9Calways=E2=80=9D, you=E2=80=99re graceful key roll-over = won=E2=80=99t be very
effective. Could I satisfy this by defining =E2=80=9Cmost recent=E2=80=9D? = It is the key
with the latest start-time=E2=80=9D.

 I think that part is clear. What probably needs to be said is that you can&= #39;t use "always" if this scheme is in use (unless you want to r= esolve it some other way).


[several resolved points elided]

- Section 5 also suggests keys be encrypted or obfuscated on the device
that is to use them, presumably in a way that can be decrypted or
unobfuscated using information also on the device. I don't know what th= e
current security area thinking around this is, but given that the
information needed to retrieve plaintext keys is necessarily present on
the device, this seems like a fig-leaf that provides an illusion of
security without providing any real benefit. That mis-impression seems
potentially harmful.
I only added this at the behest of one of the other reviews. The problem with security is that there conflicting opinions, and as the adage goes
=E2=80=9Ceverybody=E2=80=99s got one.=E2=80=9D I=E2=80=99ll defer to the Se= curity ADs.

 Right; that's what I meant by "I don't know what the current s= ecurity area thinking around this is." I'd be curious to have EKR = or Kathleen weigh in

What I took home here = was that you would encrypt them and display the encrypted
version= instead of showing asterisks. Is that not what the thinking was?

-Ekr


/a


--001a11492bfc4ffecb054e061a4b-- From nobody Tue Apr 25 17:47:37 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DBA131710; Tue, 25 Apr 2017 17:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bpq791WxjJoU; Tue, 25 Apr 2017 17:47:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1151317BD; Tue, 25 Apr 2017 17:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3938; q=dns/txt; s=iport; t=1493167652; x=1494377252; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TUft5nL3KFlmVjmmrCO9G48uQAid1GMEs8GaXev6vGo=; b=VbYxzkKBjxBJB26J3135frOd5RGm42wVYB3c8N6mo0VBKFgu9h+oIGCW LKMwN10K9LCJbHnWpD4ro+vZ1SSI5mloj+sMA/bRLrk3jwe0/jo9qh90S sqRC19eM3h09Rrqql/ECIRlcGO7pXIu+fn2sb+NQA70YEpdQP5TYZIwbu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BqAQCS7f9Y/4oNJK1SAQkZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDVIFtB4NgihWRb5Vlgg+GJAIag3s/GAECAQEBAQEBAWsohRY?= =?us-ascii?q?BBSMRRRACAQgYAgImAgICMBUQAgQBDQMCihyrB4Imiy0BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgQuKPoQvASeDBoJfAQSdQQGTBZFXlBgBHziBBmMVhWKBSkMyiCm?= =?us-ascii?q?BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,252,1488844800"; d="scan'208";a="240597688" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Apr 2017 00:47:30 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3Q0lUmY014729 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 00:47:30 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Apr 2017 20:47:29 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 25 Apr 2017 20:47:29 -0400 From: "Acee Lindem (acee)" To: Adam Roach , The IESG CC: Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" , "Brian Weis (bew)" Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvgrQg2iqyhFsfkS24vnExw0B6KHWqNaAgABJNoD//982gA== Date: Wed, 26 Apr 2017 00:47:29 +0000 Message-ID: References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <5FE6C2D5DC515A44B4431779AEC455B7@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 00:47:35 -0000 DQoNCk9uIDQvMjUvMTcsIDY6NDQgUE0sICJBZGFtIFJvYWNoIiA8YWRhbUBub3N0cnVtLmNvbT4g d3JvdGU6DQoNCj5PbiA0LzI1LzE3IDE3OjIyLCBBY2VlIExpbmRlbSAoYWNlZSkgd3JvdGU6DQo+ PiBIaSBBZGFtLA0KPj4NCj4+IE9uIDQvMjUvMTcsIDU6MjcgUE0sICJBZGFtIFJvYWNoIiA8YWRh bUBub3N0cnVtLmNvbT4gd3JvdGU6DQo+Pg0KPj4+IC0gU2VjdGlvbiA1IGRpc2N1c3NlcyB0aGUg dXNlIG9mIGEgS0VLLCBkaXN0cmlidXRlZCBvdXQtb2YtYmFuZCwgdG8NCj4+PiBkZWNyeXB0IHRo ZSBrZXlzIHN0b3JlZCBpbiB0aGlzIGZvcm1hdC4gVGhlcmUgYXBwZWFycyB0byBiZSBubw0KPj4+ YWZmb3JkYW5jZQ0KPj4+IGZvciBpbmRpY2F0aW5nIHRoZSBpZGVudGl0eSBvZiB3aGljaCBLRUsg dG8gdXNlLCB3aGljaCB3b3VsZCBjb21lIGluDQo+Pj4gaGFuZHkgZm9yIHRoZSB0eXBlcyBvZiBr ZXkgcm90YXRpb24gc2NoZW1lcyBJJ20gZmFtaWxpYXIgd2l0aC4gTW9zdGx5LA0KPj4+IEknbSB3 b3JyaWVkIGFib3V0IHRoZSAidHJ5IGl0IGFuZCBzZWUgaWYgaXQgd29ya3MiIGFwcHJvYWNoIHdo ZW4geW91DQo+Pj5oYXZlDQo+Pj4gdHdvIHZhbGlkIEtFS3MgKGFzIGR1cmluZyBhIHRyYW5zaXRp b24pLCBhcyBpdCdzIG5vdCBjbGVhciB0aGF0IHlvdQ0KPj4+d2lsbA0KPj4+IGJlIGFibGUgdG8g ZGlzdGluZ3Vpc2ggc3VjY2VzcyBmcm9tIGZhaWx1cmUgaW4gYWxsIGNhc2VzLg0KPj4gQUVTIGlz IGFuIGFsZ29yaXRobS4gSSBrbm93IHRoZXJlIGFyZSAxMjgsIDE5MiwgYW5kIDI1NiBiaXQgdmFy aWV0aWVzLg0KPj5Ebw0KPj4geW91IHdhbnQgbWUgdG8gc3BlY2lmeSB0aGFuIGFueSB2YXJpZXR5 IG1heSBiZSB1c2VkPyBJIGFsbW9zdCByZW1vdmVkDQo+PnRoaXMNCj4+IG91dC1vZi1iYW5kIGtl eSBlbmNyeXB0aW9uIG9uY2UuDQo+DQo+DQo+VGhpcyBpc24ndCBhYm91dCBjcnlwdG8tYWdpbGl0 eTsgaXQncyBhYm91dCBrZXkgcm90YXRpb24uIFRoaXMgc2VjdGlvbg0KPnBvc2l0cyBhIHN5c3Rl bSBpbiB3aGljaCB5b3UgaGF2ZSBzb21lIEtFSywgZGlzdHJpYnV0ZWQgb3V0LW9mLWJhbmQuDQo+ TGV0J3MgY2FsbCB0aGUga2V5IHdlJ3JlIHVzaW5nIGF0IHRoaXMgbW9tZW50ICJHZW5lcmF0aW9u IEEuIiBBdCBzb21lDQo+cG9pbnQgLS0gbGV0J3Mgc2F5IG5leHQgd2VlayAtLSB3ZSBkZWNpZGUg dGhhdCBpdCdzIHRpbWUgdG8gY2hhbmdlIHRoZQ0KPktFSyB0byBvbmUgd2UncmUgZ29pbmcgdG8g Y2FsbCAiR2VuZXJhdGlvbiBCLiIgRmlyc3QsIHdlIG5lZWQgdG8gZ2V0IHRoZQ0KPiJHZW5lcmF0 aW9uIEIiIEtFS3MgdG8gZXZlcnlvbmUgYmVmb3JlIHRoZSBzd2l0Y2gtb3ZlciAodG8gYXZvaWQg YQ0KPnBlcmlvZCBvZiB0aW1lIGR1cmluZyB3aGljaCB0aGV5IGNhbid0IGRlY3J5cHQgdGhlIFlB Tkctc3RvcmVkIGtleXMpLg0KPlRoZSBpc3N1ZSBiZWNvbWVzOiBvbmNlIHlvdSBoYXZlIGJvdGgg IkdlbmVyYXRpb24gQSIgYW5kICJHZW5lcmF0aW9uIEIiLA0KPmhvdyBkbyB5b3Uga25vdyB3aGlj aCBvbmUgdG8gdXNlIHRvIGRlY3J5cHQgdGhlIFlBTkcga2V5cz8gSWYgdGhlcmUgd2VyZQ0KPmEg cGxhY2UgdG8gc3RvcmUgYSBrZXkgSUQgaW4gdGhlIFlBTkcgbW9kZWwsIGl0IGNvdWxkIGlkZW50 aWZ5IHdoaWNoIG9mDQo+dGhlIHR3byBrZXlzIHRvIHVzZS4gTGFja2luZyB0aGF0LCBmb3Igc29t ZSBraW5kcyBvZiBkYXRhLCB5b3UgY2FuIGRvIGENCj4idHJ5IGJvdGggYW5kIHNlZSB3aGljaCB3 b3JrcywiIGJ1dCBpdCdzIG5vdCBjbGVhciB0aGF0IGRvaW5nIHNvIGlzDQo+cG9zc2libGUgaW4g dGhpcyBjYXNlIChzaW5jZSB0aGUgdGhpbmcgeW91J3JlIGRlY3J5cHRpbmcgaXMgYSBrZXksIGFu ZA0KPndpbGwgc2ltcGx5IGxvb2sgbGlrZSByYW5kb20gYml0cyByZWdhcmRsZXNzIG9mIHdoaWNo IEtFSyB5b3UgdXNlIG9uIGl0LA0KPnlvdSBjYW4ndCBleGFtaW5lIGl0cyBzdHJ1Y3R1cmUgdG8g ZGV0ZXJtaW5lIHdoZXRoZXIgaXQgaXMgdmFsaWQpLg0KPg0KPlRoaXMgaXNuJ3QgYSBibG9ja2lu ZyBjb21tZW50OyBJJ20ganVzdCB3b25kZXJpbmcgd2hldGhlciB0aGlzDQo+b3BlcmF0aW9uYWwg YXNwZWN0IG9jY3VycmVkIHRvIHRoZSBXRyB3aGVuIHRoaXMgc2NoZW1lIHdhcyBiZWluZw0KPmRp c2N1c3NlZCwgYW5kIHdoZXRoZXIgdGhlcmUncyBzb21lIHRyaXZpYWwgd2F5IHRvIHBlcmZvcm0g S0VLIHJvdGF0aW9uDQo+dGhhdCBjb3VsZCBiZSBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50LiBX aXRob3V0IHRoZSBhYmlsaXR5IHRvIHJvdGF0ZQ0KPnRoZSBLRUssIEknbSBub3Qgc3VyZSB0aGlz IHNjaGVtZSBpcyBhbGwgdGhhdCB1c2VmdWwuDQoNCkl0IHNlZW1zIHRoYXQgdGhpcyBzaG91bGQg aGF2ZSBiZWVuIGNvdmVyZWQgaW4gc29tZSBvdGhlciBTZWN1cml0eSBSRkMuIElmDQpub3QgUkZD IDU2NDkgKHdoaWNoIHNlZW1zIHRvIGJlIGluZXhwbGljYWJseSBuYXJyb3cgaW4gc2NvcGUpLCB0 aGVuIHNvbWUNCm90aGVyIFNlY3VyaXR5IGRvY3VtZW50LiBJZiB0aGVyZSBpcyBhbSBvdXQtb2Yt YmFuZCBLRUsgcHJvY2VkdXJlIGZvcg0KZW5jcnlwdGlvbiBvZiBrZXkgc3RyaW5nLCB0aGVuIGl0 IHNob3VsZCBoYXZlIGJlZW4gZG9jdW1lbnRlZCBwcmlvciB0byBteQ0KdXNhZ2UuIEnigJltIGNv cHlpbmcgQnJpYW4gV2VpcyAoYSBTZWN1cml0eSBEaXJlY3RvcmF0ZSBtZW1iZXIpIHdobw0Kb3Jp Z2luYWxseSBzdWdnZXN0ZWQgdGhpcy4gTXkgaW5jbGluYXRpb24gaXMgdG8gcmVtb3ZlIGFsbCB0 cmFjZXMgb2YgQUVBDQpLZXkgV3JhcCAoUkZDIDU2NDkpIGFuZCByZWx5IG9uIE5DQUNNLg0KDQpU aGFua3MsIA0KQWNlZSANCj4NCj4vYQ0KDQo= From nobody Tue Apr 25 17:54:28 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2AA1205D3; Tue, 25 Apr 2017 17:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWTGxDOK0Lg1; Tue, 25 Apr 2017 17:54:25 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB941317C1; Tue, 25 Apr 2017 17:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4382; q=dns/txt; s=iport; t=1493168065; x=1494377665; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jBXNh1Hswl+CqOSEbgf/tS64HTYvs3aangq7fOR6kzs=; b=FtlhzOFvLUpiQRTsmg/gcCYE8bhHjq57UlvvXT1HB9yj7/N8A3usQLq2 +EVQTIQ1m8pZ08A6MCW1lHw3/CIrnQm5W67FdaUEXkzVYWf1615p+MduI K+aun4CcZVcLM6C9HjRsZkXGwakmS0lVzoaU26/LEtLhQvTEPpaUwCy5g k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BqAQC17v9Y/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1SBbQeDYIoVkW+VZYIPhiQCGoN7PxgBAgEBAQEBAQFrKIUWAQU?= =?us-ascii?q?jEUUQAgEIGAICJgICAjAVEAIEAQ0FH4l9qwmCJostAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEegQuKPoQpEQEcgwaCXwWdQQGTBZFXlBgBHzh+CGMVhS0cGYFKdYcIgSG?= =?us-ascii?q?BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,252,1488844800"; d="scan'208";a="417720591" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2017 00:54:23 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3Q0sMm5025896 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 00:54:23 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Apr 2017 20:54:22 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 25 Apr 2017 20:54:22 -0400 From: "Acee Lindem (acee)" To: Adam Roach , The IESG CC: Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvgrQg2iqyhFsfkS24vnExw0B6KHWqNaAgABLE4D//99EgA== Date: Wed, 26 Apr 2017 00:54:22 +0000 Message-ID: References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> <21bc8763-1620-730e-35e3-cb0bc7995d57@nostrum.com> In-Reply-To: <21bc8763-1620-730e-35e3-cb0bc7995d57@nostrum.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.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <73016BF9F92146449958E744F925DCE1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 00:54:26 -0000 SGkgQWRhbSwgDQoNCk9uIDQvMjUvMTcsIDY6NTEgUE0sICJBZGFtIFJvYWNoIiA8YWRhbUBub3N0 cnVtLmNvbT4gd3JvdGU6DQoNCj5JIHdhbnRlZCB0byB0cmVhdCB0aGUgS0VLIGlzc3VlIHNlcGFy YXRlbHksIHNpbmNlIGl0IGhhcyB0aGUgcG9zc2liaWxpdHkNCj50byB0dXJuIGludG8gYSBsYXJn ZXIgY29udmVyc2F0aW9uLiBBbnN3ZXJpbmcgdGhlIHJlbWFpbmluZyBwb2ludHMgaW4NCj50aGlz IGVtYWlsLiBUaGFua3MgZm9yIGJlaW5nIHNvIHJlc3BvbnNpdmUhDQoNCkFncmVlZC4gSSBhZGRl ZCB0aGlzIFJGQyA1NjQ5IG1lY2hhbmlzbSBwcmlvciB0byB1c2luZyBOQ0FDTSBzbywgaWYgaXQN Cndyb3VnaHQgd2l0aCBzcGVjaWZpY2F0aW9uIGlzc3VlcywgdGhlbiBJ4oCZbSBpbmNsaW5lZCB0 byByZW1vdmUgaXQuDQoNCj4NCj4vYQ0KPg0KPk9uIDQvMjUvMTcgMTc6MjIsIEFjZWUgTGluZGVt IChhY2VlKSB3cm90ZToNCj4+IEhpIEFkYW0sDQo+Pg0KPj4gT24gNC8yNS8xNywgNToyNyBQTSwg IkFkYW0gUm9hY2giIDxhZGFtQG5vc3RydW0uY29tPiB3cm90ZToNCj4+DQo+Pj4gLSBUaGUgc2Vj b25kIHBhcmFncmFwaCBpbiB0aGUgQWJzdHJhY3Qgc2VlbXMgdmVyeSBzcGVjaWZpYyBmb3IgYW4N Cj4+PiBBYnN0cmFjdC4gU2luY2UgdGhpcyB2YXJpYXRpb24gaXMgY292ZXJlZCBpbiB0aGUgSW50 cm9kdWN0aW9uLCBjb25zaWRlcg0KPj4+IHJlbW92aW5nIGl0IGZyb20gdGhlIEFic3RyYWN0Lg0K Pj4gQWdyZWVkLiBNYXliZSB0aGlzIHdpbGwgcGFydGlhbGx5IHNhdGlzZnkgTWlyamHigJlzIHJl cXVlc3QgdGhhdCBJIHJlbW92ZQ0KPj4gdGhlIOKAnEludHJvZHVjdGlvbiIgYXMgd2VsbC4NCj4N Cj5Tb3VuZHMgZ29vZCB0byBtZS4NCj4NCj4+PiAtIFNpbmNlIHRoZSBzeW50YXggaW4gc2VjdGlv biAxLjIgaXMgdXNlZCBvbmx5IGluIHNlY3Rpb24gMy4zIChmcm9tDQo+Pj53aGljaA0KPj4+IEkg a2VwdCByZWZlcnJpbmcgYmFjayB0byBpdCksIGNvbnNpZGVyIG1vdmluZyBpdCBkb3duIGludG8g c2VjdGlvbiAzDQo+Pj4gc29tZXdoZXJlLg0KPj4gSeKAmW0gaGVzaXRhbnQgdG8gZG8gdGhpcyBz aW5jZSBhbGwgdGhlIG90aGVyIFlBTkcgZG9jdW1lbnRzIGhhdmUgdGhlIHRyZWUNCj4+IHN5bnRh eCBhcyBhIHN1Yi1zZWN0aW9uIG9mIHRoZSDigJxJbnRyb2R1Y3Rpb27igJ0uIFJlZmVyIHRvIFJG QyA3MjIzLg0KPg0KPkNvbnNpc3RlbmN5IHdpdGggb3RoZXIgWUFORyBkb2N1bWVudHMgc2VlbXMg cmVhc29uYWJsZSBtb3RpdmF0aW9uIHRvDQo+a2VlcCB0aGlzIGFzLWlzLg0KPg0KPj4+IC0gU2Vj dGlvbiAyLjIgZGVzY3JpYmVzIGEgc2NoZW1lIGluIHdoaWNoIHRoZSBrZXkgd2l0aCB0aGUgIm1v c3QgcmVjZW50DQo+Pj4gc2VuZCBsaWZldGltZSIgaXMgdXNlZCBmb3Igc2VuZGluZy4gVGhlIGRh dGEgbW9kZWwgYWxsb3dzIGZvciBsaWZldGltZXMNCj4+PiB0byBiZSBpbmRpY2F0ZWQgd2l0aCAi YWx3YXlzLiIgSXQgc2VlbXMgdGhhdCB0aGVyZSBzaG91bGQgYmUgdHJlYXRtZW50DQo+Pj5vZg0K Pj4+IHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuICJtb3N0IHJlY2VudCIgYW5kICJhbHdheXMiLg0K Pj4gSWYgeW91IHVzZSDigJxhbHdheXPigJ0sIHlvdeKAmXJlIGdyYWNlZnVsIGtleSByb2xsLW92 ZXIgd29u4oCZdCBiZSB2ZXJ5DQo+PiBlZmZlY3RpdmUuIENvdWxkIEkgc2F0aXNmeSB0aGlzIGJ5 IGRlZmluaW5nIOKAnG1vc3QgcmVjZW504oCdPyBJdCBpcyB0aGUga2V5DQo+PiB3aXRoIHRoZSBs YXRlc3Qgc3RhcnQtdGltZeKAnS4NCj4NCj5JIHRoaW5rIHRoYXQgcGFydCBpcyBjbGVhci4gV2hh dCBwcm9iYWJseSBuZWVkcyB0byBiZSBzYWlkIGlzIHRoYXQgeW91DQo+Y2FuJ3QgdXNlICJhbHdh eXMiIGlmIHRoaXMgc2NoZW1lIGlzIGluIHVzZSAodW5sZXNzIHlvdSB3YW50IHRvIHJlc29sdmUN Cj5pdCBzb21lIG90aGVyIHdheSkuDQoNClJpZ2h0IC0gd2lsbCBkby4gT3RoZXIgYXBwcm9hY2hl cyBhcmUgcG9zc2libGUgYnV0IHRoaXMgaXMgdGhlIG9uZSBJDQppbXBsZW1lbnRlZCBhdCBSZWRi YWNrL0VyaWNzc29uIHdpdGggc3VjY2Vzcy4NCg0KPg0KPg0KPltzZXZlcmFsIHJlc29sdmVkIHBv aW50cyBlbGlkZWRdDQo+DQo+Pj4gLSBTZWN0aW9uIDUgYWxzbyBzdWdnZXN0cyBrZXlzIGJlIGVu Y3J5cHRlZCBvciBvYmZ1c2NhdGVkIG9uIHRoZSBkZXZpY2UNCj4+PiB0aGF0IGlzIHRvIHVzZSB0 aGVtLCBwcmVzdW1hYmx5IGluIGEgd2F5IHRoYXQgY2FuIGJlIGRlY3J5cHRlZCBvcg0KPj4+IHVu b2JmdXNjYXRlZCB1c2luZyBpbmZvcm1hdGlvbiBhbHNvIG9uIHRoZSBkZXZpY2UuIEkgZG9uJ3Qg a25vdyB3aGF0DQo+Pj50aGUNCj4+PiBjdXJyZW50IHNlY3VyaXR5IGFyZWEgdGhpbmtpbmcgYXJv dW5kIHRoaXMgaXMsIGJ1dCBnaXZlbiB0aGF0IHRoZQ0KPj4+IGluZm9ybWF0aW9uIG5lZWRlZCB0 byByZXRyaWV2ZSBwbGFpbnRleHQga2V5cyBpcyBuZWNlc3NhcmlseSBwcmVzZW50IG9uDQo+Pj4g dGhlIGRldmljZSwgdGhpcyBzZWVtcyBsaWtlIGEgZmlnLWxlYWYgdGhhdCBwcm92aWRlcyBhbiBp bGx1c2lvbiBvZg0KPj4+IHNlY3VyaXR5IHdpdGhvdXQgcHJvdmlkaW5nIGFueSByZWFsIGJlbmVm aXQuIFRoYXQgbWlzLWltcHJlc3Npb24gc2VlbXMNCj4+PiBwb3RlbnRpYWxseSBoYXJtZnVsLg0K Pj4gSSBvbmx5IGFkZGVkIHRoaXMgYXQgdGhlIGJlaGVzdCBvZiBvbmUgb2YgdGhlIG90aGVyIHJl dmlld3MuIFRoZSBwcm9ibGVtDQo+PiB3aXRoIHNlY3VyaXR5IGlzIHRoYXQgdGhlcmUgY29uZmxp Y3Rpbmcgb3BpbmlvbnMsIGFuZCBhcyB0aGUgYWRhZ2UgZ29lcw0KPj4g4oCcZXZlcnlib2R54oCZ cyBnb3Qgb25lLuKAnSBJ4oCZbGwgZGVmZXIgdG8gdGhlIFNlY3VyaXR5IEFEcy4NCj4NCj5SaWdo dDsgdGhhdCdzIHdoYXQgSSBtZWFudCBieSAiSSBkb24ndCBrbm93IHdoYXQgdGhlIGN1cnJlbnQg c2VjdXJpdHkNCj5hcmVhIHRoaW5raW5nIGFyb3VuZCB0aGlzIGlzLiIgSSdkIGJlIGN1cmlvdXMg dG8gaGF2ZSBFS1Igb3IgS2F0aGxlZW4NCj53ZWlnaCBpbi4NCg0KSeKAmWQgYmUgaW50ZXJlc3Rl ZCBhcyB3ZWxsIHNpbmNlIGFkZGluZyB0aGlzIHdhc27igJl0IHNvbWV0aGluZyBJIHdhcyBzdXJl DQphZGRlZCB2YWx1ZSBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNClRoYW5rcywNCkFjZWUNCg0KPg0K Pi9hDQoNCg== From nobody Tue Apr 25 18:03:27 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3AA126D05; Tue, 25 Apr 2017 18:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7gDiMB-NjZe; Tue, 25 Apr 2017 18:03:16 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56832124D37; Tue, 25 Apr 2017 18:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16311; q=dns/txt; s=iport; t=1493168596; x=1494378196; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8N4rmiH7xRQzsLkSMHUZS7fFm7+BzkkoDurPUs85gZQ=; b=NOb2Krvh8YuLLWuMC/IXupux3+MFzHvqn9LUzk5pYCTQ/Iulq4CUhhXV 5XYtGdf2ipQ23dRfjBkWBRI0UeOsefJL4MfBACUzXgRV7waaMT6hfIS/4 ZJOle7shH+EAKtYjxI4FQ2DvCA+yrwg5lAqGLsWhRcn25BMB7veobtB9U E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQDS8P9Y/51dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5mgW0Hg2CKFZFviCCIEIU1gg+GJAIag3s/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAyNWEAIBCA4DAwECKAMCAgIfERQJCAIEAQ0FH4llAxWrB4Imh0ENg?= =?us-ascii?q?18BAQEBAQEBAQEBAQEBAQEBAQEBAQEdiDCDGYJRgVgRAQg0gmaCXwWWSYY9OwG?= =?us-ascii?q?OPIRJkVeLEokGAR84fghjFYUtHBmBSnWGeg4XgQqBDQEBAQ?= X-IronPort-AV: E=Sophos; i="5.37,252,1488844800"; d="scan'208,217"; a="19618372" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2017 01:03:15 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3Q13EHF005747 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 01:03:15 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Apr 2017 21:03:14 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 25 Apr 2017 21:03:14 -0400 From: "Acee Lindem (acee)" To: Eric Rescorla , Adam Roach CC: The IESG , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvgrQg2iqyhFsfkS24vnExw0B6KHWqNaAgABLE4CAAAqXgP//1ygA Date: Wed, 26 Apr 2017 01:03:14 +0000 Message-ID: References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> <21bc8763-1620-730e-35e3-cb0bc7995d57@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: multipart/alternative; boundary="_000_D5256856AB5F2aceeciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 01:03:19 -0000 --_000_D5256856AB5F2aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYywNCg0KRnJvbTogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JA cnRmbS5jb20+Pg0KRGF0ZTogVHVlc2RheSwgQXByaWwgMjUsIDIwMTcgYXQgNzoyOSBQTQ0KVG86 IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb208bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+Pg0K Q2M6IEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+Piwg VGhlIElFU0cgPGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+PiwgSmVmZiBUYW50 c3VyYSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmplZmZ0YW50LmlldGZAZ21haWwu Y29tPj4sICJydGd3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnLWNoYWlyc0BpZXRmLm9y Zz4iIDxydGd3Zy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnLWNoYWlyc0BpZXRmLm9yZz4+ LCAiZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQt aWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbkBpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLXJ0Z3dnLXlh bmcta2V5LWNoYWluQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNo YWluQGlldGYub3JnPj4sIFJvdXRpbmcgV0cgPHJ0Z3dnQGlldGYub3JnPG1haWx0bzpydGd3Z0Bp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogQWRhbSBSb2FjaCdzIE5vIE9iamVjdGlvbiBvbiBkcmFm dC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluLTIwOiAod2l0aCBDT01NRU5UKQ0KDQoNCg0KT24g VHVlLCBBcHIgMjUsIDIwMTcgYXQgMzo1MSBQTSwgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNv bTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+IHdyb3RlOg0KSSB3YW50ZWQgdG8gdHJlYXQgdGhl IEtFSyBpc3N1ZSBzZXBhcmF0ZWx5LCBzaW5jZSBpdCBoYXMgdGhlIHBvc3NpYmlsaXR5IHRvIHR1 cm4gaW50byBhIGxhcmdlciBjb252ZXJzYXRpb24uIEFuc3dlcmluZyB0aGUgcmVtYWluaW5nIHBv aW50cyBpbiB0aGlzIGVtYWlsLiBUaGFua3MgZm9yIGJlaW5nIHNvIHJlc3BvbnNpdmUhDQoNCi9h DQoNCk9uIDQvMjUvMTcgMTc6MjIsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToNCkhpIEFkYW0s DQoNCk9uIDQvMjUvMTcsIDU6MjcgUE0sICJBZGFtIFJvYWNoIiA8YWRhbUBub3N0cnVtLmNvbTxt YWlsdG86YWRhbUBub3N0cnVtLmNvbT4+IHdyb3RlOg0KDQotIFRoZSBzZWNvbmQgcGFyYWdyYXBo IGluIHRoZSBBYnN0cmFjdCBzZWVtcyB2ZXJ5IHNwZWNpZmljIGZvciBhbg0KQWJzdHJhY3QuIFNp bmNlIHRoaXMgdmFyaWF0aW9uIGlzIGNvdmVyZWQgaW4gdGhlIEludHJvZHVjdGlvbiwgY29uc2lk ZXINCnJlbW92aW5nIGl0IGZyb20gdGhlIEFic3RyYWN0Lg0KQWdyZWVkLiBNYXliZSB0aGlzIHdp bGwgcGFydGlhbGx5IHNhdGlzZnkgTWlyamHigJlzIHJlcXVlc3QgdGhhdCBJIHJlbW92ZQ0KdGhl IOKAnEludHJvZHVjdGlvbiIgYXMgd2VsbC4NCg0KU291bmRzIGdvb2QgdG8gbWUuDQoNCi0gU2lu Y2UgdGhlIHN5bnRheCBpbiBzZWN0aW9uIDEuMiBpcyB1c2VkIG9ubHkgaW4gc2VjdGlvbiAzLjMg KGZyb20gd2hpY2gNCkkga2VwdCByZWZlcnJpbmcgYmFjayB0byBpdCksIGNvbnNpZGVyIG1vdmlu ZyBpdCBkb3duIGludG8gc2VjdGlvbiAzDQpzb21ld2hlcmUuDQpJ4oCZbSBoZXNpdGFudCB0byBk byB0aGlzIHNpbmNlIGFsbCB0aGUgb3RoZXIgWUFORyBkb2N1bWVudHMgaGF2ZSB0aGUgdHJlZQ0K c3ludGF4IGFzIGEgc3ViLXNlY3Rpb24gb2YgdGhlIOKAnEludHJvZHVjdGlvbuKAnS4gUmVmZXIg dG8gUkZDIDcyMjMuDQoNCkNvbnNpc3RlbmN5IHdpdGggb3RoZXIgWUFORyBkb2N1bWVudHMgc2Vl bXMgcmVhc29uYWJsZSBtb3RpdmF0aW9uIHRvIGtlZXAgdGhpcyBhcy1pcy4NCg0KLSBTZWN0aW9u IDIuMiBkZXNjcmliZXMgYSBzY2hlbWUgaW4gd2hpY2ggdGhlIGtleSB3aXRoIHRoZSAibW9zdCBy ZWNlbnQNCnNlbmQgbGlmZXRpbWUiIGlzIHVzZWQgZm9yIHNlbmRpbmcuIFRoZSBkYXRhIG1vZGVs IGFsbG93cyBmb3IgbGlmZXRpbWVzDQp0byBiZSBpbmRpY2F0ZWQgd2l0aCAiYWx3YXlzLiIgSXQg c2VlbXMgdGhhdCB0aGVyZSBzaG91bGQgYmUgdHJlYXRtZW50IG9mDQp0aGUgaW50ZXJhY3Rpb24g YmV0d2VlbiAibW9zdCByZWNlbnQiIGFuZCAiYWx3YXlzIi4NCklmIHlvdSB1c2Ug4oCcYWx3YXlz 4oCdLCB5b3XigJlyZSBncmFjZWZ1bCBrZXkgcm9sbC1vdmVyIHdvbuKAmXQgYmUgdmVyeQ0KZWZm ZWN0aXZlLiBDb3VsZCBJIHNhdGlzZnkgdGhpcyBieSBkZWZpbmluZyDigJxtb3N0IHJlY2VudOKA nT8gSXQgaXMgdGhlIGtleQ0Kd2l0aCB0aGUgbGF0ZXN0IHN0YXJ0LXRpbWXigJ0uDQoNCkkgdGhp bmsgdGhhdCBwYXJ0IGlzIGNsZWFyLiBXaGF0IHByb2JhYmx5IG5lZWRzIHRvIGJlIHNhaWQgaXMg dGhhdCB5b3UgY2FuJ3QgdXNlICJhbHdheXMiIGlmIHRoaXMgc2NoZW1lIGlzIGluIHVzZSAodW5s ZXNzIHlvdSB3YW50IHRvIHJlc29sdmUgaXQgc29tZSBvdGhlciB3YXkpLg0KDQoNCltzZXZlcmFs IHJlc29sdmVkIHBvaW50cyBlbGlkZWRdDQoNCi0gU2VjdGlvbiA1IGFsc28gc3VnZ2VzdHMga2V5 cyBiZSBlbmNyeXB0ZWQgb3Igb2JmdXNjYXRlZCBvbiB0aGUgZGV2aWNlDQp0aGF0IGlzIHRvIHVz ZSB0aGVtLCBwcmVzdW1hYmx5IGluIGEgd2F5IHRoYXQgY2FuIGJlIGRlY3J5cHRlZCBvcg0KdW5v YmZ1c2NhdGVkIHVzaW5nIGluZm9ybWF0aW9uIGFsc28gb24gdGhlIGRldmljZS4gSSBkb24ndCBr bm93IHdoYXQgdGhlDQpjdXJyZW50IHNlY3VyaXR5IGFyZWEgdGhpbmtpbmcgYXJvdW5kIHRoaXMg aXMsIGJ1dCBnaXZlbiB0aGF0IHRoZQ0KaW5mb3JtYXRpb24gbmVlZGVkIHRvIHJldHJpZXZlIHBs YWludGV4dCBrZXlzIGlzIG5lY2Vzc2FyaWx5IHByZXNlbnQgb24NCnRoZSBkZXZpY2UsIHRoaXMg c2VlbXMgbGlrZSBhIGZpZy1sZWFmIHRoYXQgcHJvdmlkZXMgYW4gaWxsdXNpb24gb2YNCnNlY3Vy aXR5IHdpdGhvdXQgcHJvdmlkaW5nIGFueSByZWFsIGJlbmVmaXQuIFRoYXQgbWlzLWltcHJlc3Np b24gc2VlbXMNCnBvdGVudGlhbGx5IGhhcm1mdWwuDQpJIG9ubHkgYWRkZWQgdGhpcyBhdCB0aGUg YmVoZXN0IG9mIG9uZSBvZiB0aGUgb3RoZXIgcmV2aWV3cy4gVGhlIHByb2JsZW0NCndpdGggc2Vj dXJpdHkgaXMgdGhhdCB0aGVyZSBjb25mbGljdGluZyBvcGluaW9ucywgYW5kIGFzIHRoZSBhZGFn ZSBnb2VzDQrigJxldmVyeWJvZHnigJlzIGdvdCBvbmUu4oCdIEnigJlsbCBkZWZlciB0byB0aGUg U2VjdXJpdHkgQURzLg0KDQpSaWdodDsgdGhhdCdzIHdoYXQgSSBtZWFudCBieSAiSSBkb24ndCBr bm93IHdoYXQgdGhlIGN1cnJlbnQgc2VjdXJpdHkgYXJlYSB0aGlua2luZyBhcm91bmQgdGhpcyBp cy4iIEknZCBiZSBjdXJpb3VzIHRvIGhhdmUgRUtSIG9yIEthdGhsZWVuIHdlaWdoIGluDQoNCldo YXQgSSB0b29rIGhvbWUgaGVyZSB3YXMgdGhhdCB5b3Ugd291bGQgZW5jcnlwdCB0aGVtIGFuZCBk aXNwbGF5IHRoZSBlbmNyeXB0ZWQNCnZlcnNpb24gaW5zdGVhZCBvZiBzaG93aW5nIGFzdGVyaXNr cy4gSXMgdGhhdCBub3Qgd2hhdCB0aGUgdGhpbmtpbmcgd2FzPw0KDQpJIGRvbuKAmXQgYnJvYWNo IHRoZSBzdWJqZWN0IG9mIGRpc3BsYXkgaGVyZSDigJMgdGhpcyBpcyB3aXRoIHJlc3BlY3QgdG8g dGhlIGludGVybmFsIHN0b3JhZ2Ugb2YgdGhlIGtleXMuDQoNCkFyZSB5b3UgdGFsa2luZyBhYm91 dCB0aGUgTkVUQ09ORiA8Z2V0LWNvbmZpZz4gb3BlcmF0aW9uIFtSRkMgNjI0MV0gb24gdGhlIFlB TkcgbW9kZWw/IElmIHlvdSBoYXZlIHRoZSBwcm9wZXIgTkNBQ00gcGVybWlzc2lvbnMsIHRoZW4g eW91IHdpbGwgYmUgYWJsZSB0byByZXRyaWV2ZSB0aGUga2V5IHN0cmluZ3MgaW4gcGxhaW4gdGV4 dC4NCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCg0KDQoNCg0KLUVrcg0KDQoNCi9hDQoNCg0K --_000_D5256856AB5F2aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBFcmljLCZu YnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsg dGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7 IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1M RUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29s aWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5FcmljIFJlc2NvcmxhICZsdDs8 YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwgQXByaWwg MjUsIDIwMTcgYXQgNzoyOSBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzogPC9zcGFuPkFkYW0gUm9hY2ggJmx0OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29t Ij5hZGFtQG5vc3RydW0uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+Q2M6IDwvc3Bhbj5BY2VlIExpbmRlbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lz Y28uY29tIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7LCBUaGUgSUVTRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+Jmd0OywgSmVmZiBUYW50c3VyYSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmplZmZ0YW50LmlldGZAZ21haWwuY29tIj5qZWZmdGFudC5pZXRm QGdtYWlsLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cnRnd2ctY2hhaXJzQGll dGYub3JnIj5ydGd3Zy1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1h aWx0bzpydGd3Zy1jaGFpcnNAaWV0Zi5vcmciPnJ0Z3dnLWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7 LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbkBp ZXRmLm9yZyI+ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbkBpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluQGll dGYub3JnIj5kcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluQGlldGYub3JnPC9hPiZndDss DQogUm91dGluZyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnQGlldGYub3JnIj5ydGd3Z0Bp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1Ympl Y3Q6IDwvc3Bhbj5SZTogQWRhbSBSb2FjaCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXJ0 Z3dnLXlhbmcta2V5LWNoYWluLTIwOiAod2l0aCBDT01NRU5UKTxicj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAg MCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi Pk9uIFR1ZSwgQXByIDI1LCAyMDE3IGF0IDM6NTEgUE0sIEFkYW0gUm9hY2ggPHNwYW4gZGlyPSJs dHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29tIiB0YXJnZXQ9Il9ibGFu ayI+YWRhbUBub3N0cnVtLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVm dDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkkgd2FudGVkIHRvIHRyZWF0IHRo ZSBLRUsgaXNzdWUgc2VwYXJhdGVseSwgc2luY2UgaXQgaGFzIHRoZSBwb3NzaWJpbGl0eSB0byB0 dXJuIGludG8gYSBsYXJnZXIgY29udmVyc2F0aW9uLiBBbnN3ZXJpbmcgdGhlIHJlbWFpbmluZyBw b2ludHMgaW4gdGhpcyBlbWFpbC4gVGhhbmtzIGZvciBiZWluZyBzbyByZXNwb25zaXZlITxicj4N Cjxicj4NCi9hPHNwYW4gY2xhc3M9IiI+PGJyPg0KPGJyPg0KT24gNC8yNS8xNyAxNzoyMiwgQWNl ZSBMaW5kZW0gKGFjZWUpIHdyb3RlOjxicj4NCjwvc3Bhbj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPHNwYW4gY2xhc3M9IiI+SGkgQWRhbSw8YnI+DQo8 YnI+DQpPbiA0LzI1LzE3LCA1OjI3IFBNLCAmcXVvdDtBZGFtIFJvYWNoJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYW1Abm9zdHJ1 bS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDti b3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCi0gVGhlIHNlY29u ZCBwYXJhZ3JhcGggaW4gdGhlIEFic3RyYWN0IHNlZW1zIHZlcnkgc3BlY2lmaWMgZm9yIGFuPGJy Pg0KQWJzdHJhY3QuIFNpbmNlIHRoaXMgdmFyaWF0aW9uIGlzIGNvdmVyZWQgaW4gdGhlIEludHJv ZHVjdGlvbiwgY29uc2lkZXI8YnI+DQpyZW1vdmluZyBpdCBmcm9tIHRoZSBBYnN0cmFjdC48YnI+ DQo8L2Jsb2NrcXVvdGU+DQpBZ3JlZWQuIE1heWJlIHRoaXMgd2lsbCBwYXJ0aWFsbHkgc2F0aXNm eSBNaXJqYeKAmXMgcmVxdWVzdCB0aGF0IEkgcmVtb3ZlPGJyPg0KdGhlIOKAnEludHJvZHVjdGlv biZxdW90OyBhcyB3ZWxsLjxicj4NCjwvc3Bhbj48L2Jsb2NrcXVvdGU+DQo8YnI+DQpTb3VuZHMg Z29vZCB0byBtZS48c3BhbiBjbGFzcz0iIj48YnI+DQo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh ZGRpbmctbGVmdDoxZXgiPg0KLSBTaW5jZSB0aGUgc3ludGF4IGluIHNlY3Rpb24gMS4yIGlzIHVz ZWQgb25seSBpbiBzZWN0aW9uIDMuMyAoZnJvbSB3aGljaDxicj4NCkkga2VwdCByZWZlcnJpbmcg YmFjayB0byBpdCksIGNvbnNpZGVyIG1vdmluZyBpdCBkb3duIGludG8gc2VjdGlvbiAzPGJyPg0K c29tZXdoZXJlLjxicj4NCjwvYmxvY2txdW90ZT4NCknigJltIGhlc2l0YW50IHRvIGRvIHRoaXMg c2luY2UgYWxsIHRoZSBvdGhlciBZQU5HIGRvY3VtZW50cyBoYXZlIHRoZSB0cmVlPGJyPg0Kc3lu dGF4IGFzIGEgc3ViLXNlY3Rpb24gb2YgdGhlIOKAnEludHJvZHVjdGlvbuKAnS4gUmVmZXIgdG8g UkZDIDcyMjMuPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9zcGFuPkNvbnNpc3RlbmN5IHdp dGggb3RoZXIgWUFORyBkb2N1bWVudHMgc2VlbXMgcmVhc29uYWJsZSBtb3RpdmF0aW9uIHRvIGtl ZXAgdGhpcyBhcy1pcy48c3BhbiBjbGFzcz0iIj48YnI+DQo8YnI+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KLSBTZWN0aW9uIDIuMiBkZXNjcmliZXMgYSBzY2hlbWUgaW4g d2hpY2ggdGhlIGtleSB3aXRoIHRoZSAmcXVvdDttb3N0IHJlY2VudDxicj4NCnNlbmQgbGlmZXRp bWUmcXVvdDsgaXMgdXNlZCBmb3Igc2VuZGluZy4gVGhlIGRhdGEgbW9kZWwgYWxsb3dzIGZvciBs aWZldGltZXM8YnI+DQp0byBiZSBpbmRpY2F0ZWQgd2l0aCAmcXVvdDthbHdheXMuJnF1b3Q7IEl0 IHNlZW1zIHRoYXQgdGhlcmUgc2hvdWxkIGJlIHRyZWF0bWVudCBvZjxicj4NCnRoZSBpbnRlcmFj dGlvbiBiZXR3ZWVuICZxdW90O21vc3QgcmVjZW50JnF1b3Q7IGFuZCAmcXVvdDthbHdheXMmcXVv dDsuPGJyPg0KPC9ibG9ja3F1b3RlPg0KSWYgeW91IHVzZSDigJxhbHdheXPigJ0sIHlvdeKAmXJl IGdyYWNlZnVsIGtleSByb2xsLW92ZXIgd29u4oCZdCBiZSB2ZXJ5PGJyPg0KZWZmZWN0aXZlLiBD b3VsZCBJIHNhdGlzZnkgdGhpcyBieSBkZWZpbmluZyDigJxtb3N0IHJlY2VudOKAnT8gSXQgaXMg dGhlIGtleTxicj4NCndpdGggdGhlIGxhdGVzdCBzdGFydC10aW1l4oCdLjxicj4NCjwvYmxvY2tx dW90ZT4NCjxicj4NCjwvc3Bhbj5JIHRoaW5rIHRoYXQgcGFydCBpcyBjbGVhci4gV2hhdCBwcm9i YWJseSBuZWVkcyB0byBiZSBzYWlkIGlzIHRoYXQgeW91IGNhbid0IHVzZSAmcXVvdDthbHdheXMm cXVvdDsgaWYgdGhpcyBzY2hlbWUgaXMgaW4gdXNlICh1bmxlc3MgeW91IHdhbnQgdG8gcmVzb2x2 ZSBpdCBzb21lIG90aGVyIHdheSkuPGJyPg0KPGJyPg0KPGJyPg0KW3NldmVyYWwgcmVzb2x2ZWQg cG9pbnRzIGVsaWRlZF08c3BhbiBjbGFzcz0iIj48YnI+DQo8YnI+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KLSBTZWN0aW9uIDUgYWxzbyBzdWdnZXN0cyBrZXlzIGJlIGVu Y3J5cHRlZCBvciBvYmZ1c2NhdGVkIG9uIHRoZSBkZXZpY2U8YnI+DQp0aGF0IGlzIHRvIHVzZSB0 aGVtLCBwcmVzdW1hYmx5IGluIGEgd2F5IHRoYXQgY2FuIGJlIGRlY3J5cHRlZCBvcjxicj4NCnVu b2JmdXNjYXRlZCB1c2luZyBpbmZvcm1hdGlvbiBhbHNvIG9uIHRoZSBkZXZpY2UuIEkgZG9uJ3Qg a25vdyB3aGF0IHRoZTxicj4NCmN1cnJlbnQgc2VjdXJpdHkgYXJlYSB0aGlua2luZyBhcm91bmQg dGhpcyBpcywgYnV0IGdpdmVuIHRoYXQgdGhlPGJyPg0KaW5mb3JtYXRpb24gbmVlZGVkIHRvIHJl dHJpZXZlIHBsYWludGV4dCBrZXlzIGlzIG5lY2Vzc2FyaWx5IHByZXNlbnQgb248YnI+DQp0aGUg ZGV2aWNlLCB0aGlzIHNlZW1zIGxpa2UgYSBmaWctbGVhZiB0aGF0IHByb3ZpZGVzIGFuIGlsbHVz aW9uIG9mPGJyPg0Kc2VjdXJpdHkgd2l0aG91dCBwcm92aWRpbmcgYW55IHJlYWwgYmVuZWZpdC4g VGhhdCBtaXMtaW1wcmVzc2lvbiBzZWVtczxicj4NCnBvdGVudGlhbGx5IGhhcm1mdWwuPGJyPg0K PC9ibG9ja3F1b3RlPg0KSSBvbmx5IGFkZGVkIHRoaXMgYXQgdGhlIGJlaGVzdCBvZiBvbmUgb2Yg dGhlIG90aGVyIHJldmlld3MuIFRoZSBwcm9ibGVtPGJyPg0Kd2l0aCBzZWN1cml0eSBpcyB0aGF0 IHRoZXJlIGNvbmZsaWN0aW5nIG9waW5pb25zLCBhbmQgYXMgdGhlIGFkYWdlIGdvZXM8YnI+DQri gJxldmVyeWJvZHnigJlzIGdvdCBvbmUu4oCdIEnigJlsbCBkZWZlciB0byB0aGUgU2VjdXJpdHkg QURzLjxicj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjwvc3Bhbj5SaWdodDsgdGhhdCdzIHdoYXQg SSBtZWFudCBieSAmcXVvdDtJIGRvbid0IGtub3cgd2hhdCB0aGUgY3VycmVudCBzZWN1cml0eSBh cmVhIHRoaW5raW5nIGFyb3VuZCB0aGlzIGlzLiZxdW90OyBJJ2QgYmUgY3VyaW91cyB0byBoYXZl IEVLUiBvciBLYXRobGVlbiB3ZWlnaCBpbjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PldoYXQgSSB0b29rIGhvbWUgaGVyZSB3YXMgdGhhdCB5b3Ugd291bGQgZW5jcnlwdCB0 aGVtIGFuZCBkaXNwbGF5IHRoZSBlbmNyeXB0ZWQ8L2Rpdj4NCjxkaXY+dmVyc2lvbiBpbnN0ZWFk IG9mIHNob3dpbmcgYXN0ZXJpc2tzLiBJcyB0aGF0IG5vdCB3aGF0IHRoZSB0aGlua2luZyB3YXM/ PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBkb27igJl0IGJyb2FjaCB0 aGUgc3ViamVjdCBvZiBkaXNwbGF5IGhlcmUg4oCTIHRoaXMgaXMgd2l0aCByZXNwZWN0IHRvIHRo ZSBpbnRlcm5hbCBzdG9yYWdlIG9mIHRoZSBrZXlzLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+QXJlIHlvdSB0YWxraW5nIGFib3V0IHRoZSBORVRDT05GICZsdDtnZXQtY29u ZmlnJmd0OyBvcGVyYXRpb24gW1JGQyA2MjQxXSBvbiB0aGUgWUFORyBtb2RlbD8gSWYgeW91IGhh dmUgdGhlIHByb3BlciBOQ0FDTSBwZXJtaXNzaW9ucywgdGhlbiB5b3Ugd2lsbCBiZSBhYmxlIHRv IHJldHJpZXZlIHRoZSBrZXkgc3RyaW5ncyBpbiBwbGFpbiB0ZXh0LiZuYnNwOzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6 MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tRWtyPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8c3BhbiBjbGFzcz0i SE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPg0KL2E8YnI+DQo8YnI+DQo8L2ZvbnQ+ PC9zcGFuPjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D5256856AB5F2aceeciscocom_-- From nobody Wed Apr 26 01:39:12 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A89F1319EA; Wed, 26 Apr 2017 01:39:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: akatlas@gmail.com, jefftant.ietf@gmail.com, rtgwg-chairs@ietf.org, rtgwg@ietf.org Subject: rtgwg - Update to a Meeting Session Request for IETF 99 X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149319595040.6340.13071580920945034985.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 01:39:10 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 08:39:10 -0000 An update to a meeting session request has just been submitted by Jeff Tantsura, a Chair of the rtgwg working group. --------------------------------------------------------- Working Group Name: Routing Area Working Group Area Name: Routing Area Session Requester: Jeff Tantsura Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2 Hours Number of Attendees: 200 Conflicts to Avoid: People who must be present: Alia Atlas Jeff Tantsura Chris Bowers Resources Requested: Special Requests: RTGWG has a rather wide charter, we would like to avoid conflict with any other RTG WG/BoF. First meeting is mostly dedicated to YANG and conflicts with netconf, netmod and lime should be avoided. --------------------------------------------------------- From nobody Wed Apr 26 02:00:05 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD98131A42 for ; Wed, 26 Apr 2017 02:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzgcJ7JEgRH4 for ; Wed, 26 Apr 2017 02:00:00 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C737131A3F for ; Wed, 26 Apr 2017 02:00:00 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id u65so31388572wmu.3 for ; Wed, 26 Apr 2017 02:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=fyYPZIvxPhl9wE+B9suRts8mKqZSVRoXvhRoOfex8tQ=; b=tCC+lzAlVlk/3oticEJAqM9T4s+kx3J5aSTEgwZ6r6HfyjY4uHJ6XIe9TCNYNAMWb6 sHbMMHwzw82nelbRu8gBheFBqaivLBA2YecZRzaNNwJqOvMfbSl8/KlzagckpslXhMPe yCC8nTzYn61Na2tQVvvQgWqjUGwiwk6iIfepJT+Wlr3YLzhStniEswibUIR9xqUNtBNn 49xc5aizBbCgzOpdajjawcPgmN6VBHu4qNu5n/67Ol0AThJjjXqZ96i5YcRg04xh3RZw 8abg61LxYLvu/ycJPvBxn9ECPZJr574nkqX+xMSpW8MTDvXb/dwmCXzJtQ0ZWYBLd5hG jJow== 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:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=fyYPZIvxPhl9wE+B9suRts8mKqZSVRoXvhRoOfex8tQ=; b=FeNt/mbZ7t7FZAMzV8G726s+MwAb+RsQ71NkYXHdgBNWEqfISFNL5GeyLy6IaXA5y2 u618MdYM2z6gKZh04QFjjhrr9rHuBkrxXRCo2nerXC8sLPqqo4vhLqel4ynQLKq86zP0 F8InK4q6gD+8XwWG1gPQrxO425970ol3z/7PjjDuYg71ZS/wNNc8vhMiL3GE8cXNdiW1 v3Lys5hrkIBCct7QGf+e83J0zxtgU2yzbjSvKk88kuGkjaUBWlx2i7r9VAv7EDIrDb6H cshNyknaQTz2Bp/etQSM7zKrqEBL4RBG9mfCw3NU/gZ0WgD5S1xVjwjQApJYcOI+aZlI vfQQ== X-Gm-Message-State: AN3rC/57kufW9nRQHBmLAe0QwtV8Y6evo5SP0tZsqsmuJmijsZCiQFfF hkDEL48AhGaM3g== X-Received: by 10.28.69.147 with SMTP id l19mr4594325wmi.91.1493197199016; Wed, 26 Apr 2017 01:59:59 -0700 (PDT) Received: from [192.168.1.26] ([5.29.156.189]) by smtp.gmail.com with ESMTPSA id w10sm5282199wmw.14.2017.04.26.01.59.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 01:59:58 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.21.0.170409 Date: Wed, 26 Apr 2017 01:58:33 -0700 Subject: Re: Query on Re: RTGWG minutes IETF98 From: Jeff Tantsura To: "t.petch" , RTGWG CC: rtgwg-chairs Message-ID: <008170D4-B3D9-4401-98EB-FB74F3FFB762@gmail.com> Thread-Topic: Query on Re: RTGWG minutes IETF98 References: <037a01d2bac8$b8f42800$4001a8c0@gateway.2wire.net> In-Reply-To: <037a01d2bac8$b8f42800$4001a8c0@gateway.2wire.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 09:00:03 -0000 Hi Tom, The finalized version of =E2=80=9Cupdated nmda guidelines=E2=80=9D will be published s= oon.=20 That=E2=80=99s the document describing the new guidelines, please use it for your= further references.=20 Hope this helps, Cheers, Jeff =20 On 4/21/17, 08:55, "t.petch" wrote: "JT: Xufeng presented 4 considerations yesterday on how to proceed, please take a look." =20 Do you have a reference for that, preferrably an I-D and not PowerPoint= ? =20 Tom Petch =20 =20 ----- Original Message ----- From: "Jeff Tantsura" To: "RTGWG" Cc: "rtgwg-chairs" Sent: Friday, April 14, 2017 12:08 AM > > The minutes have been published at: https://datatracker.ietf.org/doc/minutes-98-rtgwg/ > Please provide your comments. > > Thanks! > Jeff & Chris > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg =20 =20 From nobody Wed Apr 26 06:15:05 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5C4129B88; Wed, 26 Apr 2017 06:14:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-rtgwg-yang-key-chain@ietf.org, Jeff Tantsura , rtgwg-chairs@ietf.org, jefftant.ietf@gmail.com, rtgwg@ietf.org Subject: Benoit Claise's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149321249896.13684.11935486935025787351.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 06:14:58 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 13:14:59 -0000 Benoit Claise has entered the following ballot position for draft-ietf-rtgwg-yang-key-chain-20: 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-rtgwg-yang-key-chain/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial: - To be aligned with the other feature descriptions: OLD: feature accept-tolerance { description "To specify the tolerance or acceptance limit."; } NEW: feature accept-tolerance { description "Support the tolerance or acceptance limit."; } - I would spell out "Network Management Datastore Architecture" [NMDA] All lights are green from a tooling point of view. As a side note, since you used the new NMDA tree structure, I would warn all the draft authors with YANG modules that depend on this YANG module that they might have to update their modules. See https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-key-chain&recurse=0&rfcs=0 for the source of information. From nobody Wed Apr 26 06:18:35 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FEC129B98 for ; Wed, 26 Apr 2017 06:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIJCNhdjIDbZ for ; Wed, 26 Apr 2017 06:18:30 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0101.outbound.protection.outlook.com [104.47.42.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C6812741D for ; Wed, 26 Apr 2017 06:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u5WLsM8tVo4LjpnvobGvXNxosxIokC9E24P+kLswRtU=; b=SH9GuWIVBdWklohFb1Mk3mAYhxWhndZFB5qkxdQgVeG9q/uLKNQrszSdR98K0Va4l0z8HDh++te5LaVnumB8o9sWZ9JECzL8LEIh/SBpncrnfKzhOMMOfB9UTTV9uYBTVass6dbvAtSRsXxBHIPr9hYakiTcdMC7bFR45pzwZxE= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by DM2PR02MB1371.namprd02.prod.outlook.com (10.161.143.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Wed, 26 Apr 2017 13:18:28 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1047.019; Wed, 26 Apr 2017 13:18:27 +0000 From: Xufeng Liu To: Henning Rogge CC: Jonathan Hardwick , Athanasios Kyparlis , "parikhr@vmware.com" , "zhangmingui@huawei.com" , Routing WG Subject: RE: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp Thread-Topic: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp Thread-Index: AQHSvM5DkWzkWiy5OUyGyrzZT7T+E6HWF3bAgAAEdICAAYkXIA== Date: Wed, 26 Apr 2017 13:18:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=jabil.com; x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR02MB1371; 7:LxcBTx9pGVme1oaRVhtIqHLZNdNr0Wcek3bsn+fFpj34VZT5zq9sNhV1BzWo/MjgfcW3lNa5IQdCGmcP/ZRBj8qQUYJM4HbLy4FR1UasOUINE8+/ACd8UVUu0jfp3n06uw7deGHnzqEV8UDAghrkGMDSAOzEo++8I9MMbul1/ZfPAHLa5iozVfCOIyjCtaxeFAQ5opk1wdOXbB09XUGfjGcwEc5qVQ+4Pj0+kAQCduZ/TMwj/6toSUgTIZodtlr5QJ4fij4l4PSsATGVL7GwTuVyPFYmKgxB5kcM3dURZO0eT2Ku+mGeTW6GsKXkLZqVeeVTdLZpMmh88EUV4ifNdw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39400400002)(39860400002)(39840400002)(39450400003)(66654002)(377454003)(13464003)(24454002)(229853002)(2900100001)(86362001)(2950100002)(5660300001)(3660700001)(93886004)(6916009)(102836003)(3280700002)(6116002)(33656002)(2906002)(3846002)(80792005)(66066001)(74316002)(77096006)(122556002)(6506006)(6436002)(110136004)(6306002)(50986999)(9686003)(54356999)(189998001)(4326008)(305945005)(76176999)(55016002)(99286003)(8936002)(7736002)(39060400002)(6246003)(25786009)(54906002)(8676002)(38730400002)(1411001)(81166006)(53936002)(7696004)(53546009)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR02MB1371; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: edd72d40-e14b-4910-0e73-08d48ca6b9c3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM2PR02MB1371; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(120809045254105)(50582790962513)(21534305686606); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:DM2PR02MB1371; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1371; x-forefront-prvs: 0289B6431E spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2017 13:18:26.8885 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1371 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 13:18:33 -0000 SGkgSGVubmluZywNCg0KWWVzLiBXZSB3aWxsIGFkZCBzb21lIGV4cGxhbmF0aW9ucy4NClRoYW5r cywNCi0gWHVmZW5nDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGVu bmluZyBSb2dnZSBbbWFpbHRvOmhyb2dnZUBnbWFpbC5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEFw cmlsIDI1LCAyMDE3IDk6NTAgQU0NCj4gVG86IFh1ZmVuZyBMaXUgPFh1ZmVuZ19MaXVAamFiaWwu Y29tPg0KPiBDYzogSm9uYXRoYW4gSGFyZHdpY2sgPEpvbmF0aGFuLkhhcmR3aWNrQG1ldGFzd2l0 Y2guY29tPjsgQXRoYW5hc2lvcw0KPiBLeXBhcmxpcyA8QXRoYW5hc2lvc19LeXBhcmxpc0BqYWJp bC5jb20+OyBwYXJpa2hyQHZtd2FyZS5jb207DQo+IHpoYW5nbWluZ3VpQGh1YXdlaS5jb207IFJv dXRpbmcgV0cgPHJ0Z3dnQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogUm91dGluZyBkaXJlY3Rv cmF0ZSBRQSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLXZycnANCj4gDQo+IE9uIFR1 ZSwgQXByIDI1LCAyMDE3IGF0IDM6NDcgUE0sIFh1ZmVuZyBMaXUgPFh1ZmVuZ19MaXVAamFiaWwu Y29tPiB3cm90ZToNCj4gPg0KPiA+IEhpIEhlbm5pbmcsDQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhh bmsgeW91IG11Y2ggZm9yIHRoZSByZXZpZXcuDQo+ID4NCj4gPg0KPiA+DQo+ID4gWW91IGFyZSBy aWdodCBhYm91dCB0aGUgbWFwcGluZyBmb3IgImFkZHJlc3Mgb2YgdGhlIHZpcnR1YWwgcm91dGVy Ii4gVGhlDQo+IGV4aXN0aW5nIFlBTkcgZGF0YSBtb2RlbCBmb3IgY29uZmlndXJpbmcgYW5kIG1h bmFnaW5nIElQIGFkZHJlc3NlcyBpcyBSRkM3Mjc3LA0KPiB3aGljaCBhdWdtZW50cyB0aGUgaWV0 Zi1pbnRlcmZhY2VzIG1vZGVsIHNwZWNpZmllZCBieSBSRkM3MjIzLiBUaGlzIFZSUlANCj4gbW9k ZWwgZm9sbG93cyB0aGUgc2FtZSBwYXJhZGlnbS4gU3VjaCBhIHN0cnVjdHVyZSBpcyBhbHNvIFZS UlAgcHJvdG9jb2xzIGFyZQ0KPiB1c3VhbGx5IGltcGxlbWVudGVkLg0KPiANCj4gTWF5YmUgdGhl IG5hbWluZyBvZiB0aGUgdmFyaWFibGVzIG9yIHRoZSBleHBsYW5hdGlvbiBvZiB0aGVtIGNvdWxk IGJlDQo+IGltcHJvdmVkIHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhpcy4NCj4gDQo+IEhlbm5pbmcN Cj4gDQo+ID4NCj4gPg0KPiA+DQo+ID4gV2Ugd2lsbCBmaXggdGhlIGVycm9yIGluICBBcHBlbmRp eCBBLiBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCj4gPg0KPiA+DQo+ID4NCj4gPiBSZWdhcmRzLA0K PiA+DQo+ID4gLSBYdWZlbmcNCj4gPg0KPiA+DQo+ID4NCj4gPiBGcm9tOiBIZW5uaW5nIFJvZ2dl IFttYWlsdG86aHJvZ2dlQGdtYWlsLmNvbV0NCj4gPiBTZW50OiBNb25kYXksIEFwcmlsIDI0LCAy MDE3IDM6NDEgQU0NCj4gPiBUbzogSm9uYXRoYW4gSGFyZHdpY2sgPEpvbmF0aGFuLkhhcmR3aWNr QG1ldGFzd2l0Y2guY29tPjsgWHVmZW5nIExpdQ0KPiA+IDxYdWZlbmdfTGl1QGphYmlsLmNvbT47 IEF0aGFuYXNpb3MgS3lwYXJsaXMNCj4gPiA8QXRoYW5hc2lvc19LeXBhcmxpc0BqYWJpbC5jb20+ OyBwYXJpa2hyQHZtd2FyZS5jb207DQo+ID4gemhhbmdtaW5ndWlAaHVhd2VpLmNvbQ0KPiA+IENj OiBSb3V0aW5nIFdHIDxydGd3Z0BpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBSZTogUm91dGluZyBk aXJlY3RvcmF0ZSBRQSByZXZpZXcgb2YNCj4gPiBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmctdnJycA0K PiA+DQo+ID4NCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4NCj4gPg0KPiA+IEpvbmF0aGFuIEhhcmR3 aWNrIGFza2VkIG1lIHRvIGRvIGFuIGVhcmx5IHJldmlldyBvZiB0aGUgZHJhZnQtaWV0Zi1ydGd3 Zy0NCj4geWFuZy12cnJwIGRvY3VtZW50IChjdXJyZW50bHkgcmV2aXNpb24gMDIpIGZvciB0aGUg cm91dGluZyBkaXJlY3RvcmF0ZS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGUgZHJhZnQgaXRzZWxm IGlzIHByZXR0eSBzdHJhaWdodCBmb3J3YXJkIGFuZCBjb21wYWN0LCBlc3BlY2lhbGx5IHdoZW4g eW91DQo+IGNvbnNpZGVyIHRoYXQgYSBsb3Qgb2YgdGV4dCBoYXMgdG8gYmUgcmVwZWF0ZWQgdHdv IG9yIGZvdXIgdGltZXMgKElQdjQvSVB2NiwNCj4gY29uZmlnIHZzLiByZWFkLW9ubHkgc3RhdGUp Lg0KPiA+DQo+ID4NCj4gPg0KPiA+IEJ1dCBJIGhhZCBxdWl0ZSBhIGJpdCBvZiB0cm91YmxlIG1h cHBpbmcgdGhlIHBocmFzZXMgZnJvbSB0aGUgbmV3IGRyYWZ0LWlldGYtDQo+IHJ0Z3dnLXlhbmct dnJycC0wMiBkb2N1bWVudCB0byB0aGUgZXhpc3RpbmcgVlJSUCBkb2N1bWVudHMgKGUuZy4gUkZD NTc5OCkuDQo+IFRoaXMgbWlnaHQgY29tZSBmcm9tIG15IHVuZmFtaWxhcml0eSB3aXRoIFZSUlAu DQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhlIGRyYWZ0IFlBTkcgbW9kZWwgYWxsb3dzIHRvIHJlYWQg KGlmOmludGVyZmFjZXMtc3RhdGUpIGFuZCBjb25maWd1cmUNCj4gKGlmOmludGVyZmFjZXMpIHZp cnR1YWwgSVAgYWRkcmVzc2VzLCBidXQgdGhpcyBkb2VzIG5vdCBzZWVtIHRvIGJlIGEgY29tbW9u DQo+IHBocmFzZSBmcm9tIHRoZSBSRkNzLiBJcyBpdCB0aGUgc2FtZSBhcyAiYWRkcmVzcyBvZiB0 aGUgdmlydHVhbCByb3V0ZXIiIG9mdGVuDQo+IG1lbnRpb25lZCBpbiBSRkM1Nzk4Pw0KPiA+DQo+ ID4NCj4gPg0KPiA+IEluIGFkZGl0aW9uIHRvIHRoaXMsIEkgZm91bmQgKEkgdGhpbmspIGEgdHlw byBvciBpbmNvbnNpc3RlbmN5IGluIEFwcGVuZGl4IEE6DQo+ID4NCj4gPiB0aGUgYXNjaWkgYXJ0 IHNheXMgImV0aDAiIGJ1dCB0cmVlIHNheXMgImV0aDEiLg0KPiA+DQo+ID4NCj4gPg0KPiA+IEhl bm5pbmcgUm9nZ2UNCj4gPg0KPiA+DQo+ID4NCj4gPiBPbiBNb24sIE1hciAyNywgMjAxNyBhdCA1 OjQzIFBNLCBKb25hdGhhbiBIYXJkd2ljaw0KPiA8Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRj aC5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgSGVubmluZw0KPiA+DQo+ID4NCj4gPg0KPiA+IFBs ZWFzZSB3b3VsZCB5b3UgZG8gYSByb3V0aW5nIGRpcmVjdG9yYXRlIGVhcmx5IHJldmlldyBvZiB0 aGlzIGRyYWZ0PyAgV291bGQNCj4geW91IGJlIGFibGUgdG8gZG8gaXQgaW4gMiB0byAzIHdlZWtz Pw0KPiA+DQo+ID4NCj4gPg0KPiA+IE1hbnkgdGhhbmtzDQo+ID4NCj4gPiBKb24NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+DQo+ID4gUGxlYXNlIHdvdWxkIHlvdSBkbyBhIHJvdXRpbmcgZGlyZWN0 b3JhdGUgUUEgcmV2aWV3IG9mIHRoaXMgZHJhZnQ/DQo+ID4NCj4gPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Z3dnLXlhbmctdnJycC8NCj4gPg0KPiA+DQo+ ID4NCj4gPiBUaGUgZHJhZnQgaXMgc3RpbGwgaW4gdGhlIFJUR1dHIGFuZCBpcyByZWFkeSBmb3Ig V0cgbGFzdCBjYWxsLiAgVGhlIFdHIGNoYWlycw0KPiBoYXZlIGFza2VkIGZvciBhIFFBIHJldmll dyBmcm9tIHRoZSBkaXJlY3RvcmF0ZS4gIFRoZSBmb2xsb3dpbmcgbGluayBwcm92aWRlcw0KPiBn dWlkYW5jZSBvbiBRQSByZXZpZXdzLg0KPiA+DQo+ID4gaHR0cHM6Ly90cmFjLmlldGYub3JnL3Ry YWMvcnRnL3dpa2kvUnRnRGlyRG9jUWENCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCg== From nobody Wed Apr 26 08:37:21 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACDA12EBB9; Wed, 26 Apr 2017 08:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zahe06USOiZ9; Wed, 26 Apr 2017 08:37:09 -0700 (PDT) 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 8133D12EC8C; Wed, 26 Apr 2017 08:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2350; q=dns/txt; s=iport; t=1493221022; x=1494430622; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DvN0RpPv/kXrhGwfuTajIa/I6QHfmqz/fi5yYbeHjlQ=; b=W/r11T7EzmM4Es5k302JVPCvtuUVECD7U+oJIs39/SF7VrbF8GUoEOAB U5PkQ4Hfu2+GWfpgA2vSra8YPanImJ3hyXBGz3ve6pBo9kDgINTy0qPh+ K5LoBkMhum/bGksMOXiSc7qDmcmHV6aOQDs9vrUGJt7p9lWzA3QlFmlSW o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlAQCGvQBZ/49dJa1BGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNVYYEMB4NhihanNYIPLIV4AhqECj8YAQIBAQEBAQEBayiFFgY?= =?us-ascii?q?jEUUQAgEIEggCJgICAjAVAg4CBAENBYobDjGqBoImiycBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYELhyeDGoQxCwYBHIMGgl8FiTyUEgGHGItyggKFN4oliHSLMgE?= =?us-ascii?q?fOH8IZRWFZoFKdQGGOA4XgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208";a="236082327" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2017 15:37:01 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3QFb1xX005601 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 15:37:01 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 11:37:00 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 26 Apr 2017 11:37:00 -0400 From: "Acee Lindem (acee)" To: "Benoit Claise (bclaise)" , The IESG CC: "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "rtgwg@ietf.org" Subject: Re: Benoit Claise's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Benoit Claise's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvqLy6vuyk9QtUUunFw5Ta0XTPg== Date: Wed, 26 Apr 2017 15:37:00 +0000 Message-ID: References: <149321249896.13684.11935486935025787351.idtracker@ietfa.amsl.com> In-Reply-To: <149321249896.13684.11935486935025787351.idtracker@ietfa.amsl.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.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:37:12 -0000 SGkgQmVub2l0LCANCknigJlsbCBpbmNvcnBvcmF0ZSBib3RoIGNvbW1lbnRzLg0KVGhhbmtzLA0K QWNlZSANCg0KT24gNC8yNi8xNywgOToxNCBBTSwgIkJlbm9pdCBDbGFpc2UgKGJjbGFpc2UpIiA8 YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0KDQo+QmVub2l0IENsYWlzZSBoYXMgZW50ZXJlZCB0 aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj5kcmFmdC1pZXRmLXJ0Z3dnLXlhbmct a2V5LWNoYWluLTIwOiBObyBPYmplY3Rpb24NCj4NCj5XaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBr ZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj5lbWFpbCBhZGRy ZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQg dGhpcw0KPmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPg0KPg0KPlBsZWFzZSBy ZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRl cmlhLmh0bWwNCj5mb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENP TU1FTlQgcG9zaXRpb25zLg0KPg0KPg0KPlRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBi YWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluLw0KPg0KPg0KPg0K Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj5DT01NRU5UOg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj5FZGl0b3JpYWw6 DQo+DQo+LSBUbyBiZSBhbGlnbmVkIHdpdGggdGhlIG90aGVyIGZlYXR1cmUgZGVzY3JpcHRpb25z Og0KPk9MRDoNCj4NCj4gIGZlYXR1cmUgYWNjZXB0LXRvbGVyYW5jZSB7DQo+ICAgICAgIGRlc2Ny aXB0aW9uDQo+ICAgICAgICAgIlRvIHNwZWNpZnkgdGhlIHRvbGVyYW5jZSBvciBhY2NlcHRhbmNl IGxpbWl0LiI7DQo+ICAgICB9DQo+DQo+TkVXOg0KPg0KPiAgZmVhdHVyZSBhY2NlcHQtdG9sZXJh bmNlIHsNCj4gICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAgICAiU3VwcG9ydCB0aGUgdG9sZXJh bmNlIG9yIGFjY2VwdGFuY2UgbGltaXQuIjsNCj4gICAgIH0NCj4NCj4tIEkgd291bGQgc3BlbGwg b3V0ICJOZXR3b3JrIE1hbmFnZW1lbnQgRGF0YXN0b3JlIEFyY2hpdGVjdHVyZSIgW05NREFdDQo+ DQo+QWxsIGxpZ2h0cyBhcmUgZ3JlZW4gZnJvbSBhIHRvb2xpbmcgcG9pbnQgb2Ygdmlldy4NCj5B cyBhIHNpZGUgbm90ZSwgc2luY2UgeW91IHVzZWQgdGhlIG5ldyBOTURBIHRyZWUgc3RydWN0dXJl LCBJIHdvdWxkIHdhcm4NCj5hbGwgdGhlIGRyYWZ0IGF1dGhvcnMgd2l0aCBZQU5HIG1vZHVsZXMg dGhhdCBkZXBlbmQgb24gdGhpcyBZQU5HIG1vZHVsZQ0KPnRoYXQgdGhleSBtaWdodCBoYXZlIHRv IHVwZGF0ZSB0aGVpciBtb2R1bGVzLiBTZWUNCj5odHRwczovL3d3dy55YW5nY2F0YWxvZy5vcmcv eWFuZy1zZWFyY2gvaW1wYWN0X2FuYWx5c2lzLnBocD9tb2R1bGVzW109aWV0Zg0KPi1rZXktY2hh aW4mcmVjdXJzZT0wJnJmY3M9MA0KPmZvciB0aGUgc291cmNlIG9mIGluZm9ybWF0aW9uLg0KPg0K Pg0KDQo= From nobody Wed Apr 26 08:45:15 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FBC130889; Wed, 26 Apr 2017 08:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnpq321b2lM6; Wed, 26 Apr 2017 08:45:03 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5DE131446; Wed, 26 Apr 2017 08:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6960; q=dns/txt; s=iport; t=1493221503; x=1494431103; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DYUYzOFl9RJSYkdCgjwc3wR1EEgR+U52hH8MYqFyezs=; b=Sc192j/g3hM3Y+bLJhVW+1QC+C+1rseDHAbswZXqcSWB6+FwIqwlcU+u l4WovRvlg44FB8vDjzoqpduM/zbZdE/xGk6Vv3iNCsD2Hti556sn1Mz4l yMXmVZvsblbeBbxCtMj7NHv5soShBDytGUGMDvQUISVuNO863LWsLkohH I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAgCOvwBZ/5JdJa1RAQYDGQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBg1WBWxIHg2GKFpEpIZVrgg+CboM2AhqECj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQECASMRRQULAgEIGAICJgICAjAVEAIEDgMCihMIqj+CJosmAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYELh1ILgmSEMQYBCgEcFwomgj8ugjEFiUGUDQG?= =?us-ascii?q?TCpFelCYBHzh/CGUVVgGFD4FKQzKGR4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208";a="416279277" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2017 15:45:01 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3QFj1i1001402 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 15:45:01 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 11:45:00 -0400 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.1210.000; Wed, 26 Apr 2017 11:45:00 -0400 From: "Brian Weis (bew)" To: "Acee Lindem (acee)" CC: Adam Roach , The IESG , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvgrQg2iqyhFsfkS24vnExw0B6KHWqNaAgABJNoD//982gIABPdYA Date: Wed, 26 Apr 2017 15:45:00 +0000 Message-ID: References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.174] Content-Type: text/plain; charset="utf-8" Content-ID: <339547B65EC77644A382582A015FA801@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:45:05 -0000 RGlzdHJpYnV0aW5nIGFuZCBtYWludGFpbmluZyBrZXlzIGhhcyBhIGhpZ2hlciBzZWN1cml0eSBi YXIgdGhhbiBtb3N0IGNvbmZpZ3VyYXRpb24gaXRlbXMsIGJlY2F1c2UgdGhlaXIgbGVha2FnZSBj YW4gdXN1YWxseSBjYXVzZSBtb3JlIGhhcm0uIEZvciBleGFtcGxlLCBhIGxlYWtlZCBrZXkgZnJv bSB0aGUgcm91dGluZyBrZXkgY2hhaW4gY291bGQgYWxsb3cgYW4gYXR0YWNrZXIgdG8gc3Vic3Rp dHV0ZSBpdHMgb3duIHJvdXRpbmcgbWVzc2FnZXMgZm9yIGF1dGhlbnRpYyBvbmVzLg0KDQpEaXN0 cmlidXRpbmcgcGxhaW4tdGV4dCBrZXlzIHRocm91Z2ggYSBnZW5lcmFsIHB1cnBvc2UgY29uZmln dXJhdGlvbiBwcm90b2NvbCBpcyBub3QgYWx3YXlzIGNvbnNpZGVyZWQgc2FmZS4gV2hlbiB0aGUg Y29uZmlndXJhdGlvbiAgcHJvdG9jb2wgaXMgcHJvdGVjdGVkIChlLmcuLCBUTFMpLCB0aGUgc2Vj dXJpdHkgcmVxdWlyZW1lbnRzIG9mIHNvbWUgdXNlcnMgYXJlIHNhdGlzZmllZCBiZWNhdXNlIHRo ZXkgYXJlIG9ubHkgd29ycmllZCBhYm91dCBwcm90ZWN0aW5nIHRoZSBrZXlzIG9uIHRoZSB3aXJl LiAgQnV0IG90aGVyIHVzZXJzIHdpdGggbGFyZ2VyIHRocmVhdCBwcm9maWxlIChlLmcuLCBnb3Zl cm5tZW50IHVzZXJzKSBvZnRlbiBkbyBub3QgY29uc2lkZXIgc2VuZGluZyBwbGFpbi10ZXh0IGtl eXMgdGhyb3VnaCBhIHByb3RlY3RlZCBjb25maWd1cmF0aW9uIHByb3RvY29sIHRvIGJlIHN1ZmZp Y2llbnQsIGJlY2F1c2UgdGhleSBtYXkgbm90IGhhdmUgZW5vdWdoIGNvbnRyb2wgb3ZlciB0aGUg Y2lwaGVycyBjaG9zZW4gZm9yIHRoZSBUTFMgc2Vzc2lvbiwgb3IgcGVyaGFwcyB0aGV5IHdhbnQg dG8gcHJvdGVjdCB0aGUga2V5cyBpbiB0aGUgY29uZmlndXJhdGlvbiBzeXN0ZW0gYmVmb3JlIHRo ZXkgYXJlIGRlbGl2ZXJlZCB0byB0aGUgVExTIHNlc3Npb24uIEluIHRoZXNlIGNhc2VzIGl04oCZ cyB2YWx1YWJsZSB0byAia2V5IHdyYXDigJ0gKGVuY3J5cHQpIHRoZSBrZXlzIGluIHRoZSBzb2Z0 d2FyZSB0aGF0IGdlbmVyYXRlcyB0aGUga2V5cywgYW5kIHVud3JhcCB0aGVtIGluIHRoZSBwaWVj ZSBvZiBzb2Z0d2FyZSB0aGF0IGlzIGFjdHVhbGx5IGluc3RhbGxpbmcgdGhlIGtleXMuIFRoYXTi gJlzIHRoZSBtb3RpdmF0aW9uIGZvciBpbmNsdWRpbmcgYW4gb3B0aW9uYWwga2V5IHdyYXAgbWV0 aG9kIGluIHRoZSBrZXkgY2hhaW4gWWFuZyBkYXRhIG1vZGVsLg0KDQpZZXMsIHVzaW5nIGEga2V5 IHdyYXAgbWV0aG9kIG1lYW5zIHRoZXJl4oCZcyBhbiBleHRyYSBjb21wbGljYXRpb24gd2l0aCAg bmVlZGluZyB0byBtYWludGFpbiBhIGtleSB3cmFwIGtleS4gVXNlcnMgdGhhdCByZXF1aXJlIHRo ZSB1c2Ugb2YgYSBrZXkgd3JhcCBwcm9iYWJseSBkb27igJl0IGhhdmUgYSBwcm9ibGVtIHdpdGgg ZGlzdHJpYnV0aW5nIGEga2V5IG91dCBvZiBiYW5kIGZvciB0aGlzLiBEaXN0cmlidXRpbmcgaXQg aW4tYmFuZCB3b3VsZCBsaWtlbHkgbWVhbiBzZW5kaW5nIGl0IHRocm91Z2ggYSBkaWZmZXJlbnQg WWFuZyBkYXRhIG1vZGVsLCB3aGljaCB3b3VsZCBoYXZlIGV4YWN0bHkgdGhlIHNhbWUgcHJvYmxl bSBvZiBuZWVkaW5nIHRvIGJlIGtleSB3cmFwcGVkIHNvIEnigJltIG5vdCBzdXJlIGl04oCZcyB2 YWx1YWJsZSB0byBldmVuIHNwZWNpZnkgYW4gaW4tYmFuZCBtZXRob2QuIElmIHRoYXTigJlzIGEg aGFyZCByZXF1aXJlbWVudCwgdGhlbiBJIHN1cHBvc2UgdGhlIGtleSB3cmFwIG1ldGhvZCBjYW4g YmUgcmVtb3ZlZC4gQnV0IHRoZSByZW1vdmFsIG9mIHRoZSBrZXkgd3JhcCBvcHRpb24gIGlzIGxp a2VseSB0byByZXN0cmljdCB0aGUgdXNlcnMgd2hvIGNhbiB1c2UgdGhlIGtleSBjaGFpbiBkYXRh IG1vZGUuDQoNCkhvcGUgdGhhdCBoZWxwcywNCkJyaWFuDQoNCj4gT24gQXByIDI1LCAyMDE3LCBh dCA1OjQ3IFBNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4g DQo+IA0KPiANCj4gT24gNC8yNS8xNywgNjo0NCBQTSwgIkFkYW0gUm9hY2giIDxhZGFtQG5vc3Ry dW0uY29tPiB3cm90ZToNCj4gDQo+PiBPbiA0LzI1LzE3IDE3OjIyLCBBY2VlIExpbmRlbSAoYWNl ZSkgd3JvdGU6DQo+Pj4gSGkgQWRhbSwNCj4+PiANCj4+PiBPbiA0LzI1LzE3LCA1OjI3IFBNLCAi QWRhbSBSb2FjaCIgPGFkYW1Abm9zdHJ1bS5jb20+IHdyb3RlOg0KPj4+IA0KPj4+PiAtIFNlY3Rp b24gNSBkaXNjdXNzZXMgdGhlIHVzZSBvZiBhIEtFSywgZGlzdHJpYnV0ZWQgb3V0LW9mLWJhbmQs IHRvDQo+Pj4+IGRlY3J5cHQgdGhlIGtleXMgc3RvcmVkIGluIHRoaXMgZm9ybWF0LiBUaGVyZSBh cHBlYXJzIHRvIGJlIG5vDQo+Pj4+IGFmZm9yZGFuY2UNCj4+Pj4gZm9yIGluZGljYXRpbmcgdGhl IGlkZW50aXR5IG9mIHdoaWNoIEtFSyB0byB1c2UsIHdoaWNoIHdvdWxkIGNvbWUgaW4NCj4+Pj4g aGFuZHkgZm9yIHRoZSB0eXBlcyBvZiBrZXkgcm90YXRpb24gc2NoZW1lcyBJJ20gZmFtaWxpYXIg d2l0aC4gTW9zdGx5LA0KPj4+PiBJJ20gd29ycmllZCBhYm91dCB0aGUgInRyeSBpdCBhbmQgc2Vl IGlmIGl0IHdvcmtzIiBhcHByb2FjaCB3aGVuIHlvdQ0KPj4+PiBoYXZlDQo+Pj4+IHR3byB2YWxp ZCBLRUtzIChhcyBkdXJpbmcgYSB0cmFuc2l0aW9uKSwgYXMgaXQncyBub3QgY2xlYXIgdGhhdCB5 b3UNCj4+Pj4gd2lsbA0KPj4+PiBiZSBhYmxlIHRvIGRpc3Rpbmd1aXNoIHN1Y2Nlc3MgZnJvbSBm YWlsdXJlIGluIGFsbCBjYXNlcy4NCj4+PiBBRVMgaXMgYW4gYWxnb3JpdGhtLiBJIGtub3cgdGhl cmUgYXJlIDEyOCwgMTkyLCBhbmQgMjU2IGJpdCB2YXJpZXRpZXMuDQo+Pj4gRG8NCj4+PiB5b3Ug d2FudCBtZSB0byBzcGVjaWZ5IHRoYW4gYW55IHZhcmlldHkgbWF5IGJlIHVzZWQ/IEkgYWxtb3N0 IHJlbW92ZWQNCj4+PiB0aGlzDQo+Pj4gb3V0LW9mLWJhbmQga2V5IGVuY3J5cHRpb24gb25jZS4N Cj4+IA0KPj4gDQo+PiBUaGlzIGlzbid0IGFib3V0IGNyeXB0by1hZ2lsaXR5OyBpdCdzIGFib3V0 IGtleSByb3RhdGlvbi4gVGhpcyBzZWN0aW9uDQo+PiBwb3NpdHMgYSBzeXN0ZW0gaW4gd2hpY2gg eW91IGhhdmUgc29tZSBLRUssIGRpc3RyaWJ1dGVkIG91dC1vZi1iYW5kLg0KPj4gTGV0J3MgY2Fs bCB0aGUga2V5IHdlJ3JlIHVzaW5nIGF0IHRoaXMgbW9tZW50ICJHZW5lcmF0aW9uIEEuIiBBdCBz b21lDQo+PiBwb2ludCAtLSBsZXQncyBzYXkgbmV4dCB3ZWVrIC0tIHdlIGRlY2lkZSB0aGF0IGl0 J3MgdGltZSB0byBjaGFuZ2UgdGhlDQo+PiBLRUsgdG8gb25lIHdlJ3JlIGdvaW5nIHRvIGNhbGwg IkdlbmVyYXRpb24gQi4iIEZpcnN0LCB3ZSBuZWVkIHRvIGdldCB0aGUNCj4+ICJHZW5lcmF0aW9u IEIiIEtFS3MgdG8gZXZlcnlvbmUgYmVmb3JlIHRoZSBzd2l0Y2gtb3ZlciAodG8gYXZvaWQgYQ0K Pj4gcGVyaW9kIG9mIHRpbWUgZHVyaW5nIHdoaWNoIHRoZXkgY2FuJ3QgZGVjcnlwdCB0aGUgWUFO Ry1zdG9yZWQga2V5cykuDQo+PiBUaGUgaXNzdWUgYmVjb21lczogb25jZSB5b3UgaGF2ZSBib3Ro ICJHZW5lcmF0aW9uIEEiIGFuZCAiR2VuZXJhdGlvbiBCIiwNCj4+IGhvdyBkbyB5b3Uga25vdyB3 aGljaCBvbmUgdG8gdXNlIHRvIGRlY3J5cHQgdGhlIFlBTkcga2V5cz8gSWYgdGhlcmUgd2VyZQ0K Pj4gYSBwbGFjZSB0byBzdG9yZSBhIGtleSBJRCBpbiB0aGUgWUFORyBtb2RlbCwgaXQgY291bGQg aWRlbnRpZnkgd2hpY2ggb2YNCj4+IHRoZSB0d28ga2V5cyB0byB1c2UuIExhY2tpbmcgdGhhdCwg Zm9yIHNvbWUga2luZHMgb2YgZGF0YSwgeW91IGNhbiBkbyBhDQo+PiAidHJ5IGJvdGggYW5kIHNl ZSB3aGljaCB3b3JrcywiIGJ1dCBpdCdzIG5vdCBjbGVhciB0aGF0IGRvaW5nIHNvIGlzDQo+PiBw b3NzaWJsZSBpbiB0aGlzIGNhc2UgKHNpbmNlIHRoZSB0aGluZyB5b3UncmUgZGVjcnlwdGluZyBp cyBhIGtleSwgYW5kDQo+PiB3aWxsIHNpbXBseSBsb29rIGxpa2UgcmFuZG9tIGJpdHMgcmVnYXJk bGVzcyBvZiB3aGljaCBLRUsgeW91IHVzZSBvbiBpdCwNCj4+IHlvdSBjYW4ndCBleGFtaW5lIGl0 cyBzdHJ1Y3R1cmUgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgaXQgaXMgdmFsaWQpLg0KPj4gDQo+PiBU aGlzIGlzbid0IGEgYmxvY2tpbmcgY29tbWVudDsgSSdtIGp1c3Qgd29uZGVyaW5nIHdoZXRoZXIg dGhpcw0KPj4gb3BlcmF0aW9uYWwgYXNwZWN0IG9jY3VycmVkIHRvIHRoZSBXRyB3aGVuIHRoaXMg c2NoZW1lIHdhcyBiZWluZw0KPj4gZGlzY3Vzc2VkLCBhbmQgd2hldGhlciB0aGVyZSdzIHNvbWUg dHJpdmlhbCB3YXkgdG8gcGVyZm9ybSBLRUsgcm90YXRpb24NCj4+IHRoYXQgY291bGQgYmUgZGVz Y3JpYmVkIGluIHRoZSBkb2N1bWVudC4gV2l0aG91dCB0aGUgYWJpbGl0eSB0byByb3RhdGUNCj4+ IHRoZSBLRUssIEknbSBub3Qgc3VyZSB0aGlzIHNjaGVtZSBpcyBhbGwgdGhhdCB1c2VmdWwuDQo+ IA0KPiBJdCBzZWVtcyB0aGF0IHRoaXMgc2hvdWxkIGhhdmUgYmVlbiBjb3ZlcmVkIGluIHNvbWUg b3RoZXIgU2VjdXJpdHkgUkZDLiBJZg0KPiBub3QgUkZDIDU2NDkgKHdoaWNoIHNlZW1zIHRvIGJl IGluZXhwbGljYWJseSBuYXJyb3cgaW4gc2NvcGUpLCB0aGVuIHNvbWUNCj4gb3RoZXIgU2VjdXJp dHkgZG9jdW1lbnQuIElmIHRoZXJlIGlzIGFtIG91dC1vZi1iYW5kIEtFSyBwcm9jZWR1cmUgZm9y DQo+IGVuY3J5cHRpb24gb2Yga2V5IHN0cmluZywgdGhlbiBpdCBzaG91bGQgaGF2ZSBiZWVuIGRv Y3VtZW50ZWQgcHJpb3IgdG8gbXkNCj4gdXNhZ2UuIEnigJltIGNvcHlpbmcgQnJpYW4gV2VpcyAo YSBTZWN1cml0eSBEaXJlY3RvcmF0ZSBtZW1iZXIpIHdobw0KPiBvcmlnaW5hbGx5IHN1Z2dlc3Rl ZCB0aGlzLiBNeSBpbmNsaW5hdGlvbiBpcyB0byByZW1vdmUgYWxsIHRyYWNlcyBvZiBBRUENCj4g S2V5IFdyYXAgKFJGQyA1NjQ5KSBhbmQgcmVseSBvbiBOQ0FDTS4NCj4gDQo+IFRoYW5rcywgDQo+ IEFjZWUgDQo+PiANCj4+IC9hDQo+IA0KDQotLSANCkJyaWFuIFdlaXMNClNlY3VyaXR5LCBDU0cs IENpc2NvIFN5c3RlbXMNClRlbGVwaG9uZTogKzEgNDA4IDUyNiA0Nzk2DQpFbWFpbDogYmV3QGNp c2NvLmNvbQ0KDQo= From nobody Wed Apr 26 08:55:30 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D679213147D; Wed, 26 Apr 2017 08:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeRUzVeO0miZ; Wed, 26 Apr 2017 08:55:20 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D080B131475; Wed, 26 Apr 2017 08:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7764; q=dns/txt; s=iport; t=1493222119; x=1494431719; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ReUC30MQzvaoFUjZYRz2s+YO7Om8h9GT8J58w2OsDxU=; b=PWOuB6snbg88TZEaxwlIa9ybnRMUGTcuJTHX2QAPEbPYy5QC89m4PiYT WbG8RTQQGeOxa/9GjtyYrwTmZ4EI8y6FYV9FBM0hLsFDXNcNmRKhlgTP9 /GVKQfgAN6pR3ShcZjJ0IT/PpEo5ZtMJEDHkFI8gV/wcg+DBK4xyDrMGF I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlAQB+wQBZ/40NJK1RAQYDGQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBg1WBWxIHg2GKFpFKlWuCD4JugzYCGoQMPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUWAQUjEUUQAgEIGAICJgICAjAVEAIEDgMCihuqOIImiyUBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBH4ELikGEMQYBCgEcFwomgj+CXwWJQZQNAZMKkV6UJgEfOH8IZRW?= =?us-ascii?q?FZoFKQzKGR4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208";a="415931363" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Apr 2017 15:55:18 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3QFtIdC016808 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 15:55:18 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 11:55:17 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 26 Apr 2017 11:55:17 -0400 From: "Acee Lindem (acee)" To: "Brian Weis (bew)" CC: Adam Roach , The IESG , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvgrQg2iqyhFsfkS24vnExw0B6KHWqNaAgABJNoD//982gIABPdYA//+/ywA= Date: Wed, 26 Apr 2017 15:55:17 +0000 Message-ID: References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <90C6D5CA6D714245AF67AAB4FFB1C139@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:55:22 -0000 SGkgQnJpYW4sIA0KDQpPbiA0LzI2LzE3LCAxMTo0NSBBTSwgIkJyaWFuIFdlaXMgKGJldykiIDxi ZXdAY2lzY28uY29tPiB3cm90ZToNCg0KPkRpc3RyaWJ1dGluZyBhbmQgbWFpbnRhaW5pbmcga2V5 cyBoYXMgYSBoaWdoZXIgc2VjdXJpdHkgYmFyIHRoYW4gbW9zdA0KPmNvbmZpZ3VyYXRpb24gaXRl bXMsIGJlY2F1c2UgdGhlaXIgbGVha2FnZSBjYW4gdXN1YWxseSBjYXVzZSBtb3JlIGhhcm0uDQo+ Rm9yIGV4YW1wbGUsIGEgbGVha2VkIGtleSBmcm9tIHRoZSByb3V0aW5nIGtleSBjaGFpbiBjb3Vs ZCBhbGxvdyBhbg0KPmF0dGFja2VyIHRvIHN1YnN0aXR1dGUgaXRzIG93biByb3V0aW5nIG1lc3Nh Z2VzIGZvciBhdXRoZW50aWMgb25lcy4NCj4NCj5EaXN0cmlidXRpbmcgcGxhaW4tdGV4dCBrZXlz IHRocm91Z2ggYSBnZW5lcmFsIHB1cnBvc2UgY29uZmlndXJhdGlvbg0KPnByb3RvY29sIGlzIG5v dCBhbHdheXMgY29uc2lkZXJlZCBzYWZlLiBXaGVuIHRoZSBjb25maWd1cmF0aW9uICBwcm90b2Nv bA0KPmlzIHByb3RlY3RlZCAoZS5nLiwgVExTKSwgdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBv ZiBzb21lIHVzZXJzIGFyZQ0KPnNhdGlzZmllZCBiZWNhdXNlIHRoZXkgYXJlIG9ubHkgd29ycmll ZCBhYm91dCBwcm90ZWN0aW5nIHRoZSBrZXlzIG9uIHRoZQ0KPndpcmUuICBCdXQgb3RoZXIgdXNl cnMgd2l0aCBsYXJnZXIgdGhyZWF0IHByb2ZpbGUgKGUuZy4sIGdvdmVybm1lbnQNCj51c2Vycykg b2Z0ZW4gZG8gbm90IGNvbnNpZGVyIHNlbmRpbmcgcGxhaW4tdGV4dCBrZXlzIHRocm91Z2ggYSBw cm90ZWN0ZWQNCj5jb25maWd1cmF0aW9uIHByb3RvY29sIHRvIGJlIHN1ZmZpY2llbnQsIGJlY2F1 c2UgdGhleSBtYXkgbm90IGhhdmUgZW5vdWdoDQo+Y29udHJvbCBvdmVyIHRoZSBjaXBoZXJzIGNo b3NlbiBmb3IgdGhlIFRMUyBzZXNzaW9uLCBvciBwZXJoYXBzIHRoZXkgd2FudA0KPnRvIHByb3Rl Y3QgdGhlIGtleXMgaW4gdGhlIGNvbmZpZ3VyYXRpb24gc3lzdGVtIGJlZm9yZSB0aGV5IGFyZSBk ZWxpdmVyZWQNCj50byB0aGUgVExTIHNlc3Npb24uIEluIHRoZXNlIGNhc2VzIGl04oCZcyB2YWx1 YWJsZSB0byAia2V5IHdyYXDigJ0gKGVuY3J5cHQpDQo+dGhlIGtleXMgaW4gdGhlIHNvZnR3YXJl IHRoYXQgZ2VuZXJhdGVzIHRoZSBrZXlzLCBhbmQgdW53cmFwIHRoZW0gaW4gdGhlDQo+cGllY2Ug b2Ygc29mdHdhcmUgdGhhdCBpcyBhY3R1YWxseSBpbnN0YWxsaW5nIHRoZSBrZXlzLiBUaGF04oCZ cyB0aGUNCj5tb3RpdmF0aW9uIGZvciBpbmNsdWRpbmcgYW4gb3B0aW9uYWwga2V5IHdyYXAgbWV0 aG9kIGluIHRoZSBrZXkgY2hhaW4NCj5ZYW5nIGRhdGEgbW9kZWwuDQo+DQo+WWVzLCB1c2luZyBh IGtleSB3cmFwIG1ldGhvZCBtZWFucyB0aGVyZeKAmXMgYW4gZXh0cmEgY29tcGxpY2F0aW9uIHdp dGgNCj5uZWVkaW5nIHRvIG1haW50YWluIGEga2V5IHdyYXAga2V5LiBVc2VycyB0aGF0IHJlcXVp cmUgdGhlIHVzZSBvZiBhIGtleQ0KPndyYXAgcHJvYmFibHkgZG9u4oCZdCBoYXZlIGEgcHJvYmxl bSB3aXRoIGRpc3RyaWJ1dGluZyBhIGtleSBvdXQgb2YgYmFuZA0KPmZvciB0aGlzLiBEaXN0cmli dXRpbmcgaXQgaW4tYmFuZCB3b3VsZCBsaWtlbHkgbWVhbiBzZW5kaW5nIGl0IHRocm91Z2ggYQ0K PmRpZmZlcmVudCBZYW5nIGRhdGEgbW9kZWwsIHdoaWNoIHdvdWxkIGhhdmUgZXhhY3RseSB0aGUg c2FtZSBwcm9ibGVtIG9mDQo+bmVlZGluZyB0byBiZSBrZXkgd3JhcHBlZCBzbyBJ4oCZbSBub3Qg c3VyZSBpdOKAmXMgdmFsdWFibGUgdG8gZXZlbiBzcGVjaWZ5DQo+YW4gaW4tYmFuZCBtZXRob2Qu IElmIHRoYXTigJlzIGEgaGFyZCByZXF1aXJlbWVudCwgdGhlbiBJIHN1cHBvc2UgdGhlIGtleQ0K PndyYXAgbWV0aG9kIGNhbiBiZSByZW1vdmVkLiBCdXQgdGhlIHJlbW92YWwgb2YgdGhlIGtleSB3 cmFwIG9wdGlvbiAgaXMNCj5saWtlbHkgdG8gcmVzdHJpY3QgdGhlIHVzZXJzIHdobyBjYW4gdXNl IHRoZSBrZXkgY2hhaW4gZGF0YSBtb2RlLg0KDQpTaW5jZSBSRkMgNTY0OSBpcyBzaW1wbHkgdGhl IGFsZ29yaXRobSB3aXRob3V0IG11Y2ggZ3VpZGFuY2Ugb24NCm9wZXJhdGlvbnMsIHRoZSBpbmNs dXNpb24gb2YgdGhpcyBvcHRpb24gaGFzIHJhaXNlZCBtb3JlIHF1ZXN0aW9ucyB0aGFuDQp0aGUg Y29tbWVuc3VyYXRlIGJlbmVmaXQuIEFkZGl0aW9uYWxseSwgdGhlcmUgaXMgbm90aGluZyBwcmVj bHVkaW5nIGEgdXNlcg0KZnJvbSBkZXBsb3lpbmcgS0VLIGZvciB0aGUga2V5cyBpbiB0aGUgWUFO RyBrZXktY2hhaW4gbW9kZWwuDQoNCkZpbmFsbHksIGRvIHlvdSBrbm93IG9mIGFueSBpbXBsZW1l bnRhdGlvbnMgb2YgS0VLPw0KDQpUaGFua3MsDQpBY2VlIA0KPg0KPkhvcGUgdGhhdCBoZWxwcywN Cj5Ccmlhbg0KPg0KPj4gT24gQXByIDI1LCAyMDE3LCBhdCA1OjQ3IFBNLCBBY2VlIExpbmRlbSAo YWNlZSkgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+IA0KPj4gDQo+PiANCj4+IE9uIDQvMjUv MTcsIDY6NDQgUE0sICJBZGFtIFJvYWNoIiA8YWRhbUBub3N0cnVtLmNvbT4gd3JvdGU6DQo+PiAN Cj4+PiBPbiA0LzI1LzE3IDE3OjIyLCBBY2VlIExpbmRlbSAoYWNlZSkgd3JvdGU6DQo+Pj4+IEhp IEFkYW0sDQo+Pj4+IA0KPj4+PiBPbiA0LzI1LzE3LCA1OjI3IFBNLCAiQWRhbSBSb2FjaCIgPGFk YW1Abm9zdHJ1bS5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4+IC0gU2VjdGlvbiA1IGRpc2N1c3Nl cyB0aGUgdXNlIG9mIGEgS0VLLCBkaXN0cmlidXRlZCBvdXQtb2YtYmFuZCwgdG8NCj4+Pj4+IGRl Y3J5cHQgdGhlIGtleXMgc3RvcmVkIGluIHRoaXMgZm9ybWF0LiBUaGVyZSBhcHBlYXJzIHRvIGJl IG5vDQo+Pj4+PiBhZmZvcmRhbmNlDQo+Pj4+PiBmb3IgaW5kaWNhdGluZyB0aGUgaWRlbnRpdHkg b2Ygd2hpY2ggS0VLIHRvIHVzZSwgd2hpY2ggd291bGQgY29tZSBpbg0KPj4+Pj4gaGFuZHkgZm9y IHRoZSB0eXBlcyBvZiBrZXkgcm90YXRpb24gc2NoZW1lcyBJJ20gZmFtaWxpYXIgd2l0aC4NCj4+ Pj4+TW9zdGx5LA0KPj4+Pj4gSSdtIHdvcnJpZWQgYWJvdXQgdGhlICJ0cnkgaXQgYW5kIHNlZSBp ZiBpdCB3b3JrcyIgYXBwcm9hY2ggd2hlbiB5b3UNCj4+Pj4+IGhhdmUNCj4+Pj4+IHR3byB2YWxp ZCBLRUtzIChhcyBkdXJpbmcgYSB0cmFuc2l0aW9uKSwgYXMgaXQncyBub3QgY2xlYXIgdGhhdCB5 b3UNCj4+Pj4+IHdpbGwNCj4+Pj4+IGJlIGFibGUgdG8gZGlzdGluZ3Vpc2ggc3VjY2VzcyBmcm9t IGZhaWx1cmUgaW4gYWxsIGNhc2VzLg0KPj4+PiBBRVMgaXMgYW4gYWxnb3JpdGhtLiBJIGtub3cg dGhlcmUgYXJlIDEyOCwgMTkyLCBhbmQgMjU2IGJpdCB2YXJpZXRpZXMuDQo+Pj4+IERvDQo+Pj4+ IHlvdSB3YW50IG1lIHRvIHNwZWNpZnkgdGhhbiBhbnkgdmFyaWV0eSBtYXkgYmUgdXNlZD8gSSBh bG1vc3QgcmVtb3ZlZA0KPj4+PiB0aGlzDQo+Pj4+IG91dC1vZi1iYW5kIGtleSBlbmNyeXB0aW9u IG9uY2UuDQo+Pj4gDQo+Pj4gDQo+Pj4gVGhpcyBpc24ndCBhYm91dCBjcnlwdG8tYWdpbGl0eTsg aXQncyBhYm91dCBrZXkgcm90YXRpb24uIFRoaXMgc2VjdGlvbg0KPj4+IHBvc2l0cyBhIHN5c3Rl bSBpbiB3aGljaCB5b3UgaGF2ZSBzb21lIEtFSywgZGlzdHJpYnV0ZWQgb3V0LW9mLWJhbmQuDQo+ Pj4gTGV0J3MgY2FsbCB0aGUga2V5IHdlJ3JlIHVzaW5nIGF0IHRoaXMgbW9tZW50ICJHZW5lcmF0 aW9uIEEuIiBBdCBzb21lDQo+Pj4gcG9pbnQgLS0gbGV0J3Mgc2F5IG5leHQgd2VlayAtLSB3ZSBk ZWNpZGUgdGhhdCBpdCdzIHRpbWUgdG8gY2hhbmdlIHRoZQ0KPj4+IEtFSyB0byBvbmUgd2UncmUg Z29pbmcgdG8gY2FsbCAiR2VuZXJhdGlvbiBCLiIgRmlyc3QsIHdlIG5lZWQgdG8gZ2V0DQo+Pj50 aGUNCj4+PiAiR2VuZXJhdGlvbiBCIiBLRUtzIHRvIGV2ZXJ5b25lIGJlZm9yZSB0aGUgc3dpdGNo LW92ZXIgKHRvIGF2b2lkIGENCj4+PiBwZXJpb2Qgb2YgdGltZSBkdXJpbmcgd2hpY2ggdGhleSBj YW4ndCBkZWNyeXB0IHRoZSBZQU5HLXN0b3JlZCBrZXlzKS4NCj4+PiBUaGUgaXNzdWUgYmVjb21l czogb25jZSB5b3UgaGF2ZSBib3RoICJHZW5lcmF0aW9uIEEiIGFuZCAiR2VuZXJhdGlvbg0KPj4+ QiIsDQo+Pj4gaG93IGRvIHlvdSBrbm93IHdoaWNoIG9uZSB0byB1c2UgdG8gZGVjcnlwdCB0aGUg WUFORyBrZXlzPyBJZiB0aGVyZQ0KPj4+d2VyZQ0KPj4+IGEgcGxhY2UgdG8gc3RvcmUgYSBrZXkg SUQgaW4gdGhlIFlBTkcgbW9kZWwsIGl0IGNvdWxkIGlkZW50aWZ5IHdoaWNoIG9mDQo+Pj4gdGhl IHR3byBrZXlzIHRvIHVzZS4gTGFja2luZyB0aGF0LCBmb3Igc29tZSBraW5kcyBvZiBkYXRhLCB5 b3UgY2FuIGRvIGENCj4+PiAidHJ5IGJvdGggYW5kIHNlZSB3aGljaCB3b3JrcywiIGJ1dCBpdCdz IG5vdCBjbGVhciB0aGF0IGRvaW5nIHNvIGlzDQo+Pj4gcG9zc2libGUgaW4gdGhpcyBjYXNlIChz aW5jZSB0aGUgdGhpbmcgeW91J3JlIGRlY3J5cHRpbmcgaXMgYSBrZXksIGFuZA0KPj4+IHdpbGwg c2ltcGx5IGxvb2sgbGlrZSByYW5kb20gYml0cyByZWdhcmRsZXNzIG9mIHdoaWNoIEtFSyB5b3Ug dXNlIG9uDQo+Pj5pdCwNCj4+PiB5b3UgY2FuJ3QgZXhhbWluZSBpdHMgc3RydWN0dXJlIHRvIGRl dGVybWluZSB3aGV0aGVyIGl0IGlzIHZhbGlkKS4NCj4+PiANCj4+PiBUaGlzIGlzbid0IGEgYmxv Y2tpbmcgY29tbWVudDsgSSdtIGp1c3Qgd29uZGVyaW5nIHdoZXRoZXIgdGhpcw0KPj4+IG9wZXJh dGlvbmFsIGFzcGVjdCBvY2N1cnJlZCB0byB0aGUgV0cgd2hlbiB0aGlzIHNjaGVtZSB3YXMgYmVp bmcNCj4+PiBkaXNjdXNzZWQsIGFuZCB3aGV0aGVyIHRoZXJlJ3Mgc29tZSB0cml2aWFsIHdheSB0 byBwZXJmb3JtIEtFSyByb3RhdGlvbg0KPj4+IHRoYXQgY291bGQgYmUgZGVzY3JpYmVkIGluIHRo ZSBkb2N1bWVudC4gV2l0aG91dCB0aGUgYWJpbGl0eSB0byByb3RhdGUNCj4+PiB0aGUgS0VLLCBJ J20gbm90IHN1cmUgdGhpcyBzY2hlbWUgaXMgYWxsIHRoYXQgdXNlZnVsLg0KPj4gDQo+PiBJdCBz ZWVtcyB0aGF0IHRoaXMgc2hvdWxkIGhhdmUgYmVlbiBjb3ZlcmVkIGluIHNvbWUgb3RoZXIgU2Vj dXJpdHkgUkZDLg0KPj5JZg0KPj4gbm90IFJGQyA1NjQ5ICh3aGljaCBzZWVtcyB0byBiZSBpbmV4 cGxpY2FibHkgbmFycm93IGluIHNjb3BlKSwgdGhlbiBzb21lDQo+PiBvdGhlciBTZWN1cml0eSBk b2N1bWVudC4gSWYgdGhlcmUgaXMgYW0gb3V0LW9mLWJhbmQgS0VLIHByb2NlZHVyZSBmb3INCj4+ IGVuY3J5cHRpb24gb2Yga2V5IHN0cmluZywgdGhlbiBpdCBzaG91bGQgaGF2ZSBiZWVuIGRvY3Vt ZW50ZWQgcHJpb3IgdG8NCj4+bXkNCj4+IHVzYWdlLiBJ4oCZbSBjb3B5aW5nIEJyaWFuIFdlaXMg KGEgU2VjdXJpdHkgRGlyZWN0b3JhdGUgbWVtYmVyKSB3aG8NCj4+IG9yaWdpbmFsbHkgc3VnZ2Vz dGVkIHRoaXMuIE15IGluY2xpbmF0aW9uIGlzIHRvIHJlbW92ZSBhbGwgdHJhY2VzIG9mIEFFQQ0K Pj4gS2V5IFdyYXAgKFJGQyA1NjQ5KSBhbmQgcmVseSBvbiBOQ0FDTS4NCj4+IA0KPj4gVGhhbmtz LCANCj4+IEFjZWUgDQo+Pj4gDQo+Pj4gL2ENCj4+IA0KPg0KPi0tIA0KPkJyaWFuIFdlaXMNCj5T ZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zDQo+VGVsZXBob25lOiArMSA0MDggNTI2IDQ3OTYN Cj5FbWFpbDogYmV3QGNpc2NvLmNvbQ0KPg0KDQo= From nobody Wed Apr 26 09:05:06 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A0613147D; Wed, 26 Apr 2017 09:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD1RkEhkRW1L; Wed, 26 Apr 2017 09:05:02 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6E3131450; Wed, 26 Apr 2017 09:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33280; q=dns/txt; s=iport; t=1493222702; x=1494432302; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6kORH0UzQWuPT22WIkGR0VNOKISTNnh8bajyt2EHVeg=; b=Xyqcf/hCVoim/9agp2yoQ+hlmPnkKOMIMa+Pp3oAevTaeaRN1iD6de4h XOvSpM1ByGOwzcJY29ueoLEPPT4WC8J8I3r45ooPiyCEna2/KSnvfJRyR XjEwUAhSPHIeWK7QMtmaLw1Sg41fY59b/yytzr6XCJtqribBfDidFLGcF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlAQC/xABZ/40NJK1RAQYDGQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgm5ngVsSB4NhihanNYIPgm6DNgIahA8/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRYGI1YQAgEIOAcDAgICMBQRAgQOAwKKG6pFgiaLJAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2IXYJvhDEGAQoBMwomgj8ugjEFiUGUDQGTCpFelCYBHzh/CGUVVgG?= =?us-ascii?q?FD4FKQzKGR4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208,217";a="417426207" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Apr 2017 16:05:00 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3QG50JI029995 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 16:05:00 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 12:04:59 -0400 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.1210.000; Wed, 26 Apr 2017 12:04:59 -0400 From: "Brian Weis (bew)" To: "Acee Lindem (acee)" CC: Adam Roach , The IESG , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvgrQg2iqyhFsfkS24vnExw0B6KHWqNaAgABJNoD//982gIABPdYA//+/ywCAAEXJAA== Date: Wed, 26 Apr 2017 16:04:59 +0000 Message-ID: <45A012DC-092D-42C9-80B3-488E9044F13D@cisco.com> References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.174] Content-Type: multipart/alternative; boundary="_000_45A012DC092D42C980B3488E9044F13Dciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:05:05 -0000 --_000_45A012DC092D42C980B3488E9044F13Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWNlZSwNCg0KT24gQXByIDI2LCAyMDE3LCBhdCA4OjU1IEFNLCBBY2VlIExpbmRlbSAoYWNl ZSkgPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSBC cmlhbiwNCg0KT24gNC8yNi8xNywgMTE6NDUgQU0sICJCcmlhbiBXZWlzIChiZXcpIiA8YmV3QGNp c2NvLmNvbTxtYWlsdG86YmV3QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpEaXN0cmlidXRpbmcgYW5k IG1haW50YWluaW5nIGtleXMgaGFzIGEgaGlnaGVyIHNlY3VyaXR5IGJhciB0aGFuIG1vc3QNCmNv bmZpZ3VyYXRpb24gaXRlbXMsIGJlY2F1c2UgdGhlaXIgbGVha2FnZSBjYW4gdXN1YWxseSBjYXVz ZSBtb3JlIGhhcm0uDQpGb3IgZXhhbXBsZSwgYSBsZWFrZWQga2V5IGZyb20gdGhlIHJvdXRpbmcg a2V5IGNoYWluIGNvdWxkIGFsbG93IGFuDQphdHRhY2tlciB0byBzdWJzdGl0dXRlIGl0cyBvd24g cm91dGluZyBtZXNzYWdlcyBmb3IgYXV0aGVudGljIG9uZXMuDQoNCkRpc3RyaWJ1dGluZyBwbGFp bi10ZXh0IGtleXMgdGhyb3VnaCBhIGdlbmVyYWwgcHVycG9zZSBjb25maWd1cmF0aW9uDQpwcm90 b2NvbCBpcyBub3QgYWx3YXlzIGNvbnNpZGVyZWQgc2FmZS4gV2hlbiB0aGUgY29uZmlndXJhdGlv biAgcHJvdG9jb2wNCmlzIHByb3RlY3RlZCAoZS5nLiwgVExTKSwgdGhlIHNlY3VyaXR5IHJlcXVp cmVtZW50cyBvZiBzb21lIHVzZXJzIGFyZQ0Kc2F0aXNmaWVkIGJlY2F1c2UgdGhleSBhcmUgb25s eSB3b3JyaWVkIGFib3V0IHByb3RlY3RpbmcgdGhlIGtleXMgb24gdGhlDQp3aXJlLiAgQnV0IG90 aGVyIHVzZXJzIHdpdGggbGFyZ2VyIHRocmVhdCBwcm9maWxlIChlLmcuLCBnb3Zlcm5tZW50DQp1 c2Vycykgb2Z0ZW4gZG8gbm90IGNvbnNpZGVyIHNlbmRpbmcgcGxhaW4tdGV4dCBrZXlzIHRocm91 Z2ggYSBwcm90ZWN0ZWQNCmNvbmZpZ3VyYXRpb24gcHJvdG9jb2wgdG8gYmUgc3VmZmljaWVudCwg YmVjYXVzZSB0aGV5IG1heSBub3QgaGF2ZSBlbm91Z2gNCmNvbnRyb2wgb3ZlciB0aGUgY2lwaGVy cyBjaG9zZW4gZm9yIHRoZSBUTFMgc2Vzc2lvbiwgb3IgcGVyaGFwcyB0aGV5IHdhbnQNCnRvIHBy b3RlY3QgdGhlIGtleXMgaW4gdGhlIGNvbmZpZ3VyYXRpb24gc3lzdGVtIGJlZm9yZSB0aGV5IGFy ZSBkZWxpdmVyZWQNCnRvIHRoZSBUTFMgc2Vzc2lvbi4gSW4gdGhlc2UgY2FzZXMgaXTigJlzIHZh bHVhYmxlIHRvICJrZXkgd3JhcOKAnSAoZW5jcnlwdCkNCnRoZSBrZXlzIGluIHRoZSBzb2Z0d2Fy ZSB0aGF0IGdlbmVyYXRlcyB0aGUga2V5cywgYW5kIHVud3JhcCB0aGVtIGluIHRoZQ0KcGllY2Ug b2Ygc29mdHdhcmUgdGhhdCBpcyBhY3R1YWxseSBpbnN0YWxsaW5nIHRoZSBrZXlzLiBUaGF04oCZ cyB0aGUNCm1vdGl2YXRpb24gZm9yIGluY2x1ZGluZyBhbiBvcHRpb25hbCBrZXkgd3JhcCBtZXRo b2QgaW4gdGhlIGtleSBjaGFpbg0KWWFuZyBkYXRhIG1vZGVsLg0KDQpZZXMsIHVzaW5nIGEga2V5 IHdyYXAgbWV0aG9kIG1lYW5zIHRoZXJl4oCZcyBhbiBleHRyYSBjb21wbGljYXRpb24gd2l0aA0K bmVlZGluZyB0byBtYWludGFpbiBhIGtleSB3cmFwIGtleS4gVXNlcnMgdGhhdCByZXF1aXJlIHRo ZSB1c2Ugb2YgYSBrZXkNCndyYXAgcHJvYmFibHkgZG9u4oCZdCBoYXZlIGEgcHJvYmxlbSB3aXRo IGRpc3RyaWJ1dGluZyBhIGtleSBvdXQgb2YgYmFuZA0KZm9yIHRoaXMuIERpc3RyaWJ1dGluZyBp dCBpbi1iYW5kIHdvdWxkIGxpa2VseSBtZWFuIHNlbmRpbmcgaXQgdGhyb3VnaCBhDQpkaWZmZXJl bnQgWWFuZyBkYXRhIG1vZGVsLCB3aGljaCB3b3VsZCBoYXZlIGV4YWN0bHkgdGhlIHNhbWUgcHJv YmxlbSBvZg0KbmVlZGluZyB0byBiZSBrZXkgd3JhcHBlZCBzbyBJ4oCZbSBub3Qgc3VyZSBpdOKA mXMgdmFsdWFibGUgdG8gZXZlbiBzcGVjaWZ5DQphbiBpbi1iYW5kIG1ldGhvZC4gSWYgdGhhdOKA mXMgYSBoYXJkIHJlcXVpcmVtZW50LCB0aGVuIEkgc3VwcG9zZSB0aGUga2V5DQp3cmFwIG1ldGhv ZCBjYW4gYmUgcmVtb3ZlZC4gQnV0IHRoZSByZW1vdmFsIG9mIHRoZSBrZXkgd3JhcCBvcHRpb24g IGlzDQpsaWtlbHkgdG8gcmVzdHJpY3QgdGhlIHVzZXJzIHdobyBjYW4gdXNlIHRoZSBrZXkgY2hh aW4gZGF0YSBtb2RlLg0KDQpTaW5jZSBSRkMgNTY0OSBpcyBzaW1wbHkgdGhlIGFsZ29yaXRobSB3 aXRob3V0IG11Y2ggZ3VpZGFuY2Ugb24NCm9wZXJhdGlvbnMsIHRoZSBpbmNsdXNpb24gb2YgdGhp cyBvcHRpb24gaGFzIHJhaXNlZCBtb3JlIHF1ZXN0aW9ucyB0aGFuDQp0aGUgY29tbWVuc3VyYXRl IGJlbmVmaXQuIEFkZGl0aW9uYWxseSwgdGhlcmUgaXMgbm90aGluZyBwcmVjbHVkaW5nIGEgdXNl cg0KZnJvbSBkZXBsb3lpbmcgS0VLIGZvciB0aGUga2V5cyBpbiB0aGUgWUFORyBrZXktY2hhaW4g bW9kZWwuDQoNCklmIHlvdSB0b29rIG91dCB0aGUga2V5IHdyYXAgbWV0aG9kLCB0aGVuIHN0YXRp bmcgaG93IGEgdXNlciBtaWdodCBkbyB0aGUga2V5IHdyYXBwaW5nIHRoZW1zZWx2ZXMgc2hvdWxk IGJlIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQuIEkgZ3Vlc3MgdGhhdCBtYWtlcyB0aGVtIHJlc3Bv bnNpYmxlIGZvciBwcmUtIGFuZCBwb3N0LSBwcm9jZXNzaW5nIG9mIHRoZSBrZXlzIGluIGFuIGlt cGxlbWVudGF0aW9uLXNwZWNpZmljIG1hbm5lci4uDQoNCkZpbmFsbHksIGRvIHlvdSBrbm93IG9m IGFueSBpbXBsZW1lbnRhdGlvbnMgb2YgS0VLPw0KDQpOb3Qgd2l0aCB0aGlzIGRhdGEgbW9kZWws IGJlY2F1c2UgSeKAmW0gbm90IGludm9sdmVkIHdpdGggaW1wbGVtZW50YXRpb25zIG9mIHRoZSBk YXRhIG1vZGVsLiBUaGUgdXNlIG9mIGEga2V5IHdyYXAgYW5kIEtFSyBpcyB1c2VkIGluIG90aGVy IGNhc2VzLg0KDQpCcmlhbg0KDQoNClRoYW5rcywNCkFjZWUNCg0KSG9wZSB0aGF0IGhlbHBzLA0K QnJpYW4NCg0KT24gQXByIDI1LCAyMDE3LCBhdCA1OjQ3IFBNLCBBY2VlIExpbmRlbSAoYWNlZSkg PGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCg0KT24g NC8yNS8xNywgNjo0NCBQTSwgIkFkYW0gUm9hY2giIDxhZGFtQG5vc3RydW0uY29tPG1haWx0bzph ZGFtQG5vc3RydW0uY29tPj4gd3JvdGU6DQoNCk9uIDQvMjUvMTcgMTc6MjIsIEFjZWUgTGluZGVt IChhY2VlKSB3cm90ZToNCkhpIEFkYW0sDQoNCk9uIDQvMjUvMTcsIDU6MjcgUE0sICJBZGFtIFJv YWNoIiA8YWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+IHdyb3RlOg0K DQotIFNlY3Rpb24gNSBkaXNjdXNzZXMgdGhlIHVzZSBvZiBhIEtFSywgZGlzdHJpYnV0ZWQgb3V0 LW9mLWJhbmQsIHRvDQpkZWNyeXB0IHRoZSBrZXlzIHN0b3JlZCBpbiB0aGlzIGZvcm1hdC4gVGhl cmUgYXBwZWFycyB0byBiZSBubw0KYWZmb3JkYW5jZQ0KZm9yIGluZGljYXRpbmcgdGhlIGlkZW50 aXR5IG9mIHdoaWNoIEtFSyB0byB1c2UsIHdoaWNoIHdvdWxkIGNvbWUgaW4NCmhhbmR5IGZvciB0 aGUgdHlwZXMgb2Yga2V5IHJvdGF0aW9uIHNjaGVtZXMgSSdtIGZhbWlsaWFyIHdpdGguDQpNb3N0 bHksDQpJJ20gd29ycmllZCBhYm91dCB0aGUgInRyeSBpdCBhbmQgc2VlIGlmIGl0IHdvcmtzIiBh cHByb2FjaCB3aGVuIHlvdQ0KaGF2ZQ0KdHdvIHZhbGlkIEtFS3MgKGFzIGR1cmluZyBhIHRyYW5z aXRpb24pLCBhcyBpdCdzIG5vdCBjbGVhciB0aGF0IHlvdQ0Kd2lsbA0KYmUgYWJsZSB0byBkaXN0 aW5ndWlzaCBzdWNjZXNzIGZyb20gZmFpbHVyZSBpbiBhbGwgY2FzZXMuDQpBRVMgaXMgYW4gYWxn b3JpdGhtLiBJIGtub3cgdGhlcmUgYXJlIDEyOCwgMTkyLCBhbmQgMjU2IGJpdCB2YXJpZXRpZXMu DQpEbw0KeW91IHdhbnQgbWUgdG8gc3BlY2lmeSB0aGFuIGFueSB2YXJpZXR5IG1heSBiZSB1c2Vk PyBJIGFsbW9zdCByZW1vdmVkDQp0aGlzDQpvdXQtb2YtYmFuZCBrZXkgZW5jcnlwdGlvbiBvbmNl Lg0KDQoNClRoaXMgaXNuJ3QgYWJvdXQgY3J5cHRvLWFnaWxpdHk7IGl0J3MgYWJvdXQga2V5IHJv dGF0aW9uLiBUaGlzIHNlY3Rpb24NCnBvc2l0cyBhIHN5c3RlbSBpbiB3aGljaCB5b3UgaGF2ZSBz b21lIEtFSywgZGlzdHJpYnV0ZWQgb3V0LW9mLWJhbmQuDQpMZXQncyBjYWxsIHRoZSBrZXkgd2Un cmUgdXNpbmcgYXQgdGhpcyBtb21lbnQgIkdlbmVyYXRpb24gQS4iIEF0IHNvbWUNCnBvaW50IC0t IGxldCdzIHNheSBuZXh0IHdlZWsgLS0gd2UgZGVjaWRlIHRoYXQgaXQncyB0aW1lIHRvIGNoYW5n ZSB0aGUNCktFSyB0byBvbmUgd2UncmUgZ29pbmcgdG8gY2FsbCAiR2VuZXJhdGlvbiBCLiIgRmly c3QsIHdlIG5lZWQgdG8gZ2V0DQp0aGUNCiJHZW5lcmF0aW9uIEIiIEtFS3MgdG8gZXZlcnlvbmUg YmVmb3JlIHRoZSBzd2l0Y2gtb3ZlciAodG8gYXZvaWQgYQ0KcGVyaW9kIG9mIHRpbWUgZHVyaW5n IHdoaWNoIHRoZXkgY2FuJ3QgZGVjcnlwdCB0aGUgWUFORy1zdG9yZWQga2V5cykuDQpUaGUgaXNz dWUgYmVjb21lczogb25jZSB5b3UgaGF2ZSBib3RoICJHZW5lcmF0aW9uIEEiIGFuZCAiR2VuZXJh dGlvbg0KQiIsDQpob3cgZG8geW91IGtub3cgd2hpY2ggb25lIHRvIHVzZSB0byBkZWNyeXB0IHRo ZSBZQU5HIGtleXM/IElmIHRoZXJlDQp3ZXJlDQphIHBsYWNlIHRvIHN0b3JlIGEga2V5IElEIGlu IHRoZSBZQU5HIG1vZGVsLCBpdCBjb3VsZCBpZGVudGlmeSB3aGljaCBvZg0KdGhlIHR3byBrZXlz IHRvIHVzZS4gTGFja2luZyB0aGF0LCBmb3Igc29tZSBraW5kcyBvZiBkYXRhLCB5b3UgY2FuIGRv IGENCiJ0cnkgYm90aCBhbmQgc2VlIHdoaWNoIHdvcmtzLCIgYnV0IGl0J3Mgbm90IGNsZWFyIHRo YXQgZG9pbmcgc28gaXMNCnBvc3NpYmxlIGluIHRoaXMgY2FzZSAoc2luY2UgdGhlIHRoaW5nIHlv dSdyZSBkZWNyeXB0aW5nIGlzIGEga2V5LCBhbmQNCndpbGwgc2ltcGx5IGxvb2sgbGlrZSByYW5k b20gYml0cyByZWdhcmRsZXNzIG9mIHdoaWNoIEtFSyB5b3UgdXNlIG9uDQppdCwNCnlvdSBjYW4n dCBleGFtaW5lIGl0cyBzdHJ1Y3R1cmUgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgaXQgaXMgdmFsaWQp Lg0KDQpUaGlzIGlzbid0IGEgYmxvY2tpbmcgY29tbWVudDsgSSdtIGp1c3Qgd29uZGVyaW5nIHdo ZXRoZXIgdGhpcw0Kb3BlcmF0aW9uYWwgYXNwZWN0IG9jY3VycmVkIHRvIHRoZSBXRyB3aGVuIHRo aXMgc2NoZW1lIHdhcyBiZWluZw0KZGlzY3Vzc2VkLCBhbmQgd2hldGhlciB0aGVyZSdzIHNvbWUg dHJpdmlhbCB3YXkgdG8gcGVyZm9ybSBLRUsgcm90YXRpb24NCnRoYXQgY291bGQgYmUgZGVzY3Jp YmVkIGluIHRoZSBkb2N1bWVudC4gV2l0aG91dCB0aGUgYWJpbGl0eSB0byByb3RhdGUNCnRoZSBL RUssIEknbSBub3Qgc3VyZSB0aGlzIHNjaGVtZSBpcyBhbGwgdGhhdCB1c2VmdWwuDQoNCkl0IHNl ZW1zIHRoYXQgdGhpcyBzaG91bGQgaGF2ZSBiZWVuIGNvdmVyZWQgaW4gc29tZSBvdGhlciBTZWN1 cml0eSBSRkMuDQpJZg0Kbm90IFJGQyA1NjQ5ICh3aGljaCBzZWVtcyB0byBiZSBpbmV4cGxpY2Fi bHkgbmFycm93IGluIHNjb3BlKSwgdGhlbiBzb21lDQpvdGhlciBTZWN1cml0eSBkb2N1bWVudC4g SWYgdGhlcmUgaXMgYW0gb3V0LW9mLWJhbmQgS0VLIHByb2NlZHVyZSBmb3INCmVuY3J5cHRpb24g b2Yga2V5IHN0cmluZywgdGhlbiBpdCBzaG91bGQgaGF2ZSBiZWVuIGRvY3VtZW50ZWQgcHJpb3Ig dG8NCm15DQp1c2FnZS4gSeKAmW0gY29weWluZyBCcmlhbiBXZWlzIChhIFNlY3VyaXR5IERpcmVj dG9yYXRlIG1lbWJlcikgd2hvDQpvcmlnaW5hbGx5IHN1Z2dlc3RlZCB0aGlzLiBNeSBpbmNsaW5h dGlvbiBpcyB0byByZW1vdmUgYWxsIHRyYWNlcyBvZiBBRUENCktleSBXcmFwIChSRkMgNTY0OSkg YW5kIHJlbHkgb24gTkNBQ00uDQoNClRoYW5rcywNCkFjZWUNCg0KL2ENCg0KDQotLQ0KQnJpYW4g V2Vpcw0KU2VjdXJpdHksIENTRywgQ2lzY28gU3lzdGVtcw0KVGVsZXBob25lOiArMSA0MDggNTI2 IDQ3OTYNCkVtYWlsOiBiZXdAY2lzY28uY29tPG1haWx0bzpiZXdAY2lzY28uY29tPg0KDQotLQ0K QnJpYW4gV2Vpcw0KU2VjdXJpdHksIENTRywgQ2lzY28gU3lzdGVtcw0KVGVsZXBob25lOiArMSA0 MDggNTI2IDQ3OTYNCkVtYWlsOiBiZXdAY2lzY28uY29tPG1haWx0bzpiZXdAY2lzY28uY29tPg0K DQo= --_000_45A012DC092D42C980B3488E9044F13Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <256A14BEEDC5FD45A88978D96B574394@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgQWNlZSwNCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgMjYsIDIwMTcsIGF0IDg6NTUgQU0sIEFjZWUgTGluZGVt IChhY2VlKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIiBjbGFzcz0iIj5hY2Vl QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNo YW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SGkNCiBCcmlhbiw8 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxi ciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyIgY2xhc3M9IiI+T24NCiA0LzI2LzE3LCAxMTo0NSBBTSwgJnF1b3Q7QnJpYW4gV2Vp cyAoYmV3KSZxdW90OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpiZXdAY2lzY28uY29tIiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5i ZXdAY2lzY28uY29tPC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5 OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPiZndDsNCiB3cm90ZTo8L3NwYW4+PGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCkRpc3RyaWJ1dGluZyBhbmQgbWFpbnRhaW5pbmcga2V5 cyBoYXMgYSBoaWdoZXIgc2VjdXJpdHkgYmFyIHRoYW4gbW9zdDxiciBjbGFzcz0iIj4NCmNvbmZp Z3VyYXRpb24gaXRlbXMsIGJlY2F1c2UgdGhlaXIgbGVha2FnZSBjYW4gdXN1YWxseSBjYXVzZSBt b3JlIGhhcm0uPGJyIGNsYXNzPSIiPg0KRm9yIGV4YW1wbGUsIGEgbGVha2VkIGtleSBmcm9tIHRo ZSByb3V0aW5nIGtleSBjaGFpbiBjb3VsZCBhbGxvdyBhbjxiciBjbGFzcz0iIj4NCmF0dGFja2Vy IHRvIHN1YnN0aXR1dGUgaXRzIG93biByb3V0aW5nIG1lc3NhZ2VzIGZvciBhdXRoZW50aWMgb25l cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpEaXN0cmlidXRpbmcgcGxhaW4tdGV4dCBr ZXlzIHRocm91Z2ggYSBnZW5lcmFsIHB1cnBvc2UgY29uZmlndXJhdGlvbjxiciBjbGFzcz0iIj4N CnByb3RvY29sIGlzIG5vdCBhbHdheXMgY29uc2lkZXJlZCBzYWZlLiBXaGVuIHRoZSBjb25maWd1 cmF0aW9uICZuYnNwO3Byb3RvY29sPGJyIGNsYXNzPSIiPg0KaXMgcHJvdGVjdGVkIChlLmcuLCBU TFMpLCB0aGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIG9mIHNvbWUgdXNlcnMgYXJlPGJyIGNsYXNz PSIiPg0Kc2F0aXNmaWVkIGJlY2F1c2UgdGhleSBhcmUgb25seSB3b3JyaWVkIGFib3V0IHByb3Rl Y3RpbmcgdGhlIGtleXMgb24gdGhlPGJyIGNsYXNzPSIiPg0Kd2lyZS4gJm5ic3A7QnV0IG90aGVy IHVzZXJzIHdpdGggbGFyZ2VyIHRocmVhdCBwcm9maWxlIChlLmcuLCBnb3Zlcm5tZW50PGJyIGNs YXNzPSIiPg0KdXNlcnMpIG9mdGVuIGRvIG5vdCBjb25zaWRlciBzZW5kaW5nIHBsYWluLXRleHQg a2V5cyB0aHJvdWdoIGEgcHJvdGVjdGVkPGJyIGNsYXNzPSIiPg0KY29uZmlndXJhdGlvbiBwcm90 b2NvbCB0byBiZSBzdWZmaWNpZW50LCBiZWNhdXNlIHRoZXkgbWF5IG5vdCBoYXZlIGVub3VnaDxi ciBjbGFzcz0iIj4NCmNvbnRyb2wgb3ZlciB0aGUgY2lwaGVycyBjaG9zZW4gZm9yIHRoZSBUTFMg c2Vzc2lvbiwgb3IgcGVyaGFwcyB0aGV5IHdhbnQ8YnIgY2xhc3M9IiI+DQp0byBwcm90ZWN0IHRo ZSBrZXlzIGluIHRoZSBjb25maWd1cmF0aW9uIHN5c3RlbSBiZWZvcmUgdGhleSBhcmUgZGVsaXZl cmVkPGJyIGNsYXNzPSIiPg0KdG8gdGhlIFRMUyBzZXNzaW9uLiBJbiB0aGVzZSBjYXNlcyBpdOKA mXMgdmFsdWFibGUgdG8gJnF1b3Q7a2V5IHdyYXDigJ0gKGVuY3J5cHQpPGJyIGNsYXNzPSIiPg0K dGhlIGtleXMgaW4gdGhlIHNvZnR3YXJlIHRoYXQgZ2VuZXJhdGVzIHRoZSBrZXlzLCBhbmQgdW53 cmFwIHRoZW0gaW4gdGhlPGJyIGNsYXNzPSIiPg0KcGllY2Ugb2Ygc29mdHdhcmUgdGhhdCBpcyBh Y3R1YWxseSBpbnN0YWxsaW5nIHRoZSBrZXlzLiBUaGF04oCZcyB0aGU8YnIgY2xhc3M9IiI+DQpt b3RpdmF0aW9uIGZvciBpbmNsdWRpbmcgYW4gb3B0aW9uYWwga2V5IHdyYXAgbWV0aG9kIGluIHRo ZSBrZXkgY2hhaW48YnIgY2xhc3M9IiI+DQpZYW5nIGRhdGEgbW9kZWwuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KWWVzLCB1c2luZyBhIGtleSB3cmFwIG1ldGhvZCBtZWFucyB0aGVyZeKA mXMgYW4gZXh0cmEgY29tcGxpY2F0aW9uIHdpdGg8YnIgY2xhc3M9IiI+DQpuZWVkaW5nIHRvIG1h aW50YWluIGEga2V5IHdyYXAga2V5LiBVc2VycyB0aGF0IHJlcXVpcmUgdGhlIHVzZSBvZiBhIGtl eTxiciBjbGFzcz0iIj4NCndyYXAgcHJvYmFibHkgZG9u4oCZdCBoYXZlIGEgcHJvYmxlbSB3aXRo IGRpc3RyaWJ1dGluZyBhIGtleSBvdXQgb2YgYmFuZDxiciBjbGFzcz0iIj4NCmZvciB0aGlzLiBE aXN0cmlidXRpbmcgaXQgaW4tYmFuZCB3b3VsZCBsaWtlbHkgbWVhbiBzZW5kaW5nIGl0IHRocm91 Z2ggYTxiciBjbGFzcz0iIj4NCmRpZmZlcmVudCBZYW5nIGRhdGEgbW9kZWwsIHdoaWNoIHdvdWxk IGhhdmUgZXhhY3RseSB0aGUgc2FtZSBwcm9ibGVtIG9mPGJyIGNsYXNzPSIiPg0KbmVlZGluZyB0 byBiZSBrZXkgd3JhcHBlZCBzbyBJ4oCZbSBub3Qgc3VyZSBpdOKAmXMgdmFsdWFibGUgdG8gZXZl biBzcGVjaWZ5PGJyIGNsYXNzPSIiPg0KYW4gaW4tYmFuZCBtZXRob2QuIElmIHRoYXTigJlzIGEg aGFyZCByZXF1aXJlbWVudCwgdGhlbiBJIHN1cHBvc2UgdGhlIGtleTxiciBjbGFzcz0iIj4NCndy YXAgbWV0aG9kIGNhbiBiZSByZW1vdmVkLiBCdXQgdGhlIHJlbW92YWwgb2YgdGhlIGtleSB3cmFw IG9wdGlvbiAmbmJzcDtpczxiciBjbGFzcz0iIj4NCmxpa2VseSB0byByZXN0cmljdCB0aGUgdXNl cnMgd2hvIGNhbiB1c2UgdGhlIGtleSBjaGFpbiBkYXRhIG1vZGUuPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi PlNpbmNlDQogUkZDIDU2NDkgaXMgc2ltcGx5IHRoZSBhbGdvcml0aG0gd2l0aG91dCBtdWNoIGd1 aWRhbmNlIG9uPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFz cz0iIj5vcGVyYXRpb25zLA0KIHRoZSBpbmNsdXNpb24gb2YgdGhpcyBvcHRpb24gaGFzIHJhaXNl ZCBtb3JlIHF1ZXN0aW9ucyB0aGFuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBv cnRhbnQ7IiBjbGFzcz0iIj50aGUNCiBjb21tZW5zdXJhdGUgYmVuZWZpdC4gQWRkaXRpb25hbGx5 LCB0aGVyZSBpcyBub3RoaW5nIHByZWNsdWRpbmcgYSB1c2VyPC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxh eTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5mcm9tDQogZGVwbG95aW5nIEtFSyBmb3Ig dGhlIGtleXMgaW4gdGhlIFlBTkcga2V5LWNoYWluIG1vZGVsLjwvc3Bhbj48YnIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KSWYgeW91IHRvb2sgb3V0IHRoZSBrZXkgd3JhcCBtZXRob2QsIHRoZW4gc3Rh dGluZyBob3cgYSB1c2VyIG1pZ2h0IGRvIHRoZSBrZXkgd3JhcHBpbmcgdGhlbXNlbHZlcyBzaG91 bGQgYmUgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4gSSBndWVzcyB0aGF0IG1ha2VzIHRoZW0gcmVz cG9uc2libGUgZm9yIHByZS0gYW5kIHBvc3QtIHByb2Nlc3Npbmcgb2YgdGhlIGtleXMgaW4gYW4g aW1wbGVtZW50YXRpb24tc3BlY2lmaWMgbWFubmVyLi48L2Rpdj4NCjxkaXY+Jm5ic3A7PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y dGFudDsiIGNsYXNzPSIiPkZpbmFsbHksDQogZG8geW91IGtub3cgb2YgYW55IGltcGxlbWVudGF0 aW9ucyBvZiBLRUs/PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpOb3Qgd2l0aCB0aGlz IGRhdGEgbW9kZWwsIGJlY2F1c2UgSeKAmW0gbm90IGludm9sdmVkIHdpdGggaW1wbGVtZW50YXRp b25zIG9mIHRoZSBkYXRhIG1vZGVsLiBUaGUgdXNlIG9mIGEga2V5IHdyYXAgYW5kIEtFSyBpcyB1 c2VkIGluIG90aGVyIGNhc2VzLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXY+QnJpYW48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGFua3MsPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s aW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5BY2VlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIb3BlIHRoYXQgaGVs cHMsPGJyIGNsYXNzPSIiPg0KQnJpYW48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiBBcHIgMjUsIDIwMTcsIGF0IDU6NDcgUE0s IEFjZWUgTGluZGVtIChhY2VlKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIiBj bGFzcz0iIj5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDQvMjUvMTcsIDY6NDQg UE0sICZxdW90O0FkYW0gUm9hY2gmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3Ry dW0uY29tIiBjbGFzcz0iIj5hZGFtQG5vc3RydW0uY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24g NC8yNS8xNyAxNzoyMiwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkhpIEFkYW0sPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KT24gNC8yNS8xNywgNToyNyBQTSwgJnF1b3Q7QWRhbSBSb2FjaCZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iIGNsYXNzPSIiPmFkYW1Abm9zdHJ1 bS5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4tIFNlY3Rpb24gNSBkaXNjdXNzZXMgdGhlIHVzZSBv ZiBhIEtFSywgZGlzdHJpYnV0ZWQgb3V0LW9mLWJhbmQsIHRvPGJyIGNsYXNzPSIiPg0KZGVjcnlw dCB0aGUga2V5cyBzdG9yZWQgaW4gdGhpcyBmb3JtYXQuIFRoZXJlIGFwcGVhcnMgdG8gYmUgbm88 YnIgY2xhc3M9IiI+DQphZmZvcmRhbmNlPGJyIGNsYXNzPSIiPg0KZm9yIGluZGljYXRpbmcgdGhl IGlkZW50aXR5IG9mIHdoaWNoIEtFSyB0byB1c2UsIHdoaWNoIHdvdWxkIGNvbWUgaW48YnIgY2xh c3M9IiI+DQpoYW5keSBmb3IgdGhlIHR5cGVzIG9mIGtleSByb3RhdGlvbiBzY2hlbWVzIEknbSBm YW1pbGlhciB3aXRoLjxiciBjbGFzcz0iIj4NCk1vc3RseSw8YnIgY2xhc3M9IiI+DQpJJ20gd29y cmllZCBhYm91dCB0aGUgJnF1b3Q7dHJ5IGl0IGFuZCBzZWUgaWYgaXQgd29ya3MmcXVvdDsgYXBw cm9hY2ggd2hlbiB5b3U8YnIgY2xhc3M9IiI+DQpoYXZlPGJyIGNsYXNzPSIiPg0KdHdvIHZhbGlk IEtFS3MgKGFzIGR1cmluZyBhIHRyYW5zaXRpb24pLCBhcyBpdCdzIG5vdCBjbGVhciB0aGF0IHlv dTxiciBjbGFzcz0iIj4NCndpbGw8YnIgY2xhc3M9IiI+DQpiZSBhYmxlIHRvIGRpc3Rpbmd1aXNo IHN1Y2Nlc3MgZnJvbSBmYWlsdXJlIGluIGFsbCBjYXNlcy48YnIgY2xhc3M9IiI+DQo8L2Jsb2Nr cXVvdGU+DQpBRVMgaXMgYW4gYWxnb3JpdGhtLiBJIGtub3cgdGhlcmUgYXJlIDEyOCwgMTkyLCBh bmQgMjU2IGJpdCB2YXJpZXRpZXMuPGJyIGNsYXNzPSIiPg0KRG88YnIgY2xhc3M9IiI+DQp5b3Ug d2FudCBtZSB0byBzcGVjaWZ5IHRoYW4gYW55IHZhcmlldHkgbWF5IGJlIHVzZWQ/IEkgYWxtb3N0 IHJlbW92ZWQ8YnIgY2xhc3M9IiI+DQp0aGlzPGJyIGNsYXNzPSIiPg0Kb3V0LW9mLWJhbmQga2V5 IGVuY3J5cHRpb24gb25jZS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGlzbid0IGFib3V0IGNyeXB0by1hZ2lsaXR5OyBpdCdz IGFib3V0IGtleSByb3RhdGlvbi4gVGhpcyBzZWN0aW9uPGJyIGNsYXNzPSIiPg0KcG9zaXRzIGEg c3lzdGVtIGluIHdoaWNoIHlvdSBoYXZlIHNvbWUgS0VLLCBkaXN0cmlidXRlZCBvdXQtb2YtYmFu ZC48YnIgY2xhc3M9IiI+DQpMZXQncyBjYWxsIHRoZSBrZXkgd2UncmUgdXNpbmcgYXQgdGhpcyBt b21lbnQgJnF1b3Q7R2VuZXJhdGlvbiBBLiZxdW90OyBBdCBzb21lPGJyIGNsYXNzPSIiPg0KcG9p bnQgLS0gbGV0J3Mgc2F5IG5leHQgd2VlayAtLSB3ZSBkZWNpZGUgdGhhdCBpdCdzIHRpbWUgdG8g Y2hhbmdlIHRoZTxiciBjbGFzcz0iIj4NCktFSyB0byBvbmUgd2UncmUgZ29pbmcgdG8gY2FsbCAm cXVvdDtHZW5lcmF0aW9uIEIuJnF1b3Q7IEZpcnN0LCB3ZSBuZWVkIHRvIGdldDxiciBjbGFzcz0i Ij4NCnRoZTxiciBjbGFzcz0iIj4NCiZxdW90O0dlbmVyYXRpb24gQiZxdW90OyBLRUtzIHRvIGV2 ZXJ5b25lIGJlZm9yZSB0aGUgc3dpdGNoLW92ZXIgKHRvIGF2b2lkIGE8YnIgY2xhc3M9IiI+DQpw ZXJpb2Qgb2YgdGltZSBkdXJpbmcgd2hpY2ggdGhleSBjYW4ndCBkZWNyeXB0IHRoZSBZQU5HLXN0 b3JlZCBrZXlzKS48YnIgY2xhc3M9IiI+DQpUaGUgaXNzdWUgYmVjb21lczogb25jZSB5b3UgaGF2 ZSBib3RoICZxdW90O0dlbmVyYXRpb24gQSZxdW90OyBhbmQgJnF1b3Q7R2VuZXJhdGlvbjxiciBj bGFzcz0iIj4NCkImcXVvdDssPGJyIGNsYXNzPSIiPg0KaG93IGRvIHlvdSBrbm93IHdoaWNoIG9u ZSB0byB1c2UgdG8gZGVjcnlwdCB0aGUgWUFORyBrZXlzPyBJZiB0aGVyZTxiciBjbGFzcz0iIj4N CndlcmU8YnIgY2xhc3M9IiI+DQphIHBsYWNlIHRvIHN0b3JlIGEga2V5IElEIGluIHRoZSBZQU5H IG1vZGVsLCBpdCBjb3VsZCBpZGVudGlmeSB3aGljaCBvZjxiciBjbGFzcz0iIj4NCnRoZSB0d28g a2V5cyB0byB1c2UuIExhY2tpbmcgdGhhdCwgZm9yIHNvbWUga2luZHMgb2YgZGF0YSwgeW91IGNh biBkbyBhPGJyIGNsYXNzPSIiPg0KJnF1b3Q7dHJ5IGJvdGggYW5kIHNlZSB3aGljaCB3b3Jrcywm cXVvdDsgYnV0IGl0J3Mgbm90IGNsZWFyIHRoYXQgZG9pbmcgc28gaXM8YnIgY2xhc3M9IiI+DQpw b3NzaWJsZSBpbiB0aGlzIGNhc2UgKHNpbmNlIHRoZSB0aGluZyB5b3UncmUgZGVjcnlwdGluZyBp cyBhIGtleSwgYW5kPGJyIGNsYXNzPSIiPg0Kd2lsbCBzaW1wbHkgbG9vayBsaWtlIHJhbmRvbSBi aXRzIHJlZ2FyZGxlc3Mgb2Ygd2hpY2ggS0VLIHlvdSB1c2Ugb248YnIgY2xhc3M9IiI+DQppdCw8 YnIgY2xhc3M9IiI+DQp5b3UgY2FuJ3QgZXhhbWluZSBpdHMgc3RydWN0dXJlIHRvIGRldGVybWlu ZSB3aGV0aGVyIGl0IGlzIHZhbGlkKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlz IGlzbid0IGEgYmxvY2tpbmcgY29tbWVudDsgSSdtIGp1c3Qgd29uZGVyaW5nIHdoZXRoZXIgdGhp czxiciBjbGFzcz0iIj4NCm9wZXJhdGlvbmFsIGFzcGVjdCBvY2N1cnJlZCB0byB0aGUgV0cgd2hl biB0aGlzIHNjaGVtZSB3YXMgYmVpbmc8YnIgY2xhc3M9IiI+DQpkaXNjdXNzZWQsIGFuZCB3aGV0 aGVyIHRoZXJlJ3Mgc29tZSB0cml2aWFsIHdheSB0byBwZXJmb3JtIEtFSyByb3RhdGlvbjxiciBj bGFzcz0iIj4NCnRoYXQgY291bGQgYmUgZGVzY3JpYmVkIGluIHRoZSBkb2N1bWVudC4gV2l0aG91 dCB0aGUgYWJpbGl0eSB0byByb3RhdGU8YnIgY2xhc3M9IiI+DQp0aGUgS0VLLCBJJ20gbm90IHN1 cmUgdGhpcyBzY2hlbWUgaXMgYWxsIHRoYXQgdXNlZnVsLjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxiciBjbGFzcz0iIj4NCkl0IHNlZW1zIHRoYXQgdGhpcyBzaG91bGQgaGF2ZSBiZWVu IGNvdmVyZWQgaW4gc29tZSBvdGhlciBTZWN1cml0eSBSRkMuPGJyIGNsYXNzPSIiPg0KSWY8YnIg Y2xhc3M9IiI+DQpub3QgUkZDIDU2NDkgKHdoaWNoIHNlZW1zIHRvIGJlIGluZXhwbGljYWJseSBu YXJyb3cgaW4gc2NvcGUpLCB0aGVuIHNvbWU8YnIgY2xhc3M9IiI+DQpvdGhlciBTZWN1cml0eSBk b2N1bWVudC4gSWYgdGhlcmUgaXMgYW0gb3V0LW9mLWJhbmQgS0VLIHByb2NlZHVyZSBmb3I8YnIg Y2xhc3M9IiI+DQplbmNyeXB0aW9uIG9mIGtleSBzdHJpbmcsIHRoZW4gaXQgc2hvdWxkIGhhdmUg YmVlbiBkb2N1bWVudGVkIHByaW9yIHRvPGJyIGNsYXNzPSIiPg0KbXk8YnIgY2xhc3M9IiI+DQp1 c2FnZS4gSeKAmW0gY29weWluZyBCcmlhbiBXZWlzIChhIFNlY3VyaXR5IERpcmVjdG9yYXRlIG1l bWJlcikgd2hvPGJyIGNsYXNzPSIiPg0Kb3JpZ2luYWxseSBzdWdnZXN0ZWQgdGhpcy4gTXkgaW5j bGluYXRpb24gaXMgdG8gcmVtb3ZlIGFsbCB0cmFjZXMgb2YgQUVBPGJyIGNsYXNzPSIiPg0KS2V5 IFdyYXAgKFJGQyA1NjQ5KSBhbmQgcmVseSBvbiBOQ0FDTS48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpUaGFua3MsPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxiciBjbGFzcz0iIj4NCkFjZWU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KL2E8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8 YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQotLTxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpCcmlh biBXZWlzPGJyIGNsYXNzPSIiPg0KU2VjdXJpdHksIENTRywgQ2lzY28gU3lzdGVtczxiciBjbGFz cz0iIj4NClRlbGVwaG9uZTogJiM0MzsxIDQwOCA1MjYgNDc5NjxiciBjbGFzcz0iIj4NCkVtYWls OiA8YSBocmVmPSJtYWlsdG86YmV3QGNpc2NvLmNvbSIgY2xhc3M9IiI+YmV3QGNpc2NvLmNvbTwv YT48L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4tLSZuYnNwOzxiciBjbGFzcz0iIj4NCkJyaWFuIFdlaXM8YnIg Y2xhc3M9IiI+DQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zPGJyIGNsYXNzPSIiPg0KVGVs ZXBob25lOiAmIzQzOzEgNDA4IDUyNiA0Nzk2PGJyIGNsYXNzPSIiPg0KRW1haWw6IDxhIGhyZWY9 Im1haWx0bzpiZXdAY2lzY28uY29tIiBjbGFzcz0iIj5iZXdAY2lzY28uY29tPC9hPiA8L2Rpdj4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_45A012DC092D42C980B3488E9044F13Dciscocom_-- From nobody Wed Apr 26 09:06:18 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F1213013C; Wed, 26 Apr 2017 09:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 4t5pz6mVjOyU; Wed, 26 Apr 2017 09:05:56 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 7C30512EC42; Wed, 26 Apr 2017 09:05:54 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 194so2169197pfv.3; Wed, 26 Apr 2017 09:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sAztvb/93A1knrhLSUVBSrCdi27N9wMCIJsX8mOFf54=; b=jDDgAWjls19x3KFwpSQOVGQrLDsFmhYWAmX2wMgLq6faPF9jYGbXB1euDKSg0pGz14 6J6uYnM6NRx7Dn1obI0ALWfA91wUoQDzdtqtPtETCcpFfxqI5bjeEeme4TxNjuBQ5vlP PgNwrH9RvhakWlTdWl2x5c44BkNJiJw7wA5c2paNY0Kgph4JOaHuv6GaZre6pLQRQQPP gSJtEp0MC4N7FsjoHmFefwbLc30SEZhIaWEMHiCAPqeHIeq3PLKA8N0BSVr6QN9sfVDv f7dsb4i3saHcASMe767QTR2TDGi9d6/YwxUagk4KX+V+EqB8sPdJPfNTjGWUQ+8T4l4i BbSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sAztvb/93A1knrhLSUVBSrCdi27N9wMCIJsX8mOFf54=; b=PuyTvAu6A2UzZ91clR4QJMyvL1dgK/RcRgtJYzxL/6pjXv7woaXOiBfwBfmnhM2pP0 g5tjkO35M4G79CexqcAn2lGfeDDR8sV/8yHAhJzRFRuKg7fT4IOdAaHEsI6mvH36PU1E hqzN63BGjTbZFpEXuCy3Mu4og3edHJdc7m/BWSSaIiF190N1K4kiHPUN03s3HUjzdphg 0BFYb5DbnIDQE+NiSxYPWpUCgjmDk0Zg7ROK2RrM826hQK4GgjrEzYgfRykI/PCz0ddy y02TX2EAGP05GVSAEft0RsU7TW/PLkD5IJVtIgq1ToSigtg0QrjdISIUoVG6zmwHqHAk 4xXg== X-Gm-Message-State: AN3rC/7aKjMWBb6ZmqSxBXuofeSM8GfQTHj7WgPq7y+pcBst0ov0M9wz 2u74aUf1MmXoC4h75wa4UEqvekzY9w== X-Received: by 10.98.60.134 with SMTP id b6mr551190pfk.19.1493222753973; Wed, 26 Apr 2017 09:05:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 09:05:13 -0700 (PDT) In-Reply-To: References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 12:05:13 -0400 Message-ID: Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) To: "Acee Lindem (acee)" Cc: "Brian Weis (bew)" , Adam Roach , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , The IESG , Jeff Tantsura , "rtgwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:06:07 -0000 Thanks, Brian for chiming in, I am just finishing my read of this draft and looking at the NACM & referenced RFC5649. On Wed, Apr 26, 2017 at 11:55 AM, Acee Lindem (acee) wrote= : > Hi Brian, > > On 4/26/17, 11:45 AM, "Brian Weis (bew)" wrote: > >>Distributing and maintaining keys has a higher security bar than most >>configuration items, because their leakage can usually cause more harm. >>For example, a leaked key from the routing key chain could allow an >>attacker to substitute its own routing messages for authentic ones. >> >>Distributing plain-text keys through a general purpose configuration >>protocol is not always considered safe. When the configuration protocol >>is protected (e.g., TLS), the security requirements of some users are >>satisfied because they are only worried about protecting the keys on the >>wire. But other users with larger threat profile (e.g., government >>users) often do not consider sending plain-text keys through a protected >>configuration protocol to be sufficient, because they may not have enough >>control over the ciphers chosen for the TLS session, or perhaps they want >>to protect the keys in the configuration system before they are delivered >>to the TLS session. In these cases it=E2=80=99s valuable to "key wrap=E2= =80=9D (encrypt) >>the keys in the software that generates the keys, and unwrap them in the >>piece of software that is actually installing the keys. That=E2=80=99s th= e >>motivation for including an optional key wrap method in the key chain >>Yang data model. >> >>Yes, using a key wrap method means there=E2=80=99s an extra complication = with >>needing to maintain a key wrap key. Users that require the use of a key >>wrap probably don=E2=80=99t have a problem with distributing a key out of= band >>for this. Distributing it in-band would likely mean sending it through a >>different Yang data model, which would have exactly the same problem of >>needing to be key wrapped so I=E2=80=99m not sure it=E2=80=99s valuable t= o even specify >>an in-band method. If that=E2=80=99s a hard requirement, then I suppose t= he key >>wrap method can be removed. But the removal of the key wrap option is >>likely to restrict the users who can use the key chain data mode. > > Since RFC 5649 is simply the algorithm without much guidance on > operations, the inclusion of this option has raised more questions than > the commensurate benefit. Additionally, there is nothing precluding a use= r > from deploying KEK for the keys in the YANG key-chain model. I'd like to see this option stay as having better options to protect keys is important. Having said that, I agree that there isn't enough guidance for the implementer and it would be good to add add that into this draft. I can put a discuss placeholder while we wait for that text. > > Finally, do you know of any implementations of KEK? This would be very helpful to know as well and if adding the guidance to implement will increase the likelihood. Thank you, Kathleen > > Thanks, > Acee >> >>Hope that helps, >>Brian >> >>> On Apr 25, 2017, at 5:47 PM, Acee Lindem (acee) wrote: >>> >>> >>> >>> On 4/25/17, 6:44 PM, "Adam Roach" wrote: >>> >>>> On 4/25/17 17:22, Acee Lindem (acee) wrote: >>>>> Hi Adam, >>>>> >>>>> On 4/25/17, 5:27 PM, "Adam Roach" wrote: >>>>> >>>>>> - Section 5 discusses the use of a KEK, distributed out-of-band, to >>>>>> decrypt the keys stored in this format. There appears to be no >>>>>> affordance >>>>>> for indicating the identity of which KEK to use, which would come in >>>>>> handy for the types of key rotation schemes I'm familiar with. >>>>>>Mostly, >>>>>> I'm worried about the "try it and see if it works" approach when you >>>>>> have >>>>>> two valid KEKs (as during a transition), as it's not clear that you >>>>>> will >>>>>> be able to distinguish success from failure in all cases. >>>>> AES is an algorithm. I know there are 128, 192, and 256 bit varieties= . >>>>> Do >>>>> you want me to specify than any variety may be used? I almost removed >>>>> this >>>>> out-of-band key encryption once. >>>> >>>> >>>> This isn't about crypto-agility; it's about key rotation. This section >>>> posits a system in which you have some KEK, distributed out-of-band. >>>> Let's call the key we're using at this moment "Generation A." At some >>>> point -- let's say next week -- we decide that it's time to change the >>>> KEK to one we're going to call "Generation B." First, we need to get >>>>the >>>> "Generation B" KEKs to everyone before the switch-over (to avoid a >>>> period of time during which they can't decrypt the YANG-stored keys). >>>> The issue becomes: once you have both "Generation A" and "Generation >>>>B", >>>> how do you know which one to use to decrypt the YANG keys? If there >>>>were >>>> a place to store a key ID in the YANG model, it could identify which o= f >>>> the two keys to use. Lacking that, for some kinds of data, you can do = a >>>> "try both and see which works," but it's not clear that doing so is >>>> possible in this case (since the thing you're decrypting is a key, and >>>> will simply look like random bits regardless of which KEK you use on >>>>it, >>>> you can't examine its structure to determine whether it is valid). >>>> >>>> This isn't a blocking comment; I'm just wondering whether this >>>> operational aspect occurred to the WG when this scheme was being >>>> discussed, and whether there's some trivial way to perform KEK rotatio= n >>>> that could be described in the document. Without the ability to rotate >>>> the KEK, I'm not sure this scheme is all that useful. >>> >>> It seems that this should have been covered in some other Security RFC. >>>If >>> not RFC 5649 (which seems to be inexplicably narrow in scope), then som= e >>> other Security document. If there is am out-of-band KEK procedure for >>> encryption of key string, then it should have been documented prior to >>>my >>> usage. I=E2=80=99m copying Brian Weis (a Security Directorate member) w= ho >>> originally suggested this. My inclination is to remove all traces of AE= A >>> Key Wrap (RFC 5649) and rely on NCACM. >>> >>> Thanks, >>> Acee >>>> >>>> /a >>> >> >>-- >>Brian Weis >>Security, CSG, Cisco Systems >>Telephone: +1 408 526 4796 >>Email: bew@cisco.com >> > --=20 Best regards, Kathleen From nobody Wed Apr 26 09:09:02 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3593A13147D; Wed, 26 Apr 2017 09:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 c72ewy1amKc1; Wed, 26 Apr 2017 09:08:58 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D141D131489; Wed, 26 Apr 2017 09:08:55 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id v14so2216575pfd.2; Wed, 26 Apr 2017 09:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dd2sRS2O78+c0MnMH5M2ee5mGIJlmqXfh18ZyqlUarY=; b=emyvSJ4ZZKaBn+nOg6zyv+kEU+5OPu/8ItsMJwPQepgCeUuYLEyQ4crymH1N/CTQX6 2aCgLYzkpDDxCOd4fh3zV5pfAYY9k7o6fmTBqdCt3jKnM4j8lx/VpDkXH1CdXyomlEr1 LgoWh+pYpYqNTo4ut5acxmwyEdMEh7Vgo9w4VRTi+hXbDjEmXQBzRl+Bwhn0p2FlVXHl B05vX20ediFm8+zcxLqOoedGpW/W257D6lEcWFdXgFat7TlhLK4yAA8tRajbZgJRGDiC gGeLHgVs/2RcxJVqESTgspqQaGraUqI+JGpIGBF7PAaztkzSYpKTkWmkkxqSm2vACzCs 6iTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dd2sRS2O78+c0MnMH5M2ee5mGIJlmqXfh18ZyqlUarY=; b=SoJTfTi5uCMTGKtVM8Yw6rdpjmWOAp4PBSEg+AzPAyU6rcQzEDr5FdBhCiGJW/k4sW CjG7ct5Kthq4JQPfl9NaQSbTWx6ZyeyI1GjnvEfduEBBv45y3zjLOB+MCKWQ33KMoW1I 7lXStDQnl1rVKRnApdcReGll0CprTB4cTfdlUICNOYSFpb1CjMHfwBZv133JDGy3KTuf 9TIkrFfYDjeVy44YZiMA+zhbFN/ZVsCtKom7o8tugZLzk+YadbvAPgh8ws6cZyUXlDYN ffr9aid8oAWNQ/2ab5vD/of5fj9JBn1TztccY33yPCwPiy15BP+eAEEnUJCha1nN0Us4 RfXw== X-Gm-Message-State: AN3rC/7QVKkYl9f3Nf4/QG/yG8MbGC/Wgb984OzGj50cKP4PfVAwyAZ4 l9ggoaTOCNXoY3Ns7OkLuJ/uwc+Ixg== X-Received: by 10.98.29.86 with SMTP id d83mr642265pfd.68.1493222935346; Wed, 26 Apr 2017 09:08:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 09:08:14 -0700 (PDT) In-Reply-To: <45A012DC-092D-42C9-80B3-488E9044F13D@cisco.com> References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> <45A012DC-092D-42C9-80B3-488E9044F13D@cisco.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 12:08:14 -0400 Message-ID: Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) To: "Brian Weis (bew)" Cc: "Acee Lindem (acee)" , Adam Roach , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , The IESG , Jeff Tantsura , "rtgwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:09:00 -0000 On Wed, Apr 26, 2017 at 12:04 PM, Brian Weis (bew) wrote: > Hi Acee, > > On Apr 26, 2017, at 8:55 AM, Acee Lindem (acee) wrote: > > Hi Brian, > > On 4/26/17, 11:45 AM, "Brian Weis (bew)" wrote: > > Distributing and maintaining keys has a higher security bar than most > configuration items, because their leakage can usually cause more harm. > For example, a leaked key from the routing key chain could allow an > attacker to substitute its own routing messages for authentic ones. > > Distributing plain-text keys through a general purpose configuration > protocol is not always considered safe. When the configuration protocol > is protected (e.g., TLS), the security requirements of some users are > satisfied because they are only worried about protecting the keys on the > wire. But other users with larger threat profile (e.g., government > users) often do not consider sending plain-text keys through a protected > configuration protocol to be sufficient, because they may not have enough > control over the ciphers chosen for the TLS session, or perhaps they want > to protect the keys in the configuration system before they are delivered > to the TLS session. In these cases it=E2=80=99s valuable to "key wrap=E2= =80=9D (encrypt) > the keys in the software that generates the keys, and unwrap them in the > piece of software that is actually installing the keys. That=E2=80=99s th= e > motivation for including an optional key wrap method in the key chain > Yang data model. > > Yes, using a key wrap method means there=E2=80=99s an extra complication = with > needing to maintain a key wrap key. Users that require the use of a key > wrap probably don=E2=80=99t have a problem with distributing a key out of= band > for this. Distributing it in-band would likely mean sending it through a > different Yang data model, which would have exactly the same problem of > needing to be key wrapped so I=E2=80=99m not sure it=E2=80=99s valuable t= o even specify > an in-band method. If that=E2=80=99s a hard requirement, then I suppose t= he key > wrap method can be removed. But the removal of the key wrap option is > likely to restrict the users who can use the key chain data mode. > > > Since RFC 5649 is simply the algorithm without much guidance on > operations, the inclusion of this option has raised more questions than > the commensurate benefit. Additionally, there is nothing precluding a use= r > from deploying KEK for the keys in the YANG key-chain model. > > > If you took out the key wrap method, then stating how a user might do the > key wrapping themselves should be described in the draft. I guess that ma= kes > them responsible for pre- and post- processing of the keys in an > implementation-specific manner.. > > > Finally, do you know of any implementations of KEK? > > > Not with this data model, because I=E2=80=99m not involved with implement= ations of > the data model. The use of a key wrap and KEK is used in other cases. Great, is this already documented in a draft or RFC for usage with YANG data models? If so, a reference to that would help or additional text in this draft. Having the guidance in one document to reference would be helpful in any case (might be this one, I suspect). Thanks, Kathleen > > Brian > > > Thanks, > Acee > > > Hope that helps, > Brian > > On Apr 25, 2017, at 5:47 PM, Acee Lindem (acee) wrote: > > > > On 4/25/17, 6:44 PM, "Adam Roach" wrote: > > On 4/25/17 17:22, Acee Lindem (acee) wrote: > > Hi Adam, > > On 4/25/17, 5:27 PM, "Adam Roach" wrote: > > - Section 5 discusses the use of a KEK, distributed out-of-band, to > decrypt the keys stored in this format. There appears to be no > affordance > for indicating the identity of which KEK to use, which would come in > handy for the types of key rotation schemes I'm familiar with. > Mostly, > I'm worried about the "try it and see if it works" approach when you > have > two valid KEKs (as during a transition), as it's not clear that you > will > be able to distinguish success from failure in all cases. > > AES is an algorithm. I know there are 128, 192, and 256 bit varieties. > Do > you want me to specify than any variety may be used? I almost removed > this > out-of-band key encryption once. > > > > This isn't about crypto-agility; it's about key rotation. This section > posits a system in which you have some KEK, distributed out-of-band. > Let's call the key we're using at this moment "Generation A." At some > point -- let's say next week -- we decide that it's time to change the > KEK to one we're going to call "Generation B." First, we need to get > the > "Generation B" KEKs to everyone before the switch-over (to avoid a > period of time during which they can't decrypt the YANG-stored keys). > The issue becomes: once you have both "Generation A" and "Generation > B", > how do you know which one to use to decrypt the YANG keys? If there > were > a place to store a key ID in the YANG model, it could identify which of > the two keys to use. Lacking that, for some kinds of data, you can do a > "try both and see which works," but it's not clear that doing so is > possible in this case (since the thing you're decrypting is a key, and > will simply look like random bits regardless of which KEK you use on > it, > you can't examine its structure to determine whether it is valid). > > This isn't a blocking comment; I'm just wondering whether this > operational aspect occurred to the WG when this scheme was being > discussed, and whether there's some trivial way to perform KEK rotation > that could be described in the document. Without the ability to rotate > the KEK, I'm not sure this scheme is all that useful. > > > It seems that this should have been covered in some other Security RFC. > If > not RFC 5649 (which seems to be inexplicably narrow in scope), then some > other Security document. If there is am out-of-band KEK procedure for > encryption of key string, then it should have been documented prior to > my > usage. I=E2=80=99m copying Brian Weis (a Security Directorate member) who > originally suggested this. My inclination is to remove all traces of AEA > Key Wrap (RFC 5649) and rely on NCACM. > > Thanks, > Acee > > > /a > > > > -- > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > > -- > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > --=20 Best regards, Kathleen From nobody Wed Apr 26 09:24:59 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2337C1314DD for ; Wed, 26 Apr 2017 09:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5830iwKHyKKJ for ; Wed, 26 Apr 2017 09:24:56 -0700 (PDT) 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 221C41314DF for ; Wed, 26 Apr 2017 09:24:23 -0700 (PDT) Received: from Orochi.local (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 v3QGOLCG054830 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 11:24:22 -0500 (CDT) (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 Orochi.local Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) To: "Brian Weis (bew)" , "Acee Lindem (acee)" Cc: "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , The IESG , Jeff Tantsura , "rtgwg@ietf.org" References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Wed, 26 Apr 2017 11:24:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:24:58 -0000 I'm not concerned about how the KEKs get distributed. I'm concerned about how you know which one to use. /a On 4/26/17 10:45, Brian Weis (bew) wrote: > Distributing and maintaining keys has a higher security bar than most configuration items, because their leakage can usually cause more harm. For example, a leaked key from the routing key chain could allow an attacker to substitute its own routing messages for authentic ones. > > Distributing plain-text keys through a general purpose configuration protocol is not always considered safe. When the configuration protocol is protected (e.g., TLS), the security requirements of some users are satisfied because they are only worried about protecting the keys on the wire. But other users with larger threat profile (e.g., government users) often do not consider sending plain-text keys through a protected configuration protocol to be sufficient, because they may not have enough control over the ciphers chosen for the TLS session, or perhaps they want to protect the keys in the configuration system before they are delivered to the TLS session. In these cases it’s valuable to "key wrap” (encrypt) the keys in the software that generates the keys, and unwrap them in the piece of software that is actually installing the keys. That’s the motivation for including an optional key wrap method in the key chain Yang data model. > > Yes, using a key wrap method means there’s an extra complication with needing to maintain a key wrap key. Users that require the use of a key wrap probably don’t have a problem with distributing a key out of band for this. Distributing it in-band would likely mean sending it through a different Yang data model, which would have exactly the same problem of needing to be key wrapped so I’m not sure it’s valuable to even specify an in-band method. If that’s a hard requirement, then I suppose the key wrap method can be removed. But the removal of the key wrap option is likely to restrict the users who can use the key chain data mode. > > Hope that helps, > Brian > >> On Apr 25, 2017, at 5:47 PM, Acee Lindem (acee) wrote: >> >> >> >> On 4/25/17, 6:44 PM, "Adam Roach" wrote: >> >>> On 4/25/17 17:22, Acee Lindem (acee) wrote: >>>> Hi Adam, >>>> >>>> On 4/25/17, 5:27 PM, "Adam Roach" wrote: >>>> >>>>> - Section 5 discusses the use of a KEK, distributed out-of-band, to >>>>> decrypt the keys stored in this format. There appears to be no >>>>> affordance >>>>> for indicating the identity of which KEK to use, which would come in >>>>> handy for the types of key rotation schemes I'm familiar with. Mostly, >>>>> I'm worried about the "try it and see if it works" approach when you >>>>> have >>>>> two valid KEKs (as during a transition), as it's not clear that you >>>>> will >>>>> be able to distinguish success from failure in all cases. >>>> AES is an algorithm. I know there are 128, 192, and 256 bit varieties. >>>> Do >>>> you want me to specify than any variety may be used? I almost removed >>>> this >>>> out-of-band key encryption once. >>> >>> This isn't about crypto-agility; it's about key rotation. This section >>> posits a system in which you have some KEK, distributed out-of-band. >>> Let's call the key we're using at this moment "Generation A." At some >>> point -- let's say next week -- we decide that it's time to change the >>> KEK to one we're going to call "Generation B." First, we need to get the >>> "Generation B" KEKs to everyone before the switch-over (to avoid a >>> period of time during which they can't decrypt the YANG-stored keys). >>> The issue becomes: once you have both "Generation A" and "Generation B", >>> how do you know which one to use to decrypt the YANG keys? If there were >>> a place to store a key ID in the YANG model, it could identify which of >>> the two keys to use. Lacking that, for some kinds of data, you can do a >>> "try both and see which works," but it's not clear that doing so is >>> possible in this case (since the thing you're decrypting is a key, and >>> will simply look like random bits regardless of which KEK you use on it, >>> you can't examine its structure to determine whether it is valid). >>> >>> This isn't a blocking comment; I'm just wondering whether this >>> operational aspect occurred to the WG when this scheme was being >>> discussed, and whether there's some trivial way to perform KEK rotation >>> that could be described in the document. Without the ability to rotate >>> the KEK, I'm not sure this scheme is all that useful. >> It seems that this should have been covered in some other Security RFC. If >> not RFC 5649 (which seems to be inexplicably narrow in scope), then some >> other Security document. If there is am out-of-band KEK procedure for >> encryption of key string, then it should have been documented prior to my >> usage. I’m copying Brian Weis (a Security Directorate member) who >> originally suggested this. My inclination is to remove all traces of AEA >> Key Wrap (RFC 5649) and rely on NCACM. >> >> Thanks, >> Acee >>> /a From nobody Wed Apr 26 09:34:34 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A6212953D; Wed, 26 Apr 2017 09:34:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-rtgwg-yang-key-chain@ietf.org, Jeff Tantsura , rtgwg-chairs@ietf.org, jefftant.ietf@gmail.com, rtgwg@ietf.org Subject: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 09:34:32 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:34:32 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-rtgwg-yang-key-chain-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft. There is one outstanding issue from the SecDir review that may require some updated text to resolve. It seems use of the key wrap method in RFC5649 requires more guidance for implementations to use it with this YANG module. It's good to know that this is in use for other modules, so having a clear reference either to another draft or the text being in this draft for later reference would be helpful. In looking at this text within the draft, I think it would be better to pull the text out of the Security Considerations section and into an earlier section of the draft. It's better to introduce this prior to enumerating security considerations for the draft since this something that would be implemented. Then security considerations should mention the considerations of using this option versus just what's in NACM. You have the text: When configured, the key-strings can be encrypted using the AES Key Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is not included in the YANG model and must be set or derived independent of key-chain configuration. When AES key-encryption is used, the hex-key-string feature is also required since the encrypted keys will contain characters that are not representable in the YANG string built-in type [YANG]. AES key-encryption MAY be used for added key security in situations where the NETCONF Access Control Mode is not available. I think it's pretty straightforward after looking at RFC5649, but maybe more text would be helpful to clarify for implementers. This might mean more text from 5649 on what gets placed in the YANG data model where you have already allocated for this or including an example. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for working through the SecDir review and making the suggested updates. Since the following text int he Security Considerations section is a recommendation, IMO it would be better to drop "or otherwise obfuscated" from the sentence as encrypting the keys really should be the recommendation. Can we make this update? It is RECOMMENDED that keys be encrypted or otherwise obfuscated when stored internally on a network device supporting this specification. If obfuscation is what happens more often in practice, maybe mention this as a fallback from the recommendation, but not make them sound equivalent? From nobody Wed Apr 26 09:36:51 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2C01314F4 for ; Wed, 26 Apr 2017 09:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pcuqs7WAw7X for ; Wed, 26 Apr 2017 09:36:46 -0700 (PDT) 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 9ADF9131508 for ; Wed, 26 Apr 2017 09:36:29 -0700 (PDT) Received: from Orochi.local (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 v3QGaQSG056036 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 11:36:28 -0500 (CDT) (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 Orochi.local Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) From: Adam Roach To: "Brian Weis (bew)" , "Acee Lindem (acee)" Cc: Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> Message-ID: Date: Wed, 26 Apr 2017 11:36:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:36:48 -0000 Okay, on further digging through RFC5649, it does have handling for this in the form of a 64-bit key data integrity check. So it looks like the "try it and see if it works" approach will be fine. /a On 4/26/17 11:24, Adam Roach wrote: > I'm not concerned about how the KEKs get distributed. > > I'm concerned about how you know which one to use. > > /a > > On 4/26/17 10:45, Brian Weis (bew) wrote: >> Distributing and maintaining keys has a higher security bar than most >> configuration items, because their leakage can usually cause more >> harm. For example, a leaked key from the routing key chain could >> allow an attacker to substitute its own routing messages for >> authentic ones. >> >> Distributing plain-text keys through a general purpose configuration >> protocol is not always considered safe. When the configuration >> protocol is protected (e.g., TLS), the security requirements of some >> users are satisfied because they are only worried about protecting >> the keys on the wire. But other users with larger threat profile >> (e.g., government users) often do not consider sending plain-text >> keys through a protected configuration protocol to be sufficient, >> because they may not have enough control over the ciphers chosen for >> the TLS session, or perhaps they want to protect the keys in the >> configuration system before they are delivered to the TLS session. In >> these cases it’s valuable to "key wrap” (encrypt) the keys in the >> software that generates the keys, and unwrap them in the piece of >> software that is actually installing the keys. That’s the motivation >> for including an optional key wrap method in the key chain Yang data >> model. >> >> Yes, using a key wrap method means there’s an extra complication >> with needing to maintain a key wrap key. Users that require the use >> of a key wrap probably don’t have a problem with distributing a key >> out of band for this. Distributing it in-band would likely mean >> sending it through a different Yang data model, which would have >> exactly the same problem of needing to be key wrapped so I’m not sure >> it’s valuable to even specify an in-band method. If that’s a hard >> requirement, then I suppose the key wrap method can be removed. But >> the removal of the key wrap option is likely to restrict the users >> who can use the key chain data mode. >> >> Hope that helps, >> Brian >> >>> On Apr 25, 2017, at 5:47 PM, Acee Lindem (acee) wrote: >>> >>> >>> >>> On 4/25/17, 6:44 PM, "Adam Roach" wrote: >>> >>>> On 4/25/17 17:22, Acee Lindem (acee) wrote: >>>>> Hi Adam, >>>>> >>>>> On 4/25/17, 5:27 PM, "Adam Roach" wrote: >>>>> >>>>>> - Section 5 discusses the use of a KEK, distributed out-of-band, to >>>>>> decrypt the keys stored in this format. There appears to be no >>>>>> affordance >>>>>> for indicating the identity of which KEK to use, which would come in >>>>>> handy for the types of key rotation schemes I'm familiar with. >>>>>> Mostly, >>>>>> I'm worried about the "try it and see if it works" approach when you >>>>>> have >>>>>> two valid KEKs (as during a transition), as it's not clear that you >>>>>> will >>>>>> be able to distinguish success from failure in all cases. >>>>> AES is an algorithm. I know there are 128, 192, and 256 bit >>>>> varieties. >>>>> Do >>>>> you want me to specify than any variety may be used? I almost removed >>>>> this >>>>> out-of-band key encryption once. >>>> >>>> This isn't about crypto-agility; it's about key rotation. This section >>>> posits a system in which you have some KEK, distributed out-of-band. >>>> Let's call the key we're using at this moment "Generation A." At some >>>> point -- let's say next week -- we decide that it's time to change the >>>> KEK to one we're going to call "Generation B." First, we need to >>>> get the >>>> "Generation B" KEKs to everyone before the switch-over (to avoid a >>>> period of time during which they can't decrypt the YANG-stored keys). >>>> The issue becomes: once you have both "Generation A" and >>>> "Generation B", >>>> how do you know which one to use to decrypt the YANG keys? If there >>>> were >>>> a place to store a key ID in the YANG model, it could identify >>>> which of >>>> the two keys to use. Lacking that, for some kinds of data, you can >>>> do a >>>> "try both and see which works," but it's not clear that doing so is >>>> possible in this case (since the thing you're decrypting is a key, and >>>> will simply look like random bits regardless of which KEK you use >>>> on it, >>>> you can't examine its structure to determine whether it is valid). >>>> >>>> This isn't a blocking comment; I'm just wondering whether this >>>> operational aspect occurred to the WG when this scheme was being >>>> discussed, and whether there's some trivial way to perform KEK >>>> rotation >>>> that could be described in the document. Without the ability to rotate >>>> the KEK, I'm not sure this scheme is all that useful. >>> It seems that this should have been covered in some other Security >>> RFC. If >>> not RFC 5649 (which seems to be inexplicably narrow in scope), then >>> some >>> other Security document. If there is am out-of-band KEK procedure for >>> encryption of key string, then it should have been documented prior >>> to my >>> usage. I’m copying Brian Weis (a Security Directorate member) who >>> originally suggested this. My inclination is to remove all traces of >>> AEA >>> Key Wrap (RFC 5649) and rely on NCACM. >>> >>> Thanks, >>> Acee >>>> /a > > From nobody Wed Apr 26 09:46:18 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00C7129B81 for ; Wed, 26 Apr 2017 09:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp9RShgAqZR4 for ; Wed, 26 Apr 2017 09:46:15 -0700 (PDT) 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 9801A129B14 for ; Wed, 26 Apr 2017 09:46:15 -0700 (PDT) Received: from Orochi.local (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 v3QGkCd9056927 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 11:46:13 -0500 (CDT) (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 Orochi.local Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) To: Eric Rescorla Cc: "Acee Lindem (acee)" , The IESG , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> <21bc8763-1620-730e-35e3-cb0bc7995d57@nostrum.com> From: Adam Roach Message-ID: <68915b31-90c1-db0a-1fcf-655dc5854da2@nostrum.com> Date: Wed, 26 Apr 2017 11:46:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B20519555280FFD0948680F9" Content-Language: en-US Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:46:17 -0000 This is a multi-part message in MIME format. --------------B20519555280FFD0948680F9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/25/17 18:29, Eric Rescorla wrote: > > > On Tue, Apr 25, 2017 at 3:51 PM, Adam Roach > wrote: > > > > - Section 5 also suggests keys be encrypted or obfuscated > on the device > that is to use them, presumably in a way that can be > decrypted or > unobfuscated using information also on the device. I don't > know what the > current security area thinking around this is, but given > that the > information needed to retrieve plaintext keys is > necessarily present on > the device, this seems like a fig-leaf that provides an > illusion of > security without providing any real benefit. That > mis-impression seems > potentially harmful. > > I only added this at the behest of one of the other reviews. > The problem > with security is that there conflicting opinions, and as the > adage goes > “everybody’s got one.” I’ll defer to the Security ADs. > > > Right; that's what I meant by "I don't know what the current > security area thinking around this is." I'd be curious to have EKR > or Kathleen weigh in > > > What I took home here was that you would encrypt them and display the > encrypted > version instead of showing asterisks. Is that not what the thinking was? By my reading, this is just talking about encrypting "on the disk" storage on the device. Any processes involved in provisioning the values or using them to process traffic would have access to the plaintext, presumably by reading the encrypted form off disk, reading some keying material off disk, and combining them to retrieve the plaintext key. My concern is: if these process can extract the plaintext key from information stored on the disk, then so can other processes on the same device. Encryption in this case seems to provide the mere illusion of security -- akin to installing an deadbolt keyhole on a door that has no actual bolt attached. /a --------------B20519555280FFD0948680F9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/25/17 18:29, Eric Rescorla wrote:


On Tue, Apr 25, 2017 at 3:51 PM, Adam Roach <adam@nostrum.com> wrote:



- Section 5 also suggests keys be encrypted or obfuscated on the device
that is to use them, presumably in a way that can be decrypted or
unobfuscated using information also on the device. I don't know what the
current security area thinking around this is, but given that the
information needed to retrieve plaintext keys is necessarily present on
the device, this seems like a fig-leaf that provides an illusion of
security without providing any real benefit. That mis-impression seems
potentially harmful.
I only added this at the behest of one of the other reviews. The problem
with security is that there conflicting opinions, and as the adage goes
“everybody’s got one.” I’ll defer to the Security ADs.

 Right; that's what I meant by "I don't know what the current security area thinking around this is." I'd be curious to have EKR or Kathleen weigh in

What I took home here was that you would encrypt them and display the encrypted
version instead of showing asterisks. Is that not what the thinking was?

By my reading, this is just talking about encrypting "on the disk" storage on the device. Any processes involved in provisioning the values or using them to process traffic would have access to the plaintext, presumably by reading the encrypted form off disk, reading some keying material off disk, and combining them to retrieve the plaintext key.

My concern is: if these process can extract the plaintext key from information stored on the disk, then so can other processes on the same device. Encryption in this case seems to provide the mere illusion of security -- akin to installing an deadbolt keyhole on a door that has no actual bolt attached.

/a
--------------B20519555280FFD0948680F9-- From nobody Wed Apr 26 09:52:35 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6048212947C; Wed, 26 Apr 2017 09:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRbLiuSQGYRu; Wed, 26 Apr 2017 09:52:26 -0700 (PDT) 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 8577C129452; Wed, 26 Apr 2017 09:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5662; q=dns/txt; s=iport; t=1493225546; x=1494435146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wVp/Nu9YeQgpbKpowfeGzkNbXsTvs+zTYYd82PNW90w=; b=eJ5dYn+gjD8UoolwX58nbRIuZm1sYv0xOc+l0avN4+g0tJz2GDTiAhNN sxpZw21eF3vZpemg3H18HZPEM3+5JJWNQTbxBlAP3y4LBoW+w+6Ej3k/g B0yTMaUxIm3hrAx9RHuIp2EDHoRzL3EKKb0fG77y52EGoYft8gKxjFifd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlAQDjzwBZ/4wNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VhgQwHg2GKFplrjUqCDyELhXgCGoQQPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?WAgEDAQEhEToLEAIBCBoCJgICAh8GCxUQAgQBDQWKAwMVDqpCgiaHOA2DXwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgQuHJ4MaglOBXhEBgyKCXwWJPJNXOwGHGIc?= =?us-ascii?q?nhEuCAoU3iiWIdIIliQ0BHzh/CGUVRIUigUp1AYZGgSGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208";a="413116566" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Apr 2017 16:52:25 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3QGqP42006715 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 16:52:25 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 12:52:24 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 26 Apr 2017 12:52:24 -0400 From: "Acee Lindem (acee)" To: Kathleen Moriarty , The IESG CC: "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Index: AQHSvqsBaK6mr1jQpUuQYLHDV2KBn6HX3ZuA Date: Wed, 26 Apr 2017 16:52:24 +0000 Message-ID: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> In-Reply-To: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.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.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <67F2C9F0A6365F40B0EAF57C127D1268@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 16:52:28 -0000 S2F0aGxlZW4sIA0KDQpUaGUgbGFjayBvZiBLRUsgc3BlY2lmaWNhdGlvbiBpcyBub3QgYSBwcm9i bGVtIHdpdGggdGhlIFlBTkcga2V5LWNoYWluDQptb2RlbCwgaXQgd2l0aCBSRkMgNTY0OSBhbmQg S0VLLiBJ4oCZZCByZXF1ZXN0IHRoYXQgeW91cnNlbGYgb3Igc29tZW9uZSBpbg0KdGhlIHNlY3Vy aXR5IGFyZWEgcHJvdmlkZSBhIHJlZmVyZW5jZSBvciB0ZXh0LiBBIHByaW1hcnkgcmVhc29uIEtF SyBoYXMNCm5vdCBiZWVuIHdpZGVseSBkZXBsb3llZCBpcyB0aGF0IFJGQyA1NjQ5IGlzIHdvZWZ1 bGx5IGxhY2tpbmcgaW4NCm9wZXJhdGlvbmFsIGd1aWRhbmNlLiBJZiB5b3UgY2Fu4oCZdCBkbyB0 aGlzLCBJ4oCZbGwgcmVtb3ZlIHRoZSByZWZlcmVuY2UgYW5kDQpyZWx5IG9uIE5DQUNNIHNpbWls YXIgdG8gdGhlIHNoYXJlZC1zZWNyZXQgZGF0YSBub2RlIGluIFJGQyA3MzE3Lg0KDQpUaGFua3MN CkFjZWUNCg0KT24gNC8yNi8xNywgMTI6MzQgUE0sICJydGd3ZyBvbiBiZWhhbGYgb2YgS2F0aGxl ZW4gTW9yaWFydHkiDQo8cnRnd2ctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgS2F0aGxl ZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+DQp3cm90ZToNCg0KPkthdGhsZWVuIE1vcmlhcnR5 IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPmRyYWZ0LWll dGYtcnRnd2cteWFuZy1rZXktY2hhaW4tMjA6IERpc2N1c3MNCj4NCj5XaGVuIHJlc3BvbmRpbmcs IHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj5l bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpcw0KPmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPg0KPg0K PlBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNj dXNzLWNyaXRlcmlhLmh0bWwNCj5mb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NV U1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPg0KPg0KPlRoZSBkb2N1bWVudCwgYWxvbmcgd2l0 aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluLw0K Pg0KPg0KPg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5ESVNDVVNTOg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj5U aGFua3MgZm9yIHlvdXIgd29yayBvbiB0aGlzIGRyYWZ0LiAgVGhlcmUgaXMgb25lIG91dHN0YW5k aW5nIGlzc3VlIGZyb20NCj50aGUgU2VjRGlyIHJldmlldyB0aGF0IG1heSByZXF1aXJlIHNvbWUg dXBkYXRlZCB0ZXh0IHRvIHJlc29sdmUuICBJdA0KPnNlZW1zIHVzZSBvZiB0aGUga2V5IHdyYXAg bWV0aG9kIGluIFJGQzU2NDkgcmVxdWlyZXMgbW9yZSBndWlkYW5jZSBmb3INCj5pbXBsZW1lbnRh dGlvbnMgdG8gdXNlIGl0IHdpdGggdGhpcyBZQU5HIG1vZHVsZS4gIEl0J3MgZ29vZCB0byBrbm93 IHRoYXQNCj50aGlzIGlzIGluIHVzZSBmb3Igb3RoZXIgbW9kdWxlcywgc28gaGF2aW5nIGEgY2xl YXIgcmVmZXJlbmNlIGVpdGhlciB0bw0KPmFub3RoZXIgZHJhZnQgb3IgdGhlIHRleHQgYmVpbmcg aW4gdGhpcyBkcmFmdCBmb3IgbGF0ZXIgcmVmZXJlbmNlIHdvdWxkDQo+YmUgaGVscGZ1bC4NCj4N Cj5JbiBsb29raW5nIGF0IHRoaXMgdGV4dCB3aXRoaW4gdGhlIGRyYWZ0LCBJIHRoaW5rIGl0IHdv dWxkIGJlIGJldHRlciB0bw0KPnB1bGwgdGhlIHRleHQgb3V0IG9mIHRoZSBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyBzZWN0aW9uIGFuZCBpbnRvIGFuDQo+ZWFybGllciBzZWN0aW9uIG9mIHRoZSBk cmFmdC4gIEl0J3MgYmV0dGVyIHRvIGludHJvZHVjZSB0aGlzIHByaW9yIHRvDQo+ZW51bWVyYXRp bmcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSBkcmFmdCBzaW5jZSB0aGlzIHNvbWV0 aGluZw0KPnRoYXQgd291bGQgYmUgaW1wbGVtZW50ZWQuICBUaGVuIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNob3VsZCBtZW50aW9uDQo+dGhlIGNvbnNpZGVyYXRpb25zIG9mIHVzaW5nIHRoaXMg b3B0aW9uIHZlcnN1cyBqdXN0IHdoYXQncyBpbiBOQUNNLg0KPg0KPllvdSBoYXZlIHRoZSB0ZXh0 Og0KPg0KPiAgV2hlbiBjb25maWd1cmVkLCB0aGUga2V5LXN0cmluZ3MgY2FuIGJlIGVuY3J5cHRl ZCB1c2luZyB0aGUgQUVTIEtleQ0KPiAgIFdyYXAgYWxnb3JpdGhtIFtBRVMtS0VZLVdSQVBdLiAg VGhlIEFFUyBrZXktZW5jcnlwdGlvbiBrZXkgKEtFSykgaXMNCj4gICBub3QgaW5jbHVkZWQgaW4g dGhlIFlBTkcgbW9kZWwgYW5kIG11c3QgYmUgc2V0IG9yIGRlcml2ZWQNCj5pbmRlcGVuZGVudA0K PiAgIG9mIGtleS1jaGFpbiBjb25maWd1cmF0aW9uLiAgV2hlbiBBRVMga2V5LWVuY3J5cHRpb24g aXMgdXNlZCwgdGhlDQo+ICAgaGV4LWtleS1zdHJpbmcgZmVhdHVyZSBpcyBhbHNvIHJlcXVpcmVk IHNpbmNlIHRoZSBlbmNyeXB0ZWQga2V5cw0KPndpbGwNCj4gICBjb250YWluIGNoYXJhY3RlcnMg dGhhdCBhcmUgbm90IHJlcHJlc2VudGFibGUgaW4gdGhlIFlBTkcgc3RyaW5nDQo+ICAgYnVpbHQt aW4gdHlwZSBbWUFOR10uICBBRVMga2V5LWVuY3J5cHRpb24gTUFZIGJlIHVzZWQgZm9yIGFkZGVk IGtleQ0KPiAgIHNlY3VyaXR5IGluIHNpdHVhdGlvbnMgd2hlcmUgdGhlIE5FVENPTkYgQWNjZXNz IENvbnRyb2wgTW9kZSBpcyBub3QNCj4gICBhdmFpbGFibGUuDQo+DQo+SSB0aGluayBpdCdzIHBy ZXR0eSBzdHJhaWdodGZvcndhcmQgYWZ0ZXIgbG9va2luZyBhdCBSRkM1NjQ5LCBidXQgbWF5YmUN Cj5tb3JlIHRleHQgd291bGQgYmUgaGVscGZ1bCB0byBjbGFyaWZ5IGZvciBpbXBsZW1lbnRlcnMu ICBUaGlzIG1pZ2h0IG1lYW4NCj5tb3JlIHRleHQgZnJvbSA1NjQ5IG9uIHdoYXQgZ2V0cyBwbGFj ZWQgaW4gdGhlIFlBTkcgZGF0YSBtb2RlbCB3aGVyZSB5b3UNCj5oYXZlIGFscmVhZHkgYWxsb2Nh dGVkIGZvciB0aGlzIG9yIGluY2x1ZGluZyBhbiBleGFtcGxlLg0KPg0KPg0KPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj5DT01NRU5UOg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj5UaGFuayB5b3UgZm9yIHdvcmtpbmcg dGhyb3VnaCB0aGUgU2VjRGlyIHJldmlldyBhbmQgbWFraW5nIHRoZSBzdWdnZXN0ZWQNCj51cGRh dGVzLg0KPg0KPlNpbmNlIHRoZSBmb2xsb3dpbmcgdGV4dCBpbnQgaGUgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgc2VjdGlvbiBpcyBhDQo+cmVjb21tZW5kYXRpb24sIElNTyBpdCB3b3VsZCBiZSBi ZXR0ZXIgdG8gZHJvcCAib3Igb3RoZXJ3aXNlIG9iZnVzY2F0ZWQiDQo+ZnJvbSB0aGUgc2VudGVu Y2UgYXMgZW5jcnlwdGluZyB0aGUga2V5cyByZWFsbHkgc2hvdWxkIGJlIHRoZQ0KPnJlY29tbWVu ZGF0aW9uLiAgQ2FuIHdlIG1ha2UgdGhpcyB1cGRhdGU/DQo+DQo+ICAgSXQgaXMgUkVDT01NRU5E RUQgdGhhdCBrZXlzIGJlIGVuY3J5cHRlZCBvciBvdGhlcndpc2Ugb2JmdXNjYXRlZA0KPndoZW4N Cj4gICBzdG9yZWQgaW50ZXJuYWxseSBvbiBhIG5ldHdvcmsgZGV2aWNlIHN1cHBvcnRpbmcgdGhp cyBzcGVjaWZpY2F0aW9uLg0KPg0KPklmIG9iZnVzY2F0aW9uIGlzIHdoYXQgaGFwcGVucyBtb3Jl IG9mdGVuIGluIHByYWN0aWNlLCBtYXliZSBtZW50aW9uIHRoaXMNCj5hcyBhIGZhbGxiYWNrIGZy b20gdGhlIHJlY29tbWVuZGF0aW9uLCBidXQgbm90IG1ha2UgdGhlbSBzb3VuZA0KPmVxdWl2YWxl bnQ/DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5ydGd3ZyBtYWlsaW5nIGxpc3QNCj5ydGd3Z0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2cNCg0K From nobody Wed Apr 26 10:03:32 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C70612948A; Wed, 26 Apr 2017 10:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HdooRgsvzuI; Wed, 26 Apr 2017 10:03:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2361314CA; Wed, 26 Apr 2017 10:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11715; q=dns/txt; s=iport; t=1493226201; x=1494435801; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wNSpI4oN53RWzaGxIlgHykbQzc6Nbw4l93Y9o7XhAUw=; b=QrNU/IpC6Fc1N2kf+ttIWXaaA4My/1PBEfJQMEi/tGCrJLf3w6dBNs01 ey6sRALO4ZoG/44ceFV+phvjRGh3rDdGxZMbxuAlSUoVs6L5TORFXTYK2 VeljYQU6oNTd2UE3BgpBkZAXD7DKYl2BQnxkcIztLABt7mY51i/igbJwq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAQD+0QBZ/40NJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5ngW0Hg2GKFpFKiCGIE4U3gg+GJAIahBA/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAyNWEAIBCBEDAQIoAwICAh8RFAkIAgQBDQWKAwMVqkyCJiuHDQ2DX?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBAR2IMoMaglOBeDSCZoJfBZ0TOwGOP4RLkV6?= =?us-ascii?q?LGYkNAR84gQdlFYVmgUp1hjmBL4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208,217";a="237959236" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Apr 2017 17:03:10 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3QH3Axb003011 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 17:03:10 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 13:03:09 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 26 Apr 2017 13:03:09 -0400 From: "Acee Lindem (acee)" To: Adam Roach , Eric Rescorla CC: The IESG , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvgrQg2iqyhFsfkS24vnExw0B6KHWqNaAgAE0WgOAAASrgA== Date: Wed, 26 Apr 2017 17:03:09 +0000 Message-ID: References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> <21bc8763-1620-730e-35e3-cb0bc7995d57@nostrum.com> <68915b31-90c1-db0a-1fcf-655dc5854da2@nostrum.com> In-Reply-To: <68915b31-90c1-db0a-1fcf-655dc5854da2@nostrum.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.116.152.197] Content-Type: multipart/alternative; boundary="_000_D5264A6DAB789aceeciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:03:24 -0000 --_000_D5264A6DAB789aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb208bWFpbHRvOmFkYW1Abm9zdHJ1 bS5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBBcHJpbCAyNiwgMjAxNyBhdCAxMjo0NiBQTQ0KVG86 IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4NCkNjOiBB Y2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4sIFRoZSBJ RVNHIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPj4sIEplZmYgVGFudHN1cmEg PGplZmZ0YW50LmlldGZAZ21haWwuY29tPG1haWx0bzpqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4+ LCAicnRnd2ctY2hhaXJzQGlldGYub3JnPG1haWx0bzpydGd3Zy1jaGFpcnNAaWV0Zi5vcmc+IiA8 cnRnd2ctY2hhaXJzQGlldGYub3JnPG1haWx0bzpydGd3Zy1jaGFpcnNAaWV0Zi5vcmc+PiwgImRy YWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW5AaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYt cnRnd2cteWFuZy1rZXktY2hhaW5AaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtl eS1jaGFpbkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbkBp ZXRmLm9yZz4+LCBSb3V0aW5nIFdHIDxydGd3Z0BpZXRmLm9yZzxtYWlsdG86cnRnd2dAaWV0Zi5v cmc+Pg0KU3ViamVjdDogUmU6IEFkYW0gUm9hY2gncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0 Zi1ydGd3Zy15YW5nLWtleS1jaGFpbi0yMDogKHdpdGggQ09NTUVOVCkNCg0KT24gNC8yNS8xNyAx ODoyOSwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCg0KDQpPbiBUdWUsIEFwciAyNSwgMjAxNyBhdCAz OjUxIFBNLCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPG1haWx0bzphZGFtQG5vc3RydW0u Y29tPj4gd3JvdGU6DQoNCg0KDQotIFNlY3Rpb24gNSBhbHNvIHN1Z2dlc3RzIGtleXMgYmUgZW5j cnlwdGVkIG9yIG9iZnVzY2F0ZWQgb24gdGhlIGRldmljZQ0KdGhhdCBpcyB0byB1c2UgdGhlbSwg cHJlc3VtYWJseSBpbiBhIHdheSB0aGF0IGNhbiBiZSBkZWNyeXB0ZWQgb3INCnVub2JmdXNjYXRl ZCB1c2luZyBpbmZvcm1hdGlvbiBhbHNvIG9uIHRoZSBkZXZpY2UuIEkgZG9uJ3Qga25vdyB3aGF0 IHRoZQ0KY3VycmVudCBzZWN1cml0eSBhcmVhIHRoaW5raW5nIGFyb3VuZCB0aGlzIGlzLCBidXQg Z2l2ZW4gdGhhdCB0aGUNCmluZm9ybWF0aW9uIG5lZWRlZCB0byByZXRyaWV2ZSBwbGFpbnRleHQg a2V5cyBpcyBuZWNlc3NhcmlseSBwcmVzZW50IG9uDQp0aGUgZGV2aWNlLCB0aGlzIHNlZW1zIGxp a2UgYSBmaWctbGVhZiB0aGF0IHByb3ZpZGVzIGFuIGlsbHVzaW9uIG9mDQpzZWN1cml0eSB3aXRo b3V0IHByb3ZpZGluZyBhbnkgcmVhbCBiZW5lZml0LiBUaGF0IG1pcy1pbXByZXNzaW9uIHNlZW1z DQpwb3RlbnRpYWxseSBoYXJtZnVsLg0KSSBvbmx5IGFkZGVkIHRoaXMgYXQgdGhlIGJlaGVzdCBv ZiBvbmUgb2YgdGhlIG90aGVyIHJldmlld3MuIFRoZSBwcm9ibGVtDQp3aXRoIHNlY3VyaXR5IGlz IHRoYXQgdGhlcmUgY29uZmxpY3Rpbmcgb3BpbmlvbnMsIGFuZCBhcyB0aGUgYWRhZ2UgZ29lcw0K 4oCcZXZlcnlib2R54oCZcyBnb3Qgb25lLuKAnSBJ4oCZbGwgZGVmZXIgdG8gdGhlIFNlY3VyaXR5 IEFEcy4NCg0KUmlnaHQ7IHRoYXQncyB3aGF0IEkgbWVhbnQgYnkgIkkgZG9uJ3Qga25vdyB3aGF0 IHRoZSBjdXJyZW50IHNlY3VyaXR5IGFyZWEgdGhpbmtpbmcgYXJvdW5kIHRoaXMgaXMuIiBJJ2Qg YmUgY3VyaW91cyB0byBoYXZlIEVLUiBvciBLYXRobGVlbiB3ZWlnaCBpbg0KDQpXaGF0IEkgdG9v ayBob21lIGhlcmUgd2FzIHRoYXQgeW91IHdvdWxkIGVuY3J5cHQgdGhlbSBhbmQgZGlzcGxheSB0 aGUgZW5jcnlwdGVkDQp2ZXJzaW9uIGluc3RlYWQgb2Ygc2hvd2luZyBhc3Rlcmlza3MuIElzIHRo YXQgbm90IHdoYXQgdGhlIHRoaW5raW5nIHdhcz8NCg0KQnkgbXkgcmVhZGluZywgdGhpcyBpcyBq dXN0IHRhbGtpbmcgYWJvdXQgZW5jcnlwdGluZyAib24gdGhlIGRpc2siIHN0b3JhZ2Ugb24gdGhl IGRldmljZS4gQW55IHByb2Nlc3NlcyBpbnZvbHZlZCBpbiBwcm92aXNpb25pbmcgdGhlIHZhbHVl cyBvciB1c2luZyB0aGVtIHRvIHByb2Nlc3MgdHJhZmZpYyB3b3VsZCBoYXZlIGFjY2VzcyB0byB0 aGUgcGxhaW50ZXh0LCBwcmVzdW1hYmx5IGJ5IHJlYWRpbmcgdGhlIGVuY3J5cHRlZCBmb3JtIG9m ZiBkaXNrLCByZWFkaW5nIHNvbWUga2V5aW5nIG1hdGVyaWFsIG9mZiBkaXNrLCBhbmQgY29tYmlu aW5nIHRoZW0gdG8gcmV0cmlldmUgdGhlIHBsYWludGV4dCBrZXkuDQoNClRoaXMgaXMgdGhlIGNv cnJlY3QgaW50ZXJwcmV0YXRpb24uDQoNCg0KTXkgY29uY2VybiBpczogaWYgdGhlc2UgcHJvY2Vz cyBjYW4gZXh0cmFjdCB0aGUgcGxhaW50ZXh0IGtleSBmcm9tIGluZm9ybWF0aW9uIHN0b3JlZCBv biB0aGUgZGlzaywgdGhlbiBzbyBjYW4gb3RoZXIgcHJvY2Vzc2VzIG9uIHRoZSBzYW1lIGRldmlj ZS4gRW5jcnlwdGlvbiBpbiB0aGlzIGNhc2Ugc2VlbXMgdG8gcHJvdmlkZSB0aGUgbWVyZSBpbGx1 c2lvbiBvZiBzZWN1cml0eSAtLSBha2luIHRvIGluc3RhbGxpbmcgYW4gZGVhZGJvbHQga2V5aG9s ZSBvbiBhIGRvb3IgdGhhdCBoYXMgbm8gYWN0dWFsIGJvbHQgYXR0YWNoZWQuDQoNCkkgZG9u4oCZ dCBzZWUgYW55IHdheSBhcm91bmQgdGhpcyBpZiB5b3Ugd2FudCB0byB1c2UgdGhlIGtleXMuDQoN ClRoYW5rcywNCkFjZWUNCg0KDQovYQ0K --_000_D5264A6DAB789aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxp Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QWRhbSBSb2FjaCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFkYW1Abm9zdHJ1bS5jb20iPmFkYW1Abm9zdHJ1bS5jb208L2E+Jmd0Ozxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBBcHJpbCAy NiwgMjAxNyBhdCAxMjo0NiBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzogPC9zcGFuPkVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20i PmVrckBydGZtLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkNjOiA8L3NwYW4+QWNlZSBMaW5kZW0gJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNv bSI+YWNlZUBjaXNjby5jb208L2E+Jmd0OywgVGhlIElFU0cgJmx0OzxhIGhyZWY9Im1haWx0bzpp ZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3JnPC9hPiZndDssIEplZmYgVGFudHN1cmEgJmx0Ozxh IGhyZWY9Im1haWx0bzpqZWZmdGFudC5pZXRmQGdtYWlsLmNvbSI+amVmZnRhbnQuaWV0ZkBnbWFp bC5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnLWNoYWlyc0BpZXRmLm9y ZyI+cnRnd2ctY2hhaXJzQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86 cnRnd2ctY2hhaXJzQGlldGYub3JnIj5ydGd3Zy1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW5AaWV0Zi5v cmciPmRyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW5AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbkBpZXRmLm9y ZyI+ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbkBpZXRmLm9yZzwvYT4mZ3Q7LA0KIFJv dXRpbmcgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+cnRnd2dAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8 L3NwYW4+UmU6IEFkYW0gUm9hY2gncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1ydGd3Zy15 YW5nLWtleS1jaGFpbi0yMDogKHdpdGggQ09NTUVOVCk8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9U RSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsg TUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNG RkZGRkYiPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiA0LzI1LzE3IDE4OjI5LCBF cmljIFJlc2NvcmxhIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2l0ZT0ibWlkOkNBQmNaZUJQYTJKNzgydFNMN1gxd25lOFA4VGhoMm1QbURtNmN2cDdNX0FyU2hz dG5mUUBtYWlsLmdtYWlsLmNvbSI+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwgQXByIDI1 LCAyMDE3IGF0IDM6NTEgUE0sIEFkYW0gUm9hY2ggPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhy ZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29tIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIj5hZGFtQG5vc3RydW0uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxi cj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMA0K ICAgICAgICAgICAgICAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPg0KPHNwYW4gY2xhc3M9IiI+PGJyPg0KPGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwDQogICAgICAgICAgICAgICAgICAuOGV4O2Jv cmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwDQogICAgICAgICAgICAgICAg ICAgIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQot IFNlY3Rpb24gNSBhbHNvIHN1Z2dlc3RzIGtleXMgYmUgZW5jcnlwdGVkIG9yIG9iZnVzY2F0ZWQg b24gdGhlIGRldmljZTxicj4NCnRoYXQgaXMgdG8gdXNlIHRoZW0sIHByZXN1bWFibHkgaW4gYSB3 YXkgdGhhdCBjYW4gYmUgZGVjcnlwdGVkIG9yPGJyPg0KdW5vYmZ1c2NhdGVkIHVzaW5nIGluZm9y bWF0aW9uIGFsc28gb24gdGhlIGRldmljZS4gSSBkb24ndCBrbm93IHdoYXQgdGhlPGJyPg0KY3Vy cmVudCBzZWN1cml0eSBhcmVhIHRoaW5raW5nIGFyb3VuZCB0aGlzIGlzLCBidXQgZ2l2ZW4gdGhh dCB0aGU8YnI+DQppbmZvcm1hdGlvbiBuZWVkZWQgdG8gcmV0cmlldmUgcGxhaW50ZXh0IGtleXMg aXMgbmVjZXNzYXJpbHkgcHJlc2VudCBvbjxicj4NCnRoZSBkZXZpY2UsIHRoaXMgc2VlbXMgbGlr ZSBhIGZpZy1sZWFmIHRoYXQgcHJvdmlkZXMgYW4gaWxsdXNpb24gb2Y8YnI+DQpzZWN1cml0eSB3 aXRob3V0IHByb3ZpZGluZyBhbnkgcmVhbCBiZW5lZml0LiBUaGF0IG1pcy1pbXByZXNzaW9uIHNl ZW1zPGJyPg0KcG90ZW50aWFsbHkgaGFybWZ1bC48YnI+DQo8L2Jsb2NrcXVvdGU+DQpJIG9ubHkg YWRkZWQgdGhpcyBhdCB0aGUgYmVoZXN0IG9mIG9uZSBvZiB0aGUgb3RoZXIgcmV2aWV3cy4gVGhl IHByb2JsZW08YnI+DQp3aXRoIHNlY3VyaXR5IGlzIHRoYXQgdGhlcmUgY29uZmxpY3Rpbmcgb3Bp bmlvbnMsIGFuZCBhcyB0aGUgYWRhZ2UgZ29lczxicj4NCuKAnGV2ZXJ5Ym9keeKAmXMgZ290IG9u ZS7igJ0gSeKAmWxsIGRlZmVyIHRvIHRoZSBTZWN1cml0eSBBRHMuPGJyPg0KPC9ibG9ja3F1b3Rl Pg0KPGJyPg0KPC9zcGFuPlJpZ2h0OyB0aGF0J3Mgd2hhdCBJIG1lYW50IGJ5ICZxdW90O0kgZG9u J3Qga25vdyB3aGF0IHRoZSBjdXJyZW50IHNlY3VyaXR5IGFyZWEgdGhpbmtpbmcgYXJvdW5kIHRo aXMgaXMuJnF1b3Q7IEknZCBiZSBjdXJpb3VzIHRvIGhhdmUgRUtSIG9yIEthdGhsZWVuIHdlaWdo IGluPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2hhdCBJIHRvb2sgaG9t ZSBoZXJlIHdhcyB0aGF0IHlvdSB3b3VsZCBlbmNyeXB0IHRoZW0gYW5kIGRpc3BsYXkgdGhlIGVu Y3J5cHRlZDwvZGl2Pg0KPGRpdj52ZXJzaW9uIGluc3RlYWQgb2Ygc2hvd2luZyBhc3Rlcmlza3Mu IElzIHRoYXQgbm90IHdoYXQgdGhlIHRoaW5raW5nIHdhcz88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCkJ5IG15IHJlYWRpbmcsIHRoaXMgaXMganVz dCB0YWxraW5nIGFib3V0IGVuY3J5cHRpbmcgJnF1b3Q7b24gdGhlIGRpc2smcXVvdDsgc3RvcmFn ZSBvbiB0aGUgZGV2aWNlLiBBbnkgcHJvY2Vzc2VzIGludm9sdmVkIGluIHByb3Zpc2lvbmluZyB0 aGUgdmFsdWVzIG9yIHVzaW5nIHRoZW0gdG8gcHJvY2VzcyB0cmFmZmljIHdvdWxkIGhhdmUgYWNj ZXNzIHRvIHRoZSBwbGFpbnRleHQsIHByZXN1bWFibHkgYnkgcmVhZGluZyB0aGUgZW5jcnlwdGVk IGZvcm0gb2ZmIGRpc2ssDQogcmVhZGluZyBzb21lIGtleWluZyBtYXRlcmlhbCBvZmYgZGlzaywg YW5kIGNvbWJpbmluZyB0aGVtIHRvIHJldHJpZXZlIHRoZSBwbGFpbnRleHQga2V5LjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5U aGlzIGlzIHRoZSBjb3JyZWN0IGludGVycHJldGF0aW9uLiZuYnNwOzwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRS SUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsg UEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgdGV4dD0iIzAw MDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiI+PGJyPg0KPGJyPg0KTXkgY29uY2VybiBpczogaWYgdGhl c2UgcHJvY2VzcyBjYW4gZXh0cmFjdCB0aGUgcGxhaW50ZXh0IGtleSBmcm9tIGluZm9ybWF0aW9u IHN0b3JlZCBvbiB0aGUgZGlzaywgdGhlbiBzbyBjYW4gb3RoZXIgcHJvY2Vzc2VzIG9uIHRoZSBz YW1lIGRldmljZS4gRW5jcnlwdGlvbiBpbiB0aGlzIGNhc2Ugc2VlbXMgdG8gcHJvdmlkZSB0aGUg bWVyZSBpbGx1c2lvbiBvZiBzZWN1cml0eSAtLSBha2luIHRvIGluc3RhbGxpbmcgYW4gZGVhZGJv bHQga2V5aG9sZQ0KIG9uIGEgZG9vciB0aGF0IGhhcyBubyBhY3R1YWwgYm9sdCBhdHRhY2hlZC48 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+SSBkb27igJl0IHNlZSBhbnkgd2F5IGFyb3VuZCB0aGlzIGlmIHlvdSB3YW50IHRvIHVz ZSB0aGUga2V5cy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8 L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF IiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBN QVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZG RkZGRiI+PGJyPg0KPGJyPg0KL2E8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D5264A6DAB789aceeciscocom_-- From nobody Wed Apr 26 10:05:15 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62722126DDF; Wed, 26 Apr 2017 10:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=EVawIT4w; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RPzXeEoc 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 bWJoKNs0L2fw; Wed, 26 Apr 2017 10:05:06 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF1E131518; Wed, 26 Apr 2017 10:05:06 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7755B21C0A; Wed, 26 Apr 2017 13:05:05 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 26 Apr 2017 13:05:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=oLGgU71r95Kza0LlJu 3POH2BBPeWbooEa6BjOMSvKSo=; b=EVawIT4w8Z6Qgp/eozreuuoDZuy2+t0Q0b CsMotjaZR9F2hbDbgMd0JAkeq8VNN4V0/q38t6oqkwy13GrBPR1lEl3Mn5x2no41 1IsIE56CnOkpzjmcDd2awZm3/Tk/0Xu8ro5JTSFIb748DaVRT1zhnJsatu1HFT5E c5t/eMfb6wF+yVuc+Hxdz6Nif9kk4WwQqeMGdfJr9PKdRojobXWSKyoCBhx7Hi84 trTlh7IARRItVuKNEw6p5o/J8Ee6MmTaE7DGEZhOVUhMUt1XWaH9sGloS67jGPhi 0E0uw5V8dujI+jlSfmWdjPqElYuS1vdiCLCkpqFXxUaS8h6HgFKg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=oLGgU71r95Kza0LlJu3POH2BBPeWbooEa6BjOMSvKSo=; b=RPzXeEoc KwOZFbQTqaqmFMGHGKgMnqb0mxHBdwv+7huMonJaHUuo0MbMRhEw7uS/T+8xdsY9 MMReU9PWGCIcdJ1WhfB2d16T9W1YTaUa3p2dWII2HUiVBQkg0NjesOtfNXBio3gQ zXKMzHhV374W4Aje2z+A0P58N6LuOvndRqmX0o18AhI8DciaRfFuv/STQdmbhagv HT2OM3tFgdk7ffhnQ8J9yUJYb1qesaWuQSNyMisc17pHWUtR1LyfXQeuoDQBJ2Ei BATGExUW8j5LkCvssKdh8C+mDH9TeSDyR4PKV5TwvBDKtIPoi0HGlL0DXLH/jmGG U6+9791aEaA/CQ== X-ME-Sender: X-Sasl-enc: Cs8pMiCu2xNUHMGqA9UZ/JI8Enkfh8ZH1VIkBpP6Xyob 1493226305 Received: from [10.24.116.101] (unknown [128.107.241.169]) by mail.messagingengine.com (Postfix) with ESMTPA id 68A0C7E0A4; Wed, 26 Apr 2017 13:05:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-yang-key-chain-17 From: Alissa Cooper In-Reply-To: <149158793224.11224.1489071223626497682@ietfa.amsl.com> Date: Wed, 26 Apr 2017 13:05:03 -0400 Cc: gen-art@ietf.org, draft-ietf-rtgwg-yang-key-chain.all@ietf.org, rtgwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <60BA3230-F2EF-4DDB-B9F0-694DBD674762@cooperw.in> References: <149158793224.11224.1489071223626497682@ietfa.amsl.com> To: Matthew Miller X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:05:08 -0000 Matt, thanks for your review. Authors, thanks for your engagement with = Matt. I have ballotted no-objection. Alissa > On Apr 7, 2017, at 1:58 PM, Matthew Miller = wrote: >=20 > Reviewer: Matthew Miller > Review result: Almost Ready >=20 > 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. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-rtgwg-yang-key-chain-17 > Reviewer: Matthew A. Miller > Review Date: 2017-04-07 > IETF LC End Date: 2017-04-07 > IESG Telechat date: 2017-04-13 >=20 > Summary: >=20 > This document is almost ready to be published as a Proposed Standard, > once the issues noted herein are resolved. >=20 > Major issues: >=20 > NONE >=20 > Minor issues: >=20 > * Forgive me for my limited knowledge of YANG, but is there a reason > key-strings are only representable as either a YANG string or > hex-string type, and not the YANG binary type? >=20 > * This document does not provide much guidance around AES key wrap > other than it can be used and the KEK is provided > out-of-band/-context. > For instance, AES key-wrapped key-strings probably require using > "hexidecimal-string". Also, assuming I'm reading the model > correctly, > it appears this feature applies to the whole chain, which I think is > worth calling out. >=20 > * This document warns against using the "clear-text" algorithm, which > the > reader is lead to understand is for legacy implementation reasons. > However, is there not a similar concern with cryptographically weak > algorithms, such as md5 and (arguably) sha1? >=20 > Nits/editorial comments: >=20 > * In Section 3.2. "Key Chain Model Features", the word "of" is > missing > between "configuration" and "an" in the phrase "support configuration > an > acceptance tolerance". >=20 > Non-nits: >=20 > * I note that idnits is calling out some odd spacing issues, but I > think > they are safe to ignore. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Apr 26 10:12:11 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D71A12EE44; Wed, 26 Apr 2017 10:12:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: draft-ietf-rtgwg-yang-key-chain.all@ietf.org, ietf@ietf.org, rtgwg@ietf.org Subject: Genart telechat review of draft-ietf-rtgwg-yang-key-chain-20 X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149322673002.13018.17056147061701748095@ietfa.amsl.com> Date: Wed, 26 Apr 2017 10:12:10 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:12:10 -0000 Reviewer: Matthew Miller Review result: Ready 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-rtgwg-yang-key-chain-?? Reviewer: Matthew Miller Review Date: 2017-04-26 IETF LC End Date: 2017-04-07 IESG Telechat date: 2017-04-27 Summary: This document is ready to be published as Proposed Standard. This version (-20) addresses all concerns raised in the review of a previous version (-17). Major issues: NONE Minor issues: NONE Nits/editorial comments: NONE From nobody Wed Apr 26 10:51:19 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171A3131551 for ; Wed, 26 Apr 2017 10:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eozXfhNgIJJi for ; Wed, 26 Apr 2017 10:51:15 -0700 (PDT) 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 9664C131529 for ; Wed, 26 Apr 2017 10:51:12 -0700 (PDT) Received: from Orochi.local (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 v3QHp75P063618 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 12:51:08 -0500 (CDT) (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 Orochi.local Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) To: "Acee Lindem (acee)" , Eric Rescorla Cc: The IESG , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> <21bc8763-1620-730e-35e3-cb0bc7995d57@nostrum.com> <68915b31-90c1-db0a-1fcf-655dc5854da2@nostrum.com> From: Adam Roach Message-ID: <9335f62b-d906-c35c-f50b-56fd086e2e02@nostrum.com> Date: Wed, 26 Apr 2017 12:51:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F0929A5AABA1A06CF57C00F2" Content-Language: en-US Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:51:17 -0000 This is a multi-part message in MIME format. --------------F0929A5AABA1A06CF57C00F2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/26/17 12:03, Acee Lindem (acee) wrote: > > > From: Adam Roach > > Date: Wednesday, April 26, 2017 at 12:46 PM > To: Eric Rescorla > > Cc: Acee Lindem >, The IESG > >, Jeff Tantsura > >, > "rtgwg-chairs@ietf.org " > >, > "draft-ietf-rtgwg-yang-key-chain@ietf.org > " > >, Routing WG > > > Subject: Re: Adam Roach's No Objection on > draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) > > On 4/25/17 18:29, Eric Rescorla wrote: >> >> >> On Tue, Apr 25, 2017 at 3:51 PM, Adam Roach > > wrote: >> >> >> >> - Section 5 also suggests keys be encrypted or >> obfuscated on the device >> that is to use them, presumably in a way that can be >> decrypted or >> unobfuscated using information also on the device. I >> don't know what the >> current security area thinking around this is, but >> given that the >> information needed to retrieve plaintext keys is >> necessarily present on >> the device, this seems like a fig-leaf that provides >> an illusion of >> security without providing any real benefit. That >> mis-impression seems >> potentially harmful. >> >> I only added this at the behest of one of the other >> reviews. The problem >> with security is that there conflicting opinions, and as >> the adage goes >> “everybody’s got one.” I’ll defer to the Security ADs. >> >> >> Right; that's what I meant by "I don't know what the current >> security area thinking around this is." I'd be curious to >> have EKR or Kathleen weigh in >> >> >> What I took home here was that you would encrypt them and display >> the encrypted >> version instead of showing asterisks. Is that not what the >> thinking was? > > By my reading, this is just talking about encrypting "on the disk" > storage on the device. Any processes involved in provisioning the > values or using them to process traffic would have access to the > plaintext, presumably by reading the encrypted form off disk, > reading some keying material off disk, and combining them to > retrieve the plaintext key. > > > This is the correct interpretation. > > > > My concern is: if these process can extract the plaintext key from > information stored on the disk, then so can other processes on the > same device. Encryption in this case seems to provide the mere > illusion of security -- akin to installing an deadbolt keyhole on > a door that has no actual bolt attached. > > > I don’t see any way around this if you want to use the keys. So don't encrypt the keys on disk. To use the analogy I set up above -- it's better for people to *know* that there's no deadbolt than to mistakenly think that there is one: it leads them to take an appropriate level of precaution. /a --------------F0929A5AABA1A06CF57C00F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/26/17 12:03, Acee Lindem (acee) wrote:


From: Adam Roach <adam@nostrum.com>
Date: Wednesday, April 26, 2017 at 12:46 PM
To: Eric Rescorla <ekr@rtfm.com>
Cc: Acee Lindem <acee@cisco.com>, The IESG <iesg@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "draft-ietf-rtgwg-yang-key-chain@ietf.org" <draft-ietf-rtgwg-yang-key-chain@ietf.org>, Routing WG <rtgwg@ietf.org>
Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT)

On 4/25/17 18:29, Eric Rescorla wrote:


On Tue, Apr 25, 2017 at 3:51 PM, Adam Roach <adam@nostrum.com> wrote:



- Section 5 also suggests keys be encrypted or obfuscated on the device
that is to use them, presumably in a way that can be decrypted or
unobfuscated using information also on the device. I don't know what the
current security area thinking around this is, but given that the
information needed to retrieve plaintext keys is necessarily present on
the device, this seems like a fig-leaf that provides an illusion of
security without providing any real benefit. That mis-impression seems
potentially harmful.
I only added this at the behest of one of the other reviews. The problem
with security is that there conflicting opinions, and as the adage goes
“everybody’s got one.” I’ll defer to the Security ADs.

Right; that's what I meant by "I don't know what the current security area thinking around this is." I'd be curious to have EKR or Kathleen weigh in

What I took home here was that you would encrypt them and display the encrypted
version instead of showing asterisks. Is that not what the thinking was?

By my reading, this is just talking about encrypting "on the disk" storage on the device. Any processes involved in provisioning the values or using them to process traffic would have access to the plaintext, presumably by reading the encrypted form off disk, reading some keying material off disk, and combining them to retrieve the plaintext key.

This is the correct interpretation. 


My concern is: if these process can extract the plaintext key from information stored on the disk, then so can other processes on the same device. Encryption in this case seems to provide the mere illusion of security -- akin to installing an deadbolt keyhole on a door that has no actual bolt attached.

I don’t see any way around this if you want to use the keys. 

So don't encrypt the keys on disk. To use the analogy I set up above -- it's better for people to *know* that there's no deadbolt than to mistakenly think that there is one: it leads them to take an appropriate level of precaution.

/a
--------------F0929A5AABA1A06CF57C00F2-- From nobody Wed Apr 26 10:57:51 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9588131529; Wed, 26 Apr 2017 10:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 VSGBogJVsc6D; Wed, 26 Apr 2017 10:57:41 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF985131544; Wed, 26 Apr 2017 10:57:40 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id a188so3567395pfa.0; Wed, 26 Apr 2017 10:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cF3EmutAJs99kdKkIjpmTCjZs3gBNQWmxmPq2f6ZBcE=; b=DuIiC5+vrAHcy5qmazb/FRpmFAxOwfOV7aQd03HLajahaZf/ijw8yfDkKlDvcbZhvY EhVQyrroKaU8wJRmwOsfTGpJU97lFfk58w+To0QjIm/GbYjzh9BXI6tymHcvdamQ56i9 2xc6loGcQcSCSQPjYDKb9s3QDafPDXh5lk2yz0AQOdhrYXEJNCWG2tr149aLOtfGOHkq Rx9/qhw9ZfEDKYQjUtn2r7IVfQdfNmnndJP400r7fI/RjEl7s4JJYiEgNrb853BIy8zh t5/HT8fQM3DDAobmcU/Nbs/Jki8Eh/2oWU/oyKGS2sZg1ocAJVxhrHCDJZgVRIVI5j4g eI4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cF3EmutAJs99kdKkIjpmTCjZs3gBNQWmxmPq2f6ZBcE=; b=af89uv0Qp4Kr9Pbo69RIZqRt5MSap/VQeYMBJ0KKnk26rH2cOoVjqFODvj2D6N80UJ ya4drTXX+l8PV5+S+UhcPVEmeB/Er9nWVMKFcWrMVMv7f10Hmn7ESUztb+lGzw3A/mL+ jig9Soeoo42u7loAx0yxt/8h9ligwV2s8eiuA2OEv7b85gqM3b6SNPUjlE4EbYsHKSPx A5Ubh/itqB0BVTrETBQWWN+WaX+TpnW1nvf1FP2ywBlM2VwXCwz2khBKVjELfHnv1gFS vAF3NCpYH6MsP2i6xQtWPSmgIA7stR7JlvJKFf1dTgPCpxR2gvthnMy3a057Vr7KfBsu Eyfw== X-Gm-Message-State: AN3rC/5WZfTUPSEur7OH7wq9Nw0GxuW8aDe07zFEv2rpeXeCCTnxPvcr zawVHBdzW6g6vM36FXpHaGL8BvW0IA== X-Received: by 10.99.126.13 with SMTP id z13mr1092665pgc.158.1493229460521; Wed, 26 Apr 2017 10:57:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 10:57:00 -0700 (PDT) In-Reply-To: <9335f62b-d906-c35c-f50b-56fd086e2e02@nostrum.com> References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> <21bc8763-1620-730e-35e3-cb0bc7995d57@nostrum.com> <68915b31-90c1-db0a-1fcf-655dc5854da2@nostrum.com> <9335f62b-d906-c35c-f50b-56fd086e2e02@nostrum.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 13:57:00 -0400 Message-ID: Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) To: Adam Roach Cc: "Acee Lindem (acee)" , Eric Rescorla , Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:57:43 -0000 On Wed, Apr 26, 2017 at 1:51 PM, Adam Roach wrote: > On 4/26/17 12:03, Acee Lindem (acee) wrote: > > > > From: Adam Roach > Date: Wednesday, April 26, 2017 at 12:46 PM > To: Eric Rescorla > Cc: Acee Lindem , The IESG , Jeff Tantsura > , "rtgwg-chairs@ietf.org" , > "draft-ietf-rtgwg-yang-key-chain@ietf.org" > , Routing WG > Subject: Re: Adam Roach's No Objection on > draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) > > On 4/25/17 18:29, Eric Rescorla wrote: > > > > On Tue, Apr 25, 2017 at 3:51 PM, Adam Roach wrote: > >> >> >>>> - Section 5 also suggests keys be encrypted or obfuscated on the devic= e >>>> that is to use them, presumably in a way that can be decrypted or >>>> unobfuscated using information also on the device. I don't know what t= he >>>> current security area thinking around this is, but given that the >>>> information needed to retrieve plaintext keys is necessarily present o= n >>>> the device, this seems like a fig-leaf that provides an illusion of >>>> security without providing any real benefit. That mis-impression seems >>>> potentially harmful. >>> >>> I only added this at the behest of one of the other reviews. The proble= m >>> with security is that there conflicting opinions, and as the adage goes >>> =E2=80=9Ceverybody=E2=80=99s got one.=E2=80=9D I=E2=80=99ll defer to th= e Security ADs. >> >> >> Right; that's what I meant by "I don't know what the current security ar= ea >> thinking around this is." I'd be curious to have EKR or Kathleen weigh i= n > > > What I took home here was that you would encrypt them and display the > encrypted > version instead of showing asterisks. Is that not what the thinking was? > > > By my reading, this is just talking about encrypting "on the disk" storag= e > on the device. Any processes involved in provisioning the values or using > them to process traffic would have access to the plaintext, presumably by > reading the encrypted form off disk, reading some keying material off dis= k, > and combining them to retrieve the plaintext key. > > > This is the correct interpretation. > > > > My concern is: if these process can extract the plaintext key from > information stored on the disk, then so can other processes on the same > device. Encryption in this case seems to provide the mere illusion of > security -- akin to installing an deadbolt keyhole on a door that has no > actual bolt attached. > > > I don=E2=80=99t see any way around this if you want to use the keys. > > > So don't encrypt the keys on disk. To use the analogy I set up above -- i= t's > better for people to *know* that there's no deadbolt than to mistakenly > think that there is one: it leads them to take an appropriate level of > precaution. Brian pointed out that RFC5649 is used with other YANG modules, so I'm going to poke at the gap a little that Acee mentioned for operators. Thanks. > > /a --=20 Best regards, Kathleen From nobody Wed Apr 26 11:07:16 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F0B13156B; Wed, 26 Apr 2017 11:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qPyGLyge3lT; Wed, 26 Apr 2017 11:07:08 -0700 (PDT) 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 BC5DA13156A; Wed, 26 Apr 2017 11:07:08 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3QI75RB065236 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 13:07:06 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) To: Kathleen Moriarty Cc: "Acee Lindem (acee)" , Eric Rescorla , Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> <21bc8763-1620-730e-35e3-cb0bc7995d57@nostrum.com> <68915b31-90c1-db0a-1fcf-655dc5854da2@nostrum.com> <9335f62b-d906-c35c-f50b-56fd086e2e02@nostrum.com> From: Adam Roach Message-ID: Date: Wed, 26 Apr 2017 13:07:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:07:10 -0000 On 4/26/17 12:57 PM, Kathleen Moriarty wrote: > On Wed, Apr 26, 2017 at 1:51 PM, Adam Roach wrote: >> On 4/26/17 12:03, Acee Lindem (acee) wrote: >> >> >> >> From: Adam Roach >> Date: Wednesday, April 26, 2017 at 12:46 PM >> To: Eric Rescorla >> Cc: Acee Lindem , The IESG , Jeff Tantsura >> , "rtgwg-chairs@ietf.org" , >> "draft-ietf-rtgwg-yang-key-chain@ietf.org" >> , Routing WG >> Subject: Re: Adam Roach's No Objection on >> draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) >> >> On 4/25/17 18:29, Eric Rescorla wrote: >> >> >> >> On Tue, Apr 25, 2017 at 3:51 PM, Adam Roach wrote: >> >>> >>>>> - Section 5 also suggests keys be encrypted or obfuscated on the device >>>>> that is to use them, presumably in a way that can be decrypted or >>>>> unobfuscated using information also on the device. I don't know what the >>>>> current security area thinking around this is, but given that the >>>>> information needed to retrieve plaintext keys is necessarily present on >>>>> the device, this seems like a fig-leaf that provides an illusion of >>>>> security without providing any real benefit. That mis-impression seems >>>>> potentially harmful. >>>> I only added this at the behest of one of the other reviews. The problem >>>> with security is that there conflicting opinions, and as the adage goes >>>> “everybody’s got one.” I’ll defer to the Security ADs. >>> >>> Right; that's what I meant by "I don't know what the current security area >>> thinking around this is." I'd be curious to have EKR or Kathleen weigh in >> >> What I took home here was that you would encrypt them and display the >> encrypted >> version instead of showing asterisks. Is that not what the thinking was? >> >> >> By my reading, this is just talking about encrypting "on the disk" storage >> on the device. Any processes involved in provisioning the values or using >> them to process traffic would have access to the plaintext, presumably by >> reading the encrypted form off disk, reading some keying material off disk, >> and combining them to retrieve the plaintext key. >> >> >> This is the correct interpretation. >> >> >> >> My concern is: if these process can extract the plaintext key from >> information stored on the disk, then so can other processes on the same >> device. Encryption in this case seems to provide the mere illusion of >> security -- akin to installing an deadbolt keyhole on a door that has no >> actual bolt attached. >> >> >> I don’t see any way around this if you want to use the keys. >> >> >> So don't encrypt the keys on disk. To use the analogy I set up above -- it's >> better for people to *know* that there's no deadbolt than to mistakenly >> think that there is one: it leads them to take an appropriate level of >> precaution. > Brian pointed out that RFC5649 is used with other YANG modules, so I'm > going to poke at the gap a little that Acee mentioned for operators. Excellent, thanks! That's a comment for the other thread, though, where the keys are distributed as ciphertext, using KEKs shared between multiple network elements. *This* thread is about is about distributing the keys in plaintext (modulo any transport security applied), and then storing them obfuscated as a matter of local policy, using keys and/or algorithms completely local to the single network element. I would love for you to weigh in on the wisdom of doing so. /a From nobody Wed Apr 26 11:12:17 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CFA131564; Wed, 26 Apr 2017 11:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOCNy68fZR2m; Wed, 26 Apr 2017 11:12:14 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1133D1294C4; Wed, 26 Apr 2017 11:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4730; q=dns/txt; s=iport; t=1493230334; x=1494439934; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2nsvC9Pk8VO99ttfyrX0nyZfhLp8z5gHaAR35TTPFmw=; b=U/IjS038u847MV+PLeWWadDvoXlbrytPrpXOGA/OPU5G2ojdJmaSIKic iJPzx8fEDvJU66/SzcT9Zu0CSH+uHSZnP4uj4GQuuKCfwq3O51st2uPPU 9jFZfN4BpKXLfQlU/K0VX42sakgKsmx5H+dd7VaqffuUa6wWBRE/c4Pj8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlAQDH4QBZ/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1WBbQeDYYoWkUqIIY1Kgg+GJAIahBA/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAyMRRRACAQgRAwECAQICJgICAh8RFQgIAgQBDQWKAwMVqmuCJoc6DYNfA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR+BC4cngg+BC4JTgXiDGoJfAQSdEzsBjj+ES5F?= =?us-ascii?q?eixmJDQEfOIEHZRWFZoFKdQGGOIEvgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208";a="235846313" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2017 18:12:13 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v3QICCtJ010836 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 18:12:13 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 14:12:12 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 26 Apr 2017 14:12:12 -0400 From: "Acee Lindem (acee)" To: Kathleen Moriarty , Adam Roach CC: Eric Rescorla , Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Topic: Adam Roach's No Objection on draft-ietf-rtgwg-yang-key-chain-20: (with COMMENT) Thread-Index: AQHSvgrQg2iqyhFsfkS24vnExw0B6KHWqNaAgAE0WgOAAASrgIAAUHQAgAABqgD//8EoAA== Date: Wed, 26 Apr 2017 18:12:12 +0000 Message-ID: References: <149315566012.17243.14143835720282201285.idtracker@ietfa.amsl.com> <21bc8763-1620-730e-35e3-cb0bc7995d57@nostrum.com> <68915b31-90c1-db0a-1fcf-655dc5854da2@nostrum.com> <9335f62b-d906-c35c-f50b-56fd086e2e02@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <1E5127AFD8201D459AF2511FAE48A499@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:12:16 -0000 DQoNCk9uIDQvMjYvMTcsIDE6NTcgUE0sICJLYXRobGVlbiBNb3JpYXJ0eSINCjxrYXRobGVlbi5t b3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5PbiBXZWQsIEFwciAyNiwgMjAxNyBh dCAxOjUxIFBNLCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPiB3cm90ZToNCj4+IE9uIDQv MjYvMTcgMTI6MDMsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToNCj4+DQo+Pg0KPj4NCj4+IEZy b206IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+DQo+PiBEYXRlOiBXZWRuZXNkYXksIEFw cmlsIDI2LCAyMDE3IGF0IDEyOjQ2IFBNDQo+PiBUbzogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0u Y29tPg0KPj4gQ2M6IEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbT4sIFRoZSBJRVNHIDxpZXNn QGlldGYub3JnPiwgSmVmZg0KPj5UYW50c3VyYQ0KPj4gPGplZmZ0YW50LmlldGZAZ21haWwuY29t PiwgInJ0Z3dnLWNoYWlyc0BpZXRmLm9yZyINCj4+PHJ0Z3dnLWNoYWlyc0BpZXRmLm9yZz4sDQo+ PiAiZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbkBpZXRmLm9yZyINCj4+IDxkcmFmdC1p ZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluQGlldGYub3JnPiwgUm91dGluZyBXRyA8cnRnd2dAaWV0 Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogQWRhbSBSb2FjaCdzIE5vIE9iamVjdGlvbiBvbg0KPj4g ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbi0yMDogKHdpdGggQ09NTUVOVCkNCj4+DQo+ PiBPbiA0LzI1LzE3IDE4OjI5LCBFcmljIFJlc2NvcmxhIHdyb3RlOg0KPj4NCj4+DQo+Pg0KPj4g T24gVHVlLCBBcHIgMjUsIDIwMTcgYXQgMzo1MSBQTSwgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVt LmNvbT4gd3JvdGU6DQo+Pg0KPj4+DQo+Pj4NCj4+Pj4+IC0gU2VjdGlvbiA1IGFsc28gc3VnZ2Vz dHMga2V5cyBiZSBlbmNyeXB0ZWQgb3Igb2JmdXNjYXRlZCBvbiB0aGUNCj4+Pj4+ZGV2aWNlDQo+ Pj4+PiB0aGF0IGlzIHRvIHVzZSB0aGVtLCBwcmVzdW1hYmx5IGluIGEgd2F5IHRoYXQgY2FuIGJl IGRlY3J5cHRlZCBvcg0KPj4+Pj4gdW5vYmZ1c2NhdGVkIHVzaW5nIGluZm9ybWF0aW9uIGFsc28g b24gdGhlIGRldmljZS4gSSBkb24ndCBrbm93IHdoYXQNCj4+Pj4+dGhlDQo+Pj4+PiBjdXJyZW50 IHNlY3VyaXR5IGFyZWEgdGhpbmtpbmcgYXJvdW5kIHRoaXMgaXMsIGJ1dCBnaXZlbiB0aGF0IHRo ZQ0KPj4+Pj4gaW5mb3JtYXRpb24gbmVlZGVkIHRvIHJldHJpZXZlIHBsYWludGV4dCBrZXlzIGlz IG5lY2Vzc2FyaWx5IHByZXNlbnQNCj4+Pj4+b24NCj4+Pj4+IHRoZSBkZXZpY2UsIHRoaXMgc2Vl bXMgbGlrZSBhIGZpZy1sZWFmIHRoYXQgcHJvdmlkZXMgYW4gaWxsdXNpb24gb2YNCj4+Pj4+IHNl Y3VyaXR5IHdpdGhvdXQgcHJvdmlkaW5nIGFueSByZWFsIGJlbmVmaXQuIFRoYXQgbWlzLWltcHJl c3Npb24NCj4+Pj4+c2VlbXMNCj4+Pj4+IHBvdGVudGlhbGx5IGhhcm1mdWwuDQo+Pj4+DQo+Pj4+ IEkgb25seSBhZGRlZCB0aGlzIGF0IHRoZSBiZWhlc3Qgb2Ygb25lIG9mIHRoZSBvdGhlciByZXZp ZXdzLiBUaGUNCj4+Pj5wcm9ibGVtDQo+Pj4+IHdpdGggc2VjdXJpdHkgaXMgdGhhdCB0aGVyZSBj b25mbGljdGluZyBvcGluaW9ucywgYW5kIGFzIHRoZSBhZGFnZQ0KPj4+PmdvZXMNCj4+Pj4g4oCc ZXZlcnlib2R54oCZcyBnb3Qgb25lLuKAnSBJ4oCZbGwgZGVmZXIgdG8gdGhlIFNlY3VyaXR5IEFE cy4NCj4+Pg0KPj4+DQo+Pj4gUmlnaHQ7IHRoYXQncyB3aGF0IEkgbWVhbnQgYnkgIkkgZG9uJ3Qg a25vdyB3aGF0IHRoZSBjdXJyZW50IHNlY3VyaXR5DQo+Pj5hcmVhDQo+Pj4gdGhpbmtpbmcgYXJv dW5kIHRoaXMgaXMuIiBJJ2QgYmUgY3VyaW91cyB0byBoYXZlIEVLUiBvciBLYXRobGVlbiB3ZWln aA0KPj4+aW4NCj4+DQo+Pg0KPj4gV2hhdCBJIHRvb2sgaG9tZSBoZXJlIHdhcyB0aGF0IHlvdSB3 b3VsZCBlbmNyeXB0IHRoZW0gYW5kIGRpc3BsYXkgdGhlDQo+PiBlbmNyeXB0ZWQNCj4+IHZlcnNp b24gaW5zdGVhZCBvZiBzaG93aW5nIGFzdGVyaXNrcy4gSXMgdGhhdCBub3Qgd2hhdCB0aGUgdGhp bmtpbmcgd2FzPw0KPj4NCj4+DQo+PiBCeSBteSByZWFkaW5nLCB0aGlzIGlzIGp1c3QgdGFsa2lu ZyBhYm91dCBlbmNyeXB0aW5nICJvbiB0aGUgZGlzayINCj4+c3RvcmFnZQ0KPj4gb24gdGhlIGRl dmljZS4gQW55IHByb2Nlc3NlcyBpbnZvbHZlZCBpbiBwcm92aXNpb25pbmcgdGhlIHZhbHVlcyBv cg0KPj51c2luZw0KPj4gdGhlbSB0byBwcm9jZXNzIHRyYWZmaWMgd291bGQgaGF2ZSBhY2Nlc3Mg dG8gdGhlIHBsYWludGV4dCwgcHJlc3VtYWJseQ0KPj5ieQ0KPj4gcmVhZGluZyB0aGUgZW5jcnlw dGVkIGZvcm0gb2ZmIGRpc2ssIHJlYWRpbmcgc29tZSBrZXlpbmcgbWF0ZXJpYWwgb2ZmDQo+PmRp c2ssDQo+PiBhbmQgY29tYmluaW5nIHRoZW0gdG8gcmV0cmlldmUgdGhlIHBsYWludGV4dCBrZXku DQo+Pg0KPj4NCj4+IFRoaXMgaXMgdGhlIGNvcnJlY3QgaW50ZXJwcmV0YXRpb24uDQo+Pg0KPj4N Cj4+DQo+PiBNeSBjb25jZXJuIGlzOiBpZiB0aGVzZSBwcm9jZXNzIGNhbiBleHRyYWN0IHRoZSBw bGFpbnRleHQga2V5IGZyb20NCj4+IGluZm9ybWF0aW9uIHN0b3JlZCBvbiB0aGUgZGlzaywgdGhl biBzbyBjYW4gb3RoZXIgcHJvY2Vzc2VzIG9uIHRoZSBzYW1lDQo+PiBkZXZpY2UuIEVuY3J5cHRp b24gaW4gdGhpcyBjYXNlIHNlZW1zIHRvIHByb3ZpZGUgdGhlIG1lcmUgaWxsdXNpb24gb2YNCj4+ IHNlY3VyaXR5IC0tIGFraW4gdG8gaW5zdGFsbGluZyBhbiBkZWFkYm9sdCBrZXlob2xlIG9uIGEg ZG9vciB0aGF0IGhhcyBubw0KPj4gYWN0dWFsIGJvbHQgYXR0YWNoZWQuDQo+Pg0KPj4NCj4+IEkg ZG9u4oCZdCBzZWUgYW55IHdheSBhcm91bmQgdGhpcyBpZiB5b3Ugd2FudCB0byB1c2UgdGhlIGtl eXMuDQo+Pg0KPj4NCj4+IFNvIGRvbid0IGVuY3J5cHQgdGhlIGtleXMgb24gZGlzay4gVG8gdXNl IHRoZSBhbmFsb2d5IEkgc2V0IHVwIGFib3ZlIC0tDQo+Pml0J3MNCj4+IGJldHRlciBmb3IgcGVv cGxlIHRvICprbm93KiB0aGF0IHRoZXJlJ3Mgbm8gZGVhZGJvbHQgdGhhbiB0byBtaXN0YWtlbmx5 DQo+PiB0aGluayB0aGF0IHRoZXJlIGlzIG9uZTogaXQgbGVhZHMgdGhlbSB0byB0YWtlIGFuIGFw cHJvcHJpYXRlIGxldmVsIG9mDQo+PiBwcmVjYXV0aW9uLg0KPg0KPkJyaWFuIHBvaW50ZWQgb3V0 IHRoYXQgUkZDNTY0OSBpcyB1c2VkIHdpdGggb3RoZXIgWUFORyBtb2R1bGVzLCBzbyBJJ20NCj5n b2luZyB0byBwb2tlIGF0IHRoZSBnYXAgYSBsaXR0bGUgdGhhdCBBY2VlIG1lbnRpb25lZCBmb3Ig b3BlcmF0b3JzLg0KDQpUaGlzIGlzIG5vdCB0cnVlIGZvciBhbnkgSUVURiBZQU5HIG1vZGVscy4N Cg0KVGhhbmtzLA0KQWNlZQ0KDQoNCj4NCj5UaGFua3MuDQo+Pg0KPj4gL2ENCj4NCj4NCj4NCj4t LSANCj4NCj5CZXN0IHJlZ2FyZHMsDQo+S2F0aGxlZW4NCg0K From nobody Wed Apr 26 11:14:59 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1C4131553; Wed, 26 Apr 2017 11:14:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-yang-key-chain-21.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149323049136.2877.1564158938626407409@ietfa.amsl.com> Date: Wed, 26 Apr 2017 11:14:51 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:14:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Routing Key Chain YANG Data Model Authors : Acee Lindem Yingzhen Qu Derek Yeung Ing-Wher Chen Jeffrey Zhang Filename : draft-ietf-rtgwg-yang-key-chain-21.txt Pages : 23 Date : 2017-04-26 Abstract: This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-21 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-key-chain-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-yang-key-chain-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 26 11:21:41 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940D313156A; Wed, 26 Apr 2017 11:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ8o7ULXTDS6; Wed, 26 Apr 2017 11:21:14 -0700 (PDT) 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 7C217131565; Wed, 26 Apr 2017 11:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3228; q=dns/txt; s=iport; t=1493230874; x=1494440474; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=m5/P/DMR0Th+Mv7O5OyQpCQhFt8e02FwAJMu66PPWxE=; b=itMy+Xui/T21ElUhVpyKmaixcM9djdWEtZAXEJ4yesz48pJYgL21JvZx S7x5fTos0rKS5vUA8cNEEEuzA6pGZBcReH0teMqjkUBk+R8wICsugkaLU Go4YyvN/d8H10rOf9xNNSxnltvZMOgSFJ1b7yorsej4DlEwOJpX7vENru s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlAQDk4wBZ/4YNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VhgQwHg2GKFqc1gg8hDYV2AhqEED8YAQIBAQEBAQEBayiFFgI?= =?us-ascii?q?BAwEBIRE6CxACAQgaAiYCAgIlCxUQAgQOBYobDqpdgiaLJQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2BC4cngxqDIIE/gwaCXwWdTgGHGItyggJVhGKKJZQmAR84gQd?= =?us-ascii?q?lFRoqhmx1h2iBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208";a="413166551" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Apr 2017 18:21:13 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v3QILDbj004692 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 18:21:13 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 14:21:12 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 26 Apr 2017 14:21:12 -0400 From: "Acee Lindem (acee)" To: The IESG CC: "rtgwg@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" Subject: Re: I-D Action: draft-ietf-rtgwg-yang-key-chain-21.txt Thread-Topic: I-D Action: draft-ietf-rtgwg-yang-key-chain-21.txt Thread-Index: AQHSvrkTCVSdAxBcDUe2+T5my3whj6HX9ksA Date: Wed, 26 Apr 2017 18:21:12 +0000 Message-ID: References: <149323049136.2877.1564158938626407409@ietfa.amsl.com> In-Reply-To: <149323049136.2877.1564158938626407409@ietfa.amsl.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.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <60091D3A3FFF4649885C303936945178@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:21:19 -0000 VGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyB0aGUgSUVTRyBjb21tZW50cyByZWNlaXZlZCBoZXJldG9m b3JlLiBUaGUNCmFzZS1rZXktd3JhcCBmZWF0dXJlIGhhcyBiZWVuIHJlbW92ZWQgYW5kIE5BQ00g d2lsbCBiZSBhdmFpbGVkIGZvcg0Ka2V5LXN0cmluZyBzZWN1cml0eSBzaW1pbGFyIHRvIHRoZSBz aGFyZWQtc2VjcmV0IFlBTkcgZGF0YSBub2RlIGluIFJGQw0KNzMxNy4gDQoNClRoYW5rcywNCkFj ZWUNCg0KT24gNC8yNi8xNywgMjoxNCBQTSwgInJ0Z3dnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmciDQo8cnRnd2ctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPmRpcmVjdG9y aWVzLg0KPlRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFJvdXRpbmcgQXJlYSBXb3Jr aW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPg0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogUm91 dGluZyBLZXkgQ2hhaW4gWUFORyBEYXRhIE1vZGVsDQo+ICAgICAgICBBdXRob3JzICAgICAgICAg OiBBY2VlIExpbmRlbQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgWWluZ3poZW4gUXUNCj4g ICAgICAgICAgICAgICAgICAgICAgICAgIERlcmVrIFlldW5nDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICBJbmctV2hlciBDaGVuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBKZWZmcmV5 IFpoYW5nDQo+CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hh aW4tMjEudHh0DQo+CVBhZ2VzICAgICAgICAgICA6IDIzDQo+CURhdGUgICAgICAgICAgICA6IDIw MTctMDQtMjYNCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUg a2V5IGNoYWluIFlBTkcgZGF0YSBtb2RlbC4gIEtleSBjaGFpbnMNCj4gICBhcmUgY29tbW9ubHkg dXNlZCBmb3Igcm91dGluZyBwcm90b2NvbCBhdXRoZW50aWNhdGlvbiBhbmQgb3RoZXINCj4gICBh cHBsaWNhdGlvbnMgcmVxdWlyaW5nIHN5bW1ldHJpYyBrZXlzLiAgQSBrZXkgY2hhaW4gaXMgYSBs aXN0IG9mDQo+ICAgZWxlbWVudHMgZWFjaCBjb250YWluaW5nIGEga2V5IHN0cmluZywgc2VuZCBs aWZldGltZSwgYWNjZXB0DQo+ICAgbGlmZXRpbWUsIGFuZCBhbGdvcml0aG0gKGF1dGhlbnRpY2F0 aW9uIG9yIGVuY3J5cHRpb24pLiAgQnkgcHJvcGVybHkNCj4gICBvdmVybGFwcGluZyB0aGUgc2Vu ZCBhbmQgYWNjZXB0IGxpZmV0aW1lcyBvZiBtdWx0aXBsZSBrZXkgY2hhaW4NCj4gICBlbGVtZW50 cywga2V5IHN0cmluZ3MgYW5kIGFsZ29yaXRobXMgbWF5IGJlIGdyYWNlZnVsbHkgdXBkYXRlZC4g IEJ5DQo+ICAgcmVwcmVzZW50aW5nIHRoZW0gaW4gYSBZQU5HIGRhdGEgbW9kZWwsIGtleSBkaXN0 cmlidXRpb24gY2FuIGJlDQo+ICAgYXV0b21hdGVkLg0KPg0KPg0KPlRoZSBJRVRGIGRhdGF0cmFj a2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW4vDQo+DQo+VGhlcmUg YXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWluLTIxDQo+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5 LWNoYWluLTIxDQo+DQo+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJ0 Z3dnLXlhbmcta2V5LWNoYWluLTIxDQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uDQo+dW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCj4NCj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnJ0Z3dnIG1h aWxpbmcgbGlzdA0KPnJ0Z3dnQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGd3Zw0KDQo= From nobody Wed Apr 26 11:42:20 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBB813159D; Wed, 26 Apr 2017 11:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLCeEOeP2WDE; Wed, 26 Apr 2017 11:42:17 -0700 (PDT) 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 F06BB13159C; Wed, 26 Apr 2017 11:42:16 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3QIgEfw068777 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 13:42:15 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Kathleen Moriarty , The IESG Cc: jefftant.ietf@gmail.com, rtgwg-chairs@ietf.org, draft-ietf-rtgwg-yang-key-chain@ietf.org, rtgwg@ietf.org References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Wed, 26 Apr 2017 13:42:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:42:18 -0000 On 4/26/17 11:34 AM, Kathleen Moriarty wrote: > Since the following text int he Security Considerations section is a > recommendation, IMO it would be better to drop "or otherwise obfuscated" > from the sentence as encrypting the keys really should be the > recommendation. Can we make this update? > > It is RECOMMENDED that keys be encrypted or otherwise obfuscated > when > stored internally on a network device supporting this specification. > > If obfuscation is what happens more often in practice, maybe mention this > as a fallback from the recommendation, but not make them sound > equivalent? To be clear -- the current guidance from the security area is to perform this kind of encryption, where you have encrypted material living side-by-side with the key necessary to decrypt it? /a From nobody Wed Apr 26 12:05:54 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA3912946A; Wed, 26 Apr 2017 12:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 LzpzyRbcHcb0; Wed, 26 Apr 2017 12:05:45 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 A8688129468; Wed, 26 Apr 2017 12:05:45 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id c198so4335273pfc.1; Wed, 26 Apr 2017 12:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=122BbilCOVcgUKo134UDlLE+pBKc3SCzUfIFBkXbarI=; b=qUtBapnbNuD2KSZppGhmBNl6QkRJtm1hHJxJIG7VgXki/KSvtBPBMjXOyZh7AXgZWJ zK9zLCDn6Ln3VbvIzMHNUblsYBzLuy56J+HT0lJLOiJjTn+r+7jU6cmbqF/F2pLpkFvJ IB8OoVI5SKbMTO9lxqs1PXvBk8T6T0po4Fy35n3V+dBaywAh2a5nJ+3l0X2Za2tqhV1J H51grgcEC8hJ+ywUqAA//pfUhLXb3VUY8ZZb5urtFHLNFtpw8sOclw/cDhNprr1WBhs/ 58++/bQFt5bd3nhC0fdBde6/ZM9Op2g4K9SdtSoEF6Aiz2Cmh5c2S5OKesUfZSdDT3Bl TNqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=122BbilCOVcgUKo134UDlLE+pBKc3SCzUfIFBkXbarI=; b=IsITUArkoaAHurYFyyq2kgIE5kV1uRGdr0ChuxDUrmO3VTdLpVqq7nT0oeyupcabcJ yEMJbYfr4+wuPzMz31UrSLjbETPKD29yF+WkjiZFpIs5/5u/HF3JA8/vBbSJbokzopVm 6ADcDsqrwRPsJnOXHe/PnQMkirG66KjClTRTFrD1J7cBz8iaabIbAiEqg6eDeJIkMSEs Cdboz0lAdH7kw+nOXY9ErIJqvtIiHgwXhwSX1YD3V5HmR6HECmXAHwDQrJJBGl/mkV2j 8eQB6gOWa+jeu+GnWepTu+yDgPNGBVy80DVHCdv2oNl87AXbfeL+DgHbhuLdL1WhXWYJ qlWg== X-Gm-Message-State: AN3rC/68tutxr0mji1/SdbGYmkKQDjO7pgIB3lLXazWvT7xkRIEGyvPp KBFDL1cwWgxvZi4nw2x2LX+EahqRhA== X-Received: by 10.98.29.86 with SMTP id d83mr1564281pfd.68.1493233545157; Wed, 26 Apr 2017 12:05:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 12:05:04 -0700 (PDT) In-Reply-To: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 15:05:04 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: "Acee Lindem (acee)" , Brian Weis Cc: The IESG , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:05:47 -0000 Hi Acee, Adding Brian since he may be able to assist since he is familiar with other implementations with YANG modules. On Wed, Apr 26, 2017 at 12:52 PM, Acee Lindem (acee) wrote= : > Kathleen, > > The lack of KEK specification is not a problem with the YANG key-chain > model, it with RFC 5649 and KEK. I=E2=80=99d request that yourself or som= eone in > the security area provide a reference or text. A primary reason KEK has > not been widely deployed is that RFC 5649 is woefully lacking in > operational guidance. If you can=E2=80=99t do this, I=E2=80=99ll remove t= he reference and > rely on NCACM similar to the shared-secret data node in RFC 7317. I'm not following you as to what is lacking, if you could please expand on that it would be appreciated and then we can assist more. RFC 3394 and RFC5649 are widely deployed according to the author. Do you mean deployed specific to YANG modules or something else? Does the following guidance help: If you want to wrap an AES key and nothing else, use RFC 3394 If you want to wrap an AES key and some other attributes too, use RFC 5= 649 I think it would be better to have the text from the -20 version in the body of the document (rather than security considerations section), I see it was removed in -21. Then have the considerations for using/not using in the security considerations section. I think Brian's responses help cover some of what would go into the text for the security considerations section. Is this the text provided what you need help with or is it something additional for developers? By implementors, are you referring to the developers or operators configuring the devices? I just want to be sure we are clear on the problem so we can assist. Thank you, Kathleen > > Thanks > Acee > > On 4/26/17, 12:34 PM, "rtgwg on behalf of Kathleen Moriarty" > > wrote: > >>Kathleen Moriarty has entered the following ballot position for >>draft-ietf-rtgwg-yang-key-chain-20: Discuss >> >>When responding, please keep the subject line intact and reply to all >>email addresses included in the To and CC lines. (Feel free to cut this >>introductory paragraph, however.) >> >> >>Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>for more information about IESG DISCUSS and COMMENT positions. >> >> >>The document, along with other ballot positions, can be found here: >>https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ >> >> >> >>---------------------------------------------------------------------- >>DISCUSS: >>---------------------------------------------------------------------- >> >>Thanks for your work on this draft. There is one outstanding issue from >>the SecDir review that may require some updated text to resolve. It >>seems use of the key wrap method in RFC5649 requires more guidance for >>implementations to use it with this YANG module. It's good to know that >>this is in use for other modules, so having a clear reference either to >>another draft or the text being in this draft for later reference would >>be helpful. >> >>In looking at this text within the draft, I think it would be better to >>pull the text out of the Security Considerations section and into an >>earlier section of the draft. It's better to introduce this prior to >>enumerating security considerations for the draft since this something >>that would be implemented. Then security considerations should mention >>the considerations of using this option versus just what's in NACM. >> >>You have the text: >> >> When configured, the key-strings can be encrypted using the AES Key >> Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is >> not included in the YANG model and must be set or derived >>independent >> of key-chain configuration. When AES key-encryption is used, the >> hex-key-string feature is also required since the encrypted keys >>will >> contain characters that are not representable in the YANG string >> built-in type [YANG]. AES key-encryption MAY be used for added key >> security in situations where the NETCONF Access Control Mode is not >> available. >> >>I think it's pretty straightforward after looking at RFC5649, but maybe >>more text would be helpful to clarify for implementers. This might mean >>more text from 5649 on what gets placed in the YANG data model where you >>have already allocated for this or including an example. >> >> >>---------------------------------------------------------------------- >>COMMENT: >>---------------------------------------------------------------------- >> >>Thank you for working through the SecDir review and making the suggested >>updates. >> >>Since the following text int he Security Considerations section is a >>recommendation, IMO it would be better to drop "or otherwise obfuscated" >>from the sentence as encrypting the keys really should be the >>recommendation. Can we make this update? >> >> It is RECOMMENDED that keys be encrypted or otherwise obfuscated >>when >> stored internally on a network device supporting this specification. >> >>If obfuscation is what happens more often in practice, maybe mention this >>as a fallback from the recommendation, but not make them sound >>equivalent? >> >> >>_______________________________________________ >>rtgwg mailing list >>rtgwg@ietf.org >>https://www.ietf.org/mailman/listinfo/rtgwg > --=20 Best regards, Kathleen From nobody Wed Apr 26 12:36:58 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C5312ECED; Wed, 26 Apr 2017 12:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 BsB1cJM85Sht; Wed, 26 Apr 2017 12:36:51 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 01ADD129450; Wed, 26 Apr 2017 12:36:51 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id c198so4678415pfc.1; Wed, 26 Apr 2017 12:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xiaWtI2o23HIADVS+l+3Nffw1FhZNF/xOw+p7awquUg=; b=jVzxdqdJdQ+ievrFf05VSKzUIaJ5lPY4qtxI3FcLw9fnzD/1R6NpOxyM78Pk71uYVU I8mP0Lu/HppuDQawyHdglYBjqHeHfH8g9UxLjEsPK3bebz4Mz22VAmz4m+rv5ZO7eG7i YIkEbCI7DMWd0yTYSu0hWykl50Eb01S+MTaAtRZCKhYxJCq/76dTuxebu2MVHfJiX4v6 U5q+tLN/D5kSN9L9dgOjAX1vqkPUPC4dhDj56y6UTYI9nlC7v0hBAfpYCP+ot+i8060P Y82IfEsr7UIUodOnRNfwWSDWwhAlo9Fo24Od2be74t+CONtrPUl9Gb2vXM+KKAIV0x65 Qe/A== 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=xiaWtI2o23HIADVS+l+3Nffw1FhZNF/xOw+p7awquUg=; b=by1p39GmscN5TDDwjqZTjh8q3Cpcyfy0t/djZAlzXOya+L/PSNEGDfhYVPNRFT474s ftnh7nDtplER5GIkkVp26/kYI5PmLenvxBQWodaf9Erju0WztnJqwuKEh+GBEDbmK/2A xND1/ppab78k02XsfY61L4ogvMRK1R+aH2bxiyYTqot20p0dx4Z8MKxjBvqJ5D1L7qla hpb4bG96JLir4P1Y3TySqDKm2XmwvP8DZvzqfLbT257U+4UWosRhf5OXkhnkCajkI3nN xVI1RV23eTV+uOlIAvy5+LdRGKySTmBBRu6kVsceej2H9FKzFRP1+02URWDtAeBhYfLN GPBA== X-Gm-Message-State: AN3rC/4BlGIXulwI0vMr9qt8SPlfiogeq8044VjjHm1aQcUFsj9vNTer N5kux3Wz3f5YrIUqyzy3OU+UPKcD0w== X-Received: by 10.99.2.9 with SMTP id 9mr1517031pgc.69.1493235410554; Wed, 26 Apr 2017 12:36:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 12:36:10 -0700 (PDT) In-Reply-To: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 15:36:10 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Adam Roach Cc: The IESG , Jeff Tantsura , rtgwg-chairs@ietf.org, draft-ietf-rtgwg-yang-key-chain@ietf.org, rtgwg@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:36:52 -0000 On Wed, Apr 26, 2017 at 2:42 PM, Adam Roach wrote: > On 4/26/17 11:34 AM, Kathleen Moriarty wrote: >> >> Since the following text int he Security Considerations section is a >> recommendation, IMO it would be better to drop "or otherwise obfuscated" >> from the sentence as encrypting the keys really should be the >> recommendation. Can we make this update? >> >> It is RECOMMENDED that keys be encrypted or otherwise obfuscated >> when >> stored internally on a network device supporting this specification. >> >> If obfuscation is what happens more often in practice, maybe mention this >> as a fallback from the recommendation, but not make them sound >> equivalent? > > > > To be clear -- the current guidance from the security area is to perform > this kind of encryption, where you have encrypted material living > side-by-side with the key necessary to decrypt it? We are talking about using a key encrypting key (KEK) and storing that, not storing the raw key next to the encrypted data as far as I can tell. Additionally, I haven't seen a discussion on the hardware this is expected to run on. Some implementations of KEK solutions use dedicated hardware for the KEK and require authentication for access to the key, hence preventing generic access and side-by-side storage of the KEK's protected key, and encrypted data. I'd rather see a KEK used than just a key stored in any case. Are you arguing for not using any encryption at all? For YANG modules, couldn't the application via NETCONF/RESTCONF accessing the module provide the credentials to access the key protected by the KEK? Some implementations could store the KEK in dedicated hardware as well. In this way, storing the KEK and data together is not the same as storing a key right next to the data it is protecting. Use of a KEK is better then not encrypting and can be done well. Am I missing something? Was there something implementation specific that has the raw key stored with the encrypted data? Thanks, Kathleen > > /a > -- Best regards, Kathleen From nobody Wed Apr 26 13:18:17 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F1E12ECED; Wed, 26 Apr 2017 13:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScVyF3WrT0zH; Wed, 26 Apr 2017 13:18:02 -0700 (PDT) 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 8EB851294D8; Wed, 26 Apr 2017 13:18:02 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3QKI0KU078280 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 15:18:01 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Kathleen Moriarty Cc: The IESG , Jeff Tantsura , rtgwg-chairs@ietf.org, draft-ietf-rtgwg-yang-key-chain@ietf.org, rtgwg@ietf.org References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> Date: Wed, 26 Apr 2017 15:18:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:18:09 -0000 On 4/26/17 2:36 PM, Kathleen Moriarty wrote: > On Wed, Apr 26, 2017 at 2:42 PM, Adam Roach wrote: >> On 4/26/17 11:34 AM, Kathleen Moriarty wrote: >>> Since the following text int he Security Considerations section is a >>> recommendation, IMO it would be better to drop "or otherwise obfuscated" >>> from the sentence as encrypting the keys really should be the >>> recommendation. Can we make this update? >>> >>> It is RECOMMENDED that keys be encrypted or otherwise obfuscated >>> when >>> stored internally on a network device supporting this specification. >>> >>> If obfuscation is what happens more often in practice, maybe mention this >>> as a fallback from the recommendation, but not make them sound >>> equivalent? >> >> >> To be clear -- the current guidance from the security area is to perform >> this kind of encryption, where you have encrypted material living >> side-by-side with the key necessary to decrypt it? > We are talking about using a key encrypting key (KEK) and storing > that, not storing the raw key next to the encrypted data as far as I > can tell. Right. > Additionally, I haven't seen a discussion on the hardware > this is expected to run on. That might be appropriate matter for the draft, if it is going to make this recommendation. > Some implementations of KEK solutions use dedicated hardware for the > KEK and require authentication for access to the key, hence preventing > generic access and side-by-side storage of the KEK's protected key, > and encrypted data. I'd rather see a KEK used than just a key stored > in any case. Are you arguing for not using any encryption at all? I'll defer to you, of course, since you have presumably given the topic more thought than I have, but: yes. Absent something like an HSM or forcing human intervention whenever a process starts (or restarts), it seems that the scheme described in section 5 doesn't actually deter a competent attacker from obtaining the keys. My impression is that storing information in an encrypted form that can be trivially decrypted by an attacker provides a false sense of security to equipment operators. If the scheme in section 5 *does* require the kind of prerequisites you posit, such as dedicated security hardware, it seems that such prerequisites should be mentioned alongside the recommendation. > For YANG modules, couldn't the application via NETCONF/RESTCONF > accessing the module provide the credentials to access the key > protected by the KEK? That solves the issues with provisioning, but doesn't seem to help the processes actually involved in routing. > Some implementations could store the KEK in > dedicated hardware as well. In this way, storing the KEK and data > together is not the same as storing a key right next to the data it is > protecting. This makes perfect sense; and it should probably be in the document. > Use of a KEK is better then not encrypting and can be done > well. It can also be done poorly, and the mention of obfuscation (along with the exchange I cite below) leads me to believe that -- absent concrete guidance to the contrary -- implementors will choose to do it poorly. It's not clear that doing this poorly provides any benefit, and it seems to me that it may cause harm: if something _looks_ secure but isn't, doesn't that have the potential for operators to incorrectly treat it as secure? Again, this is more your area than mine and so I will defer to your opinion on the topic; but from a lay perspective, this seems likely to result in the lack of guarding against compromise of the encrypted information under the mistaken impression that it can't be decrypted trivially. > Am I missing something? Was there something implementation specific > that has the raw key stored with the encrypted data? Perhaps the following exchange with the author: Adam: "By my reading, this is just talking about encrypting 'on the disk' storage on the device. Any processes involved in provisioning the values or using them to process traffic would have access to the plaintext, presumably by reading the encrypted form off disk, reading some keying material off disk, and combining them to retrieve the plaintext key." Acee: "This is the correct interpretation." /a From nobody Wed Apr 26 13:30:58 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B651294B9; Wed, 26 Apr 2017 13:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 k9c-YZegzq1S; Wed, 26 Apr 2017 13:30:54 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B08C127342; Wed, 26 Apr 2017 13:30:50 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id 194so5231217pfv.3; Wed, 26 Apr 2017 13:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H+50gprk9TNXEMs2O7WcipwUuCw6FnOcAr/MydF6+6c=; b=GdF/lFwsrWjU7qRMTQnFHq+QJDDM9Q9Pg2E6kP9Qi2KkCfHvTZpYLIcp/UNjVbvWny tex/LROSZ4+tOapD6ugJ4CrvDe9IzldYkqFYlWgML0p3U+fwnqHmLlrMvKCTSRGuDApD phgurJ24/4L/i7VRyclqprd9Mqzpe7RNCf6XN/mXq1ZZZRV7d1AENzUhMQ5ajdXXHtui sf47qp4YvuLzx+V0MJ4epDy8vky0NQiPVfGnsKE++pGWaSM+4UxjpyUtOGQLfgtaDQ0V cvgJFxSmYoEDzHff7MQK4uqgYRy94l4Vyx+BQeA0oeAY+4/Nva4nMtt+5ayAg26OzFtP VB0A== 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=H+50gprk9TNXEMs2O7WcipwUuCw6FnOcAr/MydF6+6c=; b=LKaTV7/9lQfQnTVkBheM2W2ZDmnopF6++ENUorQQ6IWOYSSwxQ4VgFASLFp4rYIRGy VjeJNgzrS1gQ1SA+sUDgPnBYQYuym9cHuWmI0PeN8gTgPhLaaDWF576ZTF/HuuXMFPdS 3KEYFLObMnmG2QV901PlB9W3k7XNsiRKZTeCxOFsUik8mJN7CxRBL2OHadgjPUjPFLtC 9DgTgz602dvaOqRHpzMIz5NH5g9AWOTZAhCejoKTyrkEDPtRq06/9ycgPsqHEWJjf/H5 o/onA9Z76YjLOAPWwuWbjmPE2ZRFUZHGuNYyCPD6uIWu2FvmCb2bN9J+F6xHlgnPtMg6 dEag== X-Gm-Message-State: AN3rC/5o67KDtcVJQgCwBpL9XOWKPtY/criuSqLA+sgbNAeXb4zN5NPc YQKta/pwVbHO5shDjMX5FMkhJCYLgrYf X-Received: by 10.98.8.143 with SMTP id 15mr1878338pfi.268.1493238649779; Wed, 26 Apr 2017 13:30:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 13:30:09 -0700 (PDT) In-Reply-To: <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 16:30:09 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Adam Roach Cc: The IESG , Jeff Tantsura , rtgwg-chairs@ietf.org, draft-ietf-rtgwg-yang-key-chain@ietf.org, rtgwg@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:30:56 -0000 Hi Adam, I think I see where we are coming to different conclusions.... On Wed, Apr 26, 2017 at 4:18 PM, Adam Roach wrote: > On 4/26/17 2:36 PM, Kathleen Moriarty wrote: >> >> On Wed, Apr 26, 2017 at 2:42 PM, Adam Roach wrote: >>> >>> On 4/26/17 11:34 AM, Kathleen Moriarty wrote: >>>> >>>> Since the following text int he Security Considerations section is a >>>> recommendation, IMO it would be better to drop "or otherwise obfuscated" >>>> from the sentence as encrypting the keys really should be the >>>> recommendation. Can we make this update? >>>> >>>> It is RECOMMENDED that keys be encrypted or otherwise obfuscated >>>> when >>>> stored internally on a network device supporting this >>>> specification. >>>> >>>> If obfuscation is what happens more often in practice, maybe mention >>>> this >>>> as a fallback from the recommendation, but not make them sound >>>> equivalent? >>> >>> >>> >>> To be clear -- the current guidance from the security area is to perform >>> this kind of encryption, where you have encrypted material living >>> side-by-side with the key necessary to decrypt it? >> >> We are talking about using a key encrypting key (KEK) and storing >> that, not storing the raw key next to the encrypted data as far as I >> can tell. > > > Right. > >> Additionally, I haven't seen a discussion on the hardware >> this is expected to run on. > > > That might be appropriate matter for the draft, if it is going to make this > recommendation. > >> Some implementations of KEK solutions use dedicated hardware for the >> KEK and require authentication for access to the key, hence preventing >> generic access and side-by-side storage of the KEK's protected key, >> and encrypted data. I'd rather see a KEK used than just a key stored >> in any case. Are you arguing for not using any encryption at all? > > > I'll defer to you, of course, since you have presumably given the topic more > thought than I have, but: yes. > > Absent something like an HSM or forcing human intervention whenever a > process starts (or restarts), it seems that the scheme described in section > 5 doesn't actually deter a competent attacker from obtaining the keys. My > impression is that storing information in an encrypted form that can be > trivially decrypted by an attacker provides a false sense of security to > equipment operators. > > If the scheme in section 5 *does* require the kind of prerequisites you > posit, such as dedicated security hardware, it seems that such prerequisites > should be mentioned alongside the recommendation. > >> For YANG modules, couldn't the application via NETCONF/RESTCONF >> accessing the module provide the credentials to access the key >> protected by the KEK? > > > That solves the issues with provisioning, but doesn't seem to help the > processes actually involved in routing. > >> Some implementations could store the KEK in >> dedicated hardware as well. In this way, storing the KEK and data >> together is not the same as storing a key right next to the data it is >> protecting. > > > This makes perfect sense; and it should probably be in the document. > >> Use of a KEK is better then not encrypting and can be done >> well. > > > It can also be done poorly, and the mention of obfuscation (along with the > exchange I cite below) leads me to believe that -- absent concrete guidance > to the contrary -- implementors will choose to do it poorly. It's not clear > that doing this poorly provides any benefit, and it seems to me that it may > cause harm: if something _looks_ secure but isn't, doesn't that have the > potential for operators to incorrectly treat it as secure? Again, this is > more your area than mine and so I will defer to your opinion on the topic; > but from a lay perspective, this seems likely to result in the lack of > guarding against compromise of the encrypted information under the mistaken > impression that it can't be decrypted trivially. > The way I read the thread from Acee is that there aren't any KEK implementations with with particular YANG module, however Brian says there is with other YANG modules. I *think* when Acee is referring to obfuscation and less than ideal scenarios, it is with the currently deployed implementations that don't use KEKs. But the text and responses did seem to be commingled a bit too much. > >> Am I missing something? Was there something implementation specific >> that has the raw key stored with the encrypted data? > > > Perhaps the following exchange with the author: > > Adam: "By my reading, this is just talking about encrypting 'on the disk' > storage on the device. Any processes involved in provisioning the values or > using them to process traffic would have access to the plaintext, presumably > by reading the encrypted form off disk, reading some keying material off > disk, and combining them to retrieve the plaintext key." It looks like version 20 had different assumptions about using the KEK. I *think* this is describing usage without a KEK and may be part of why Acee is asking for more implementation guidance... so I'll keep my discuss to see if we can shape that up more. This is helpful as I think I see the gap more now as to what he might be looking for in terms of guidance. Here's the text from -20: When configured, the key-strings can be encrypted using the AES Key Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is not included in the YANG model and must be set or derived independent Lindem, et al. Expires October 20, 2017 [Page 15] Internet-Draft YANG Key Chain April 2017 of key-chain configuration. When AES key-encryption is used, the hex-key-string feature is also required since the encrypted keys will contain characters that are not representable in the YANG string built-in type [YANG]. AES key-encryption MAY be used for added key security in situations where the NETCONF Access Control Mode is not available. > > Acee: "This is the correct interpretation." > > /a Thanks. -- Best regards, Kathleen From nobody Wed Apr 26 13:40:02 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BB9127342; Wed, 26 Apr 2017 13:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrZsC8C_3K2N; Wed, 26 Apr 2017 13:40:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9971129469; Wed, 26 Apr 2017 13:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9756; q=dns/txt; s=iport; t=1493239200; x=1494448800; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZQjvGpUv7K9e80p/I5XDgrDYysmE4AawQZFoW91xNqc=; b=fMbtkT/m6zBefzqZ94pqGb30EXucKt+BovSoPqdRqPOSRLwpji7LJyiq C5ZsqjQUhXkg7EMu8Pd2z/P2Po8ktdXgOS0avld0rZu0BOYLrZwMAptmV 9QndlKRJQ8DSh7h7HAAbDYUtZRozBlvZfIK3Xj917Mkvcxu4sZqUoRKjb U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BPAQDtBAFZ/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyorgW0Hg2GKFpFJiCGNSoIPhiQCGoQQPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?WAQUjEUUQAgEIGAICJgICAh8RFRACBAENBRuJaAMVqz2CJoc6DYNfAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBIIELhyeCD4ELglOBVCQUgwaCXwEEnRU7AY4/hEyCAokchkC?= =?us-ascii?q?IdIIliQ0BHziBB2UVhTEcGYFKdQGGOA4XgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208";a="236216713" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2017 20:39:52 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v3QKdnPq020394 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 20:39:49 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 16:39:48 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 26 Apr 2017 16:39:49 -0400 From: "Acee Lindem (acee)" To: Kathleen Moriarty , Adam Roach , "Brian Weis (bew)" CC: The IESG , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Index: AQHSvsRbaK6mr1jQpUuQYLHDV2KBn6HYWesAgAADZoD//7+ggA== Date: Wed, 26 Apr 2017 20:39:48 +0000 Message-ID: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <5457F8A4383D3445B8AA266864124BDB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:40:02 -0000 S2F0aGxlZW4sIEJyaWFuLCANCg0KU2luY2UgS0VLIGFzIGRlc2NyaWJlZCBpbiBSRkMgNTY0OSBp cyBub3QgcmVhZHkgZm9yIHByaW1lIHRpbWUsIHdoeSBkb27igJl0DQp5b3UgdGFrZSB0aGlzIHVw IGFzIGEgc2VwYXJhdGUgZHJhZnQgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGhvbGQgdGhpcw0KaW1w b3J0YW50IGRvY3VtZW50IGhvc3RhZ2U/IFdlIGhhdmUgdGhlIE5FVENPTkYgQWNjZXNzIENvbnRy b2wgTW9kZWwNCihOQUNNKSB0byBwcm90ZWN0IHRoZSBrZXlzIGR1cmluZyB0cmFuc3BvcnQgKHdo aWNoIGhhcyBiZWVuIGltcGxlbWVudGVkKS4NCk9idmlvdXNseSwga2V5LXN0cmluZ3MgYXJlIHN0 b3JlZCBvbiBkZXZpY2VzIHRvZGF5IHNpbmNlIHRoZXkgYXJlIGJlaW5nDQp1c2VkIGZvciBwcm90 b2NvbCBhdXRoZW50aWNhdGlvbiBhbmQgZW5jcnlwdGlvbiBzbyB0aGlzIGlzIHRvdGFsbHkNCm9y dGhvZ29uYWwgdG8gdGhlIFlBTkcgbW9kZWwgYmVpbmcgdXNlZCB0byBwcm92aXNpb24gdGhlbS4N Cg0KVGhhbmtzLA0KQWNlZSANCg0KT24gNC8yNi8xNywgNDozMCBQTSwgIkthdGhsZWVuIE1vcmlh cnR5Ig0KPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KPkhpIEFk YW0sDQo+DQo+SSB0aGluayBJIHNlZSB3aGVyZSB3ZSBhcmUgY29taW5nIHRvIGRpZmZlcmVudCBj b25jbHVzaW9ucy4uLi4NCj4NCj5PbiBXZWQsIEFwciAyNiwgMjAxNyBhdCA0OjE4IFBNLCBBZGFt IFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPiB3cm90ZToNCj4+IE9uIDQvMjYvMTcgMjozNiBQTSwg S2F0aGxlZW4gTW9yaWFydHkgd3JvdGU6DQo+Pj4NCj4+PiBPbiBXZWQsIEFwciAyNiwgMjAxNyBh dCAyOjQyIFBNLCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPiB3cm90ZToNCj4+Pj4NCj4+ Pj4gT24gNC8yNi8xNyAxMTozNCBBTSwgS2F0aGxlZW4gTW9yaWFydHkgd3JvdGU6DQo+Pj4+Pg0K Pj4+Pj4gU2luY2UgdGhlIGZvbGxvd2luZyB0ZXh0IGludCBoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uIGlzIGENCj4+Pj4+IHJlY29tbWVuZGF0aW9uLCBJTU8gaXQgd291bGQgYmUg YmV0dGVyIHRvIGRyb3AgIm9yIG90aGVyd2lzZQ0KPj4+Pj5vYmZ1c2NhdGVkIg0KPj4+Pj4gZnJv bSB0aGUgc2VudGVuY2UgYXMgZW5jcnlwdGluZyB0aGUga2V5cyByZWFsbHkgc2hvdWxkIGJlIHRo ZQ0KPj4+Pj4gcmVjb21tZW5kYXRpb24uICBDYW4gd2UgbWFrZSB0aGlzIHVwZGF0ZT8NCj4+Pj4+ DQo+Pj4+PiAgICAgIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQga2V5cyBiZSBlbmNyeXB0ZWQgb3Ig b3RoZXJ3aXNlIG9iZnVzY2F0ZWQNCj4+Pj4+IHdoZW4NCj4+Pj4+ICAgICAgc3RvcmVkIGludGVy bmFsbHkgb24gYSBuZXR3b3JrIGRldmljZSBzdXBwb3J0aW5nIHRoaXMNCj4+Pj4+IHNwZWNpZmlj YXRpb24uDQo+Pj4+Pg0KPj4+Pj4gSWYgb2JmdXNjYXRpb24gaXMgd2hhdCBoYXBwZW5zIG1vcmUg b2Z0ZW4gaW4gcHJhY3RpY2UsIG1heWJlIG1lbnRpb24NCj4+Pj4+IHRoaXMNCj4+Pj4+IGFzIGEg ZmFsbGJhY2sgZnJvbSB0aGUgcmVjb21tZW5kYXRpb24sIGJ1dCBub3QgbWFrZSB0aGVtIHNvdW5k DQo+Pj4+PiBlcXVpdmFsZW50Pw0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBUbyBiZSBjbGVhciAt LSB0aGUgY3VycmVudCBndWlkYW5jZSBmcm9tIHRoZSBzZWN1cml0eSBhcmVhIGlzIHRvDQo+Pj4+ cGVyZm9ybQ0KPj4+PiB0aGlzIGtpbmQgb2YgZW5jcnlwdGlvbiwgd2hlcmUgeW91IGhhdmUgZW5j cnlwdGVkIG1hdGVyaWFsIGxpdmluZw0KPj4+PiBzaWRlLWJ5LXNpZGUgd2l0aCB0aGUga2V5IG5l Y2Vzc2FyeSB0byBkZWNyeXB0IGl0Pw0KPj4+DQo+Pj4gV2UgYXJlIHRhbGtpbmcgYWJvdXQgdXNp bmcgYSBrZXkgZW5jcnlwdGluZyBrZXkgKEtFSykgYW5kIHN0b3JpbmcNCj4+PiB0aGF0LCBub3Qg c3RvcmluZyB0aGUgcmF3IGtleSBuZXh0IHRvIHRoZSBlbmNyeXB0ZWQgZGF0YSBhcyBmYXIgYXMg SQ0KPj4+IGNhbiB0ZWxsLg0KPj4NCj4+DQo+PiBSaWdodC4NCj4+DQo+Pj4gQWRkaXRpb25hbGx5 LCBJIGhhdmVuJ3Qgc2VlbiBhIGRpc2N1c3Npb24gb24gdGhlIGhhcmR3YXJlDQo+Pj4gdGhpcyBp cyBleHBlY3RlZCB0byBydW4gb24uDQo+Pg0KPj4NCj4+IFRoYXQgbWlnaHQgYmUgYXBwcm9wcmlh dGUgbWF0dGVyIGZvciB0aGUgZHJhZnQsIGlmIGl0IGlzIGdvaW5nIHRvIG1ha2UNCj4+dGhpcw0K Pj4gcmVjb21tZW5kYXRpb24uDQo+Pg0KPj4+IFNvbWUgaW1wbGVtZW50YXRpb25zIG9mIEtFSyBz b2x1dGlvbnMgdXNlIGRlZGljYXRlZCBoYXJkd2FyZSBmb3IgdGhlDQo+Pj4gS0VLIGFuZCByZXF1 aXJlIGF1dGhlbnRpY2F0aW9uIGZvciBhY2Nlc3MgdG8gdGhlIGtleSwgaGVuY2UgcHJldmVudGlu Zw0KPj4+IGdlbmVyaWMgYWNjZXNzIGFuZCBzaWRlLWJ5LXNpZGUgc3RvcmFnZSBvZiB0aGUgS0VL J3MgcHJvdGVjdGVkIGtleSwNCj4+PiBhbmQgZW5jcnlwdGVkIGRhdGEuICBJJ2QgcmF0aGVyIHNl ZSBhIEtFSyB1c2VkIHRoYW4ganVzdCBhIGtleSBzdG9yZWQNCj4+PiBpbiBhbnkgY2FzZS4gIEFy ZSB5b3UgYXJndWluZyBmb3Igbm90IHVzaW5nIGFueSBlbmNyeXB0aW9uIGF0IGFsbD8NCj4+DQo+ Pg0KPj4gSSdsbCBkZWZlciB0byB5b3UsIG9mIGNvdXJzZSwgc2luY2UgeW91IGhhdmUgcHJlc3Vt YWJseSBnaXZlbiB0aGUgdG9waWMNCj4+bW9yZQ0KPj4gdGhvdWdodCB0aGFuIEkgaGF2ZSwgYnV0 OiB5ZXMuDQo+Pg0KPj4gQWJzZW50IHNvbWV0aGluZyBsaWtlIGFuIEhTTSBvciBmb3JjaW5nIGh1 bWFuIGludGVydmVudGlvbiB3aGVuZXZlciBhDQo+PiBwcm9jZXNzIHN0YXJ0cyAob3IgcmVzdGFy dHMpLCBpdCBzZWVtcyB0aGF0IHRoZSBzY2hlbWUgZGVzY3JpYmVkIGluDQo+PnNlY3Rpb24NCj4+ IDUgZG9lc24ndCBhY3R1YWxseSBkZXRlciBhIGNvbXBldGVudCBhdHRhY2tlciBmcm9tIG9idGFp bmluZyB0aGUga2V5cy4NCj4+TXkNCj4+IGltcHJlc3Npb24gaXMgdGhhdCBzdG9yaW5nIGluZm9y bWF0aW9uIGluIGFuIGVuY3J5cHRlZCBmb3JtIHRoYXQgY2FuIGJlDQo+PiB0cml2aWFsbHkgZGVj cnlwdGVkIGJ5IGFuIGF0dGFja2VyIHByb3ZpZGVzIGEgZmFsc2Ugc2Vuc2Ugb2Ygc2VjdXJpdHkg dG8NCj4+IGVxdWlwbWVudCBvcGVyYXRvcnMuDQo+Pg0KPj4gSWYgdGhlIHNjaGVtZSBpbiBzZWN0 aW9uIDUgKmRvZXMqIHJlcXVpcmUgdGhlIGtpbmQgb2YgcHJlcmVxdWlzaXRlcyB5b3UNCj4+IHBv c2l0LCBzdWNoIGFzIGRlZGljYXRlZCBzZWN1cml0eSBoYXJkd2FyZSwgaXQgc2VlbXMgdGhhdCBz dWNoDQo+PnByZXJlcXVpc2l0ZXMNCj4+IHNob3VsZCBiZSBtZW50aW9uZWQgYWxvbmdzaWRlIHRo ZSByZWNvbW1lbmRhdGlvbi4NCj4+DQo+Pj4gRm9yIFlBTkcgbW9kdWxlcywgY291bGRuJ3QgdGhl IGFwcGxpY2F0aW9uIHZpYSBORVRDT05GL1JFU1RDT05GDQo+Pj4gYWNjZXNzaW5nIHRoZSBtb2R1 bGUgcHJvdmlkZSB0aGUgY3JlZGVudGlhbHMgdG8gYWNjZXNzIHRoZSBrZXkNCj4+PiBwcm90ZWN0 ZWQgYnkgdGhlIEtFSz8NCj4+DQo+Pg0KPj4gVGhhdCBzb2x2ZXMgdGhlIGlzc3VlcyB3aXRoIHBy b3Zpc2lvbmluZywgYnV0IGRvZXNuJ3Qgc2VlbSB0byBoZWxwIHRoZQ0KPj4gcHJvY2Vzc2VzIGFj dHVhbGx5IGludm9sdmVkIGluIHJvdXRpbmcuDQo+Pg0KPj4+IFNvbWUgaW1wbGVtZW50YXRpb25z IGNvdWxkIHN0b3JlIHRoZSBLRUsgaW4NCj4+PiBkZWRpY2F0ZWQgaGFyZHdhcmUgYXMgd2VsbC4g SW4gdGhpcyB3YXksIHN0b3JpbmcgdGhlIEtFSyBhbmQgZGF0YQ0KPj4+IHRvZ2V0aGVyIGlzIG5v dCB0aGUgc2FtZSBhcyBzdG9yaW5nIGEga2V5IHJpZ2h0IG5leHQgdG8gdGhlIGRhdGEgaXQgaXMN Cj4+PiBwcm90ZWN0aW5nLg0KPj4NCj4+DQo+PiBUaGlzIG1ha2VzIHBlcmZlY3Qgc2Vuc2U7IGFu ZCBpdCBzaG91bGQgcHJvYmFibHkgYmUgaW4gdGhlIGRvY3VtZW50Lg0KPj4NCj4+PiBVc2Ugb2Yg YSBLRUsgaXMgYmV0dGVyIHRoZW4gbm90IGVuY3J5cHRpbmcgYW5kIGNhbiBiZSBkb25lDQo+Pj4g d2VsbC4NCj4+DQo+Pg0KPj4gSXQgY2FuIGFsc28gYmUgZG9uZSBwb29ybHksIGFuZCB0aGUgbWVu dGlvbiBvZiBvYmZ1c2NhdGlvbiAoYWxvbmcgd2l0aA0KPj50aGUNCj4+IGV4Y2hhbmdlIEkgY2l0 ZSBiZWxvdykgbGVhZHMgbWUgdG8gYmVsaWV2ZSB0aGF0IC0tIGFic2VudCBjb25jcmV0ZQ0KPj5n dWlkYW5jZQ0KPj4gdG8gdGhlIGNvbnRyYXJ5IC0tIGltcGxlbWVudG9ycyB3aWxsIGNob29zZSB0 byBkbyBpdCBwb29ybHkuIEl0J3Mgbm90DQo+PmNsZWFyDQo+PiB0aGF0IGRvaW5nIHRoaXMgcG9v cmx5IHByb3ZpZGVzIGFueSBiZW5lZml0LCBhbmQgaXQgc2VlbXMgdG8gbWUgdGhhdCBpdA0KPj5t YXkNCj4+IGNhdXNlIGhhcm06IGlmIHNvbWV0aGluZyBfbG9va3NfIHNlY3VyZSBidXQgaXNuJ3Qs IGRvZXNuJ3QgdGhhdCBoYXZlIHRoZQ0KPj4gcG90ZW50aWFsIGZvciBvcGVyYXRvcnMgdG8gaW5j b3JyZWN0bHkgdHJlYXQgaXQgYXMgc2VjdXJlPyBBZ2FpbiwgdGhpcw0KPj5pcw0KPj4gbW9yZSB5 b3VyIGFyZWEgdGhhbiBtaW5lIGFuZCBzbyBJIHdpbGwgZGVmZXIgdG8geW91ciBvcGluaW9uIG9u IHRoZQ0KPj50b3BpYzsNCj4+IGJ1dCBmcm9tIGEgbGF5IHBlcnNwZWN0aXZlLCB0aGlzIHNlZW1z IGxpa2VseSB0byByZXN1bHQgaW4gdGhlIGxhY2sgb2YNCj4+IGd1YXJkaW5nIGFnYWluc3QgY29t cHJvbWlzZSBvZiB0aGUgZW5jcnlwdGVkIGluZm9ybWF0aW9uIHVuZGVyIHRoZQ0KPj5taXN0YWtl bg0KPj4gaW1wcmVzc2lvbiB0aGF0IGl0IGNhbid0IGJlIGRlY3J5cHRlZCB0cml2aWFsbHkuDQo+ Pg0KPg0KPlRoZSB3YXkgSSByZWFkIHRoZSB0aHJlYWQgZnJvbSBBY2VlIGlzIHRoYXQgdGhlcmUg YXJlbid0IGFueSBLRUsNCj5pbXBsZW1lbnRhdGlvbnMgd2l0aCB3aXRoIHBhcnRpY3VsYXIgWUFO RyBtb2R1bGUsIGhvd2V2ZXIgQnJpYW4gc2F5cw0KPnRoZXJlIGlzIHdpdGggb3RoZXIgWUFORyBt b2R1bGVzLiAgSSAqdGhpbmsqIHdoZW4gQWNlZSBpcyByZWZlcnJpbmcgdG8NCj5vYmZ1c2NhdGlv biBhbmQgbGVzcyB0aGFuIGlkZWFsIHNjZW5hcmlvcywgaXQgaXMgd2l0aCB0aGUgY3VycmVudGx5 DQo+ZGVwbG95ZWQgaW1wbGVtZW50YXRpb25zIHRoYXQgZG9uJ3QgdXNlIEtFS3MuICBCdXQgdGhl IHRleHQgYW5kDQo+cmVzcG9uc2VzIGRpZCBzZWVtIHRvIGJlIGNvbW1pbmdsZWQgYSBiaXQgdG9v IG11Y2guDQo+DQo+Pg0KPj4+IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/ICBXYXMgdGhlcmUgc29t ZXRoaW5nIGltcGxlbWVudGF0aW9uIHNwZWNpZmljDQo+Pj4gdGhhdCBoYXMgdGhlIHJhdyBrZXkg c3RvcmVkIHdpdGggdGhlIGVuY3J5cHRlZCBkYXRhPw0KPj4NCj4+DQo+PiBQZXJoYXBzIHRoZSBm b2xsb3dpbmcgZXhjaGFuZ2Ugd2l0aCB0aGUgYXV0aG9yOg0KPj4NCj4+IEFkYW06ICJCeSBteSBy ZWFkaW5nLCB0aGlzIGlzIGp1c3QgdGFsa2luZyBhYm91dCBlbmNyeXB0aW5nICdvbiB0aGUNCj4+ ZGlzaycNCj4+IHN0b3JhZ2Ugb24gdGhlIGRldmljZS4gQW55IHByb2Nlc3NlcyBpbnZvbHZlZCBp biBwcm92aXNpb25pbmcgdGhlDQo+PnZhbHVlcyBvcg0KPj4gdXNpbmcgdGhlbSB0byBwcm9jZXNz IHRyYWZmaWMgd291bGQgaGF2ZSBhY2Nlc3MgdG8gdGhlIHBsYWludGV4dCwNCj4+cHJlc3VtYWJs eQ0KPj4gYnkgcmVhZGluZyB0aGUgZW5jcnlwdGVkIGZvcm0gb2ZmIGRpc2ssIHJlYWRpbmcgc29t ZSBrZXlpbmcgbWF0ZXJpYWwgb2ZmDQo+PiBkaXNrLCBhbmQgY29tYmluaW5nIHRoZW0gdG8gcmV0 cmlldmUgdGhlIHBsYWludGV4dCBrZXkuIg0KPg0KPkl0IGxvb2tzIGxpa2UgdmVyc2lvbiAyMCBo YWQgZGlmZmVyZW50IGFzc3VtcHRpb25zIGFib3V0IHVzaW5nIHRoZQ0KPktFSy4gIEkgKnRoaW5r KiB0aGlzIGlzIGRlc2NyaWJpbmcgdXNhZ2Ugd2l0aG91dCBhIEtFSyBhbmQgbWF5IGJlIHBhcnQN Cj5vZiB3aHkgQWNlZSBpcyBhc2tpbmcgZm9yIG1vcmUgaW1wbGVtZW50YXRpb24gZ3VpZGFuY2Uu Li4gc28gSSdsbCBrZWVwDQo+bXkgZGlzY3VzcyB0byBzZWUgaWYgd2UgY2FuIHNoYXBlIHRoYXQg dXAgbW9yZS4gIFRoaXMgaXMgaGVscGZ1bCBhcyBJDQo+dGhpbmsgSSBzZWUgdGhlIGdhcCBtb3Jl IG5vdyBhcyB0byB3aGF0IGhlIG1pZ2h0IGJlIGxvb2tpbmcgZm9yIGluDQo+dGVybXMgb2YgZ3Vp ZGFuY2UuDQo+DQo+SGVyZSdzIHRoZSB0ZXh0IGZyb20gLTIwOg0KPg0KPldoZW4gY29uZmlndXJl ZCwgdGhlIGtleS1zdHJpbmdzIGNhbiBiZSBlbmNyeXB0ZWQgdXNpbmcgdGhlIEFFUyBLZXkNCj4g ICBXcmFwIGFsZ29yaXRobSBbQUVTLUtFWS1XUkFQXS4gIFRoZSBBRVMga2V5LWVuY3J5cHRpb24g a2V5IChLRUspIGlzDQo+ICAgbm90IGluY2x1ZGVkIGluIHRoZSBZQU5HIG1vZGVsIGFuZCBtdXN0 IGJlIHNldCBvciBkZXJpdmVkIGluZGVwZW5kZW50DQo+DQo+TGluZGVtLCBldCBhbC4gICAgICAg ICAgRXhwaXJlcyBPY3RvYmVyIDIwLCAyMDE3ICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQo+SW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBZQU5HIEtleSBDaGFpbiAgICAgICAgICAgICAgICAg ICBBcHJpbCAyMDE3DQo+DQo+ICAgb2Yga2V5LWNoYWluIGNvbmZpZ3VyYXRpb24uICBXaGVuIEFF UyBrZXktZW5jcnlwdGlvbiBpcyB1c2VkLCB0aGUNCj4gICBoZXgta2V5LXN0cmluZyBmZWF0dXJl IGlzIGFsc28gcmVxdWlyZWQgc2luY2UgdGhlIGVuY3J5cHRlZCBrZXlzIHdpbGwNCj4gICBjb250 YWluIGNoYXJhY3RlcnMgdGhhdCBhcmUgbm90IHJlcHJlc2VudGFibGUgaW4gdGhlIFlBTkcgc3Ry aW5nDQo+ICAgYnVpbHQtaW4gdHlwZSBbWUFOR10uICBBRVMga2V5LWVuY3J5cHRpb24gTUFZIGJl IHVzZWQgZm9yIGFkZGVkIGtleQ0KPiAgIHNlY3VyaXR5IGluIHNpdHVhdGlvbnMgd2hlcmUgdGhl IE5FVENPTkYgQWNjZXNzIENvbnRyb2wgTW9kZSBpcyBub3QNCj4gICBhdmFpbGFibGUuDQo+DQo+ Pg0KPj4gQWNlZTogIlRoaXMgaXMgdGhlIGNvcnJlY3QgaW50ZXJwcmV0YXRpb24uIg0KPj4NCj4+ IC9hDQo+DQo+VGhhbmtzLg0KPg0KPi0tIA0KPg0KPkJlc3QgcmVnYXJkcywNCj5LYXRobGVlbg0K DQo= From nobody Wed Apr 26 13:48:38 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D21E13144C; Wed, 26 Apr 2017 13:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 J3Me6S7b8aZv; Wed, 26 Apr 2017 13:48:26 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFC212EB55; Wed, 26 Apr 2017 13:48:26 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id 194so5597366pfv.3; Wed, 26 Apr 2017 13:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FvuKu1R2tx3qcrZ6HdeaUJUikmmrriZDvjljwDw2yA0=; b=kzHy6CpNb/846Zc6Jpbd6gyvDqaO6RJm0ZNZiJ/uZd3fYirhzBpQ1ZoYDrbxjwQBJJ bJlBdWOVml9ZeqT/OLAriT2VMjzMid1R2J0P6T/S0iBuriHFr5L+GzXvohLekZ7sGDJR Y3GoD2zynkkXeul+ZLglZ99ujt8blh6KV0W0XPPHFNkQUPLT8vzV0dT3K0jFS2yqZVtg OXoJBegXFxzt4nC4dp8yr+fCylt++ZHqKEsTnwHR6W3T12FnBkOOftiS9xHngwfSFCXI /MPYoj8fjEkz8/fSvBmdklGyJ7B46hh4Amd/NjoYy2aOq+yCkNehe+dN0hc/SlNPt/YV UV3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FvuKu1R2tx3qcrZ6HdeaUJUikmmrriZDvjljwDw2yA0=; b=JtIQtJrwKaBgYUDgYUqssLWwZmWaYM1AzBhiOcWjG2/eUEZmMF9HSjwHngAjExXWwI IW1FPlWXB9jzMBfooqQxYjz5tPyY/LLF6/ijvaNjfSziqd16ghkysbwvI31OxaenoaWu qjGecx8rV5qvQpaKZSoa13GcEDTJoFZwcr6C423CanIdc+HTFvhVYnWb3HYJpg546Hiy XJrnSoK4QsfNSBpctm7mFFuE40LsU0LsJo92nIGf0QifiMvmJeoETFTOH1LzrcBWXO6c +Q9AOoWmqlKpoxofW34XBigQoZz7cseeBWIqX+pFdOBVOeYZk5MrBpOS/W+e6Nja7+yL sC8Q== X-Gm-Message-State: AN3rC/6TEYOsv9YOrEITmXk0rf++GhucAkKR1G9hvu2HaMJgljyMc99T 3FoRukZNpz/TwTpkMiDOSSw7wPwobA== X-Received: by 10.98.8.143 with SMTP id 15mr1948752pfi.268.1493239705538; Wed, 26 Apr 2017 13:48:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 13:47:44 -0700 (PDT) In-Reply-To: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 16:47:44 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: "Acee Lindem (acee)" Cc: Adam Roach , "Brian Weis (bew)" , Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:48:29 -0000 Acee, On Wed, Apr 26, 2017 at 4:39 PM, Acee Lindem (acee) wrote: > Kathleen, Brian, > > Since KEK as described in RFC 5649 is not ready for prime time, why don= =E2=80=99t This is widely deployed in other use cases, so I am not following this statement that it isn't ready for prime time. RFC5649 is straightforward. What is the gap for your usage that requires additional guidance? Brian says this in in use for other YANG modules already as well. Could you please be more explicit in terms of what you need for guidance. I offered a suggestion, if that isn't enough, could you please explain the gap as you see it so we can assist? Thank you, Kathleen > you take this up as a separate draft rather than trying to hold this > important document hostage? We have the NETCONF Access Control Model > (NACM) to protect the keys during transport (which has been implemented). > Obviously, key-strings are stored on devices today since they are being > used for protocol authentication and encryption so this is totally > orthogonal to the YANG model being used to provision them. > > Thanks, > Acee > > On 4/26/17, 4:30 PM, "Kathleen Moriarty" > wrote: > >>Hi Adam, >> >>I think I see where we are coming to different conclusions.... >> >>On Wed, Apr 26, 2017 at 4:18 PM, Adam Roach wrote: >>> On 4/26/17 2:36 PM, Kathleen Moriarty wrote: >>>> >>>> On Wed, Apr 26, 2017 at 2:42 PM, Adam Roach wrote: >>>>> >>>>> On 4/26/17 11:34 AM, Kathleen Moriarty wrote: >>>>>> >>>>>> Since the following text int he Security Considerations section is a >>>>>> recommendation, IMO it would be better to drop "or otherwise >>>>>>obfuscated" >>>>>> from the sentence as encrypting the keys really should be the >>>>>> recommendation. Can we make this update? >>>>>> >>>>>> It is RECOMMENDED that keys be encrypted or otherwise obfuscate= d >>>>>> when >>>>>> stored internally on a network device supporting this >>>>>> specification. >>>>>> >>>>>> If obfuscation is what happens more often in practice, maybe mention >>>>>> this >>>>>> as a fallback from the recommendation, but not make them sound >>>>>> equivalent? >>>>> >>>>> >>>>> >>>>> To be clear -- the current guidance from the security area is to >>>>>perform >>>>> this kind of encryption, where you have encrypted material living >>>>> side-by-side with the key necessary to decrypt it? >>>> >>>> We are talking about using a key encrypting key (KEK) and storing >>>> that, not storing the raw key next to the encrypted data as far as I >>>> can tell. >>> >>> >>> Right. >>> >>>> Additionally, I haven't seen a discussion on the hardware >>>> this is expected to run on. >>> >>> >>> That might be appropriate matter for the draft, if it is going to make >>>this >>> recommendation. >>> >>>> Some implementations of KEK solutions use dedicated hardware for the >>>> KEK and require authentication for access to the key, hence preventing >>>> generic access and side-by-side storage of the KEK's protected key, >>>> and encrypted data. I'd rather see a KEK used than just a key stored >>>> in any case. Are you arguing for not using any encryption at all? >>> >>> >>> I'll defer to you, of course, since you have presumably given the topic >>>more >>> thought than I have, but: yes. >>> >>> Absent something like an HSM or forcing human intervention whenever a >>> process starts (or restarts), it seems that the scheme described in >>>section >>> 5 doesn't actually deter a competent attacker from obtaining the keys. >>>My >>> impression is that storing information in an encrypted form that can be >>> trivially decrypted by an attacker provides a false sense of security t= o >>> equipment operators. >>> >>> If the scheme in section 5 *does* require the kind of prerequisites you >>> posit, such as dedicated security hardware, it seems that such >>>prerequisites >>> should be mentioned alongside the recommendation. >>> >>>> For YANG modules, couldn't the application via NETCONF/RESTCONF >>>> accessing the module provide the credentials to access the key >>>> protected by the KEK? >>> >>> >>> That solves the issues with provisioning, but doesn't seem to help the >>> processes actually involved in routing. >>> >>>> Some implementations could store the KEK in >>>> dedicated hardware as well. In this way, storing the KEK and data >>>> together is not the same as storing a key right next to the data it is >>>> protecting. >>> >>> >>> This makes perfect sense; and it should probably be in the document. >>> >>>> Use of a KEK is better then not encrypting and can be done >>>> well. >>> >>> >>> It can also be done poorly, and the mention of obfuscation (along with >>>the >>> exchange I cite below) leads me to believe that -- absent concrete >>>guidance >>> to the contrary -- implementors will choose to do it poorly. It's not >>>clear >>> that doing this poorly provides any benefit, and it seems to me that it >>>may >>> cause harm: if something _looks_ secure but isn't, doesn't that have th= e >>> potential for operators to incorrectly treat it as secure? Again, this >>>is >>> more your area than mine and so I will defer to your opinion on the >>>topic; >>> but from a lay perspective, this seems likely to result in the lack of >>> guarding against compromise of the encrypted information under the >>>mistaken >>> impression that it can't be decrypted trivially. >>> >> >>The way I read the thread from Acee is that there aren't any KEK >>implementations with with particular YANG module, however Brian says >>there is with other YANG modules. I *think* when Acee is referring to >>obfuscation and less than ideal scenarios, it is with the currently >>deployed implementations that don't use KEKs. But the text and >>responses did seem to be commingled a bit too much. >> >>> >>>> Am I missing something? Was there something implementation specific >>>> that has the raw key stored with the encrypted data? >>> >>> >>> Perhaps the following exchange with the author: >>> >>> Adam: "By my reading, this is just talking about encrypting 'on the >>>disk' >>> storage on the device. Any processes involved in provisioning the >>>values or >>> using them to process traffic would have access to the plaintext, >>>presumably >>> by reading the encrypted form off disk, reading some keying material of= f >>> disk, and combining them to retrieve the plaintext key." >> >>It looks like version 20 had different assumptions about using the >>KEK. I *think* this is describing usage without a KEK and may be part >>of why Acee is asking for more implementation guidance... so I'll keep >>my discuss to see if we can shape that up more. This is helpful as I >>think I see the gap more now as to what he might be looking for in >>terms of guidance. >> >>Here's the text from -20: >> >>When configured, the key-strings can be encrypted using the AES Key >> Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is >> not included in the YANG model and must be set or derived independent >> >>Lindem, et al. Expires October 20, 2017 [Page 15] >>Internet-Draft YANG Key Chain April 2017 >> >> of key-chain configuration. When AES key-encryption is used, the >> hex-key-string feature is also required since the encrypted keys will >> contain characters that are not representable in the YANG string >> built-in type [YANG]. AES key-encryption MAY be used for added key >> security in situations where the NETCONF Access Control Mode is not >> available. >> >>> >>> Acee: "This is the correct interpretation." >>> >>> /a >> >>Thanks. >> >>-- >> >>Best regards, >>Kathleen > --=20 Best regards, Kathleen From nobody Wed Apr 26 13:52:53 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D034912EB24; Wed, 26 Apr 2017 13:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZci8XvbgDv3; Wed, 26 Apr 2017 13:52:43 -0700 (PDT) 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 BB0641294A5; Wed, 26 Apr 2017 13:52:43 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3QKqeQl081956 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 15:52:41 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Kathleen Moriarty Cc: The IESG , Jeff Tantsura , rtgwg-chairs@ietf.org, draft-ietf-rtgwg-yang-key-chain@ietf.org, rtgwg@ietf.org References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> From: Adam Roach Message-ID: Date: Wed, 26 Apr 2017 15:52:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:52:46 -0000 Sorry for top-posting, but I want to see if we can untangle something. I'm glad this is getting clearer for you, but it's just getting more confusing for me. In the -20 version of the document, there was text about using a KEK for data in motion (section 5 paragraph 3), and a separate mention of using a KEK for data at rest (section 5, final paragraph)[1]. For clarity: for the remainder of this thread, I will refer to these as KEK-motion and KEK-rest respectively. For additional clarity, the exchange with Acee I cite below predates the release of the -21 version of the document, so it can only be in reference to the -20 version. While I see that there are probably some operational issues that need to be resolved regarding KEK-motion, I would like to treat them separately from my concerns with KEK-rest. My concern here is exclusively with regards to KEK-rest, which seems to be suffering some degree of conflation with KEK-motion, and which will have distinctly different considerations regarding whether and how it can be compromised. I have more to say on this, but would like to pause and make sure we're in concordance that there are two unrelated KEKs in play here. /a ____ [1] I cite as evidence that these are two different KEKs under discussion the following two points: (a) the third paragraph talks about KEKs in terms of RFC 5649, which requires AES; while the final paragraph talks about encryption "or obfuscation," which clearly can't be RFC 5649; and (b) in the -21 version of the document, all mention of RFC 5649 has been stricken, while the final paragraph of section 5 remains. On 4/26/17 3:30 PM, Kathleen Moriarty wrote: > Hi Adam, > > I think I see where we are coming to different conclusions.... > > On Wed, Apr 26, 2017 at 4:18 PM, Adam Roach wrote: >> On 4/26/17 2:36 PM, Kathleen Moriarty wrote: >>> On Wed, Apr 26, 2017 at 2:42 PM, Adam Roach wrote: >>>> On 4/26/17 11:34 AM, Kathleen Moriarty wrote: >>>>> Since the following text int he Security Considerations section is a >>>>> recommendation, IMO it would be better to drop "or otherwise obfuscated" >>>>> from the sentence as encrypting the keys really should be the >>>>> recommendation. Can we make this update? >>>>> >>>>> It is RECOMMENDED that keys be encrypted or otherwise obfuscated >>>>> when >>>>> stored internally on a network device supporting this >>>>> specification. >>>>> >>>>> If obfuscation is what happens more often in practice, maybe mention >>>>> this >>>>> as a fallback from the recommendation, but not make them sound >>>>> equivalent? >>>> >>>> >>>> To be clear -- the current guidance from the security area is to perform >>>> this kind of encryption, where you have encrypted material living >>>> side-by-side with the key necessary to decrypt it? >>> We are talking about using a key encrypting key (KEK) and storing >>> that, not storing the raw key next to the encrypted data as far as I >>> can tell. >> >> Right. >> >>> Additionally, I haven't seen a discussion on the hardware >>> this is expected to run on. >> >> That might be appropriate matter for the draft, if it is going to make this >> recommendation. >> >>> Some implementations of KEK solutions use dedicated hardware for the >>> KEK and require authentication for access to the key, hence preventing >>> generic access and side-by-side storage of the KEK's protected key, >>> and encrypted data. I'd rather see a KEK used than just a key stored >>> in any case. Are you arguing for not using any encryption at all? >> >> I'll defer to you, of course, since you have presumably given the topic more >> thought than I have, but: yes. >> >> Absent something like an HSM or forcing human intervention whenever a >> process starts (or restarts), it seems that the scheme described in section >> 5 doesn't actually deter a competent attacker from obtaining the keys. My >> impression is that storing information in an encrypted form that can be >> trivially decrypted by an attacker provides a false sense of security to >> equipment operators. >> >> If the scheme in section 5 *does* require the kind of prerequisites you >> posit, such as dedicated security hardware, it seems that such prerequisites >> should be mentioned alongside the recommendation. >> >>> For YANG modules, couldn't the application via NETCONF/RESTCONF >>> accessing the module provide the credentials to access the key >>> protected by the KEK? >> >> That solves the issues with provisioning, but doesn't seem to help the >> processes actually involved in routing. >> >>> Some implementations could store the KEK in >>> dedicated hardware as well. In this way, storing the KEK and data >>> together is not the same as storing a key right next to the data it is >>> protecting. >> >> This makes perfect sense; and it should probably be in the document. >> >>> Use of a KEK is better then not encrypting and can be done >>> well. >> >> It can also be done poorly, and the mention of obfuscation (along with the >> exchange I cite below) leads me to believe that -- absent concrete guidance >> to the contrary -- implementors will choose to do it poorly. It's not clear >> that doing this poorly provides any benefit, and it seems to me that it may >> cause harm: if something _looks_ secure but isn't, doesn't that have the >> potential for operators to incorrectly treat it as secure? Again, this is >> more your area than mine and so I will defer to your opinion on the topic; >> but from a lay perspective, this seems likely to result in the lack of >> guarding against compromise of the encrypted information under the mistaken >> impression that it can't be decrypted trivially. >> > The way I read the thread from Acee is that there aren't any KEK > implementations with with particular YANG module, however Brian says > there is with other YANG modules. I *think* when Acee is referring to > obfuscation and less than ideal scenarios, it is with the currently > deployed implementations that don't use KEKs. But the text and > responses did seem to be commingled a bit too much. > >>> Am I missing something? Was there something implementation specific >>> that has the raw key stored with the encrypted data? >> >> Perhaps the following exchange with the author: >> >> Adam: "By my reading, this is just talking about encrypting 'on the disk' >> storage on the device. Any processes involved in provisioning the values or >> using them to process traffic would have access to the plaintext, presumably >> by reading the encrypted form off disk, reading some keying material off >> disk, and combining them to retrieve the plaintext key." > It looks like version 20 had different assumptions about using the > KEK. I *think* this is describing usage without a KEK and may be part > of why Acee is asking for more implementation guidance... so I'll keep > my discuss to see if we can shape that up more. This is helpful as I > think I see the gap more now as to what he might be looking for in > terms of guidance. > > Here's the text from -20: > > When configured, the key-strings can be encrypted using the AES Key > Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is > not included in the YANG model and must be set or derived independent > > Lindem, et al. Expires October 20, 2017 [Page 15] > Internet-Draft YANG Key Chain April 2017 > > of key-chain configuration. When AES key-encryption is used, the > hex-key-string feature is also required since the encrypted keys will > contain characters that are not representable in the YANG string > built-in type [YANG]. AES key-encryption MAY be used for added key > security in situations where the NETCONF Access Control Mode is not > available. > >> Acee: "This is the correct interpretation." >> >> /a > Thanks. > From nobody Wed Apr 26 13:55:14 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E8A1294EC; Wed, 26 Apr 2017 13:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0sKOXxNgnhA; Wed, 26 Apr 2017 13:55:11 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF34127342; Wed, 26 Apr 2017 13:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11774; q=dns/txt; s=iport; t=1493240111; x=1494449711; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VeFmy1PV1YQGG04mPvu/j3YTQxfRZ073Q+x7wZTUVZ0=; b=jWQyNi+MkPtg94T9DaSMSHxRXROv8HZhI5sN7/BsC+9Nj6RRcq+/ofGv bkii+lhbTgmrePH1my3EDzb63Wt7J2essdnBA2foopfzcZUnfP2EkwQjh LvU3yfxi4cIzkZ7XXHv4qCtA0zMnPmO0Kgl+N2v2BMF3VnjZpF2tDlwTX E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOAQBACAFZ/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1WBbQeDYYoWkUmIIY1Kgg+GJAIahBA/GAECAQEBAQEBAWsohRY?= =?us-ascii?q?BBSMRRRACAQgYAgImAgICHxEVEAIEDgUbiWgDFas6giaHOA2DXwEBAQEBAQQBA?= =?us-ascii?q?QEBAQEBIYELhyeCD4ELglOBVCQUgwaCXwWdFTsBjj+ETIIChTeDZYZAiHSCJYk?= =?us-ascii?q?NAR84gQdlFYUxHBmBSnUBhjgOF4EKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208";a="416442387" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2017 20:55:10 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3QKt9Qp007217 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Apr 2017 20:55:10 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 16:55:09 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 26 Apr 2017 16:55:09 -0400 From: "Acee Lindem (acee)" To: Kathleen Moriarty CC: Adam Roach , "Brian Weis (bew)" , "Jeff Tantsura" , "rtgwg-chairs@ietf.org" , The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Index: AQHSvsRbaK6mr1jQpUuQYLHDV2KBn6HYWesAgAADZoD//7+ggIAARUkA//++/wA= Date: Wed, 26 Apr 2017 20:55:09 +0000 Message-ID: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <75177E87FB301543B3C0A082F36D8901@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:55:13 -0000 S2F0aGxlZW4sDQoNCk9uIDQvMjYvMTcsIDQ6NDcgUE0sICJLYXRobGVlbiBNb3JpYXJ0eSINCjxr YXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5BY2VlLA0KPg0KPg0K Pg0KPk9uIFdlZCwgQXByIDI2LCAyMDE3IGF0IDQ6MzkgUE0sIEFjZWUgTGluZGVtIChhY2VlKSA8 YWNlZUBjaXNjby5jb20+DQo+d3JvdGU6DQo+PiBLYXRobGVlbiwgQnJpYW4sDQo+Pg0KPj4gU2lu Y2UgS0VLIGFzIGRlc2NyaWJlZCBpbiBSRkMgNTY0OSBpcyBub3QgcmVhZHkgZm9yIHByaW1lIHRp bWUsIHdoeQ0KPj5kb27igJl0DQo+DQo+VGhpcyBpcyB3aWRlbHkgZGVwbG95ZWQgaW4gb3RoZXIg dXNlIGNhc2VzLA0KDQpOb25lIG9mIHRoZXNlIHVzZSBjYXNlcyBhcmUgZG9jdW1lbnRlZCBpbiBJ RVRGIFJGQ3Mgb3IgZHJhZnRzLg0KDQo+c28gSSBhbSBub3QgZm9sbG93aW5nIHRoaXMNCj5zdGF0 ZW1lbnQgdGhhdCBpdCBpc24ndCByZWFkeSBmb3IgcHJpbWUgdGltZS4gIFJGQzU2NDkgaXMNCj5z dHJhaWdodGZvcndhcmQuICBXaGF0IGlzIHRoZSBnYXAgZm9yIHlvdXIgdXNhZ2UgdGhhdCByZXF1 aXJlcw0KPmFkZGl0aW9uYWwgZ3VpZGFuY2U/ICBCcmlhbiBzYXlzIHRoaXMgaW4gaW4gdXNlIGZv ciBvdGhlciBZQU5HIG1vZHVsZXMNCj5hbHJlYWR5IGFzIHdlbGwuICBDb3VsZCB5b3UgcGxlYXNl IGJlIG1vcmUgZXhwbGljaXQgaW4gdGVybXMgb2Ygd2hhdA0KPnlvdSBuZWVkIGZvciBndWlkYW5j ZS4gIEkgb2ZmZXJlZCBhIHN1Z2dlc3Rpb24sIGlmIHRoYXQgaXNuJ3QgZW5vdWdoLA0KPmNvdWxk IHlvdSBwbGVhc2UgZXhwbGFpbiB0aGUgZ2FwIGFzIHlvdSBzZWUgaXQgc28gd2UgY2FuIGFzc2lz dD8NCg0KU29ycnksIEkgbXVzdCBoYXZlIG1pc3NlZCB0aGUgdGV4dCB5b3UgcmVjb21tZW5kZWQu IFBsZWFzZSBwcm92aWRlIGl0DQphZ2FpbiBhbmQgSSB3aWxsIHJlc3RvcmUgdGhlIG9wdGlvbiB3 aXRoIHRoZSBndWlkYW5jZSB0aGF0IGlzIG1pc3NpbmcgZnJvbQ0KUkZDIDU2NDkuIA0KDQpUaGFu a3MsDQpBY2VlIA0KDQoNCg0KDQo+DQo+VGhhbmsgeW91LA0KPkthdGhsZWVuDQo+DQo+PiB5b3Ug dGFrZSB0aGlzIHVwIGFzIGEgc2VwYXJhdGUgZHJhZnQgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGhv bGQgdGhpcw0KPj4gaW1wb3J0YW50IGRvY3VtZW50IGhvc3RhZ2U/IFdlIGhhdmUgdGhlIE5FVENP TkYgQWNjZXNzIENvbnRyb2wgTW9kZWwNCj4+IChOQUNNKSB0byBwcm90ZWN0IHRoZSBrZXlzIGR1 cmluZyB0cmFuc3BvcnQgKHdoaWNoIGhhcyBiZWVuDQo+PmltcGxlbWVudGVkKS4NCj4+IE9idmlv dXNseSwga2V5LXN0cmluZ3MgYXJlIHN0b3JlZCBvbiBkZXZpY2VzIHRvZGF5IHNpbmNlIHRoZXkg YXJlIGJlaW5nDQo+PiB1c2VkIGZvciBwcm90b2NvbCBhdXRoZW50aWNhdGlvbiBhbmQgZW5jcnlw dGlvbiBzbyB0aGlzIGlzIHRvdGFsbHkNCj4+IG9ydGhvZ29uYWwgdG8gdGhlIFlBTkcgbW9kZWwg YmVpbmcgdXNlZCB0byBwcm92aXNpb24gdGhlbS4NCj4+DQo+PiBUaGFua3MsDQo+PiBBY2VlDQo+ Pg0KPj4gT24gNC8yNi8xNywgNDozMCBQTSwgIkthdGhsZWVuIE1vcmlhcnR5Ig0KPj4gPGthdGhs ZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4+DQo+Pj5IaSBBZGFtLA0KPj4+ DQo+Pj5JIHRoaW5rIEkgc2VlIHdoZXJlIHdlIGFyZSBjb21pbmcgdG8gZGlmZmVyZW50IGNvbmNs dXNpb25zLi4uLg0KPj4+DQo+Pj5PbiBXZWQsIEFwciAyNiwgMjAxNyBhdCA0OjE4IFBNLCBBZGFt IFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPiB3cm90ZToNCj4+Pj4gT24gNC8yNi8xNyAyOjM2IFBN LCBLYXRobGVlbiBNb3JpYXJ0eSB3cm90ZToNCj4+Pj4+DQo+Pj4+PiBPbiBXZWQsIEFwciAyNiwg MjAxNyBhdCAyOjQyIFBNLCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPiB3cm90ZToNCj4+ Pj4+Pg0KPj4+Pj4+IE9uIDQvMjYvMTcgMTE6MzQgQU0sIEthdGhsZWVuIE1vcmlhcnR5IHdyb3Rl Og0KPj4+Pj4+Pg0KPj4+Pj4+PiBTaW5jZSB0aGUgZm9sbG93aW5nIHRleHQgaW50IGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMNCj4+Pj4+Pj5hDQo+Pj4+Pj4+IHJlY29tbWVu ZGF0aW9uLCBJTU8gaXQgd291bGQgYmUgYmV0dGVyIHRvIGRyb3AgIm9yIG90aGVyd2lzZQ0KPj4+ Pj4+Pm9iZnVzY2F0ZWQiDQo+Pj4+Pj4+IGZyb20gdGhlIHNlbnRlbmNlIGFzIGVuY3J5cHRpbmcg dGhlIGtleXMgcmVhbGx5IHNob3VsZCBiZSB0aGUNCj4+Pj4+Pj4gcmVjb21tZW5kYXRpb24uICBD YW4gd2UgbWFrZSB0aGlzIHVwZGF0ZT8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICBJdCBpcyBSRUNP TU1FTkRFRCB0aGF0IGtleXMgYmUgZW5jcnlwdGVkIG9yIG90aGVyd2lzZQ0KPj4+Pj4+Pm9iZnVz Y2F0ZWQNCj4+Pj4+Pj4gd2hlbg0KPj4+Pj4+PiAgICAgIHN0b3JlZCBpbnRlcm5hbGx5IG9uIGEg bmV0d29yayBkZXZpY2Ugc3VwcG9ydGluZyB0aGlzDQo+Pj4+Pj4+IHNwZWNpZmljYXRpb24uDQo+ Pj4+Pj4+DQo+Pj4+Pj4+IElmIG9iZnVzY2F0aW9uIGlzIHdoYXQgaGFwcGVucyBtb3JlIG9mdGVu IGluIHByYWN0aWNlLCBtYXliZQ0KPj4+Pj4+Pm1lbnRpb24NCj4+Pj4+Pj4gdGhpcw0KPj4+Pj4+ PiBhcyBhIGZhbGxiYWNrIGZyb20gdGhlIHJlY29tbWVuZGF0aW9uLCBidXQgbm90IG1ha2UgdGhl bSBzb3VuZA0KPj4+Pj4+PiBlcXVpdmFsZW50Pw0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+IFRvIGJlIGNsZWFyIC0tIHRoZSBjdXJyZW50IGd1aWRhbmNlIGZyb20gdGhlIHNlY3VyaXR5 IGFyZWEgaXMgdG8NCj4+Pj4+PnBlcmZvcm0NCj4+Pj4+PiB0aGlzIGtpbmQgb2YgZW5jcnlwdGlv biwgd2hlcmUgeW91IGhhdmUgZW5jcnlwdGVkIG1hdGVyaWFsIGxpdmluZw0KPj4+Pj4+IHNpZGUt Ynktc2lkZSB3aXRoIHRoZSBrZXkgbmVjZXNzYXJ5IHRvIGRlY3J5cHQgaXQ/DQo+Pj4+Pg0KPj4+ Pj4gV2UgYXJlIHRhbGtpbmcgYWJvdXQgdXNpbmcgYSBrZXkgZW5jcnlwdGluZyBrZXkgKEtFSykg YW5kIHN0b3JpbmcNCj4+Pj4+IHRoYXQsIG5vdCBzdG9yaW5nIHRoZSByYXcga2V5IG5leHQgdG8g dGhlIGVuY3J5cHRlZCBkYXRhIGFzIGZhciBhcyBJDQo+Pj4+PiBjYW4gdGVsbC4NCj4+Pj4NCj4+ Pj4NCj4+Pj4gUmlnaHQuDQo+Pj4+DQo+Pj4+PiBBZGRpdGlvbmFsbHksIEkgaGF2ZW4ndCBzZWVu IGEgZGlzY3Vzc2lvbiBvbiB0aGUgaGFyZHdhcmUNCj4+Pj4+IHRoaXMgaXMgZXhwZWN0ZWQgdG8g cnVuIG9uLg0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGF0IG1pZ2h0IGJlIGFwcHJvcHJpYXRlIG1hdHRl ciBmb3IgdGhlIGRyYWZ0LCBpZiBpdCBpcyBnb2luZyB0byBtYWtlDQo+Pj4+dGhpcw0KPj4+PiBy ZWNvbW1lbmRhdGlvbi4NCj4+Pj4NCj4+Pj4+IFNvbWUgaW1wbGVtZW50YXRpb25zIG9mIEtFSyBz b2x1dGlvbnMgdXNlIGRlZGljYXRlZCBoYXJkd2FyZSBmb3IgdGhlDQo+Pj4+PiBLRUsgYW5kIHJl cXVpcmUgYXV0aGVudGljYXRpb24gZm9yIGFjY2VzcyB0byB0aGUga2V5LCBoZW5jZQ0KPj4+Pj5w cmV2ZW50aW5nDQo+Pj4+PiBnZW5lcmljIGFjY2VzcyBhbmQgc2lkZS1ieS1zaWRlIHN0b3JhZ2Ug b2YgdGhlIEtFSydzIHByb3RlY3RlZCBrZXksDQo+Pj4+PiBhbmQgZW5jcnlwdGVkIGRhdGEuICBJ J2QgcmF0aGVyIHNlZSBhIEtFSyB1c2VkIHRoYW4ganVzdCBhIGtleSBzdG9yZWQNCj4+Pj4+IGlu IGFueSBjYXNlLiAgQXJlIHlvdSBhcmd1aW5nIGZvciBub3QgdXNpbmcgYW55IGVuY3J5cHRpb24g YXQgYWxsPw0KPj4+Pg0KPj4+Pg0KPj4+PiBJJ2xsIGRlZmVyIHRvIHlvdSwgb2YgY291cnNlLCBz aW5jZSB5b3UgaGF2ZSBwcmVzdW1hYmx5IGdpdmVuIHRoZQ0KPj4+PnRvcGljDQo+Pj4+bW9yZQ0K Pj4+PiB0aG91Z2h0IHRoYW4gSSBoYXZlLCBidXQ6IHllcy4NCj4+Pj4NCj4+Pj4gQWJzZW50IHNv bWV0aGluZyBsaWtlIGFuIEhTTSBvciBmb3JjaW5nIGh1bWFuIGludGVydmVudGlvbiB3aGVuZXZl ciBhDQo+Pj4+IHByb2Nlc3Mgc3RhcnRzIChvciByZXN0YXJ0cyksIGl0IHNlZW1zIHRoYXQgdGhl IHNjaGVtZSBkZXNjcmliZWQgaW4NCj4+Pj5zZWN0aW9uDQo+Pj4+IDUgZG9lc24ndCBhY3R1YWxs eSBkZXRlciBhIGNvbXBldGVudCBhdHRhY2tlciBmcm9tIG9idGFpbmluZyB0aGUga2V5cy4NCj4+ Pj5NeQ0KPj4+PiBpbXByZXNzaW9uIGlzIHRoYXQgc3RvcmluZyBpbmZvcm1hdGlvbiBpbiBhbiBl bmNyeXB0ZWQgZm9ybSB0aGF0IGNhbg0KPj4+PmJlDQo+Pj4+IHRyaXZpYWxseSBkZWNyeXB0ZWQg YnkgYW4gYXR0YWNrZXIgcHJvdmlkZXMgYSBmYWxzZSBzZW5zZSBvZiBzZWN1cml0eQ0KPj4+PnRv DQo+Pj4+IGVxdWlwbWVudCBvcGVyYXRvcnMuDQo+Pj4+DQo+Pj4+IElmIHRoZSBzY2hlbWUgaW4g c2VjdGlvbiA1ICpkb2VzKiByZXF1aXJlIHRoZSBraW5kIG9mIHByZXJlcXVpc2l0ZXMNCj4+Pj55 b3UNCj4+Pj4gcG9zaXQsIHN1Y2ggYXMgZGVkaWNhdGVkIHNlY3VyaXR5IGhhcmR3YXJlLCBpdCBz ZWVtcyB0aGF0IHN1Y2gNCj4+Pj5wcmVyZXF1aXNpdGVzDQo+Pj4+IHNob3VsZCBiZSBtZW50aW9u ZWQgYWxvbmdzaWRlIHRoZSByZWNvbW1lbmRhdGlvbi4NCj4+Pj4NCj4+Pj4+IEZvciBZQU5HIG1v ZHVsZXMsIGNvdWxkbid0IHRoZSBhcHBsaWNhdGlvbiB2aWEgTkVUQ09ORi9SRVNUQ09ORg0KPj4+ Pj4gYWNjZXNzaW5nIHRoZSBtb2R1bGUgcHJvdmlkZSB0aGUgY3JlZGVudGlhbHMgdG8gYWNjZXNz IHRoZSBrZXkNCj4+Pj4+IHByb3RlY3RlZCBieSB0aGUgS0VLPw0KPj4+Pg0KPj4+Pg0KPj4+PiBU aGF0IHNvbHZlcyB0aGUgaXNzdWVzIHdpdGggcHJvdmlzaW9uaW5nLCBidXQgZG9lc24ndCBzZWVt IHRvIGhlbHAgdGhlDQo+Pj4+IHByb2Nlc3NlcyBhY3R1YWxseSBpbnZvbHZlZCBpbiByb3V0aW5n Lg0KPj4+Pg0KPj4+Pj4gU29tZSBpbXBsZW1lbnRhdGlvbnMgY291bGQgc3RvcmUgdGhlIEtFSyBp bg0KPj4+Pj4gZGVkaWNhdGVkIGhhcmR3YXJlIGFzIHdlbGwuIEluIHRoaXMgd2F5LCBzdG9yaW5n IHRoZSBLRUsgYW5kIGRhdGENCj4+Pj4+IHRvZ2V0aGVyIGlzIG5vdCB0aGUgc2FtZSBhcyBzdG9y aW5nIGEga2V5IHJpZ2h0IG5leHQgdG8gdGhlIGRhdGEgaXQNCj4+Pj4+aXMNCj4+Pj4+IHByb3Rl Y3RpbmcuDQo+Pj4+DQo+Pj4+DQo+Pj4+IFRoaXMgbWFrZXMgcGVyZmVjdCBzZW5zZTsgYW5kIGl0 IHNob3VsZCBwcm9iYWJseSBiZSBpbiB0aGUgZG9jdW1lbnQuDQo+Pj4+DQo+Pj4+PiBVc2Ugb2Yg YSBLRUsgaXMgYmV0dGVyIHRoZW4gbm90IGVuY3J5cHRpbmcgYW5kIGNhbiBiZSBkb25lDQo+Pj4+ PiB3ZWxsLg0KPj4+Pg0KPj4+Pg0KPj4+PiBJdCBjYW4gYWxzbyBiZSBkb25lIHBvb3JseSwgYW5k IHRoZSBtZW50aW9uIG9mIG9iZnVzY2F0aW9uIChhbG9uZyB3aXRoDQo+Pj4+dGhlDQo+Pj4+IGV4 Y2hhbmdlIEkgY2l0ZSBiZWxvdykgbGVhZHMgbWUgdG8gYmVsaWV2ZSB0aGF0IC0tIGFic2VudCBj b25jcmV0ZQ0KPj4+Pmd1aWRhbmNlDQo+Pj4+IHRvIHRoZSBjb250cmFyeSAtLSBpbXBsZW1lbnRv cnMgd2lsbCBjaG9vc2UgdG8gZG8gaXQgcG9vcmx5LiBJdCdzIG5vdA0KPj4+PmNsZWFyDQo+Pj4+ IHRoYXQgZG9pbmcgdGhpcyBwb29ybHkgcHJvdmlkZXMgYW55IGJlbmVmaXQsIGFuZCBpdCBzZWVt cyB0byBtZSB0aGF0DQo+Pj4+aXQNCj4+Pj5tYXkNCj4+Pj4gY2F1c2UgaGFybTogaWYgc29tZXRo aW5nIF9sb29rc18gc2VjdXJlIGJ1dCBpc24ndCwgZG9lc24ndCB0aGF0IGhhdmUNCj4+Pj50aGUN Cj4+Pj4gcG90ZW50aWFsIGZvciBvcGVyYXRvcnMgdG8gaW5jb3JyZWN0bHkgdHJlYXQgaXQgYXMg c2VjdXJlPyBBZ2FpbiwgdGhpcw0KPj4+PmlzDQo+Pj4+IG1vcmUgeW91ciBhcmVhIHRoYW4gbWlu ZSBhbmQgc28gSSB3aWxsIGRlZmVyIHRvIHlvdXIgb3BpbmlvbiBvbiB0aGUNCj4+Pj50b3BpYzsN Cj4+Pj4gYnV0IGZyb20gYSBsYXkgcGVyc3BlY3RpdmUsIHRoaXMgc2VlbXMgbGlrZWx5IHRvIHJl c3VsdCBpbiB0aGUgbGFjayBvZg0KPj4+PiBndWFyZGluZyBhZ2FpbnN0IGNvbXByb21pc2Ugb2Yg dGhlIGVuY3J5cHRlZCBpbmZvcm1hdGlvbiB1bmRlciB0aGUNCj4+Pj5taXN0YWtlbg0KPj4+PiBp bXByZXNzaW9uIHRoYXQgaXQgY2FuJ3QgYmUgZGVjcnlwdGVkIHRyaXZpYWxseS4NCj4+Pj4NCj4+ Pg0KPj4+VGhlIHdheSBJIHJlYWQgdGhlIHRocmVhZCBmcm9tIEFjZWUgaXMgdGhhdCB0aGVyZSBh cmVuJ3QgYW55IEtFSw0KPj4+aW1wbGVtZW50YXRpb25zIHdpdGggd2l0aCBwYXJ0aWN1bGFyIFlB TkcgbW9kdWxlLCBob3dldmVyIEJyaWFuIHNheXMNCj4+PnRoZXJlIGlzIHdpdGggb3RoZXIgWUFO RyBtb2R1bGVzLiAgSSAqdGhpbmsqIHdoZW4gQWNlZSBpcyByZWZlcnJpbmcgdG8NCj4+Pm9iZnVz Y2F0aW9uIGFuZCBsZXNzIHRoYW4gaWRlYWwgc2NlbmFyaW9zLCBpdCBpcyB3aXRoIHRoZSBjdXJy ZW50bHkNCj4+PmRlcGxveWVkIGltcGxlbWVudGF0aW9ucyB0aGF0IGRvbid0IHVzZSBLRUtzLiAg QnV0IHRoZSB0ZXh0IGFuZA0KPj4+cmVzcG9uc2VzIGRpZCBzZWVtIHRvIGJlIGNvbW1pbmdsZWQg YSBiaXQgdG9vIG11Y2guDQo+Pj4NCj4+Pj4NCj4+Pj4+IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/ ICBXYXMgdGhlcmUgc29tZXRoaW5nIGltcGxlbWVudGF0aW9uIHNwZWNpZmljDQo+Pj4+PiB0aGF0 IGhhcyB0aGUgcmF3IGtleSBzdG9yZWQgd2l0aCB0aGUgZW5jcnlwdGVkIGRhdGE/DQo+Pj4+DQo+ Pj4+DQo+Pj4+IFBlcmhhcHMgdGhlIGZvbGxvd2luZyBleGNoYW5nZSB3aXRoIHRoZSBhdXRob3I6 DQo+Pj4+DQo+Pj4+IEFkYW06ICJCeSBteSByZWFkaW5nLCB0aGlzIGlzIGp1c3QgdGFsa2luZyBh Ym91dCBlbmNyeXB0aW5nICdvbiB0aGUNCj4+Pj5kaXNrJw0KPj4+PiBzdG9yYWdlIG9uIHRoZSBk ZXZpY2UuIEFueSBwcm9jZXNzZXMgaW52b2x2ZWQgaW4gcHJvdmlzaW9uaW5nIHRoZQ0KPj4+PnZh bHVlcyBvcg0KPj4+PiB1c2luZyB0aGVtIHRvIHByb2Nlc3MgdHJhZmZpYyB3b3VsZCBoYXZlIGFj Y2VzcyB0byB0aGUgcGxhaW50ZXh0LA0KPj4+PnByZXN1bWFibHkNCj4+Pj4gYnkgcmVhZGluZyB0 aGUgZW5jcnlwdGVkIGZvcm0gb2ZmIGRpc2ssIHJlYWRpbmcgc29tZSBrZXlpbmcgbWF0ZXJpYWwN Cj4+Pj5vZmYNCj4+Pj4gZGlzaywgYW5kIGNvbWJpbmluZyB0aGVtIHRvIHJldHJpZXZlIHRoZSBw bGFpbnRleHQga2V5LiINCj4+Pg0KPj4+SXQgbG9va3MgbGlrZSB2ZXJzaW9uIDIwIGhhZCBkaWZm ZXJlbnQgYXNzdW1wdGlvbnMgYWJvdXQgdXNpbmcgdGhlDQo+Pj5LRUsuICBJICp0aGluayogdGhp cyBpcyBkZXNjcmliaW5nIHVzYWdlIHdpdGhvdXQgYSBLRUsgYW5kIG1heSBiZSBwYXJ0DQo+Pj5v ZiB3aHkgQWNlZSBpcyBhc2tpbmcgZm9yIG1vcmUgaW1wbGVtZW50YXRpb24gZ3VpZGFuY2UuLi4g c28gSSdsbCBrZWVwDQo+Pj5teSBkaXNjdXNzIHRvIHNlZSBpZiB3ZSBjYW4gc2hhcGUgdGhhdCB1 cCBtb3JlLiAgVGhpcyBpcyBoZWxwZnVsIGFzIEkNCj4+PnRoaW5rIEkgc2VlIHRoZSBnYXAgbW9y ZSBub3cgYXMgdG8gd2hhdCBoZSBtaWdodCBiZSBsb29raW5nIGZvciBpbg0KPj4+dGVybXMgb2Yg Z3VpZGFuY2UuDQo+Pj4NCj4+PkhlcmUncyB0aGUgdGV4dCBmcm9tIC0yMDoNCj4+Pg0KPj4+V2hl biBjb25maWd1cmVkLCB0aGUga2V5LXN0cmluZ3MgY2FuIGJlIGVuY3J5cHRlZCB1c2luZyB0aGUg QUVTIEtleQ0KPj4+ICAgV3JhcCBhbGdvcml0aG0gW0FFUy1LRVktV1JBUF0uICBUaGUgQUVTIGtl eS1lbmNyeXB0aW9uIGtleSAoS0VLKSBpcw0KPj4+ICAgbm90IGluY2x1ZGVkIGluIHRoZSBZQU5H IG1vZGVsIGFuZCBtdXN0IGJlIHNldCBvciBkZXJpdmVkIGluZGVwZW5kZW50DQo+Pj4NCj4+Pkxp bmRlbSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMCwgMjAxNyAgICAgICAgICAg ICAgIFtQYWdlIDE1XQ0KPj4+SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBZQU5HIEtleSBD aGFpbiAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDE3DQo+Pj4NCj4+PiAgIG9mIGtleS1jaGFp biBjb25maWd1cmF0aW9uLiAgV2hlbiBBRVMga2V5LWVuY3J5cHRpb24gaXMgdXNlZCwgdGhlDQo+ Pj4gICBoZXgta2V5LXN0cmluZyBmZWF0dXJlIGlzIGFsc28gcmVxdWlyZWQgc2luY2UgdGhlIGVu Y3J5cHRlZCBrZXlzIHdpbGwNCj4+PiAgIGNvbnRhaW4gY2hhcmFjdGVycyB0aGF0IGFyZSBub3Qg cmVwcmVzZW50YWJsZSBpbiB0aGUgWUFORyBzdHJpbmcNCj4+PiAgIGJ1aWx0LWluIHR5cGUgW1lB TkddLiAgQUVTIGtleS1lbmNyeXB0aW9uIE1BWSBiZSB1c2VkIGZvciBhZGRlZCBrZXkNCj4+PiAg IHNlY3VyaXR5IGluIHNpdHVhdGlvbnMgd2hlcmUgdGhlIE5FVENPTkYgQWNjZXNzIENvbnRyb2wg TW9kZSBpcyBub3QNCj4+PiAgIGF2YWlsYWJsZS4NCj4+Pg0KPj4+Pg0KPj4+PiBBY2VlOiAiVGhp cyBpcyB0aGUgY29ycmVjdCBpbnRlcnByZXRhdGlvbi4iDQo+Pj4+DQo+Pj4+IC9hDQo+Pj4NCj4+ PlRoYW5rcy4NCj4+Pg0KPj4+LS0NCj4+Pg0KPj4+QmVzdCByZWdhcmRzLA0KPj4+S2F0aGxlZW4N Cj4+DQo+DQo+DQo+DQo+LS0gDQo+DQo+QmVzdCByZWdhcmRzLA0KPkthdGhsZWVuDQoNCg== From nobody Wed Apr 26 17:49:24 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540FA12706D; Wed, 26 Apr 2017 17:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAcWLKBEkZ6R; Wed, 26 Apr 2017 17:49:14 -0700 (PDT) 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 50278124281; Wed, 26 Apr 2017 17:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13766; q=dns/txt; s=iport; t=1493254154; x=1494463754; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8EyURRdjkud5OgdADSNaAEzxtwIIBX2A3nPYhDQYOgM=; b=OypEgxwWz3TRN5EMHL2TJr/o1ea/E+OcXyMf/u65F3ajc2ssOPKsRtMP 20FXReBRTfb5HCD8kQWkX2sF3UG+LSJPSFf1GUcM6cim9X3UMEPzHC34z ZRoaj1OqjeQz5VOjOqGp5qQKae0kKvtjhssto8DfZ5HyhIpMX1rOUCPEw Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgAdPwFZ/51dJa1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNVYXoSB4NhihiRKSGIIY1Kgg8shXgCGoQQPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQIBIxFFBQsCAQgYAgImAgICHxEVEAIEDgUbiWgDDQgOq32CJoc2D?= =?us-ascii?q?YNfAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELhycrC4FZgQuCU4FUChEBCCsKJoI?= =?us-ascii?q?/LoIxBZ0VOwGOP4RMggKFN4NlhkCIdIIliQ0BHzh/CGUVRBIBhFocGYFKdQGGO?= =?us-ascii?q?A4XgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,256,1488844800"; d="scan'208";a="418181018" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2017 00:49:13 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3R0nCte011292 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Apr 2017 00:49:12 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 26 Apr 2017 20:49:12 -0400 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.1210.000; Wed, 26 Apr 2017 20:49:11 -0400 From: "Brian Weis (bew)" To: "Acee Lindem (acee)" CC: Kathleen Moriarty , Adam Roach , Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Index: AQHSvsRbqb2W9Jmlq0avruj6y/20M6HYWesAgAADZoD//7+ggIAARUkAgAACE4CAAEFjgA== Date: Thu, 27 Apr 2017 00:49:11 +0000 Message-ID: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.165] Content-Type: text/plain; charset="utf-8" Content-ID: <51D5E78CD1AC18439A323E39E6DC7156@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 00:49:16 -0000 SGkgS2F0aGxlZW4gYW5kIEFjZWUsDQoNCkp1c3QgYSBjbGFyaWZpY2F0aW9uIG9uIHdoYXQgSSBo YWQgc2FpZCBlYXJsaWVyLg0KDQo+IE9uIEFwciAyNiwgMjAxNywgYXQgMTo1NSBQTSwgQWNlZSBM aW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBLYXRobGVlbiwNCj4g DQo+IE9uIDQvMjYvMTcsIDQ6NDcgUE0sICJLYXRobGVlbiBNb3JpYXJ0eSINCj4gPGthdGhsZWVu Lm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+PiBBY2VlLA0KPj4gDQo+PiAN Cj4+IA0KPj4gT24gV2VkLCBBcHIgMjYsIDIwMTcgYXQgNDozOSBQTSwgQWNlZSBMaW5kZW0gKGFj ZWUpIDxhY2VlQGNpc2NvLmNvbT4NCj4+IHdyb3RlOg0KPj4+IEthdGhsZWVuLCBCcmlhbiwNCj4+ PiANCj4+PiBTaW5jZSBLRUsgYXMgZGVzY3JpYmVkIGluIFJGQyA1NjQ5IGlzIG5vdCByZWFkeSBm b3IgcHJpbWUgdGltZSwgd2h5DQo+Pj4gZG9u4oCZdA0KPj4gDQo+PiBUaGlzIGlzIHdpZGVseSBk ZXBsb3llZCBpbiBvdGhlciB1c2UgY2FzZXMsDQo+IA0KPiBOb25lIG9mIHRoZXNlIHVzZSBjYXNl cyBhcmUgZG9jdW1lbnRlZCBpbiBJRVRGIFJGQ3Mgb3IgZHJhZnRzLg0KDQpUaGUgQUVTIGtleSB3 cmFwIG1ldGhvZCBpdHNlbGYgaXMgd2VsbCB1bmRlcnN0b29kLCBhbmQgaWYgeW91IGxvb2sgYXQg dGhlIGNpdGF0aW9ucyBmb3IgUkZDIDMzOTQgYXQgPGh0dHA6Ly93d3cuYXJra28uY29tL3Rvb2xz L2FsbHN0YXRzL2NpdGF0aW9ucy1yZmMzMzk0Lmh0bWw+IGl0IGlzIGFjdHVhbGx5IHVzZWQgaW4g YSBudW1iZXIgb2YgSUVURiBwcm90b2NvbHMuIFRoaXMgaXMgdGhlIGJhc2lzIGZvciB3aHkgSSBv cmlnaW5hbGx5IHN1Z2dlc3RlZCB0aGF0IGl0IG1hZGUgc2Vuc2UgdG8gaW5jbHVkZSBpdCBpbiBh IFlBTkcgbW9kZWwgdGhhdCBkaXN0cmlidXRlcyBrZXlzLg0KDQo+IA0KPj4gc28gSSBhbSBub3Qg Zm9sbG93aW5nIHRoaXMNCj4+IHN0YXRlbWVudCB0aGF0IGl0IGlzbid0IHJlYWR5IGZvciBwcmlt ZSB0aW1lLiAgUkZDNTY0OSBpcw0KPj4gc3RyYWlnaHRmb3J3YXJkLiAgV2hhdCBpcyB0aGUgZ2Fw IGZvciB5b3VyIHVzYWdlIHRoYXQgcmVxdWlyZXMNCj4+IGFkZGl0aW9uYWwgZ3VpZGFuY2U/ICBC cmlhbiBzYXlzIHRoaXMgaW4gaW4gdXNlIGZvciBvdGhlciBZQU5HIG1vZHVsZXMNCj4+IGFscmVh ZHkgYXMgd2VsbC4gIA0KDQpBcG9sb2dpZXMsIEkgd2FzIHVuY2xlYXIgaW4gd2hhdCBJIHNhaWQu IEkgYW0gbm90IGFjdHVhbGx5IGF3YXJlIG9mIGl0IGJlaW5nIHVzZWQgaW4gb3RoZXIgWUFORyBt b2R1bGVzIOKApiBJIG1lYW50IHRvIGNvbW11bmljYXRlIHdoYXQgS2F0aGxlZW4gc2FpZCBtb3Jl IHN1Y2NpbmN0bHksIHdoaWNoIGlzIHRoYXQgdGhlIFJGQyAzMzk0IGFuZCBSRkMgNTY0OSBhcmUg aW1wbGVtZW50ZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2UgaW4gb3RoZXIgKG5vbi1ZQU5HIG1vZHVs ZSkgcHJvdG9jb2xzLiBOb25lIG9mIHRoZSBjaXRhdGlvbnMgaW4gdGhlIGxpc3QgYWJvdmUgYXBw ZWFyIHRvIGJlIFlBTkcgbW9kdWxlcywgYnV0IHRoZW4gSeKAmW0gbm90IHN1cmUgd2hldGhlciBv ciBub3QgYW55IG90aGVyIFlBTkcgbW9kdWxlcyBkaXN0cmlidXRlIGtleXMgZWl0aGVyLg0KDQpI b3BlIHRoYXQgaGVscHMsDQpCcmlhbg0KDQo+PiBDb3VsZCB5b3UgcGxlYXNlIGJlIG1vcmUgZXhw bGljaXQgaW4gdGVybXMgb2Ygd2hhdA0KPj4geW91IG5lZWQgZm9yIGd1aWRhbmNlLiAgSSBvZmZl cmVkIGEgc3VnZ2VzdGlvbiwgaWYgdGhhdCBpc24ndCBlbm91Z2gsDQo+PiBjb3VsZCB5b3UgcGxl YXNlIGV4cGxhaW4gdGhlIGdhcCBhcyB5b3Ugc2VlIGl0IHNvIHdlIGNhbiBhc3Npc3Q/DQo+IA0K PiBTb3JyeSwgSSBtdXN0IGhhdmUgbWlzc2VkIHRoZSB0ZXh0IHlvdSByZWNvbW1lbmRlZC4gUGxl YXNlIHByb3ZpZGUgaXQNCj4gYWdhaW4gYW5kIEkgd2lsbCByZXN0b3JlIHRoZSBvcHRpb24gd2l0 aCB0aGUgZ3VpZGFuY2UgdGhhdCBpcyBtaXNzaW5nIGZyb20NCj4gUkZDIDU2NDkuIA0KPiANCj4g VGhhbmtzLA0KPiBBY2VlIA0KPiANCj4gDQo+IA0KPiANCj4+IA0KPj4gVGhhbmsgeW91LA0KPj4g S2F0aGxlZW4NCj4+IA0KPj4+IHlvdSB0YWtlIHRoaXMgdXAgYXMgYSBzZXBhcmF0ZSBkcmFmdCBy YXRoZXIgdGhhbiB0cnlpbmcgdG8gaG9sZCB0aGlzDQo+Pj4gaW1wb3J0YW50IGRvY3VtZW50IGhv c3RhZ2U/IFdlIGhhdmUgdGhlIE5FVENPTkYgQWNjZXNzIENvbnRyb2wgTW9kZWwNCj4+PiAoTkFD TSkgdG8gcHJvdGVjdCB0aGUga2V5cyBkdXJpbmcgdHJhbnNwb3J0ICh3aGljaCBoYXMgYmVlbg0K Pj4+IGltcGxlbWVudGVkKS4NCj4+PiBPYnZpb3VzbHksIGtleS1zdHJpbmdzIGFyZSBzdG9yZWQg b24gZGV2aWNlcyB0b2RheSBzaW5jZSB0aGV5IGFyZSBiZWluZw0KPj4+IHVzZWQgZm9yIHByb3Rv Y29sIGF1dGhlbnRpY2F0aW9uIGFuZCBlbmNyeXB0aW9uIHNvIHRoaXMgaXMgdG90YWxseQ0KPj4+ IG9ydGhvZ29uYWwgdG8gdGhlIFlBTkcgbW9kZWwgYmVpbmcgdXNlZCB0byBwcm92aXNpb24gdGhl bS4NCj4+PiANCj4+PiBUaGFua3MsDQo+Pj4gQWNlZQ0KPj4+IA0KPj4+IE9uIDQvMjYvMTcsIDQ6 MzAgUE0sICJLYXRobGVlbiBNb3JpYXJ0eSINCj4+PiA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBn bWFpbC5jb20+IHdyb3RlOg0KPj4+IA0KPj4+PiBIaSBBZGFtLA0KPj4+PiANCj4+Pj4gSSB0aGlu ayBJIHNlZSB3aGVyZSB3ZSBhcmUgY29taW5nIHRvIGRpZmZlcmVudCBjb25jbHVzaW9ucy4uLi4N Cj4+Pj4gDQo+Pj4+IE9uIFdlZCwgQXByIDI2LCAyMDE3IGF0IDQ6MTggUE0sIEFkYW0gUm9hY2gg PGFkYW1Abm9zdHJ1bS5jb20+IHdyb3RlOg0KPj4+Pj4gT24gNC8yNi8xNyAyOjM2IFBNLCBLYXRo bGVlbiBNb3JpYXJ0eSB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+PiBPbiBXZWQsIEFwciAyNiwgMjAx NyBhdCAyOjQyIFBNLCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPiB3cm90ZToNCj4+Pj4+ Pj4gDQo+Pj4+Pj4+IE9uIDQvMjYvMTcgMTE6MzQgQU0sIEthdGhsZWVuIE1vcmlhcnR5IHdyb3Rl Og0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBTaW5jZSB0aGUgZm9sbG93aW5nIHRleHQgaW50IGhlIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gaXMNCj4+Pj4+Pj4+IGENCj4+Pj4+Pj4+IHJl Y29tbWVuZGF0aW9uLCBJTU8gaXQgd291bGQgYmUgYmV0dGVyIHRvIGRyb3AgIm9yIG90aGVyd2lz ZQ0KPj4+Pj4+Pj4gb2JmdXNjYXRlZCINCj4+Pj4+Pj4+IGZyb20gdGhlIHNlbnRlbmNlIGFzIGVu Y3J5cHRpbmcgdGhlIGtleXMgcmVhbGx5IHNob3VsZCBiZSB0aGUNCj4+Pj4+Pj4+IHJlY29tbWVu ZGF0aW9uLiAgQ2FuIHdlIG1ha2UgdGhpcyB1cGRhdGU/DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICAg ICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGtleXMgYmUgZW5jcnlwdGVkIG9yIG90aGVyd2lzZQ0K Pj4+Pj4+Pj4gb2JmdXNjYXRlZA0KPj4+Pj4+Pj4gd2hlbg0KPj4+Pj4+Pj4gICAgIHN0b3JlZCBp bnRlcm5hbGx5IG9uIGEgbmV0d29yayBkZXZpY2Ugc3VwcG9ydGluZyB0aGlzDQo+Pj4+Pj4+PiBz cGVjaWZpY2F0aW9uLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBJZiBvYmZ1c2NhdGlvbiBpcyB3aGF0 IGhhcHBlbnMgbW9yZSBvZnRlbiBpbiBwcmFjdGljZSwgbWF5YmUNCj4+Pj4+Pj4+IG1lbnRpb24N Cj4+Pj4+Pj4+IHRoaXMNCj4+Pj4+Pj4+IGFzIGEgZmFsbGJhY2sgZnJvbSB0aGUgcmVjb21tZW5k YXRpb24sIGJ1dCBub3QgbWFrZSB0aGVtIHNvdW5kDQo+Pj4+Pj4+PiBlcXVpdmFsZW50Pw0KPj4+ Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUbyBiZSBjbGVhciAtLSB0aGUgY3Vy cmVudCBndWlkYW5jZSBmcm9tIHRoZSBzZWN1cml0eSBhcmVhIGlzIHRvDQo+Pj4+Pj4+IHBlcmZv cm0NCj4+Pj4+Pj4gdGhpcyBraW5kIG9mIGVuY3J5cHRpb24sIHdoZXJlIHlvdSBoYXZlIGVuY3J5 cHRlZCBtYXRlcmlhbCBsaXZpbmcNCj4+Pj4+Pj4gc2lkZS1ieS1zaWRlIHdpdGggdGhlIGtleSBu ZWNlc3NhcnkgdG8gZGVjcnlwdCBpdD8NCj4+Pj4+PiANCj4+Pj4+PiBXZSBhcmUgdGFsa2luZyBh Ym91dCB1c2luZyBhIGtleSBlbmNyeXB0aW5nIGtleSAoS0VLKSBhbmQgc3RvcmluZw0KPj4+Pj4+ IHRoYXQsIG5vdCBzdG9yaW5nIHRoZSByYXcga2V5IG5leHQgdG8gdGhlIGVuY3J5cHRlZCBkYXRh IGFzIGZhciBhcyBJDQo+Pj4+Pj4gY2FuIHRlbGwuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gUmln aHQuDQo+Pj4+PiANCj4+Pj4+PiBBZGRpdGlvbmFsbHksIEkgaGF2ZW4ndCBzZWVuIGEgZGlzY3Vz c2lvbiBvbiB0aGUgaGFyZHdhcmUNCj4+Pj4+PiB0aGlzIGlzIGV4cGVjdGVkIHRvIHJ1biBvbi4N Cj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBUaGF0IG1pZ2h0IGJlIGFwcHJvcHJpYXRlIG1hdHRlciBm b3IgdGhlIGRyYWZ0LCBpZiBpdCBpcyBnb2luZyB0byBtYWtlDQo+Pj4+PiB0aGlzDQo+Pj4+PiBy ZWNvbW1lbmRhdGlvbi4NCj4+Pj4+IA0KPj4+Pj4+IFNvbWUgaW1wbGVtZW50YXRpb25zIG9mIEtF SyBzb2x1dGlvbnMgdXNlIGRlZGljYXRlZCBoYXJkd2FyZSBmb3IgdGhlDQo+Pj4+Pj4gS0VLIGFu ZCByZXF1aXJlIGF1dGhlbnRpY2F0aW9uIGZvciBhY2Nlc3MgdG8gdGhlIGtleSwgaGVuY2UNCj4+ Pj4+PiBwcmV2ZW50aW5nDQo+Pj4+Pj4gZ2VuZXJpYyBhY2Nlc3MgYW5kIHNpZGUtYnktc2lkZSBz dG9yYWdlIG9mIHRoZSBLRUsncyBwcm90ZWN0ZWQga2V5LA0KPj4+Pj4+IGFuZCBlbmNyeXB0ZWQg ZGF0YS4gIEknZCByYXRoZXIgc2VlIGEgS0VLIHVzZWQgdGhhbiBqdXN0IGEga2V5IHN0b3JlZA0K Pj4+Pj4+IGluIGFueSBjYXNlLiAgQXJlIHlvdSBhcmd1aW5nIGZvciBub3QgdXNpbmcgYW55IGVu Y3J5cHRpb24gYXQgYWxsPw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IEknbGwgZGVmZXIgdG8geW91 LCBvZiBjb3Vyc2UsIHNpbmNlIHlvdSBoYXZlIHByZXN1bWFibHkgZ2l2ZW4gdGhlDQo+Pj4+PiB0 b3BpYw0KPj4+Pj4gbW9yZQ0KPj4+Pj4gdGhvdWdodCB0aGFuIEkgaGF2ZSwgYnV0OiB5ZXMuDQo+ Pj4+PiANCj4+Pj4+IEFic2VudCBzb21ldGhpbmcgbGlrZSBhbiBIU00gb3IgZm9yY2luZyBodW1h biBpbnRlcnZlbnRpb24gd2hlbmV2ZXIgYQ0KPj4+Pj4gcHJvY2VzcyBzdGFydHMgKG9yIHJlc3Rh cnRzKSwgaXQgc2VlbXMgdGhhdCB0aGUgc2NoZW1lIGRlc2NyaWJlZCBpbg0KPj4+Pj4gc2VjdGlv bg0KPj4+Pj4gNSBkb2Vzbid0IGFjdHVhbGx5IGRldGVyIGEgY29tcGV0ZW50IGF0dGFja2VyIGZy b20gb2J0YWluaW5nIHRoZSBrZXlzLg0KPj4+Pj4gTXkNCj4+Pj4+IGltcHJlc3Npb24gaXMgdGhh dCBzdG9yaW5nIGluZm9ybWF0aW9uIGluIGFuIGVuY3J5cHRlZCBmb3JtIHRoYXQgY2FuDQo+Pj4+ PiBiZQ0KPj4+Pj4gdHJpdmlhbGx5IGRlY3J5cHRlZCBieSBhbiBhdHRhY2tlciBwcm92aWRlcyBh IGZhbHNlIHNlbnNlIG9mIHNlY3VyaXR5DQo+Pj4+PiB0bw0KPj4+Pj4gZXF1aXBtZW50IG9wZXJh dG9ycy4NCj4+Pj4+IA0KPj4+Pj4gSWYgdGhlIHNjaGVtZSBpbiBzZWN0aW9uIDUgKmRvZXMqIHJl cXVpcmUgdGhlIGtpbmQgb2YgcHJlcmVxdWlzaXRlcw0KPj4+Pj4geW91DQo+Pj4+PiBwb3NpdCwg c3VjaCBhcyBkZWRpY2F0ZWQgc2VjdXJpdHkgaGFyZHdhcmUsIGl0IHNlZW1zIHRoYXQgc3VjaA0K Pj4+Pj4gcHJlcmVxdWlzaXRlcw0KPj4+Pj4gc2hvdWxkIGJlIG1lbnRpb25lZCBhbG9uZ3NpZGUg dGhlIHJlY29tbWVuZGF0aW9uLg0KPj4+Pj4gDQo+Pj4+Pj4gRm9yIFlBTkcgbW9kdWxlcywgY291 bGRuJ3QgdGhlIGFwcGxpY2F0aW9uIHZpYSBORVRDT05GL1JFU1RDT05GDQo+Pj4+Pj4gYWNjZXNz aW5nIHRoZSBtb2R1bGUgcHJvdmlkZSB0aGUgY3JlZGVudGlhbHMgdG8gYWNjZXNzIHRoZSBrZXkN Cj4+Pj4+PiBwcm90ZWN0ZWQgYnkgdGhlIEtFSz8NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBUaGF0 IHNvbHZlcyB0aGUgaXNzdWVzIHdpdGggcHJvdmlzaW9uaW5nLCBidXQgZG9lc24ndCBzZWVtIHRv IGhlbHAgdGhlDQo+Pj4+PiBwcm9jZXNzZXMgYWN0dWFsbHkgaW52b2x2ZWQgaW4gcm91dGluZy4N Cj4+Pj4+IA0KPj4+Pj4+IFNvbWUgaW1wbGVtZW50YXRpb25zIGNvdWxkIHN0b3JlIHRoZSBLRUsg aW4NCj4+Pj4+PiBkZWRpY2F0ZWQgaGFyZHdhcmUgYXMgd2VsbC4gSW4gdGhpcyB3YXksIHN0b3Jp bmcgdGhlIEtFSyBhbmQgZGF0YQ0KPj4+Pj4+IHRvZ2V0aGVyIGlzIG5vdCB0aGUgc2FtZSBhcyBz dG9yaW5nIGEga2V5IHJpZ2h0IG5leHQgdG8gdGhlIGRhdGEgaXQNCj4+Pj4+PiBpcw0KPj4+Pj4+ IHByb3RlY3RpbmcuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gVGhpcyBtYWtlcyBwZXJmZWN0IHNl bnNlOyBhbmQgaXQgc2hvdWxkIHByb2JhYmx5IGJlIGluIHRoZSBkb2N1bWVudC4NCj4+Pj4+IA0K Pj4+Pj4+IFVzZSBvZiBhIEtFSyBpcyBiZXR0ZXIgdGhlbiBub3QgZW5jcnlwdGluZyBhbmQgY2Fu IGJlIGRvbmUNCj4+Pj4+PiB3ZWxsLg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IEl0IGNhbiBhbHNv IGJlIGRvbmUgcG9vcmx5LCBhbmQgdGhlIG1lbnRpb24gb2Ygb2JmdXNjYXRpb24gKGFsb25nIHdp dGgNCj4+Pj4+IHRoZQ0KPj4+Pj4gZXhjaGFuZ2UgSSBjaXRlIGJlbG93KSBsZWFkcyBtZSB0byBi ZWxpZXZlIHRoYXQgLS0gYWJzZW50IGNvbmNyZXRlDQo+Pj4+PiBndWlkYW5jZQ0KPj4+Pj4gdG8g dGhlIGNvbnRyYXJ5IC0tIGltcGxlbWVudG9ycyB3aWxsIGNob29zZSB0byBkbyBpdCBwb29ybHku IEl0J3Mgbm90DQo+Pj4+PiBjbGVhcg0KPj4+Pj4gdGhhdCBkb2luZyB0aGlzIHBvb3JseSBwcm92 aWRlcyBhbnkgYmVuZWZpdCwgYW5kIGl0IHNlZW1zIHRvIG1lIHRoYXQNCj4+Pj4+IGl0DQo+Pj4+ PiBtYXkNCj4+Pj4+IGNhdXNlIGhhcm06IGlmIHNvbWV0aGluZyBfbG9va3NfIHNlY3VyZSBidXQg aXNuJ3QsIGRvZXNuJ3QgdGhhdCBoYXZlDQo+Pj4+PiB0aGUNCj4+Pj4+IHBvdGVudGlhbCBmb3Ig b3BlcmF0b3JzIHRvIGluY29ycmVjdGx5IHRyZWF0IGl0IGFzIHNlY3VyZT8gQWdhaW4sIHRoaXMN Cj4+Pj4+IGlzDQo+Pj4+PiBtb3JlIHlvdXIgYXJlYSB0aGFuIG1pbmUgYW5kIHNvIEkgd2lsbCBk ZWZlciB0byB5b3VyIG9waW5pb24gb24gdGhlDQo+Pj4+PiB0b3BpYzsNCj4+Pj4+IGJ1dCBmcm9t IGEgbGF5IHBlcnNwZWN0aXZlLCB0aGlzIHNlZW1zIGxpa2VseSB0byByZXN1bHQgaW4gdGhlIGxh Y2sgb2YNCj4+Pj4+IGd1YXJkaW5nIGFnYWluc3QgY29tcHJvbWlzZSBvZiB0aGUgZW5jcnlwdGVk IGluZm9ybWF0aW9uIHVuZGVyIHRoZQ0KPj4+Pj4gbWlzdGFrZW4NCj4+Pj4+IGltcHJlc3Npb24g dGhhdCBpdCBjYW4ndCBiZSBkZWNyeXB0ZWQgdHJpdmlhbGx5Lg0KPj4+Pj4gDQo+Pj4+IA0KPj4+ PiBUaGUgd2F5IEkgcmVhZCB0aGUgdGhyZWFkIGZyb20gQWNlZSBpcyB0aGF0IHRoZXJlIGFyZW4n dCBhbnkgS0VLDQo+Pj4+IGltcGxlbWVudGF0aW9ucyB3aXRoIHdpdGggcGFydGljdWxhciBZQU5H IG1vZHVsZSwgaG93ZXZlciBCcmlhbiBzYXlzDQo+Pj4+IHRoZXJlIGlzIHdpdGggb3RoZXIgWUFO RyBtb2R1bGVzLiAgSSAqdGhpbmsqIHdoZW4gQWNlZSBpcyByZWZlcnJpbmcgdG8NCj4+Pj4gb2Jm dXNjYXRpb24gYW5kIGxlc3MgdGhhbiBpZGVhbCBzY2VuYXJpb3MsIGl0IGlzIHdpdGggdGhlIGN1 cnJlbnRseQ0KPj4+PiBkZXBsb3llZCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkb24ndCB1c2UgS0VL cy4gIEJ1dCB0aGUgdGV4dCBhbmQNCj4+Pj4gcmVzcG9uc2VzIGRpZCBzZWVtIHRvIGJlIGNvbW1p bmdsZWQgYSBiaXQgdG9vIG11Y2guDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gQW0gSSBtaXNzaW5n IHNvbWV0aGluZz8gIFdhcyB0aGVyZSBzb21ldGhpbmcgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMN Cj4+Pj4+PiB0aGF0IGhhcyB0aGUgcmF3IGtleSBzdG9yZWQgd2l0aCB0aGUgZW5jcnlwdGVkIGRh dGE/DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gUGVyaGFwcyB0aGUgZm9sbG93aW5nIGV4Y2hhbmdl IHdpdGggdGhlIGF1dGhvcjoNCj4+Pj4+IA0KPj4+Pj4gQWRhbTogIkJ5IG15IHJlYWRpbmcsIHRo aXMgaXMganVzdCB0YWxraW5nIGFib3V0IGVuY3J5cHRpbmcgJ29uIHRoZQ0KPj4+Pj4gZGlzaycN Cj4+Pj4+IHN0b3JhZ2Ugb24gdGhlIGRldmljZS4gQW55IHByb2Nlc3NlcyBpbnZvbHZlZCBpbiBw cm92aXNpb25pbmcgdGhlDQo+Pj4+PiB2YWx1ZXMgb3INCj4+Pj4+IHVzaW5nIHRoZW0gdG8gcHJv Y2VzcyB0cmFmZmljIHdvdWxkIGhhdmUgYWNjZXNzIHRvIHRoZSBwbGFpbnRleHQsDQo+Pj4+PiBw cmVzdW1hYmx5DQo+Pj4+PiBieSByZWFkaW5nIHRoZSBlbmNyeXB0ZWQgZm9ybSBvZmYgZGlzaywg cmVhZGluZyBzb21lIGtleWluZyBtYXRlcmlhbA0KPj4+Pj4gb2ZmDQo+Pj4+PiBkaXNrLCBhbmQg Y29tYmluaW5nIHRoZW0gdG8gcmV0cmlldmUgdGhlIHBsYWludGV4dCBrZXkuIg0KPj4+PiANCj4+ Pj4gSXQgbG9va3MgbGlrZSB2ZXJzaW9uIDIwIGhhZCBkaWZmZXJlbnQgYXNzdW1wdGlvbnMgYWJv dXQgdXNpbmcgdGhlDQo+Pj4+IEtFSy4gIEkgKnRoaW5rKiB0aGlzIGlzIGRlc2NyaWJpbmcgdXNh Z2Ugd2l0aG91dCBhIEtFSyBhbmQgbWF5IGJlIHBhcnQNCj4+Pj4gb2Ygd2h5IEFjZWUgaXMgYXNr aW5nIGZvciBtb3JlIGltcGxlbWVudGF0aW9uIGd1aWRhbmNlLi4uIHNvIEknbGwga2VlcA0KPj4+ PiBteSBkaXNjdXNzIHRvIHNlZSBpZiB3ZSBjYW4gc2hhcGUgdGhhdCB1cCBtb3JlLiAgVGhpcyBp cyBoZWxwZnVsIGFzIEkNCj4+Pj4gdGhpbmsgSSBzZWUgdGhlIGdhcCBtb3JlIG5vdyBhcyB0byB3 aGF0IGhlIG1pZ2h0IGJlIGxvb2tpbmcgZm9yIGluDQo+Pj4+IHRlcm1zIG9mIGd1aWRhbmNlLg0K Pj4+PiANCj4+Pj4gSGVyZSdzIHRoZSB0ZXh0IGZyb20gLTIwOg0KPj4+PiANCj4+Pj4gV2hlbiBj b25maWd1cmVkLCB0aGUga2V5LXN0cmluZ3MgY2FuIGJlIGVuY3J5cHRlZCB1c2luZyB0aGUgQUVT IEtleQ0KPj4+PiAgV3JhcCBhbGdvcml0aG0gW0FFUy1LRVktV1JBUF0uICBUaGUgQUVTIGtleS1l bmNyeXB0aW9uIGtleSAoS0VLKSBpcw0KPj4+PiAgbm90IGluY2x1ZGVkIGluIHRoZSBZQU5HIG1v ZGVsIGFuZCBtdXN0IGJlIHNldCBvciBkZXJpdmVkIGluZGVwZW5kZW50DQo+Pj4+IA0KPj4+PiBM aW5kZW0sIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjAsIDIwMTcgICAgICAgICAg ICAgICBbUGFnZSAxNV0NCj4+Pj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBZQU5HIEtl eSBDaGFpbiAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDE3DQo+Pj4+IA0KPj4+PiAgb2Yga2V5 LWNoYWluIGNvbmZpZ3VyYXRpb24uICBXaGVuIEFFUyBrZXktZW5jcnlwdGlvbiBpcyB1c2VkLCB0 aGUNCj4+Pj4gIGhleC1rZXktc3RyaW5nIGZlYXR1cmUgaXMgYWxzbyByZXF1aXJlZCBzaW5jZSB0 aGUgZW5jcnlwdGVkIGtleXMgd2lsbA0KPj4+PiAgY29udGFpbiBjaGFyYWN0ZXJzIHRoYXQgYXJl IG5vdCByZXByZXNlbnRhYmxlIGluIHRoZSBZQU5HIHN0cmluZw0KPj4+PiAgYnVpbHQtaW4gdHlw ZSBbWUFOR10uICBBRVMga2V5LWVuY3J5cHRpb24gTUFZIGJlIHVzZWQgZm9yIGFkZGVkIGtleQ0K Pj4+PiAgc2VjdXJpdHkgaW4gc2l0dWF0aW9ucyB3aGVyZSB0aGUgTkVUQ09ORiBBY2Nlc3MgQ29u dHJvbCBNb2RlIGlzIG5vdA0KPj4+PiAgYXZhaWxhYmxlLg0KPj4+PiANCj4+Pj4+IA0KPj4+Pj4g QWNlZTogIlRoaXMgaXMgdGhlIGNvcnJlY3QgaW50ZXJwcmV0YXRpb24uIg0KPj4+Pj4gDQo+Pj4+ PiAvYQ0KPj4+PiANCj4+Pj4gVGhhbmtzLg0KPj4+PiANCj4+Pj4gLS0NCj4+Pj4gDQo+Pj4+IEJl c3QgcmVnYXJkcywNCj4+Pj4gS2F0aGxlZW4NCj4+PiANCj4+IA0KPj4gDQo+PiANCj4+IC0tIA0K Pj4gDQo+PiBCZXN0IHJlZ2FyZHMsDQo+PiBLYXRobGVlbg0KPiANCg0KLS0gDQpCcmlhbiBXZWlz DQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zDQpUZWxlcGhvbmU6ICsxIDQwOCA1MjYgNDc5 Ng0KRW1haWw6IGJld0BjaXNjby5jb20NCg0K From nobody Wed Apr 26 19:35:24 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985FC12741D; Wed, 26 Apr 2017 19:35:16 -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, 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 SxdpmJ6ZBDa0; Wed, 26 Apr 2017 19:35:14 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 AFA6D1205D3; Wed, 26 Apr 2017 19:35:14 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id c198so11839731pfc.1; Wed, 26 Apr 2017 19:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xqQH1VoSsbysGzRz7SSB4ZKczuD+B2YP7L5zUyPE3Bg=; b=AzhWElYAQaHXRqkY/g9JsCVr26T4wI1yGPl5TncBPkdnG3qpQQPMQ7JRczSOY1EIUl 7h9UTWI4H8aTNyRGSzeR0rIGq3wR3IwbDnvsOF9hEbl4t6P0Qb55rBt/5tdMkk7Gymtj zDqE100VPoBPRq76Ek7PE3rikcPXT28Es0R+LTNH4iTMm99Icg2NNgcumlPoowxNjpnG aQI8qbEE9n/T6NAyCEMdWbGfVfz16BIE2T83sRJDQ0QktB9Aftuh0ub8Z+OecE1Q56oU bvc3QBzGKTKKp/A7E1nzncdda9uIB5v7fR8JFWa8tYX50rjtU0UTMe8+9F+DsucRVblB Iwzg== 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=xqQH1VoSsbysGzRz7SSB4ZKczuD+B2YP7L5zUyPE3Bg=; b=sBky4iEcord1ycoXQvOHY3m34gBNMO2VI55PfFieoyk6C/Vq4TZPLZnOjqwQ1fPYlP QjE9nfZMVJl3+EDjtVpHqQA5V5xaBMsMbcgg9DviZe88bMDROgSMqHYmYCphfLnG4R+3 dmf1WXgCG6qUycjawHEbnyyMRNniYwneRmxubYr09bVabO1uS9Smj9Ij6Y8ou+G44wqy S6hd/C46RQhSsWoYZLrNWWN1SrwRRJLpn/h8tGAPM0bxJ/B7Zaxy3VW6y4UWZa3Cb+8x IWJZoueEq7Ya+4Iza80Y3NhRjXI3xdThIjlfW7FUeDI+9jQuUQoFJXHjHoRCNVxMcwJD Ggvw== X-Gm-Message-State: AN3rC/7yMq1/uszCdvT4L3KTGYw6tFXF//hf6YfbRH1t/fcpcd6qoBrF GAnw8d/pZsc8eBXUpu4VpMvUVJlhjsT0 X-Received: by 10.84.194.165 with SMTP id h34mr3906043pld.129.1493260514107; Wed, 26 Apr 2017 19:35:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 19:34:33 -0700 (PDT) In-Reply-To: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 22:34:33 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Adam Roach Cc: The IESG , Jeff Tantsura , rtgwg-chairs@ietf.org, draft-ietf-rtgwg-yang-key-chain@ietf.org, rtgwg@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 02:35:17 -0000 Hi Adam, On Wed, Apr 26, 2017 at 4:52 PM, Adam Roach wrote: > Sorry for top-posting, but I want to see if we can untangle something. > > I'm glad this is getting clearer for you, but it's just getting more > confusing for me. In the -20 version of the document, there was text about > using a KEK for data in motion (section 5 paragraph 3), and a separate > mention of using a KEK for data at rest (section 5, final paragraph)[1]. For > clarity: for the remainder of this thread, I will refer to these as > KEK-motion and KEK-rest respectively. > The draft is about stored key chain in a YANG module accessed (key distribution) for different purposes. Using a KEK is just a way to protect the key that is stored. NETCONF (with SSH) or RESTCONF (with TLS) are required for secure access to the keys or if a KEK is used, the protected keys. In-motion (if I understand you correctly) is just the transport of this data model element for use. As stated in the introduction, the key might not be used directly and there's no mention of using this key to protect data that is stored with the key: In some applications, the protocols do not use the key chain element key directly, but rather a key derivation function is used to derive a short-lived key from the key chain element key (e.g., the Master Keys used in [TCP-AO]). If a KEK is used, this is talking about the protected key. What I am trying to help Acee with is on the following from -20 so he has some implementation guidance around using a KEK: The AES key-encryption key (KEK) is not included in the YANG model and must be set or derived independent of key-chain configuration. The final paragraph, I believe is referring to how the key is stored - either a KEK is used and it's encrypted or it's not and it's advising obfuscation at a minimum. Does that help? I'll defer to the authors and AD and get back to the part of the thread where I'm hoping we can add the KEK back into the draft. Regards, Kathleen > For additional clarity, the exchange with Acee I cite below predates the > release of the -21 version of the document, so it can only be in reference > to the -20 version. > > While I see that there are probably some operational issues that need to be > resolved regarding KEK-motion, I would like to treat them separately from my > concerns with KEK-rest. > > My concern here is exclusively with regards to KEK-rest, which seems to be > suffering some degree of conflation with KEK-motion, and which will have > distinctly different considerations regarding whether and how it can be > compromised. > > I have more to say on this, but would like to pause and make sure we're in > concordance that there are two unrelated KEKs in play here. > > /a > > ____ > [1] I cite as evidence that these are two different KEKs under discussion > the following two points: (a) the third paragraph talks about KEKs in terms > of RFC 5649, which requires AES; while the final paragraph talks about > encryption "or obfuscation," which clearly can't be RFC 5649; and (b) in the > -21 version of the document, all mention of RFC 5649 has been stricken, > while the final paragraph of section 5 remains. > > > > On 4/26/17 3:30 PM, Kathleen Moriarty wrote: >> >> Hi Adam, >> >> I think I see where we are coming to different conclusions.... >> >> On Wed, Apr 26, 2017 at 4:18 PM, Adam Roach wrote: >>> >>> On 4/26/17 2:36 PM, Kathleen Moriarty wrote: >>>> >>>> On Wed, Apr 26, 2017 at 2:42 PM, Adam Roach wrote: >>>>> >>>>> On 4/26/17 11:34 AM, Kathleen Moriarty wrote: >>>>>> >>>>>> Since the following text int he Security Considerations section is a >>>>>> recommendation, IMO it would be better to drop "or otherwise >>>>>> obfuscated" >>>>>> from the sentence as encrypting the keys really should be the >>>>>> recommendation. Can we make this update? >>>>>> >>>>>> It is RECOMMENDED that keys be encrypted or otherwise obfuscated >>>>>> when >>>>>> stored internally on a network device supporting this >>>>>> specification. >>>>>> >>>>>> If obfuscation is what happens more often in practice, maybe mention >>>>>> this >>>>>> as a fallback from the recommendation, but not make them sound >>>>>> equivalent? >>>>> >>>>> >>>>> >>>>> To be clear -- the current guidance from the security area is to >>>>> perform >>>>> this kind of encryption, where you have encrypted material living >>>>> side-by-side with the key necessary to decrypt it? >>>> >>>> We are talking about using a key encrypting key (KEK) and storing >>>> that, not storing the raw key next to the encrypted data as far as I >>>> can tell. >>> >>> >>> Right. >>> >>>> Additionally, I haven't seen a discussion on the hardware >>>> this is expected to run on. >>> >>> >>> That might be appropriate matter for the draft, if it is going to make >>> this >>> recommendation. >>> >>>> Some implementations of KEK solutions use dedicated hardware for the >>>> KEK and require authentication for access to the key, hence preventing >>>> generic access and side-by-side storage of the KEK's protected key, >>>> and encrypted data. I'd rather see a KEK used than just a key stored >>>> in any case. Are you arguing for not using any encryption at all? >>> >>> >>> I'll defer to you, of course, since you have presumably given the topic >>> more >>> thought than I have, but: yes. >>> >>> Absent something like an HSM or forcing human intervention whenever a >>> process starts (or restarts), it seems that the scheme described in >>> section >>> 5 doesn't actually deter a competent attacker from obtaining the keys. My >>> impression is that storing information in an encrypted form that can be >>> trivially decrypted by an attacker provides a false sense of security to >>> equipment operators. >>> >>> If the scheme in section 5 *does* require the kind of prerequisites you >>> posit, such as dedicated security hardware, it seems that such >>> prerequisites >>> should be mentioned alongside the recommendation. >>> >>>> For YANG modules, couldn't the application via NETCONF/RESTCONF >>>> accessing the module provide the credentials to access the key >>>> protected by the KEK? >>> >>> >>> That solves the issues with provisioning, but doesn't seem to help the >>> processes actually involved in routing. >>> >>>> Some implementations could store the KEK in >>>> dedicated hardware as well. In this way, storing the KEK and data >>>> together is not the same as storing a key right next to the data it is >>>> protecting. >>> >>> >>> This makes perfect sense; and it should probably be in the document. >>> >>>> Use of a KEK is better then not encrypting and can be done >>>> well. >>> >>> >>> It can also be done poorly, and the mention of obfuscation (along with >>> the >>> exchange I cite below) leads me to believe that -- absent concrete >>> guidance >>> to the contrary -- implementors will choose to do it poorly. It's not >>> clear >>> that doing this poorly provides any benefit, and it seems to me that it >>> may >>> cause harm: if something _looks_ secure but isn't, doesn't that have the >>> potential for operators to incorrectly treat it as secure? Again, this is >>> more your area than mine and so I will defer to your opinion on the >>> topic; >>> but from a lay perspective, this seems likely to result in the lack of >>> guarding against compromise of the encrypted information under the >>> mistaken >>> impression that it can't be decrypted trivially. >>> >> The way I read the thread from Acee is that there aren't any KEK >> implementations with with particular YANG module, however Brian says >> there is with other YANG modules. I *think* when Acee is referring to >> obfuscation and less than ideal scenarios, it is with the currently >> deployed implementations that don't use KEKs. But the text and >> responses did seem to be commingled a bit too much. >> >>>> Am I missing something? Was there something implementation specific >>>> that has the raw key stored with the encrypted data? >>> >>> >>> Perhaps the following exchange with the author: >>> >>> Adam: "By my reading, this is just talking about encrypting 'on the disk' >>> storage on the device. Any processes involved in provisioning the values >>> or >>> using them to process traffic would have access to the plaintext, >>> presumably >>> by reading the encrypted form off disk, reading some keying material off >>> disk, and combining them to retrieve the plaintext key." >> >> It looks like version 20 had different assumptions about using the >> KEK. I *think* this is describing usage without a KEK and may be part >> of why Acee is asking for more implementation guidance... so I'll keep >> my discuss to see if we can shape that up more. This is helpful as I >> think I see the gap more now as to what he might be looking for in >> terms of guidance. >> >> Here's the text from -20: >> >> When configured, the key-strings can be encrypted using the AES Key >> Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is >> not included in the YANG model and must be set or derived independent >> >> Lindem, et al. Expires October 20, 2017 [Page 15] >> Internet-Draft YANG Key Chain April 2017 >> >> of key-chain configuration. When AES key-encryption is used, the >> hex-key-string feature is also required since the encrypted keys will >> contain characters that are not representable in the YANG string >> built-in type [YANG]. AES key-encryption MAY be used for added key >> security in situations where the NETCONF Access Control Mode is not >> available. >> >>> Acee: "This is the correct interpretation." >>> >>> /a >> >> Thanks. >> > -- Best regards, Kathleen From nobody Wed Apr 26 19:43:17 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2032712741D; Wed, 26 Apr 2017 19:43:09 -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, 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 ATSLXsGAtPbK; Wed, 26 Apr 2017 19:43:06 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7491205D3; Wed, 26 Apr 2017 19:43:06 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id 194so11949020pfv.3; Wed, 26 Apr 2017 19:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9his6IzQyPEoxaKIBONgzJ2XGYqIa0Nprc4ZprwGBq8=; b=fLbgoJHz0VxWhZOHwDqEB+2tauh5XrI9Pq2KO9OoVnZ2aijvTJ1P46ri6zuyI6RIMA NqQ8C7egOLShafgphq5T4xWHHIc2h+o4Ft+RtBa17wjuZnxHZFnnt212EcXFnaFmTWSs m+s029mPjF0a0XyQoa3wKAM38LikIb0OmG4lxW11ncf6Gd7rVLTxZ2kG4A9r8oVLlCnz AHMqYVfgu9sDUAmmDHPFfsVetUr7T3tHym7QSbnBviu2saCLbhVfk4XrVgeiiBcE9LxR G6956L7cozXFq79SN29q5wbqh4ljouBhPzjaqQ1CsW3Dg0R8y1zrThTTbpCLKjCvIwtC QqZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9his6IzQyPEoxaKIBONgzJ2XGYqIa0Nprc4ZprwGBq8=; b=lXi4jWVtD1/uOCZaiy0+dtUE0t0p8ePvULgY7lJganh1WKbvLLf7OiqTIR8it83C6y 70JiYAlieL+2V6Hw8rJ/F95rCp0UkoD0rbskxKKXqMRVbHEezIKmDxBfTLQuhH0eKXU5 PgYUa0dxONYZdDXVewr+tdOsErE/BCf+3O9T67CH/grtotkAkNwl0ulJFtRaU1VBFVME MntqlgUUv9z6ioF2FFSUyhHFBXVD3cYT4wOQmZAJuFoksxXoKJYC8JZvkplTAyWANufQ pO73q3cLxzyoMtiIICgDPN9MYylG4IZQvDJ7V6og0KdxtxAZ7jWMW2l1huW+rGY6UG4o KaxA== X-Gm-Message-State: AN3rC/7Od6MRZnKWBvY+L/RBF63fUUPzEGlGo9kqgl0J7rUvwB9DZHNN aahs4+p2TXvCR8lM9T441thrJdlQlA== X-Received: by 10.99.126.13 with SMTP id z13mr3097210pgc.158.1493260986214; Wed, 26 Apr 2017 19:43:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 19:42:25 -0700 (PDT) In-Reply-To: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 22:42:25 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: "Brian Weis (bew)" Cc: "Acee Lindem (acee)" , Adam Roach , Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 02:43:09 -0000 Hi Brian & Acee, On Wed, Apr 26, 2017 at 8:49 PM, Brian Weis (bew) wrote: > Hi Kathleen and Acee, > > Just a clarification on what I had said earlier. > >> On Apr 26, 2017, at 1:55 PM, Acee Lindem (acee) wrote: >> >> Kathleen, >> >> On 4/26/17, 4:47 PM, "Kathleen Moriarty" >> wrote: >> >>> Acee, >>> >>> >>> >>> On Wed, Apr 26, 2017 at 4:39 PM, Acee Lindem (acee) >>> wrote: >>>> Kathleen, Brian, >>>> >>>> Since KEK as described in RFC 5649 is not ready for prime time, why >>>> don=E2=80=99t >>> >>> This is widely deployed in other use cases, >> >> None of these use cases are documented in IETF RFCs or drafts. > > The AES key wrap method itself is well understood, and if you look at the= citations for RFC 3394 at it is actually used in a number of IETF protocols. This is the= basis for why I originally suggested that it made sense to include it in a= YANG model that distributes keys. > Thanks for saving me a step, I was going to use Jari's tool once I got back online for the same purpose. >> >>> so I am not following this >>> statement that it isn't ready for prime time. RFC5649 is >>> straightforward. What is the gap for your usage that requires >>> additional guidance? Brian says this in in use for other YANG modules >>> already as well. > > Apologies, I was unclear in what I said. I am not actually aware of it be= ing used in other YANG modules =E2=80=A6 I meant to communicate what Kathle= en said more succinctly, which is that the RFC 3394 and RFC 5649 are implem= ented for the same purpose in other (non-YANG module) protocols. None of th= e citations in the list above appear to be YANG modules, but then I=E2=80= =99m not sure whether or not any other YANG modules distribute keys either. Thanks, Brian, that is helpful. Acee, after a little more reading, is the gap for implementation guidance on how to use/access the key encrypting key because of the following sentence in -20? The AES key-encryption key (KEK) is not included in the YANG model and must be set or derived independent of key-chain configuration. This is an important step, I'm guessing Brian helped with this text and that may be where you need some guidance for implementing the key distribution functions with a stored KEK instead of the key obfuscated in some way. Personally, I'd leave this as implementation specific and the guidance here is enough for the draft, but vendors implementing would have to figure out how they want to do this. Before going further, can I confirm with you that this is the place where you'd like guidance? The guidance I provided earlier that is not in the draft is as follows (but might not answer your question): If you want to wrap an AES key and nothing else, use RFC 3394 If you want to wrap an AES key and some other attributes too, use RFC 5= 649 Thank you, Kathleen > > Hope that helps, > Brian > >>> Could you please be more explicit in terms of what >>> you need for guidance. I offered a suggestion, if that isn't enough, >>> could you please explain the gap as you see it so we can assist? >> >> Sorry, I must have missed the text you recommended. Please provide it >> again and I will restore the option with the guidance that is missing fr= om >> RFC 5649. >> >> Thanks, >> Acee >> >> >> >> >>> >>> Thank you, >>> Kathleen >>> >>>> you take this up as a separate draft rather than trying to hold this >>>> important document hostage? We have the NETCONF Access Control Model >>>> (NACM) to protect the keys during transport (which has been >>>> implemented). >>>> Obviously, key-strings are stored on devices today since they are bein= g >>>> used for protocol authentication and encryption so this is totally >>>> orthogonal to the YANG model being used to provision them. >>>> >>>> Thanks, >>>> Acee >>>> >>>> On 4/26/17, 4:30 PM, "Kathleen Moriarty" >>>> wrote: >>>> >>>>> Hi Adam, >>>>> >>>>> I think I see where we are coming to different conclusions.... >>>>> >>>>> On Wed, Apr 26, 2017 at 4:18 PM, Adam Roach wrote: >>>>>> On 4/26/17 2:36 PM, Kathleen Moriarty wrote: >>>>>>> >>>>>>> On Wed, Apr 26, 2017 at 2:42 PM, Adam Roach wrot= e: >>>>>>>> >>>>>>>> On 4/26/17 11:34 AM, Kathleen Moriarty wrote: >>>>>>>>> >>>>>>>>> Since the following text int he Security Considerations section i= s >>>>>>>>> a >>>>>>>>> recommendation, IMO it would be better to drop "or otherwise >>>>>>>>> obfuscated" >>>>>>>>> from the sentence as encrypting the keys really should be the >>>>>>>>> recommendation. Can we make this update? >>>>>>>>> >>>>>>>>> It is RECOMMENDED that keys be encrypted or otherwise >>>>>>>>> obfuscated >>>>>>>>> when >>>>>>>>> stored internally on a network device supporting this >>>>>>>>> specification. >>>>>>>>> >>>>>>>>> If obfuscation is what happens more often in practice, maybe >>>>>>>>> mention >>>>>>>>> this >>>>>>>>> as a fallback from the recommendation, but not make them sound >>>>>>>>> equivalent? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> To be clear -- the current guidance from the security area is to >>>>>>>> perform >>>>>>>> this kind of encryption, where you have encrypted material living >>>>>>>> side-by-side with the key necessary to decrypt it? >>>>>>> >>>>>>> We are talking about using a key encrypting key (KEK) and storing >>>>>>> that, not storing the raw key next to the encrypted data as far as = I >>>>>>> can tell. >>>>>> >>>>>> >>>>>> Right. >>>>>> >>>>>>> Additionally, I haven't seen a discussion on the hardware >>>>>>> this is expected to run on. >>>>>> >>>>>> >>>>>> That might be appropriate matter for the draft, if it is going to ma= ke >>>>>> this >>>>>> recommendation. >>>>>> >>>>>>> Some implementations of KEK solutions use dedicated hardware for th= e >>>>>>> KEK and require authentication for access to the key, hence >>>>>>> preventing >>>>>>> generic access and side-by-side storage of the KEK's protected key, >>>>>>> and encrypted data. I'd rather see a KEK used than just a key stor= ed >>>>>>> in any case. Are you arguing for not using any encryption at all? >>>>>> >>>>>> >>>>>> I'll defer to you, of course, since you have presumably given the >>>>>> topic >>>>>> more >>>>>> thought than I have, but: yes. >>>>>> >>>>>> Absent something like an HSM or forcing human intervention whenever = a >>>>>> process starts (or restarts), it seems that the scheme described in >>>>>> section >>>>>> 5 doesn't actually deter a competent attacker from obtaining the key= s. >>>>>> My >>>>>> impression is that storing information in an encrypted form that can >>>>>> be >>>>>> trivially decrypted by an attacker provides a false sense of securit= y >>>>>> to >>>>>> equipment operators. >>>>>> >>>>>> If the scheme in section 5 *does* require the kind of prerequisites >>>>>> you >>>>>> posit, such as dedicated security hardware, it seems that such >>>>>> prerequisites >>>>>> should be mentioned alongside the recommendation. >>>>>> >>>>>>> For YANG modules, couldn't the application via NETCONF/RESTCONF >>>>>>> accessing the module provide the credentials to access the key >>>>>>> protected by the KEK? >>>>>> >>>>>> >>>>>> That solves the issues with provisioning, but doesn't seem to help t= he >>>>>> processes actually involved in routing. >>>>>> >>>>>>> Some implementations could store the KEK in >>>>>>> dedicated hardware as well. In this way, storing the KEK and data >>>>>>> together is not the same as storing a key right next to the data it >>>>>>> is >>>>>>> protecting. >>>>>> >>>>>> >>>>>> This makes perfect sense; and it should probably be in the document. >>>>>> >>>>>>> Use of a KEK is better then not encrypting and can be done >>>>>>> well. >>>>>> >>>>>> >>>>>> It can also be done poorly, and the mention of obfuscation (along wi= th >>>>>> the >>>>>> exchange I cite below) leads me to believe that -- absent concrete >>>>>> guidance >>>>>> to the contrary -- implementors will choose to do it poorly. It's no= t >>>>>> clear >>>>>> that doing this poorly provides any benefit, and it seems to me that >>>>>> it >>>>>> may >>>>>> cause harm: if something _looks_ secure but isn't, doesn't that have >>>>>> the >>>>>> potential for operators to incorrectly treat it as secure? Again, th= is >>>>>> is >>>>>> more your area than mine and so I will defer to your opinion on the >>>>>> topic; >>>>>> but from a lay perspective, this seems likely to result in the lack = of >>>>>> guarding against compromise of the encrypted information under the >>>>>> mistaken >>>>>> impression that it can't be decrypted trivially. >>>>>> >>>>> >>>>> The way I read the thread from Acee is that there aren't any KEK >>>>> implementations with with particular YANG module, however Brian says >>>>> there is with other YANG modules. I *think* when Acee is referring t= o >>>>> obfuscation and less than ideal scenarios, it is with the currently >>>>> deployed implementations that don't use KEKs. But the text and >>>>> responses did seem to be commingled a bit too much. >>>>> >>>>>> >>>>>>> Am I missing something? Was there something implementation specifi= c >>>>>>> that has the raw key stored with the encrypted data? >>>>>> >>>>>> >>>>>> Perhaps the following exchange with the author: >>>>>> >>>>>> Adam: "By my reading, this is just talking about encrypting 'on the >>>>>> disk' >>>>>> storage on the device. Any processes involved in provisioning the >>>>>> values or >>>>>> using them to process traffic would have access to the plaintext, >>>>>> presumably >>>>>> by reading the encrypted form off disk, reading some keying material >>>>>> off >>>>>> disk, and combining them to retrieve the plaintext key." >>>>> >>>>> It looks like version 20 had different assumptions about using the >>>>> KEK. I *think* this is describing usage without a KEK and may be par= t >>>>> of why Acee is asking for more implementation guidance... so I'll kee= p >>>>> my discuss to see if we can shape that up more. This is helpful as I >>>>> think I see the gap more now as to what he might be looking for in >>>>> terms of guidance. >>>>> >>>>> Here's the text from -20: >>>>> >>>>> When configured, the key-strings can be encrypted using the AES Key >>>>> Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is >>>>> not included in the YANG model and must be set or derived independen= t >>>>> >>>>> Lindem, et al. Expires October 20, 2017 [Page = 15] >>>>> Internet-Draft YANG Key Chain April 2= 017 >>>>> >>>>> of key-chain configuration. When AES key-encryption is used, the >>>>> hex-key-string feature is also required since the encrypted keys wil= l >>>>> contain characters that are not representable in the YANG string >>>>> built-in type [YANG]. AES key-encryption MAY be used for added key >>>>> security in situations where the NETCONF Access Control Mode is not >>>>> available. >>>>> >>>>>> >>>>>> Acee: "This is the correct interpretation." >>>>>> >>>>>> /a >>>>> >>>>> Thanks. >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >> > > -- > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > --=20 Best regards, Kathleen From nobody Wed Apr 26 20:00:22 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A04129AD5; Wed, 26 Apr 2017 20:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyluSQ5-BMib; Wed, 26 Apr 2017 20:00:14 -0700 (PDT) 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 188391294E0; Wed, 26 Apr 2017 20:00:14 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3R30BfZ017487 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 22:00:12 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Kathleen Moriarty Cc: The IESG , Jeff Tantsura , rtgwg-chairs@ietf.org, draft-ietf-rtgwg-yang-key-chain@ietf.org, rtgwg@ietf.org References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> From: Adam Roach Message-ID: <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> Date: Wed, 26 Apr 2017 22:00:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 03:00:15 -0000 On 4/26/17 9:34 PM, Kathleen Moriarty wrote: > The final paragraph, I believe is referring to how the key is stored - > either a KEK is used and it's encrypted or it's not and it's advising > obfuscation at a minimum. That's how I read it too: it's talking about how the key is stored. If it's encrypted with a real crypto operation, it's going to have a KEK (which isn't necessarily the same KEK as is used to decrypt the information received from a remote node, right?); and, if it's obfuscated, it doesn't even necessarily have a key at all, just some kind of reversible transformation. Let's focus on the "obfuscation" case, because I think it's easier to reason about (and less likely to get conflated with other operations), and then we can extend that reasoning to the crypto case if we come to agreement. I'm making certain assumptions here which you may have a different read on (and, as before, this is your area, so I'd take your assumptions over my own) -- please correct me where I'm overstating or misstating things. In the obfuscation case -- and barring any advanced anti-debugger and anti-ICE defenses -- reverse-engineering the obfuscation technique would be a fairly straightforward exercise. So I think we can safely assume that any such obfuscation performed by popular routers will be reversible by your average black-hat hacker. That seems to negate most of the benefit obtained by obfuscation. At the same time, an administrator observing that the stored value is not the same as the actual key may make the erroneous assumption that the on-disk value itself is not particularly high value, and may take steps that make it more likely to fall into the hands of an attacker than if the administrator saw the literal key present in the configuration. That seems to make the obfuscation potentially harmful. Little benefit with possible harm would, to me, indicate that obfuscation should not be employed. > Does that help? I'll defer to the authors and AD and get back to the > part of the thread where I'm hoping we can add the KEK back into the > draft. I hope so too. As a process point: removing this from the document seems like a material change. If this went through WGLC and IETF LC with the KEK as part of the data model, I would think its removal would require WG buy-in, and running through IETF LC again. /a From nobody Wed Apr 26 21:02:33 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE9F129577; Wed, 26 Apr 2017 21:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMYSXzzv82gJ; Wed, 26 Apr 2017 21:02:16 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 775FF12426E; Wed, 26 Apr 2017 21:02:16 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id u65so5903384wmu.1; Wed, 26 Apr 2017 21:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oJ+S3O9WpUwtErfpZBh4Agf8ErXCC7tfNAeL7ph9+Ok=; b=SRtYjgHw2xfC5iq15tMuRBtMJAcVUYB/sSrH2rz1xiVZyegjTUfoU/6vdja7p5seMv F2+SyQivd7QttsCU8YJYIU0iKlJi+8vRPl8crpw8CFiva3bUwlzD6kFkMXDDNaA0v+zn TQ26j8vfXOpZg0u2nWq82F+nnRUDjRWCifSsgqf6Xyy27nJQOf6I7GJGJRUco7HoLlKB 7h1Hh6xhcoWbrV4gypWEVcupj8TQQSCF5dCAaCz7Tm8Ie/UET9aqvXCE8hXq14qdhdiW Xs1xJvb9dFhk38mJo11KhDpFjH8NJehpcCk2//811nV0oIATOozdOH2NdhfoIfBEZpvp HwzQ== 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=oJ+S3O9WpUwtErfpZBh4Agf8ErXCC7tfNAeL7ph9+Ok=; b=m5LKD+Ap7b3G93CXnwr7QAoLxYiAM5vDCC1dV97wTWU9RPjp2lT7HWua5tSrmMi2Jd 8+QCXkUci0vQanJASlZfL5tOD8DEk8c0MrDY7edvHH+y6EbuHn+StJ20zvatae0NqqIT ntSU/Hze2CFZu6j6D/8yYYrdDCWlCtzgXFD51n8m39q9v86TiWFrsMZMqH9kND/2b2Lz UiJhuw9O5nH7Yh5cfg/OExVfyyV4L0auxjHG74EEnugLGWrej4i8BR52HWTCfwy6ZKAg 5mxutoCA0IBRjI5EKuTBySQaPsTJzXUILcaZlhGZVm5k6DKZtVxHyBvEEsdltWxPHYn/ gJlw== X-Gm-Message-State: AN3rC/4hv5uEfh3/yLpFYZ+taMVpJSQpZM/PUGZjI1HRdKl9sVlwZTLt 7ddJvDXiqpWrvI0otLqstP+jRHHJfw== X-Received: by 10.28.182.69 with SMTP id g66mr769829wmf.112.1493265734717; Wed, 26 Apr 2017 21:02:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.120 with HTTP; Wed, 26 Apr 2017 21:02:14 -0700 (PDT) In-Reply-To: <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> From: Alia Atlas Date: Thu, 27 Apr 2017 00:02:14 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Adam Roach Cc: Kathleen Moriarty , Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , draft-ietf-rtgwg-yang-key-chain@ietf.org, "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=001a114b108cac5b66054e1e058e Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 04:02:19 -0000 --001a114b108cac5b66054e1e058e Content-Type: text/plain; charset=UTF-8 I am just catching up on this conversation. First, the YANG model is primarily for information in motion - either for configuration to the device or to read from the device. It is much less likely to represent the data structure and storage in the device. I believe that this draft's context is strictly for information in motion. This YANG model, as with all, is intended for transport over NetConf or RestConf, which are confidential transports. Thus, any keys sent in the YANG model are already protected in flight. However, to allow for the limited cases (as I understand it) where that isn't viewed as sufficient protection, the key might be sent encrypted (via KEK) so it is encrypted before being handed to the model, the configuration action would be with the encrypted key, and then the device would have to know how to decrypt it, which is all out-of-band behavior as far as the YANG model and associated protocols go. The gotcha - and why, as I understand it, that encrypted keys are even mentioned is that it alters the data type used for transmitting the key as in the snippet below. Normally the keystring would be a string, but if encrypted, it is a hex-string - so arbitrary bytes. "+--rw key-string | +--rw (key-string-style)? | +--:(keystring) | | +--rw keystring? string | +--:(hexadecimal) {hex-key-string}? | +--rw hexadecimal-string? yang:hex-string " This draft isn't trying to describe how or whether to use KEK. It's just making sure the YANG model is sufficient general to transmit the key if it is previously encrypted. Does that make sense and help clarify? Regards, Alia On Wed, Apr 26, 2017 at 11:00 PM, Adam Roach wrote: > On 4/26/17 9:34 PM, Kathleen Moriarty wrote: > >> The final paragraph, I believe is referring to how the key is stored - >> either a KEK is used and it's encrypted or it's not and it's advising >> obfuscation at a minimum. >> > > That's how I read it too: it's talking about how the key is stored. If > it's encrypted with a real crypto operation, it's going to have a KEK > (which isn't necessarily the same KEK as is used to decrypt the information > received from a remote node, right?); and, if it's obfuscated, it doesn't > even necessarily have a key at all, just some kind of reversible > transformation. > > Let's focus on the "obfuscation" case, because I think it's easier to > reason about (and less likely to get conflated with other operations), and > then we can extend that reasoning to the crypto case if we come to > agreement. I'm making certain assumptions here which you may have a > different read on (and, as before, this is your area, so I'd take your > assumptions over my own) -- please correct me where I'm overstating or > misstating things. > > In the obfuscation case -- and barring any advanced anti-debugger and > anti-ICE defenses -- reverse-engineering the obfuscation technique would be > a fairly straightforward exercise. So I think we can safely assume that any > such obfuscation performed by popular routers will be reversible by your > average black-hat hacker. > > That seems to negate most of the benefit obtained by obfuscation. > > At the same time, an administrator observing that the stored value is not > the same as the actual key may make the erroneous assumption that the > on-disk value itself is not particularly high value, and may take steps > that make it more likely to fall into the hands of an attacker than if the > administrator saw the literal key present in the configuration. > > That seems to make the obfuscation potentially harmful. > > Little benefit with possible harm would, to me, indicate that obfuscation > should not be employed. > > > > Does that help? I'll defer to the authors and AD and get back to the >> part of the thread where I'm hoping we can add the KEK back into the >> draft. >> > > I hope so too. As a process point: removing this from the document seems > like a material change. If this went through WGLC and IETF LC with the KEK > as part of the data model, I would think its removal would require WG > buy-in, and running through IETF LC again. > > /a > > --001a114b108cac5b66054e1e058e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am just catching up on this conversation.

=
First, the YANG model is primarily for information in motion - either = for configuration to the device
or to read from the device. =C2= =A0 It is much less likely to represent the data structure and storage in t= he device.
I believe that this draft's context is strictly fo= r information in motion.

This YANG model, as with = all, is intended for transport over NetConf or RestConf, which are confiden= tial
transports.=C2=A0 Thus, any keys sent in the YANG model are = already protected in flight.

However, to allow for= the limited cases (as I understand it) where that isn't viewed as suff= icient protection,
the key might be sent encrypted (via KEK) so i= t is encrypted before being handed to the model, the configuration
action would be with the encrypted key, and then the device would have to= know how to decrypt it, which is all
out-of-band behavior as far= as the YANG model and associated protocols go.

Th= e gotcha - and why, as I understand it, that encrypted keys are even mentio= ned is that it alters the data type
used for transmitting the key= as in the snippet below.=C2=A0 Normally the keystring would be a string, b= ut if encrypted,
it is a hex-string - so arbitrary bytes.

"+--rw key-string

=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 | =C2=A0+--rw (key-string-style)?
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--:(keystring)
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0+--rw keystring? =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 +--:(hexadecimal) {hex-key-string}?
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw hexad= ecimal-string? =C2=A0 yang:hex-string
"

Th= is draft isn't trying to describe how or whether to use KEK.=C2=A0 It&#= 39;s just making sure the YANG model is sufficient
general to tra= nsmit the key if it is previously encrypted.

Does = that make sense and help clarify?

Regards,
Alia


On Wed, Apr 26, 2017 at 11:00 PM, Adam Roach <adam@nostrum.com>= wrote:
On 4/26/17 9:34 PM, Kathleen Moriarty wrote:
The final paragraph, I believe is referring to how the key is stored -
either=C2=A0 a KEK is used and it's encrypted or it's not and it= 9;s advising
obfuscation at a minimum.

 That's how I read it too: it's talking about how the key is stored.= If it's encrypted with a real crypto operation, it's going to have= a KEK (which isn't necessarily the same KEK as is used to decrypt the = information received from a remote node, right?); and, if it's obfuscat= ed, it doesn't even necessarily have a key at all, just some kind of re= versible transformation.

Let's focus on the "obfuscation" case, because I think it'= ;s easier to reason about (and less likely to get conflated with other oper= ations), and then we can extend that reasoning to the crypto case if we com= e to agreement. I'm making certain assumptions here which you may have = a different read on (and, as before, this is your area, so I'd take you= r assumptions over my own) -- please correct me where I'm overstating o= r misstating things.

In the obfuscation case -- and barring any advanced anti-debugger and anti-= ICE defenses -- reverse-engineering the obfuscation technique would be a fa= irly straightforward exercise. So I think we can safely assume that any suc= h obfuscation performed by popular routers will be reversible by your avera= ge black-hat hacker.

That seems to negate most of the benefit obtained by obfuscation.

At the same time, an administrator observing that the stored value is not t= he same as the actual key may make the erroneous assumption that the on-dis= k value itself is not particularly high value, and may take steps that make= it more likely to fall into the hands of an attacker than if the administr= ator saw the literal key present in the configuration.

That seems to make the obfuscation potentially harmful.

Little benefit with possible harm would, to me, indicate that obfuscation s= hould not be employed.



Does that help?=C2=A0 I'll defer to the authors and AD and get back to = the
part of the thread where I'm hoping we can add the KEK back into the draft.

 I hope so too. As a process point: removing this from the document seems li= ke a material change. If this went through WGLC and IETF LC with the KEK as= part of the data model, I would think its removal would require WG buy-in,= and running through IETF LC again.

/a


--001a114b108cac5b66054e1e058e-- From nobody Wed Apr 26 21:11:44 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37D0127A97; Wed, 26 Apr 2017 21:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6jmK-70He75; Wed, 26 Apr 2017 21:11:40 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34BBE1277BB; Wed, 26 Apr 2017 21:11:40 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id r190so2748002wme.1; Wed, 26 Apr 2017 21:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HdM70hYOI4KJMyjcLQyiibec9gTDcFrjDzRQR74tIsc=; b=dxquERLyqdx5IgrHHmsW8N1SYizHj+KnDdB59xuSN1LMJdhAHxThOyyA8jIV03y+GP EsIZSOeu8Z390FSbsUG8a2J1CZ2UHIeVGwamAAqUP38EmkZdv5HdrJNvlCTYF4VxpbeQ lDXolej+0nx1Y40TpELWzpMWhHo0qJwk6biD+AOv8hAV/pZkLvk3NtXQuDUh4ck3DWi/ wh3grL14K+5ByB2CCzJJOuQOmu/3eWqI6zyK/Wk2g67LHJRLc+ivGBFyxGc7+W75wDMp FlGgxXhXQXg+DX2SN1o58/PA6F6sglmOzfk0xPT4mZqEwPzg93+vQOxlMt2NvKl96OQc cFmA== 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=HdM70hYOI4KJMyjcLQyiibec9gTDcFrjDzRQR74tIsc=; b=Amk+K7O1pwSJaFj8bUwx+tUtJuVTTIoYXCntDHEWwhSjeAq/OhfqBRW+gleX3aRQvI yBfDRrXwKUHI0D5PGndWEMnuMudeddrXY6iplmx7xN3Cx7v25k172x9pDvVg3vAu4i6r 82LWcp63QoFLoZeEQtM+TojFIsx1hwgV1BXCHxPzdcyVn2UnQnNp53J6aIWs926TYiB9 71PHf8X2bG7eIOLy0Fhj/kpowz93YROTrtULdNosZaPAngTJ5m2+vFtKj0q+y2Q84t0v dwxzhWlbbz3nXsEgWQTXqiaf8WItSB5qx7NxiHpbjJPTPJRZ1zkfcGoAKaF5jahCUnP5 iK4w== X-Gm-Message-State: AN3rC/5Ul3lmuZ46mwNnxSnlCm/fbKqakJJsIazTEEJR9T75AQRRxbzQ F1yHOxqpw1hJKb9yJsQi5AN6dv4yCSYv X-Received: by 10.28.5.8 with SMTP id 8mr701206wmf.70.1493266298478; Wed, 26 Apr 2017 21:11:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.120 with HTTP; Wed, 26 Apr 2017 21:11:37 -0700 (PDT) In-Reply-To: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> From: Alia Atlas Date: Thu, 27 Apr 2017 00:11:37 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Adam Roach Cc: Kathleen Moriarty , Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , draft-ietf-rtgwg-yang-key-chain@ietf.org, "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=001a1144369a46a54d054e1e2747 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 04:11:42 -0000 --001a1144369a46a54d054e1e2747 Content-Type: text/plain; charset=UTF-8 One last piece (sorry to top-post, but scanning the relevant security considerations piece in version -20): With this model, any user/group can read the operational state via YANG model and that would, by default, include unencrypted keys being transmitted. If NACM is supported, then only certain users/groups would be able to access the keys. Without NACM, using the KEK ensures that even if a user/group receives the operational state of the YANG model, the keys aren't unencrypted. Thus the user/group would need to have access to the key used in KEK. Does this match up with your understanding? I think that Kathleen's Discuss is just asking for a paragraph - perhaps in 3.2 or a new 3.2.1 that describes the above and that the key-handling for KEK is out-of-bounds. Regards, Alia On Thu, Apr 27, 2017 at 12:02 AM, Alia Atlas wrote: > I am just catching up on this conversation. > > First, the YANG model is primarily for information in motion - either for > configuration to the device > or to read from the device. It is much less likely to represent the data > structure and storage in the device. > I believe that this draft's context is strictly for information in motion. > > This YANG model, as with all, is intended for transport over NetConf or > RestConf, which are confidential > transports. Thus, any keys sent in the YANG model are already protected > in flight. > > However, to allow for the limited cases (as I understand it) where that > isn't viewed as sufficient protection, > the key might be sent encrypted (via KEK) so it is encrypted before being > handed to the model, the configuration > action would be with the encrypted key, and then the device would have to > know how to decrypt it, which is all > out-of-band behavior as far as the YANG model and associated protocols go. > > The gotcha - and why, as I understand it, that encrypted keys are even > mentioned is that it alters the data type > used for transmitting the key as in the snippet below. Normally the > keystring would be a string, but if encrypted, > it is a hex-string - so arbitrary bytes. > > "+--rw key-string > > | +--rw (key-string-style)? > | +--:(keystring) > | | +--rw keystring? string > | +--:(hexadecimal) {hex-key-string}? > | +--rw hexadecimal-string? yang:hex-string > " > > This draft isn't trying to describe how or whether to use KEK. It's just > making sure the YANG model is sufficient > general to transmit the key if it is previously encrypted. > > Does that make sense and help clarify? > > Regards, > Alia > > > On Wed, Apr 26, 2017 at 11:00 PM, Adam Roach wrote: > >> On 4/26/17 9:34 PM, Kathleen Moriarty wrote: >> >>> The final paragraph, I believe is referring to how the key is stored - >>> either a KEK is used and it's encrypted or it's not and it's advising >>> obfuscation at a minimum. >>> >> >> That's how I read it too: it's talking about how the key is stored. If >> it's encrypted with a real crypto operation, it's going to have a KEK >> (which isn't necessarily the same KEK as is used to decrypt the information >> received from a remote node, right?); and, if it's obfuscated, it doesn't >> even necessarily have a key at all, just some kind of reversible >> transformation. >> >> Let's focus on the "obfuscation" case, because I think it's easier to >> reason about (and less likely to get conflated with other operations), and >> then we can extend that reasoning to the crypto case if we come to >> agreement. I'm making certain assumptions here which you may have a >> different read on (and, as before, this is your area, so I'd take your >> assumptions over my own) -- please correct me where I'm overstating or >> misstating things. >> >> In the obfuscation case -- and barring any advanced anti-debugger and >> anti-ICE defenses -- reverse-engineering the obfuscation technique would be >> a fairly straightforward exercise. So I think we can safely assume that any >> such obfuscation performed by popular routers will be reversible by your >> average black-hat hacker. >> >> That seems to negate most of the benefit obtained by obfuscation. >> >> At the same time, an administrator observing that the stored value is not >> the same as the actual key may make the erroneous assumption that the >> on-disk value itself is not particularly high value, and may take steps >> that make it more likely to fall into the hands of an attacker than if the >> administrator saw the literal key present in the configuration. >> >> That seems to make the obfuscation potentially harmful. >> >> Little benefit with possible harm would, to me, indicate that obfuscation >> should not be employed. >> >> >> >> Does that help? I'll defer to the authors and AD and get back to the >>> part of the thread where I'm hoping we can add the KEK back into the >>> draft. >>> >> >> I hope so too. As a process point: removing this from the document seems >> like a material change. If this went through WGLC and IETF LC with the KEK >> as part of the data model, I would think its removal would require WG >> buy-in, and running through IETF LC again. >> >> /a >> >> > --001a1144369a46a54d054e1e2747 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One last piece (sorry to top-post, but scanning the releva= nt security considerations piece in version -20):

With t= his model, any user/group can read the operational state via YANG model and= that would, by default, include
unencrypted keys being transmitt= ed.=C2=A0 If NACM is supported, then only certain users/groups would be abl= e to access
the keys.=C2=A0 Without NACM, using the KEK ensures t= hat even if a user/group receives the operational state of the YANG
model, the keys aren't unencrypted.=C2=A0 Thus the user/group would = need to have access to the key used in KEK.

Does t= his match up with your understanding?=C2=A0

I thin= k that Kathleen's Discuss is just asking for a paragraph - perhaps in 3= .2 or a new 3.2.1 that describes the above
and that the key-handl= ing for KEK is out-of-bounds.

Regards,
A= lia

On= Thu, Apr 27, 2017 at 12:02 AM, Alia Atlas <akatlas@gmail.com> wrote:
I am just catc= hing up on this conversation.

First, the YANG model is p= rimarily for information in motion - either for configuration to the device=
or to read from the device. =C2=A0 It is much less likely to rep= resent the data structure and storage in the device.
I believe th= at this draft's context is strictly for information in motion.

This YANG model, as with all, is intended for transport ov= er NetConf or RestConf, which are confidential
transports.=C2=A0 = Thus, any keys sent in the YANG model are already protected in flight.

However, to allow for the limited cases (as I understa= nd it) where that isn't viewed as sufficient protection,
the = key might be sent encrypted (via KEK) so it is encrypted before being hande= d to the model, the configuration
action would be with the encryp= ted key, and then the device would have to know how to decrypt it, which is= all
out-of-band behavior as far as the YANG model and associated= protocols go.

The gotcha - and why, as I understa= nd it, that encrypted keys are even mentioned is that it alters the data ty= pe
used for transmitting the key as in the snippet below.=C2=A0 N= ormally the keystring would be a string, but if encrypted,
it is = a hex-string - so arbitrary bytes.

"+--rw key= -string

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw (key= -string-style)?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 +--:(keystring)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 | =C2=A0+--rw keystring? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0st= ring
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--:(hexa= decimal) {hex-key-string}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw hexadecimal-string? =C2=A0 yang:hex-string=
"

This draft isn't trying to describe= how or whether to use KEK.=C2=A0 It's just making sure the YANG model = is sufficient
general to transmit the key if it is previously enc= rypted.

Does that make sense and help clarify?

Regards,
Alia
<= div>

On Wed, A= pr 26, 2017 at 11:00 PM, Adam Roach <adam@nostrum.com> wrote:=
On 4/26/17 9:34 PM, Kathleen Moriarty wrote:
The final paragraph, I believe is referring to how the key is stored -
either=C2=A0 a KEK is used and it's encrypted or it's not and it= 9;s advising
obfuscation at a minimum.

 That's how I read it too: it's talking about how the key is stored.= If it's encrypted with a real crypto operation, it's going to have= a KEK (which isn't necessarily the same KEK as is used to decrypt the = information received from a remote node, right?); and, if it's obfuscat= ed, it doesn't even necessarily have a key at all, just some kind of re= versible transformation.

Let's focus on the "obfuscation" case, because I think it'= ;s easier to reason about (and less likely to get conflated with other oper= ations), and then we can extend that reasoning to the crypto case if we com= e to agreement. I'm making certain assumptions here which you may have = a different read on (and, as before, this is your area, so I'd take you= r assumptions over my own) -- please correct me where I'm overstating o= r misstating things.

In the obfuscation case -- and barring any advanced anti-debugger and anti-= ICE defenses -- reverse-engineering the obfuscation technique would be a fa= irly straightforward exercise. So I think we can safely assume that any suc= h obfuscation performed by popular routers will be reversible by your avera= ge black-hat hacker.

That seems to negate most of the benefit obtained by obfuscation.

At the same time, an administrator observing that the stored value is not t= he same as the actual key may make the erroneous assumption that the on-dis= k value itself is not particularly high value, and may take steps that make= it more likely to fall into the hands of an attacker than if the administr= ator saw the literal key present in the configuration.

That seems to make the obfuscation potentially harmful.

Little benefit with possible harm would, to me, indicate that obfuscation s= hould not be employed.



Does that help?=C2=A0 I'll defer to the authors and AD and get back to = the
part of the thread where I'm hoping we can add the KEK back into the draft.

 I hope so too. As a process point: removing this from the document seems li= ke a material change. If this went through WGLC and IETF LC with the KEK as= part of the data model, I would think its removal would require WG buy-in,= and running through IETF LC again.

/a



--001a1144369a46a54d054e1e2747-- From nobody Thu Apr 27 05:25:00 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A80B1288B8; Thu, 27 Apr 2017 05:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.59 X-Spam-Level: X-Spam-Status: No, score=-4.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObPo0yuwab0H; Thu, 27 Apr 2017 05:24:48 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.164]) (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 2EFAC1273B1; Thu, 27 Apr 2017 05:24:47 -0700 (PDT) Received: from [85.158.138.179] by server-4.bemta-3.messagelabs.com id 98/5F-02192-C03E1095; Thu, 27 Apr 2017 12:24:44 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VSf0gTcRTf9+7mLvP0nJrPYYTTIAstUWhEiWW FFKURBIZSt7rcaJuym7qCyvJH+SPQitS1mdmQ0qlhv2cFGhKOpLAkjFY5LacYQlKmgnXbzbL/ Pu993ufz3gceiUsH/WQkazSweh2jkfv5E0lRKdlxASMoc8NcTaiizXpCYb+8WzFxYRZTVF1cp +gz/8IVjbYvEsXryXlcMfVyGk8h0x6bnJI0q3UWS+sdsuAZ+EGxWqfMNR4Wq94NzeN5PwaRse hWEypCJW9QBfInCboMhzFHg7eQ0pcweHH3DSYUnxF03y+WVKBlpB+9BTpbnX4eHEpz0Hr+ple B058w6JwbQB4ihN4K50q7xcLQTrC4rxICjoeBLqsXE/RquD371WtE0VkwM+fwYkSvgBmHDfNg nA6H96PXvRhoGqxPXuECDoPxkQWxMF+JoKsxWehHQd1Hs8RzENBVONhbppFA7IFrNaO8gORxN NxzZwuQ17oKhYnjMPnU7ZvWwPepNiTYvMegvKvZd0MkXLNU+Pw7xNDXXCYWAsvA+bbcFz4S3B +eioUAOhh77iKEkMHQVz9KLBp96zX7wqSDu6qHqEYxpiWZTUvkpiVyE383TsdCh329MBIFVyq HJQJeA6Vmi2RpvxFJWtAajtUXsPq4hA3xSr06R2XQMmoNXyXGa1mOY3JYDaPk4o/kajsR/25n RCL0CD2oSO1BESQmD6NWdqNMaaAy9+gJFcOpDunzNSzXgyJJUg5UhIvngvVsDms8ptbwP7tIA xkgD6WUHpri8hgtp84RKAeKkoVTd4Z5gvYQqnzdX9nitw+glbIQColEImlAHqvXqg3/8xMonE TyECrRYx+g1hn+uk/wizF+MbFd5FlsYP5RsiIUY2M2zWTXm2sKg5yHBu8/m35b3NCf28w6T8U 1ZW1rj4i1aVz9B0L2JlMFho1p9+zbah3RQSd7kyofKg2BXcPzrqPV6c9ulEnHDbXH1oXvOhK8 f98yx1Dk5lhqx9UO5dl2++Tp5IzNq4yZz39ObV1QW7S/0ycTFoLrynf2p5Zk65bLCU7FJKzF9 RzzB9Ot41LoAwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-2.tower-169.messagelabs.com!1493295880!112854805!1 X-Originating-IP: [52.33.64.93] X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 4639 invoked from network); 27 Apr 2017 12:24:43 -0000 Received: from ec2-52-33-64-93.us-west-2.compute.amazonaws.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (52.33.64.93) by server-2.tower-169.messagelabs.com with AES256-SHA256 encrypted SMTP; 27 Apr 2017 12:24:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZICJtn6qIJeeCFO8GlFRaoVF9OQ5tr59GuqtRZ6COGE=; b=RVIMoV/UlmgRGKgEJTIjfG/mFUrbeyH09E3OeBgnMZ6yqDsK4GOcUilarl6t53I+lEjaN/Sh8EXiXhKPEeToWZFB7q3kzzPJhnuy0fSOo3yjz2oKMMok3gD9Dg1NxaR4WmR9fnI7Q75PZu0//xR7h50U2xYh/+RAZqUmNM4qa8s= Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by DB4PR03MB0846.eurprd03.prod.outlook.com (10.161.15.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Thu, 27 Apr 2017 12:24:39 +0000 Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::dd45:832a:e658:e737]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::dd45:832a:e658:e737%14]) with mapi id 15.01.1047.019; Thu, 27 Apr 2017 12:24:38 +0000 From: Alexander Vainshtein To: "jefftant.ietf@gmail.com" , "chrisbowers.ietf@gmail.com" CC: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)" , "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-rtgwg-backoff-algo@ietf.org" , "rtgwg@ietf.org" , "vainshtein.alex@gmail.com" Subject: Early RTG-DIR review of draft-ietf-rtgwg-backoff-algo-04 Thread-Topic: Early RTG-DIR review of draft-ietf-rtgwg-backoff-algo-04 Thread-Index: AdK8QEEK4unKSUKcREikSjn35QwsHw== Date: Thu, 27 Apr 2017 12:24:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-microsoft-exchange-diagnostics: 1; DB4PR03MB0846; 7:tRL/FiN6zrBM6clcEGX6+BDnehNMYR0eP1exSEkX94sXd4BLmqll2mHWr4fbYYKWIgdWj8UVy6+yZd020LaiLS9O9sV6Kg052DXBWcbJq0IfrLzR8hKmTlXEd6GPl1qHhA4xa6bI1QU/0mdnYWhkrLuQa7aOOMyEoVdiH/Pq9vqvoLY+a+p1I0kgejjJuAwW11GjNkHLvyLka/1yoN5zkF0CxLRCm1gEQktBwKuEROKQHrW7mMkZP5G7QDEXsJU/32sg6xyRUZMrVrH4eSwMfL5Yt65FJ88VdYgk1ktDc5eaOJ0UGH+bFb2VUpyRuTlnlHovv/v8u5lsG6XUmnqHBg== x-ms-office365-filtering-correlation-id: b2417ce9-cd9f-4a2e-d08d-08d48d685fc0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB4PR03MB0846; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(44800604510135)(120809045254105)(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:DB4PR03MB0846; BCL:0; PCL:0; RULEID:; SRVR:DB4PR03MB0846; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39400400002)(39410400002)(39840400002)(39850400002)(252514010)(2900100001)(8676002)(2906002)(3660700001)(606005)(6436002)(6116002)(790700001)(8936002)(3280700002)(3846002)(102836003)(54896002)(6306002)(9686003)(236005)(54906002)(55016002)(99286003)(53936002)(2501003)(50986999)(7696004)(54356999)(189998001)(86362001)(5250100002)(6506006)(81166006)(33656002)(74316002)(5660300001)(106356001)(7906003)(25786009)(4326008)(39060400002)(66066001)(9326002)(38730400002)(230783001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR03MB0846; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR03MB1713386BB8649B3813B8E24E9D100AM4PR03MB1713eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 12:24:38.7208 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR03MB0846 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:24:51 -0000 --_000_AM4PR03MB1713386BB8649B3813B8E24E9D100AM4PR03MB1713eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sCgpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBh cyBhbiBlYXJseSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3Jh dGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMg YXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQg c29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gSW4gdGhpcyBjYXNlIGFuIGVhcmx5IHJldmll dyBoYXMgYmVlbiByZXF1ZXN0ZWQgYnkgSmVmZiBUYW50c3VyYSDigJMgb25lIG9mIHRoZSBjby1j aGFpcnMgb2YgdGhlIFJUR1dHLgpUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuICAgRm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcgoKRG9jdW1lbnQ6IGRyYWZ0 LWlldGYtcnRnd2ctYmFja29mZi1hbGdvLTA0ClJldmlld2VyOiBBbGV4YW5kZXIgKOKAnFNhc2hh 4oCdKSBWYWluc2h0ZWluClJldmlldyBEYXRlOiAyNy1BcHItMTcKSUVURiBMQyBFbmQgRGF0ZTog Ti9BCkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRzIFRyYWNrCgpTdW1tYXJ5OgpJIGhhdmUgc29t ZSBtaW5vciBjb25jZXJucyBhYm91dCB0aGlzIGRvY3VtZW50IHRoYXQsIGZyb20gbXkgUE9WLCBz aG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLgoKQ29tbWVudHM6ClRoZSBkcmFm dCBpcyB2ZXJ5IHdlbGwgd3JpdHRlbiwgYW5kLCB3aXRoIG9uZSBub3RhYmxlIGV4Y2VwdGlvbiwg ZWFzeSB0byB1bmRlcnN0YW5kLgpJdCByZXByZXNlbnRzIGFuIGF0dGVtcHQgdG8gc3RhbmRhcmRp emUgb25lIGFzcGVjdCBvZiBiZWhhdmlvciBvZiBsaW5rLXN0YXRlIHJvdXRpbmcgcHJvdG9jb2xz OiBkZWxheSBiZXR3ZWVuIHRoZSBmaXJzdCBJR1AgZXZlbnQgdGhhdCB0cmlnZ2VycyBuZXcgU1BG IGNvbXB1dGF0aW9uIGFuZCB0aGUgU1BGIGNhbGN1bGF0aW9uLiBVbnRpbCBub3csIHRoaXMgYmVl biBsZWZ0IGZvciB0aGUgaW1wbGVtZW50ZXJzIHRvIHBsYXkgd2l0aCBmcmVlbHkuIFRoZSByZXN1 bHRpbmcgZGlmZmVyZW5jZXMgaGF2ZSBiZWVuIGtub3duIGZvciBxdWl0ZSBzb21lIHRpbWUgdG8g cmVzdWx0IGluIHNvbWUgY2FzZSBpbiB0cmFuc2llbnQgbWljcm8tbG9vcHMuCgpUaGUgcmVzb2x1 dGlvbiBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGluY2x1ZGVzIGEgd2VsbC1kZWZpbmVkIEZTTSBh bmQgYSBmdWxsIHNldCBvZiB0dW5hYmxlIHBhcmFtZXRlcnMgKHRpbWVycykgdXNlZCBpbiB0aGlz IEZTTS4KVGhlIHJhbmdlIGFuZCBncmFudWxhcml0eSBvZiBhbGwgdGhlIHR1bmFibGUgcGFyYW1l dGVycyBhcmUgZXhwbGljaXRseSBkZWZpbmVkIGluIHRoZSBkb2N1bWVudCBzbyB0aGF0IHRoZSBv cGVyYXRvciB3b3VsZCBiZSBhYmxlIHRvIHR1bmUgaXRzIG5ldHdvcmsgdG8gdXNlIGV4YWN0bHkg dGhlIHNhbWUgU1BGIGRlbGF5IGFsZ29yaXRobSB3aXRoIGV4YWN0bHkgdGhlIHNhbWUgcGFyYW1l dGVycy4gKFRoZSBkZWZhdWx0IHZhbHVlcyBhcmUgbm90IGRlZmluZWQgYmVjYXVzZSBvbmUgc2l6 ZSBkb2VzIG5vdCBmaXQgYWxsIGluIHRoaXMgY2FzZSkuCgpJdCBzaG91bGQgYmUgbm90aWNlZCB0 aGF0IHRoZSBkcmFmdCBkb2VzIG5vdCBpbnRlbmQgdG8gcHJvdmlkZSBhIGNvbXByZWhlbnNpdmUg c29sdXRpb24gb2YgdGhlIG1pY3JvLWxvb3AgcHJvYmxlbXMuClJhdGhlciwgaXQgcHJvdmlkZXMg YSBjb21tb24gYmFzZWxpbmUgdXBvbiB3aGljaCBzcGVjaWZpYyBzb2x1dGlvbnMgZm9yIHRoZXNl IHByb2JsZW1zIGNhbiBiZSBidWlsdCAoZS5nLiwgc2VlIGRyYWZ0LWlldGYtcnRnd2ctdWxvb3At ZGVsYXk8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGd3Zy11 bG9vcC1kZWxheS8/aW5jbHVkZV90ZXh0PTE+KS4KCk1ham9yIElzc3VlczogTm9uZSBmb3VuZC4K Ck1pbm9yIElzc3VlczoKCjEuICAgICAgIFRoZSBleGNlcHRpb24gdG8gZ29vZCByZWFkYWJpbGl0 eSBvZiB0aGUgZHJhZnQgcmVmZXJzIHRvIHRoZSB0ZXJtIOKAnHByb3hpbWF0ZSBmYWlsdXJlcy9J R1AgZXZlbnRz4oCdIHRoYXQgYXBwZWFycyA0IHRpbWVzIGluIHRoZSBkcmFmdC4gRW5nbGlzaCBp cyBub3QgbXkgbW90aGVyIHRvbmd1ZSwgYW5kIHRoZSByZWZlcmVuY2U8aHR0cHM6Ly93d3cubWVy cmlhbS13ZWJzdGVyLmNvbS90aGVzYXVydXMvcHJveGltYXRlPiBJ4oCZdmUgbG9va2VkIHVwIGRp ZCBub3QgaGVscCBtdWNoLiDigJxUZW1wb3JhbGx5IGNsb3Nl4oCdIChvciBzb21ldGhpbmcgYWxv bmcgdGhlc2UgbGluZXMpIGxvb2tzIGxpa2UgYSBzdWl0YWJsZSBhbHRlcm5hdGl2ZS4gKERvZXMg dGhpcyBjb21tZW50IHJ1biBzdHJpY3RseSBhZ2FpbnN0IHRoZSByZWNvbW1lbmRhdGlvbiBmb3Ig dGhlIFJURy1ESVIgcmV2aWV3ZXJzIOKAnHRvIGF2b2lkIHJhaXNpbmcgZXNvdGVyaWMgcXVlc3Rp b25zIG9mIEVuZ2xpc2ggdXNhZ2XigJ0/KQoKMi4gICAgICAgU2VjdGlvbiA1IG1lbnRpb25zIHN0 YXJ0aW5nIHRoZSBTUEZfVElNRVIgKHdpdGggb25lIG9mIHRoZSAzIHZhbHVlcyBkZWZpbmVkIGZv ciBpdCkgYXMgcGFydCBvZiB0aGUgcmVzcG9uc2UgdG8gc29tZSBGU00gZXZlbnRzIGlmIGl0IHdh cyBub3QgYWxyZWFkeSBydW5uaW5nIC0gIGJ1dCBpdCBkb2VzIG5vdCBzcGVjaWZ5IHdoYXQgaGFw cGVucyB3aGVuIHRoaXMgdGltZXIgZXhwaXJlcy4gSSBhc3N1bWUgdGhhdCBpdHMgZXhwaXJhdGlv biBsZWF2ZXMgdGhlIEZTTSBpbiBpdHMgY3VycmVudCBzdGF0ZSBhbmQgcmVzdWx0cyBpbiBydW5u aW5nIHRoZSBTUEYgY29tcHV0YXRpb24g4oCTIGlmIHRoaXMgaXMgY29ycmVjdCwgaXQgd291bGQg YmUgbmljZSB0byBzYXkgdGhhdCBleHBsaWNpdGx5LgoKMy4gICAgICAgU2VjdGlvbiA3IHJlY29t bWVuZHMgdGhhdCwgIGluIG9yZGVyIHRvIG1pdGlnYXRlIG1pY3JvLWxvb3AgcHJvYmxlbXMgdXNp bmcgdGhlIHByb3Bvc2VkIGFsZ29yaXRobSwg4oCcYWxsIHJvdXRlcnMgaW4gdGhlIElHUCBkb21h aW4sIG9yIGF0IGxlYXN0IGFsbCB0aGUgcm91dGVycyBpbiB0aGUgc2FtZSBhcmVhL2xldmVsLCBo YXZlIGV4YWN0bHkgdGhlIHNhbWUgY29uZmlndXJlZCAgdmFsdWVz4oCdIG9mIHRoZSByZWxldmFu dCB0aW1lcnMgLiBIb3dldmVyLCB0aGUgZHJhZnQgZG9lcyBub3Qgc3BlY2lmeSB3aGV0aGVyIHRo ZXNlIHRpbWVycyBzaG91bGQgYmUgY29uZmlndXJlZCBqdXN0IGF0IHRoZSBwcm90b2NvbCBpbnN0 YW5jZSBsZXZlbCBvciBhbHNvIGF0IHRoZSBsZXZlbCBvZiBlYWNoIHNwZWNpZmljIGFyZWEvbGV2 ZWwuIEZyb20gbXkgUE9WLCB0aGUgZ3JhbnVsYXJpdHkgb2YgY29uZmlndXJhdGlvbiBzaG91bGQg YmUgZGVmaW5lZCBpbiB0aGlzIGRyYWZ0IOKAkyBvbmUgd2F5IG9yIGFub3RoZXIuCgo0LiAgICAg ICBUaGUgbGF0ZXN0IHZlcnNpb25zIG9mIHRoZSBZQU5HIGRhdGEgbW9kZWwgZHJhZnRzIGZvciBJ Uy1JUyBhbmQgT1NQRiBhbHJlYWR5IGRlZmluZSB0aGUgdGltZXJzIGludHJvZHVjZWQgaW4gdGhp cyBkcmFmdC4gQnV0IHRoZXJlIGFyZSBubyByZWZlcmVuY2VzIHRvIHRoZXNlIGRyYWZ0cyBpbiB0 aGUgZG9jdW1lbnQuIEZyb20gbXkgUE9WIHN1Y2ggcmVmZXJlbmNlcyAoSW5mb3JtYXRpb25hbCBh bmQgdGhlcmVmb3JlIG5vbi1ibG9ja2luZykgd291bGQgYmUgdXNlZnVsIGZvciB0aGUgcmVhZGVy cywgYW5kIEkgc3VnZ2VzdCB0byBhZGQgdGhlbS4KCjUuICAgICAgIEkgaGF2ZSBzb21lIGNvbmNl cm5zIHJlZ2FyZGluZyBpbmNyZW1lbnRhbCBpbnRyb2R1Y3Rpb24gYW5kIGFjdGl2YXRpb24gb2Yg dGhlIHByb3Bvc2VkIGFsZ29yaXRobS4gVGhlIG9wZXJhdG9yIHRoYXQgcnVucyBhIHdlbGwtdHVu ZWQgbmV0d29yayBtYXkgZXhwZXJpZW5jZSB0cmFuc2llbnQgcHJvYmxlbXMgd2hlbiBzb21lIG9m IGl0cyByb3V0ZXJzIGFyZSBhbHJlYWR5IHVwZ3JhZGVkIGFuZCB1c2UgdGhlIHByb3Bvc2VkIGJh Y2stb2ZmIGFsZ29yaXRobSB3aGlsZSBzb21lIG90aGVycyBzdGlsbCBjYW5ub3QgZG8gdGhhdC4g U29tZSB0ZXh0IGV4cGxhaW5pbmcgcG90ZW50aWFsIGlzc3VlcyBpbiB0aGlzIHNjZW5hcmlvIGFu ZCwgaWYgcG9zc2libGUsIHRoZWlyIG1pdGlnYXRpb24sIHdvdWxkIGJlIG1vc3QgaGVscGZ1bC4K CjYuICAgICAgIFRoZSBleHBsYW5hdG9yeSB0ZXh0IGluIHRoZSBkcmFmdCBzZWVtcyB0byBzdHJv bmdseSBzdWdnZXN0IHRoYXQgIFNQRl9JTklUSUFMX0RFTEFZIDw9IFNQRl9TSE9SVF9ERUxBWSA8 PSAgU1BGX0xPTkdfREVMQVkg4oCTICBidXQgdGhpcyBpcyBub3QgZm9ybWFsaXplZCBhcyBhIHJl cXVpcmVtZW50IGFueXdoZXJlIGluIHRoZSB0ZXh0LiBGcm9tIG15IFBPViBzYXRpc2Z5aW5nIHRo aXMgcmVsYXRpb25zaGlwIHNob3VsZCBiZSBSRUNPTU1FTkRFRCB0byB0aGUgb3BlcmF0b3JzLgoK TklUUzoKCjEuICAgICAgIFNlY3Rpb24gMyBsaXN0cyAzIHBvc3NpYmxlIHZhbHVlcyBmb3IgdGhl IFNQRl9ERUxBWSB2YXJpYWJsZSBjYWxsZWQgSU5JVElBTF9TUEZfREVMQVksIFNIT1JUIFNQRl9E RUxBWSBhbmQgTE9OR19TUEZfREVMQVkuIFRoZW4sIGluIHRoZSBsYXN0IHBhcmEsIGl0IHJlZmVy cyB0byBhIHByZXZpb3VzbHkgdW5kZWZpbmVkIHZhbHVlLCBJTklUSUFMX1dBSVQuIFRoaXMgaXMg YW4gb2J2aW91cyB0eXBvIGFuZCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCBJTklUSUFMX1NQRl9E RUxBWQoKMi4gICAgICAgT25lIG9mIHRoZSBwYXJhbWV0ZXJzIG9mIHRoZSBhbGdvcml0aG0gaXMg Y2FsbGVkIEhPTERfRE9XTl9JTlRFUlZBTCAoaW4gU2VjdGlvbiAzIGFuZCBTZWN0aW9uIDYpICB2 cy4gSE9MRERPV05fSU5URVJWQUwgaW4gU2VjdGlvbiA1LiBUaGlzIGFsc28gbG9va3MgbGlrZSBh biBvYnZpb3VzIHR5cG8sIGFuZCB0aGUgc2FtZSBuYW1lIHNob3VsZCBiZSB1c2VkIGFjcm9zcyB0 aGUgZG9jdW1lbnQuCgpJIGhhdmUgZGlzY3Vzc2VkIG15IGNvbmNlcm5zIGFib3V0IHRoZSBkcmFm dCB3aXRoIHRoZSBhdXRob3JzIHdobyBoYXZlIGJlZW4gbW9zdCBjb29wZXJhdGl2ZS4KSSBiZWxp ZXZlIHRoYXQgd2UgaGF2ZSByZWFjaGVkIGFuIGFncmVlbWVudCBvbiBhY2NlcHRhYmxlIHJlc29s dXRpb24gb2YgYWxsIGNvbmNlcm5zIGxpc3RlZCBhYm92ZS4KClJlZ2FyZHMsClNhc2hhCgpPZmZp Y2U6ICs5NzItMzkyNjYzMDIKQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMgpFbWFpbDogICBBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKVGhpcyBl LW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250 YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyAKQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUg cHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgCnRy YW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9y IGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCAKYW5kIGFsbCBjb3BpZXMgdGhlcmVv Zi4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCg== --_000_AM4PR03MB1713386BB8649B3813B8E24E9D100AM4PR03MB1713eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEt LQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bAoJe21hcmdpbjowY207CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTEuMHB0 OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6IzA1NjNDMTsKCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQK CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjojOTU0RjcyOwoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgKCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7CgltYXJnaW4tdG9wOjBj bTsKCW1hcmdpbi1yaWdodDowY207CgltYXJnaW4tYm90dG9tOjBjbTsKCW1hcmdpbi1sZWZ0OjM2 LjBwdDsKCW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQtc2l6ZToxMS4wcHQ7Cglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9CnNwYW4uRW1haWxTdHlsZTE4Cgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm OwoJY29sb3I6d2luZG93dGV4dDsKCWZvbnQtd2VpZ2h0Om5vcm1hbDsKCWZvbnQtc3R5bGU6bm9y bWFsOwoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9CnNwYW4uRW1haWxTdHlsZTE5Cgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsK CWNvbG9yOiM0NDU0NkE7Cglmb250LXdlaWdodDpub3JtYWw7Cglmb250LXN0eWxlOm5vcm1hbDsK CXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQouTXNvQ2hwRGVmYXVsdAoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5OwoJZm9udC1zaXplOjEwLjBwdDsKCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30KZGl2LldvcmRTZWN0aW9uMQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30KLyogTGlzdCBEZWZpbml0aW9ucyAqLwpAbGlzdCBsMAoJe21z by1saXN0LWlkOjM3NzgyMjkxNTsKCW1zby1saXN0LXR5cGU6aHlicmlkOwoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0xMDkxMTQyMTQwIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30KQGxpc3QgbDA6 bGV2ZWwxCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDA6bGV2ZWwyCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsK CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpA bGlzdCBsMDpsZXZlbDMKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsKCW1z by1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsK CXRleHQtaW5kZW50Oi05LjBwdDt9CkBsaXN0IGwwOmxldmVsNAoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9CkBsaXN0IGwwOmxldmVsNQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDA6bGV2ZWw2Cgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlz dCBsMDpsZXZlbDcKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDgKCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpu b25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9CkBsaXN0IGwwOmxldmVsOQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy OwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxpc3QgbDEKCXttc28tbGlzdC1pZDo3NDI2Nzg4 NjY7Cgltc28tbGlzdC10eXBlOmh5YnJpZDsKCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTA5MTE0 MjE0MCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9CkBsaXN0IGwxOmxldmVsMQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsMgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDE6bGV2ZWwzCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWluZGVudDotOS4w cHQ7fQpAbGlzdCBsMTpsZXZlbDQKCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTps ZXZlbDUKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10 YWItc3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9CkBsaXN0IGwxOmxldmVsNgoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOwoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRlbnQ6LTkuMHB0O30KQGxpc3QgbDE6bGV2ZWw3Cgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0 ZXh0LWluZGVudDotMTguMHB0O30KQGxpc3QgbDE6bGV2ZWw4Cgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMTpsZXZl bDkKCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWIt c3RvcDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5kZW50 Oi05LjBwdDt9Cm9sCgl7bWFyZ2luLWJvdHRvbTowY207fQp1bAoJe21hcmdpbi1ib3R0b206MGNt O30KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4K PC9oZWFkPgo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pgo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8 bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5n IERpcmVjdG9yYXRlIGFzIGFuIGVhcmx5IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91 dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1y ZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVT RyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbAogcmVxdWVzdC4gSW4gdGhpcyBjYXNl IGFuIGVhcmx5IHJldmlldyBoYXMgYmVlbiByZXF1ZXN0ZWQgYnkgSmVmZiBUYW50c3VyYSDigJMg b25lIG9mIHRoZSBjby1jaGFpcnMgb2YgdGhlIFJUR1dHLjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNz aXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuJm5ic3A7Jm5ic3A7IEZvciBtb3JlIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8bzpwPjwvbzpwPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkRvY3VtZW50PC9iPjogZHJhZnQtaWV0Zi1ydGd3Zy1iYWNrb2ZmLWFsZ28t MDQ8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+UmV2aWV3ZXI8L2I+OiBB bGV4YW5kZXIgKOKAnFNhc2hh4oCdKSBWYWluc2h0ZWluIDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5SZXZpZXcgRGF0ZTwvYj46IDI3LUFwci0xNyA8bzpwPjwvbzpwPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+SUVURiBMQyBFbmQgRGF0ZTwvYj46IE4vQTxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5JbnRlbmRlZCBTdGF0dXM8L2I+OiBT dGFuZGFyZHMgVHJhY2s8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPlN1bW1hcnk8L2I+OjxvOnA+ PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgc29tZSBtaW5vciBjb25jZXJu cyBhYm91dCB0aGlzIGRvY3VtZW50IHRoYXQsIGZyb20gbXkgUE9WLCBzaG91bGQgYmUgcmVzb2x2 ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+Q29tbWVudHM8 L2I+OjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJhZnQgaXMgdmVy eSB3ZWxsIHdyaXR0ZW4sIGFuZCwgd2l0aCBvbmUgbm90YWJsZSBleGNlcHRpb24sIGVhc3kgdG8g dW5kZXJzdGFuZC48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgcmVwcmVz ZW50cyBhbiBhdHRlbXB0IHRvIHN0YW5kYXJkaXplIG9uZSBhc3BlY3Qgb2YgYmVoYXZpb3Igb2Yg bGluay1zdGF0ZSByb3V0aW5nIHByb3RvY29sczogZGVsYXkgYmV0d2VlbiB0aGUgZmlyc3QgSUdQ IGV2ZW50IHRoYXQgdHJpZ2dlcnMgbmV3IFNQRiBjb21wdXRhdGlvbiBhbmQgdGhlIFNQRiBjYWxj dWxhdGlvbi4gVW50aWwgbm93LCB0aGlzIGJlZW4gbGVmdCBmb3IgdGhlIGltcGxlbWVudGVycwog dG8gcGxheSB3aXRoIGZyZWVseS4gVGhlIHJlc3VsdGluZyBkaWZmZXJlbmNlcyBoYXZlIGJlZW4g a25vd24gZm9yIHF1aXRlIHNvbWUgdGltZSB0byByZXN1bHQgaW4gc29tZSBjYXNlIGluIHRyYW5z aWVudCBtaWNyby1sb29wcy4gJm5ic3A7PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcmVzb2x1 dGlvbiBwcm9wb3NlZCBpbiB0aGlzIGRyYWZ0IGluY2x1ZGVzIGEgd2VsbC1kZWZpbmVkIEZTTSBh bmQgYSBmdWxsIHNldCBvZiB0dW5hYmxlIHBhcmFtZXRlcnMgKHRpbWVycykgdXNlZCBpbiB0aGlz IEZTTS48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJhbmdlIGFuZCBn cmFudWxhcml0eSBvZiBhbGwgdGhlIHR1bmFibGUgcGFyYW1ldGVycyBhcmUgZXhwbGljaXRseSBk ZWZpbmVkIGluIHRoZSBkb2N1bWVudCBzbyB0aGF0IHRoZSBvcGVyYXRvciB3b3VsZCBiZSBhYmxl IHRvIHR1bmUgaXRzIG5ldHdvcmsgdG8gdXNlIGV4YWN0bHkgdGhlIHNhbWUgU1BGIGRlbGF5IGFs Z29yaXRobSB3aXRoIGV4YWN0bHkgdGhlIHNhbWUgcGFyYW1ldGVycy4gKFRoZSBkZWZhdWx0CiB2 YWx1ZXMgYXJlIG5vdCBkZWZpbmVkIGJlY2F1c2Ugb25lIHNpemUgZG9lcyBub3QgZml0IGFsbCBp biB0aGlzIGNhc2UpLjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc2hvdWxkIGJlIG5vdGljZWQg dGhhdCB0aGUgZHJhZnQgZG9lcyBub3QgaW50ZW5kIHRvIHByb3ZpZGUgYSBjb21wcmVoZW5zaXZl IHNvbHV0aW9uIG9mIHRoZSBtaWNyby1sb29wIHByb2JsZW1zLiZuYnNwOwo8bzpwPjwvbzpwPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmF0aGVyLCBpdCBwcm92aWRlcyBhIGNvbW1vbiBiYXNl bGluZSB1cG9uIHdoaWNoIHNwZWNpZmljIHNvbHV0aW9ucyBmb3IgdGhlc2UgcHJvYmxlbXMgY2Fu IGJlIGJ1aWx0IChlLmcuLCBzZWUKPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1ydGd3Zy11bG9vcC1kZWxheS8/aW5jbHVkZV90ZXh0PTEiPgpkcmFm dC1pZXRmLXJ0Z3dnLXVsb29wLWRlbGF5PC9hPikuPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5N YWpvciBJc3N1ZXM8L2I+OiBOb25lIGZvdW5kLjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+TWlu b3IgSXNzdWVzPC9iPjo8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRp cj0iTFRSIj48L3NwYW4+VGhlIGV4Y2VwdGlvbiB0byBnb29kIHJlYWRhYmlsaXR5IG9mIHRoZSBk cmFmdCByZWZlcnMgdG8gdGhlIHRlcm0g4oCcPGI+PGk+cHJveGltYXRlPC9pPjwvYj4gZmFpbHVy ZXMvSUdQIGV2ZW50c+KAnSB0aGF0IGFwcGVhcnMgNCB0aW1lcyBpbiB0aGUgZHJhZnQuIEVuZ2xp c2ggaXMgbm90IG15IG1vdGhlciB0b25ndWUsIGFuZCB0aGUKPGEgaHJlZj0iaHR0cHM6Ly93d3cu bWVycmlhbS13ZWJzdGVyLmNvbS90aGVzYXVydXMvcHJveGltYXRlIj5yZWZlcmVuY2U8L2E+IEni gJl2ZSBsb29rZWQgdXAgZGlkIG5vdCBoZWxwIG11Y2guIOKAnFRlbXBvcmFsbHkgY2xvc2XigJ0g KG9yIHNvbWV0aGluZyBhbG9uZyB0aGVzZSBsaW5lcykgbG9va3MgbGlrZSBhIHN1aXRhYmxlIGFs dGVybmF0aXZlLiAoRG9lcyB0aGlzIGNvbW1lbnQgcnVuIHN0cmljdGx5IGFnYWluc3QgdGhlIHJl Y29tbWVuZGF0aW9uIGZvcgogdGhlIFJURy1ESVIgcmV2aWV3ZXJzIOKAnHRvIGF2b2lkIHJhaXNp bmcgZXNvdGVyaWMgcXVlc3Rpb25zIG9mIEVuZ2xpc2ggdXNhZ2XigJ0/KTxvOnA+PC9vOnA+PC9w Pgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5TZWN0aW9uIDUgbWVu dGlvbnMgc3RhcnRpbmcgdGhlIFNQRl9USU1FUiAod2l0aCBvbmUgb2YgdGhlIDMgdmFsdWVzIGRl ZmluZWQgZm9yIGl0KSBhcyBwYXJ0IG9mIHRoZSByZXNwb25zZSB0byBzb21lIEZTTSBldmVudHMg aWYgaXQgd2FzIG5vdCBhbHJlYWR5IHJ1bm5pbmcgLSZuYnNwOyBidXQKPGI+PGk+aXQgZG9lcyBu b3Qgc3BlY2lmeSB3aGF0IGhhcHBlbnMgd2hlbiB0aGlzIHRpbWVyIGV4cGlyZXM8L2k+PC9iPi4g SSBhc3N1bWUgdGhhdCBpdHMgZXhwaXJhdGlvbiBsZWF2ZXMgdGhlIEZTTSBpbiBpdHMgY3VycmVu dCBzdGF0ZSBhbmQgcmVzdWx0cyBpbiBydW5uaW5nIHRoZSBTUEYgY29tcHV0YXRpb24g4oCTIGlm IHRoaXMgaXMgY29ycmVjdCwgaXQgd291bGQgYmUgbmljZSB0byBzYXkgdGhhdCBleHBsaWNpdGx5 LjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bh bj5TZWN0aW9uIDcgcmVjb21tZW5kcyB0aGF0LCZuYnNwOyBpbiBvcmRlciB0byBtaXRpZ2F0ZSBt aWNyby1sb29wIHByb2JsZW1zIHVzaW5nIHRoZSBwcm9wb3NlZCBhbGdvcml0aG0sIOKAnGFsbCBy b3V0ZXJzIGluIHRoZSBJR1AgZG9tYWluLCBvciBhdCBsZWFzdCBhbGwgdGhlIHJvdXRlcnMgaW4g dGhlIHNhbWUgYXJlYS9sZXZlbCwgaGF2ZSBleGFjdGx5IHRoZSBzYW1lIGNvbmZpZ3VyZWQmbmJz cDsKIHZhbHVlc+KAnSBvZiB0aGUgcmVsZXZhbnQgdGltZXJzIC4gSG93ZXZlciwgdGhlIGRyYWZ0 IGRvZXMgbm90IHNwZWNpZnkgd2hldGhlciB0aGVzZSB0aW1lcnMgc2hvdWxkIGJlIGNvbmZpZ3Vy ZWQganVzdCBhdCB0aGUgcHJvdG9jb2wgaW5zdGFuY2UgbGV2ZWwgb3IgYWxzbyBhdCB0aGUgbGV2 ZWwgb2YgZWFjaCBzcGVjaWZpYyBhcmVhL2xldmVsLiBGcm9tIG15IFBPViwgdGhlCjxiPjxpPmdy YW51bGFyaXR5IG9mIGNvbmZpZ3VyYXRpb248L2k+PC9iPiBzaG91bGQgYmUgZGVmaW5lZCBpbiB0 aGlzIGRyYWZ0IOKAkyBvbmUgd2F5IG9yIGFub3RoZXIuPG86cD48L286cD48L3A+CjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+NC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPlRoZSBsYXRlc3QgdmVyc2lvbnMgb2Yg dGhlIFlBTkcgZGF0YSBtb2RlbCBkcmFmdHMgZm9yIElTLUlTIGFuZCBPU1BGIGFscmVhZHkgZGVm aW5lIHRoZSB0aW1lcnMgaW50cm9kdWNlZCBpbiB0aGlzIGRyYWZ0LiBCdXQKPGI+PGk+dGhlcmUg YXJlIG5vIHJlZmVyZW5jZXMgdG8gdGhlc2UgZHJhZnRzIGluIHRoZSBkb2N1bWVudDwvaT48L2I+ LiBGcm9tIG15IFBPViBzdWNoIHJlZmVyZW5jZXMgKEluZm9ybWF0aW9uYWwgYW5kIHRoZXJlZm9y ZSBub24tYmxvY2tpbmcpIHdvdWxkIGJlIHVzZWZ1bCBmb3IgdGhlIHJlYWRlcnMsIGFuZCBJIHN1 Z2dlc3QgdG8gYWRkIHRoZW0uPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NS48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBkaXI9IkxUUiI+PC9zcGFuPkkgaGF2ZSBzb21lIGNvbmNlcm5zIHJlZ2FyZGluZyA8Yj4KPGk+ aW5jcmVtZW50YWwgaW50cm9kdWN0aW9uIGFuZCBhY3RpdmF0aW9uIG9mIHRoZSBwcm9wb3NlZCBh bGdvcml0aG08L2k+PC9iPi4gVGhlIG9wZXJhdG9yIHRoYXQgcnVucyBhIHdlbGwtdHVuZWQgbmV0 d29yayBtYXkgZXhwZXJpZW5jZSB0cmFuc2llbnQgcHJvYmxlbXMgd2hlbiBzb21lIG9mIGl0cyBy b3V0ZXJzIGFyZSBhbHJlYWR5IHVwZ3JhZGVkIGFuZCB1c2UgdGhlIHByb3Bvc2VkIGJhY2stb2Zm IGFsZ29yaXRobSB3aGlsZSBzb21lIG90aGVycwogc3RpbGwgY2Fubm90IGRvIHRoYXQuIFNvbWUg dGV4dCBleHBsYWluaW5nIHBvdGVudGlhbCBpc3N1ZXMgaW4gdGhpcyBzY2VuYXJpbyBhbmQsIGlm IHBvc3NpYmxlLCB0aGVpciBtaXRpZ2F0aW9uLCB3b3VsZCBiZSBtb3N0IGhlbHBmdWwuPG86cD48 L286cD48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Ni48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPlRoZSBl eHBsYW5hdG9yeSB0ZXh0IGluIHRoZSBkcmFmdCBzZWVtcyB0byBzdHJvbmdseSBzdWdnZXN0IHRo YXQmbmJzcDsKPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij5TUEZfSU5JVElBTF9ERUxBWSAmbHQ7PSBTUEZfU0hPUlRfREVMQVkgJmx0Oz0mbmJzcDsg U1BGX0xPTkdfREVMQVkKPC9zcGFuPjwvYj7igJMmbmJzcDsgYnV0IHRoaXMgaXMgbm90IGZvcm1h bGl6ZWQgYXMgYSByZXF1aXJlbWVudCBhbnl3aGVyZSBpbiB0aGUgdGV4dC4gRnJvbSBteSBQT1Yg c2F0aXNmeWluZyB0aGlzIHJlbGF0aW9uc2hpcCBzaG91bGQgYmUgUkVDT01NRU5ERUQgdG8gdGhl IG9wZXJhdG9ycy48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPk5JVFM8L2I+OjxvOnA+PC9vOnA+ PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsK PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5TZWN0aW9uIDMg bGlzdHMgMyBwb3NzaWJsZSB2YWx1ZXMgZm9yIHRoZSBTUEZfREVMQVkgdmFyaWFibGUgY2FsbGVk IElOSVRJQUxfU1BGX0RFTEFZLCBTSE9SVCBTUEZfREVMQVkgYW5kIExPTkdfU1BGX0RFTEFZLiBU aGVuLCBpbiB0aGUgbGFzdCBwYXJhLCBpdCByZWZlcnMgdG8KPGI+PGk+YSBwcmV2aW91c2x5IHVu ZGVmaW5lZCB2YWx1ZSwgSU5JVElBTF9XQUlUPC9pPjwvYj4uIFRoaXMgaXMgYW4gb2J2aW91cyB0 eXBvIGFuZCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCBJTklUSUFMX1NQRl9ERUxBWTxvOnA+PC9v OnA+PC9wPgo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsKPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj5PbmUgb2Yg dGhlIHBhcmFtZXRlcnMgb2YgdGhlIGFsZ29yaXRobSBpcyBjYWxsZWQKPGI+SE9MRF9ET1dOX0lO VEVSVkFMPC9iPiAoaW4gU2VjdGlvbiAzIGFuZCBTZWN0aW9uIDYpJm5ic3A7IHZzLiA8Yj5IT0xE RE9XTl9JTlRFUlZBTDwvYj4gaW4gU2VjdGlvbiA1LiBUaGlzIGFsc28gbG9va3MgbGlrZSBhbiBv YnZpb3VzIHR5cG8sIGFuZCB0aGUgc2FtZSBuYW1lIHNob3VsZCBiZSB1c2VkIGFjcm9zcyB0aGUg ZG9jdW1lbnQuPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgZGlzY3Vzc2VkIG15IGNvbmNl cm5zIGFib3V0IHRoZSBkcmFmdCB3aXRoIHRoZSBhdXRob3JzIHdobyBoYXZlIGJlZW4gbW9zdCBj b29wZXJhdGl2ZS4KPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYmVsaWV2 ZSB0aGF0IHdlIGhhdmUgcmVhY2hlZCBhbiBhZ3JlZW1lbnQgb24gYWNjZXB0YWJsZSByZXNvbHV0 aW9uIG9mIGFsbCBjb25jZXJucyBsaXN0ZWQgYWJvdmUuPG86cD48L286cD48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TYXNoYTxvOnA+PC9v OnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T2ZmaWNlOiAmIzQzOzk3Mi0zOTI2NjMwMjxvOnA+PC9vOnA+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5DZWxsOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm IzQzOzk3Mi01NDkyNjYzMDI8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RW1h aWw6Jm5ic3A7Jm5ic3A7IEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG86cD48L286 cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4K PGJyIGNsZWFyPSJib3RoIj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPgo8QlI+ClRoaXMgZS1tYWls IG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMg aW5mb3JtYXRpb24gd2hpY2ggaXMgPEJSPgpDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBw cm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyA8QlI+ CnRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25l IG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCA8QlI+CmFuZCBhbGwgY29waWVz IHRoZXJlb2YuPEJSPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+CjwvYm9keT4KPC9odG1sPgoK --_000_AM4PR03MB1713386BB8649B3813B8E24E9D100AM4PR03MB1713eurp_-- From nobody Thu Apr 27 06:57:37 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3DF129524; Thu, 27 Apr 2017 06:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVPFdLEtgmYY; Thu, 27 Apr 2017 06:57:27 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5440129522; Thu, 27 Apr 2017 06:57:26 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id w64so17618351wma.0; Thu, 27 Apr 2017 06:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4WEyti4LezhPxP1HgXBHycFB9GI0U0px3mtL9NCGhKc=; b=vBmflxt+IvNatBzB6hBt4ZsLZdAejr6q1d/mdSXDC8p9X59chDg+vKyC3lSZkw3bC5 doxMyXubFbBlhJ8qIr9MWJn1reEq+Y3+axXcA9d2rIaQrOGuNG8Ojlxohl7xa9YvdxwO x0X5xV8TflxuBmS20F2rRgnbprVsDQ/Z6YiBjsqHvxf6LFZTxGy9kjRGVzu0lbbhgo/z KuGPXL13yxTuR/FD0ygchh57H2/ES3LtfnpX88bkAnXPqM8A4fy8dyU5G0nicLojXUgk qJZee0OE+09DOUPqjsX+VSTRiOzo4vOiAfheDKW6ot37loIxfgYIW53/oF6RXyeRR1mh Ufdg== 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=4WEyti4LezhPxP1HgXBHycFB9GI0U0px3mtL9NCGhKc=; b=avkz2SBHpLVpe3Z6vZDq0uW+vePAb1Mlsv7MuQugKrmVZpZU/jRi/FVhfXEdosx39P hL4NLVVLh/8/8uUIt2e5SylzROEI0lOv8ii9GcO3Yv0LhgXKnf+4lVwxadme9O2XOIuV IHCpS9cjvHAyklyR1krUR4Rd+EWwA8R+0iYKVBQiUUTBx/2aK8n6geO/MwE5HlLvL6cf l5WHH77y/TnDu54d46D82PgJXjg0u9K5nvUbujsejAY/322Tr8l+NDo7/EhewHOcIFOm 1ep/T3FyEj3/5tJxwqIXvoRdbk7ngWt4k7sDnJFmLKFcYKCXgPqIwpJa4n2C7QDfebZ3 ipZw== X-Gm-Message-State: AN3rC/6u8hcKClZYh3RHQQ8dd+hG2mD75mLBY1GMEmrMRfhn98KjXmV6 jUuju6s0rJl2EyVP0v3FtG1NOBQTzZfC X-Received: by 10.28.182.69 with SMTP id g66mr2528280wmf.112.1493301445159; Thu, 27 Apr 2017 06:57:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.120 with HTTP; Thu, 27 Apr 2017 06:57:24 -0700 (PDT) In-Reply-To: <1493285941.3777460.957940184.292CDF8E@webmail.messagingengine.com> References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> <1493285941.3777460.957940184.292CDF8E@webmail.messagingengine.com> From: Alia Atlas Date: Thu, 27 Apr 2017 09:57:24 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Alexey Melnikov Cc: "iesg@ietf.org" , "rtgwg-chairs@ietf.org" , draft-ietf-rtgwg-yang-key-chain@ietf.org, "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=001a114b108c2e74cf054e26567f Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:57:30 -0000 --001a114b108c2e74cf054e26567f Content-Type: text/plain; charset=UTF-8 Hi Alexey, On Thu, Apr 27, 2017 at 5:39 AM, Alexey Melnikov wrote: > Hi Alia, > > On Thu, Apr 27, 2017, at 05:02 AM, Alia Atlas wrote: > > I am just catching up on this conversation. > > First, the YANG model is primarily for information in motion - either for > configuration to the device > or to read from the device. It is much less likely to represent the data > structure and storage in the device. > I believe that this draft's context is strictly for information in motion. > > This YANG model, as with all, is intended for transport over NetConf or > RestConf, which are confidential > transports. Thus, any keys sent in the YANG model are already protected > in flight. > > However, to allow for the limited cases (as I understand it) where that > isn't viewed as sufficient protection, > the key might be sent encrypted (via KEK) so it is encrypted before being > handed to the model, the configuration > action would be with the encrypted key, and then the device would have to > know how to decrypt it, which is all > out-of-band behavior as far as the YANG model and associated protocols go. > > I wish the document said that. > > > The gotcha - and why, as I understand it, that encrypted keys are even > mentioned is that it alters the data type > used for transmitting the key as in the snippet below. Normally the > keystring would be a string, but if encrypted, > it is a hex-string - so arbitrary bytes. > > As a side note, the document is confusing, because it doesn't explain when > and why hexstring version is to be used. > It also has some text suggesting that hexstring might be used to provide > more entropy, which doesn't necessarily mean that the keystring contains > encrypted key. > Right - those are other reasons that someone might use a hex-string for the key. > > "+--rw key-string > > | +--rw (key-string-style)? > | +--:(keystring) > | | +--rw keystring? string > | +--:(hexadecimal) {hex-key-string}? > | +--rw hexadecimal-string? yang:hex-string > " > > This draft isn't trying to describe how or whether to use KEK. It's just > making sure the YANG model is sufficient > general to transmit the key if it is previously encrypted. > > > This helps. The change in -21 to remove aes-key-wrap means that now it is > not possible to tell whether the keystring is the passphrase/key itself or > whether it contains encrypted key. > More - it doesn't tell the sender of the YANG model for providing current state to encrypt the keys or the receiver that they are encrypted. I do think it is worth working through the issues so that the aes-key-wrap goes back in the document - but I need to talk to the authors and the WG. This part of the draft is more aspirational which is why I think it is being negotiable. Regards, Alia > Does that make sense and help clarify? > > Regards, > Alia > > > On Wed, Apr 26, 2017 at 11:00 PM, Adam Roach wrote: > > On 4/26/17 9:34 PM, Kathleen Moriarty wrote: > > The final paragraph, I believe is referring to how the key is stored - > either a KEK is used and it's encrypted or it's not and it's advising > obfuscation at a minimum. > > > That's how I read it too: it's talking about how the key is stored. If > it's encrypted with a real crypto operation, it's going to have a KEK > (which isn't necessarily the same KEK as is used to decrypt the information > received from a remote node, right?); and, if it's obfuscated, it doesn't > even necessarily have a key at all, just some kind of reversible > transformation. > > Let's focus on the "obfuscation" case, because I think it's easier to > reason about (and less likely to get conflated with other operations), and > then we can extend that reasoning to the crypto case if we come to > agreement. I'm making certain assumptions here which you may have a > different read on (and, as before, this is your area, so I'd take your > assumptions over my own) -- please correct me where I'm overstating or > misstating things. > > In the obfuscation case -- and barring any advanced anti-debugger and > anti-ICE defenses -- reverse-engineering the obfuscation technique would be > a fairly straightforward exercise. So I think we can safely assume that any > such obfuscation performed by popular routers will be reversible by your > average black-hat hacker. > > That seems to negate most of the benefit obtained by obfuscation. > > At the same time, an administrator observing that the stored value is not > the same as the actual key may make the erroneous assumption that the > on-disk value itself is not particularly high value, and may take steps > that make it more likely to fall into the hands of an attacker than if the > administrator saw the literal key present in the configuration. > > That seems to make the obfuscation potentially harmful. > > Little benefit with possible harm would, to me, indicate that obfuscation > should not be employed. > > > > Does that help? I'll defer to the authors and AD and get back to the > part of the thread where I'm hoping we can add the KEK back into the > draft. > > > I hope so too. As a process point: removing this from the document seems > like a material change. If this went through WGLC and IETF LC with the KEK > as part of the data model, I would think its removal would require WG > buy-in, and running through IETF LC again. > > /a > > > --001a114b108c2e74cf054e26567f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alexey,

On Thu, Apr 27, 2017 at 5:39 AM, Alexey Melnikov <aamel= nikov@fastmail.fm> wrote:
<= u>
Hi Alia,

On Thu, Apr 27, 2017, at 05:02 AM, Alia Atlas wrote:
I am just catching up on th= is conversation.

First, the YANG model is primarily for information in motion - either = for configuration to the device
or to read from the device. =C2=A0 It is much less likely to represent= the data structure and storage in the device.
I believe that this draft's context is strictly for information in= motion.

This YANG model, as with all, is intended for transport over NetConf o= r RestConf, which are confidential
transports.=C2=A0 Thus, any keys sent in the YANG model are already pr= otected in flight.

However, to allow for the limited cases (as I understand it) where tha= t isn't viewed as sufficient protection,
the key might be sent encrypted (via KEK) so it is encrypted before be= ing handed to the model, the configuration
action would be with the encrypted key, and then the device would have= to know how to decrypt it, which is all
out-of-band behavior as far as the YANG model and associated protocols= go.
I wish the document said that.


The gotcha - and why, as I understand it, that encrypted keys are even= mentioned is that it alters the data type
used for transmitting the key as in the snippet below.=C2=A0 Normally = the keystring would be a string, but if encrypted,
it is a hex-string - so arbitrary bytes.
As a side note, the document is confusing, because= it doesn't explain when and why hexstring version is to be used.
It also has some text suggesting that hexstring might be used to provi= de more entropy, which doesn't necessarily mean that the keystring cont= ains encrypted key.

=C2=A0Right= - those are other reasons that someone might use a hex-string for the key.= =C2=A0

"+--rw key-string

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0+--rw (key-string-st= yle)?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--:(keystri= ng)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0+--r= w keystring? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--:(hexadec= imal) {hex-key-string}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0+--rw hexadecimal-string? =C2=A0 yang:hex-string
"

This draft isn't trying to describe how or whether to use KEK.=C2= =A0 It's just making sure the YANG model is sufficient
general to transmit the key if it is previously encrypted.

This helps. The change in -21 to remove=C2=A0aes-key-wrap means= that now it is not possible to tell whether the keystring is the passphras= e/key itself or whether it contains encrypted key.
=

More - it doesn't tell the sender of the YANG model= for providing current state to encrypt the keys or the receiver that they = are encrypted.

I do think it is worth working thro= ugh the issues so that the aes-key-wrap goes back in the document - but I n= eed to talk to the authors and the WG.=C2=A0 This part of the draft is more= aspirational which is why I think it is being negotiable.

=C2=A0Regards,
Alia
=
Does that make sense and he= lp clarify?

Regards,
Alia


On Wed, Apr 26, 2017 at 11:00 PM, Adam Roach &l= t;adam@nostrum.com> wrote:
On 4/26/17 9:34 PM, Kathle= en Moriarty wrote:
The final paragraph, I believe = is referring to how the key is stored -
either=C2=A0 a KEK is used and = it's encrypted or it's not and it's advising
obfuscation at= a minimum.

That's how I read = it too: it's talking about how the key is stored. If it's encrypted= with a real crypto operation, it's going to have a KEK (which isn'= t necessarily the same KEK as is used to decrypt the information received f= rom a remote node, right?); and, if it's obfuscated, it doesn't eve= n necessarily have a key at all, just some kind of reversible transformatio= n.

Let's focus on the "obfuscation" case, because I think = it's easier to reason about (and less likely to get conflated with othe= r operations), and then we can extend that reasoning to the crypto case if = we come to agreement. I'm making certain assumptions here which you may= have a different read on (and, as before, this is your area, so I'd ta= ke your assumptions over my own) -- please correct me where I'm oversta= ting or misstating things.

In the obfuscation case -- and barring any advanced anti-debugger and= anti-ICE defenses -- reverse-engineering the obfuscation technique would b= e a fairly straightforward exercise. So I think we can safely assume that a= ny such obfuscation performed by popular routers will be reversible by your= average black-hat hacker.

That seems to negate most of the benefit obtained by obfuscation.
=

At the same time, an administrator observing that the stored value is= not the same as the actual key may make the erroneous assumption that the = on-disk value itself is not particularly high value, and may take steps tha= t make it more likely to fall into the hands of an attacker than if the adm= inistrator saw the literal key present in the configuration.

That seems to make the obfuscation potentially harmful.

Little benefit with possible harm would, to me, indicate that obfusca= tion should not be employed.



Does that help?=C2=A0 I'll = defer to the authors and AD and get back to the
part of the thread wher= e I'm hoping we can add the KEK back into the
draft.

I hope so too. As a process point: removing this= from the document seems like a material change. If this went through WGLC = and IETF LC with the KEK as part of the data model, I would think its remov= al would require WG buy-in, and running through IETF LC again.
=
/a


--001a114b108c2e74cf054e26567f-- From nobody Thu Apr 27 07:01:13 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F7B1294F0; Thu, 27 Apr 2017 07:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjT3VAXzOP6y; Thu, 27 Apr 2017 07:01:01 -0700 (PDT) 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 ED9B3127775; Thu, 27 Apr 2017 07:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15478; q=dns/txt; s=iport; t=1493301661; x=1494511261; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DAhRySDocCxBMXacKaTAowu8KT9a8NJJXrwInYGhLbI=; b=fLk+I4zG5SSLiMOn4dSYjauM0MHFzcwPziNWzNxgkb0gJEaciJH+vfsj 1FvtCUTvefvxGohczpzkZONL4geweIMMhuXtFvMn3O9eARF7CNfvoSXHx XFcdZofxdBu/rxaRXQHj1/4hpZ+Z3p+EoFyUbq1p06zYy8zSXwRVvxyDm k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQAk+QFZ/4kNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1WBbQeDYYoYkUqIIo1Kgg+GJAIag38/GAECAQEBAQEBAWsohRY?= =?us-ascii?q?BBSMRRRACAQgYAgImAgICHxEVEAIEAQ0FG4lqAxWsZIImhzANg18BAQEBAQEBA?= =?us-ascii?q?wEBAQEBAQEBIIELhyeCD4ELglOBVCQUgwaCXwEEnRU7AY4/hEyCAokchkCIdII?= =?us-ascii?q?liQ0BHziBCm8VhTUcGYFKdQGGUA4XgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,384,1488844800"; d="scan'208";a="236571946" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2017 14:00:59 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3RE0xe1025851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Apr 2017 14:00:59 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Apr 2017 10:00:58 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 27 Apr 2017 10:00:58 -0400 From: "Acee Lindem (acee)" To: Kathleen Moriarty , Adam Roach CC: The IESG , Jeff Tantsura , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Index: AQHSvv7NaK6mr1jQpUuQYLHDV2KBn6HZP2EA Date: Thu, 27 Apr 2017 14:00:58 +0000 Message-ID: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <1F7194B73237F84FADDBC3E876E36856@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:01:03 -0000 S2F0aGxlZW4sIEFkYW0sIEJyaWFuLA0KDQpPbiA0LzI2LzE3LCAxMDozNCBQTSwgIkthdGhsZWVu IE1vcmlhcnR5Ig0KPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0K PkhpIEFkYW0sDQo+DQo+DQo+DQo+T24gV2VkLCBBcHIgMjYsIDIwMTcgYXQgNDo1MiBQTSwgQWRh bSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT4gd3JvdGU6DQo+PiBTb3JyeSBmb3IgdG9wLXBvc3Rp bmcsIGJ1dCBJIHdhbnQgdG8gc2VlIGlmIHdlIGNhbiB1bnRhbmdsZSBzb21ldGhpbmcuDQo+Pg0K Pj4gSSdtIGdsYWQgdGhpcyBpcyBnZXR0aW5nIGNsZWFyZXIgZm9yIHlvdSwgYnV0IGl0J3MganVz dCBnZXR0aW5nIG1vcmUNCj4+IGNvbmZ1c2luZyBmb3IgbWUuIEluIHRoZSAtMjAgdmVyc2lvbiBv ZiB0aGUgZG9jdW1lbnQsIHRoZXJlIHdhcyB0ZXh0DQo+PmFib3V0DQo+PiB1c2luZyBhIEtFSyBm b3IgZGF0YSBpbiBtb3Rpb24gKHNlY3Rpb24gNSBwYXJhZ3JhcGggMyksIGFuZCBhIHNlcGFyYXRl DQo+PiBtZW50aW9uIG9mIHVzaW5nIGEgS0VLIGZvciBkYXRhIGF0IHJlc3QgKHNlY3Rpb24gNSwg ZmluYWwNCj4+cGFyYWdyYXBoKVsxXS4gRm9yDQo+PiBjbGFyaXR5OiBmb3IgdGhlIHJlbWFpbmRl ciBvZiB0aGlzIHRocmVhZCwgSSB3aWxsIHJlZmVyIHRvIHRoZXNlIGFzDQo+PiBLRUstbW90aW9u IGFuZCBLRUstcmVzdCByZXNwZWN0aXZlbHkuDQo+Pg0KPg0KPlRoZSBkcmFmdCBpcyBhYm91dCBz dG9yZWQga2V5IGNoYWluIGluIGEgWUFORyBtb2R1bGUgYWNjZXNzZWQgKGtleQ0KPmRpc3RyaWJ1 dGlvbikgZm9yIGRpZmZlcmVudCBwdXJwb3Nlcy4gIFVzaW5nIGEgS0VLIGlzIGp1c3QgYSB3YXkg dG8NCj5wcm90ZWN0IHRoZSBrZXkgdGhhdCBpcyBzdG9yZWQuICBORVRDT05GICh3aXRoIFNTSCkg b3IgUkVTVENPTkYgKHdpdGgNCj5UTFMpIGFyZSByZXF1aXJlZCBmb3Igc2VjdXJlIGFjY2VzcyB0 byB0aGUga2V5cyAgb3IgaWYgYSBLRUsgaXMgdXNlZCwNCj50aGUgcHJvdGVjdGVkIGtleXMuICBJ bi1tb3Rpb24gKGlmIEkgdW5kZXJzdGFuZCB5b3UgY29ycmVjdGx5KSBpcyBqdXN0DQo+dGhlIHRy YW5zcG9ydCBvZiB0aGlzIGRhdGEgbW9kZWwgZWxlbWVudCBmb3IgdXNlLg0KPg0KPkFzIHN0YXRl ZCBpbiB0aGUgaW50cm9kdWN0aW9uLCB0aGUga2V5IG1pZ2h0IG5vdCBiZSB1c2VkIGRpcmVjdGx5 IGFuZA0KPnRoZXJlJ3Mgbm8gbWVudGlvbiBvZiB1c2luZyB0aGlzIGtleSB0byBwcm90ZWN0IGRh dGEgdGhhdCBpcyBzdG9yZWQNCj53aXRoIHRoZSBrZXk6DQo+DQo+ICAgSW4gc29tZSBhcHBsaWNh dGlvbnMsIHRoZSBwcm90b2NvbHMgZG8gbm90IHVzZSB0aGUga2V5IGNoYWluIGVsZW1lbnQNCj4g ICBrZXkgZGlyZWN0bHksIGJ1dCByYXRoZXIgYSBrZXkgZGVyaXZhdGlvbiBmdW5jdGlvbiBpcyB1 c2VkIHRvIGRlcml2ZQ0KPiAgIGEgc2hvcnQtbGl2ZWQga2V5IGZyb20gdGhlIGtleSBjaGFpbiBl bGVtZW50IGtleSAoZS5nLiwgdGhlIE1hc3Rlcg0KPiAgIEtleXMgdXNlZCBpbiBbVENQLUFPXSku DQo+DQo+SWYgYSBLRUsgaXMgdXNlZCwgdGhpcyBpcyB0YWxraW5nIGFib3V0IHRoZSBwcm90ZWN0 ZWQga2V5Lg0KPg0KPldoYXQgSSBhbSB0cnlpbmcgdG8gaGVscCBBY2VlIHdpdGggaXMgb24gdGhl IGZvbGxvd2luZyBmcm9tIC0yMCBzbyBoZQ0KPmhhcyBzb21lIGltcGxlbWVudGF0aW9uIGd1aWRh bmNlIGFyb3VuZCB1c2luZyBhIEtFSzoNCj4NCj4gICBUaGUgQUVTIGtleS1lbmNyeXB0aW9uIGtl eSAoS0VLKSBpcw0KPiAgIG5vdCBpbmNsdWRlZCBpbiB0aGUgWUFORyBtb2RlbCBhbmQgbXVzdCBi ZSBzZXQgb3IgZGVyaXZlZCBpbmRlcGVuZGVudA0KPiAgIG9mIGtleS1jaGFpbiBjb25maWd1cmF0 aW9uLg0KDQpJIGRvbuKAmXQgc2VlIHdoYXQgaXMgdW5jbGVhciBhYm91dCB0aGUgYWJvdmUuIE90 aGVyIHRoYW4gYW4gaW5kaWNhdGlvbiB0aGF0DQp0aGUgS0VLIGlzIGluIHVzZSBmb3IgYSBwYXJ0 aWN1bGFyIGtleS1jaGFpbiwgdGhlIFlBTkcgbW9kZWwgaXMgY29tcGxldGVseQ0KaW5kZXBlbmRl bnQgb2YgS0VLLiBJZiBhIHRyZWF0aXNlIG9uIGhvdyB0byBkZXBsb3kgS0VLIGlzIHJlcXVpcmVk LCBpdA0Kc2hvdWxkIGJlIGluIGEgc2VwYXJhdGUgZG9jdW1lbnQgd29ya2VkIG9uIGluIHRoZSBT ZWN1cml0eSBBcmVhIGFuZCBJDQpzaG91bGRu4oCZdCBiZSBzdWJqZWN0IHRvIGNhcHJpY2lvdXMg RElTQ1VTU2VzLiBJIHdpbGwgYWRkIHRoZSBzdGF0ZW1lbnQsDQrigJxUaGUgcHJvY2VkdXJlcyBh bmQgZGV0YWlscyBvZiBBU0UgS2V5LVdyYXAgZGVwbG95bWVudCBhcmUgYmV5b25kIHRoZQ0Kc2Nv cGUgb2YgdGhpcyBkb2N1bWVudC7igJ0NCg0KPg0KPlRoZSBmaW5hbCBwYXJhZ3JhcGgsIEkgYmVs aWV2ZSBpcyByZWZlcnJpbmcgdG8gaG93IHRoZSBrZXkgaXMgc3RvcmVkIC0NCj5laXRoZXIgIGEg S0VLIGlzIHVzZWQgYW5kIGl0J3MgZW5jcnlwdGVkIG9yIGl0J3Mgbm90IGFuZCBpdCdzIGFkdmlz aW5nDQo+b2JmdXNjYXRpb24gYXQgYSBtaW5pbXVtLg0KDQpXaGlsZSB5b3UgbWlnaHQgdXNlIEtF SyAoUkZDIDU2NDkpIHRvIGVuY3J5cHQga2V5cyBpbiBtZW1vcnksIHRoaXMgaXMgYQ0KbW9yZSBn ZW5lcmFsIHN0YXRlbWVudCB3aXRoIHJlc3BlY3QgdG8ga2V5cyBub3QgYmVpbmcgc3RvcmVkIGlu IHBsYWluDQp0ZXh0LiBJdCB3YXMgcmVxdWVzdGVkIGR1cmluZyBvbmUgb2YgdGhlIHJldmlld3Mu IEhvd2V2ZXIsIEkgYW0gaGFwcHkgdG8NCnJlbW92ZSBpdCBpZiBpdCBpcyBwcm9ibGVtYXRpYy4N Cg0KVGhhbmtzLA0KQWNlZSANCj4NCj5Eb2VzIHRoYXQgaGVscD8gIEknbGwgZGVmZXIgdG8gdGhl IGF1dGhvcnMgYW5kIEFEIGFuZCBnZXQgYmFjayB0byB0aGUNCj5wYXJ0IG9mIHRoZSB0aHJlYWQg d2hlcmUgSSdtIGhvcGluZyB3ZSBjYW4gYWRkIHRoZSBLRUsgYmFjayBpbnRvIHRoZQ0KPmRyYWZ0 Lg0KPg0KPlJlZ2FyZHMsDQo+S2F0aGxlZW4NCj4NCj4+IEZvciBhZGRpdGlvbmFsIGNsYXJpdHks IHRoZSBleGNoYW5nZSB3aXRoIEFjZWUgSSBjaXRlIGJlbG93IHByZWRhdGVzIHRoZQ0KPj4gcmVs ZWFzZSBvZiB0aGUgLTIxIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50LCBzbyBpdCBjYW4gb25seSBi ZSBpbg0KPj5yZWZlcmVuY2UNCj4+IHRvIHRoZSAtMjAgdmVyc2lvbi4NCj4+DQo+PiBXaGlsZSBJ IHNlZSB0aGF0IHRoZXJlIGFyZSBwcm9iYWJseSBzb21lIG9wZXJhdGlvbmFsIGlzc3VlcyB0aGF0 IG5lZWQNCj4+dG8gYmUNCj4+IHJlc29sdmVkIHJlZ2FyZGluZyBLRUstbW90aW9uLCBJIHdvdWxk IGxpa2UgdG8gdHJlYXQgdGhlbSBzZXBhcmF0ZWx5DQo+PmZyb20gbXkNCj4+IGNvbmNlcm5zIHdp dGggS0VLLXJlc3QuDQo+Pg0KPj4gTXkgY29uY2VybiBoZXJlIGlzIGV4Y2x1c2l2ZWx5IHdpdGgg cmVnYXJkcyB0byBLRUstcmVzdCwgd2hpY2ggc2VlbXMgdG8NCj4+YmUNCj4+IHN1ZmZlcmluZyBz b21lIGRlZ3JlZSBvZiBjb25mbGF0aW9uIHdpdGggS0VLLW1vdGlvbiwgYW5kIHdoaWNoIHdpbGwg aGF2ZQ0KPj4gZGlzdGluY3RseSBkaWZmZXJlbnQgY29uc2lkZXJhdGlvbnMgcmVnYXJkaW5nIHdo ZXRoZXIgYW5kIGhvdyBpdCBjYW4gYmUNCj4+IGNvbXByb21pc2VkLg0KPj4NCj4+IEkgaGF2ZSBt b3JlIHRvIHNheSBvbiB0aGlzLCBidXQgd291bGQgbGlrZSB0byBwYXVzZSBhbmQgbWFrZSBzdXJl IHdlJ3JlDQo+PmluDQo+PiBjb25jb3JkYW5jZSB0aGF0IHRoZXJlIGFyZSB0d28gdW5yZWxhdGVk IEtFS3MgaW4gcGxheSBoZXJlLg0KPj4NCj4+IC9hDQo+Pg0KPj4gX19fXw0KPj4gWzFdIEkgY2l0 ZSBhcyBldmlkZW5jZSB0aGF0IHRoZXNlIGFyZSB0d28gZGlmZmVyZW50IEtFS3MgdW5kZXINCj4+ ZGlzY3Vzc2lvbg0KPj4gdGhlIGZvbGxvd2luZyB0d28gcG9pbnRzOiAoYSkgdGhlIHRoaXJkIHBh cmFncmFwaCB0YWxrcyBhYm91dCBLRUtzIGluDQo+PnRlcm1zDQo+PiBvZiBSRkMgNTY0OSwgd2hp Y2ggcmVxdWlyZXMgQUVTOyB3aGlsZSB0aGUgZmluYWwgcGFyYWdyYXBoIHRhbGtzIGFib3V0DQo+ PiBlbmNyeXB0aW9uICJvciBvYmZ1c2NhdGlvbiwiIHdoaWNoIGNsZWFybHkgY2FuJ3QgYmUgUkZD IDU2NDk7IGFuZCAoYikNCj4+aW4gdGhlDQo+PiAtMjEgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQs IGFsbCBtZW50aW9uIG9mIFJGQyA1NjQ5IGhhcyBiZWVuIHN0cmlja2VuLA0KPj4gd2hpbGUgdGhl IGZpbmFsIHBhcmFncmFwaCBvZiBzZWN0aW9uIDUgcmVtYWlucy4NCj4+DQo+Pg0KPj4NCj4+IE9u IDQvMjYvMTcgMzozMCBQTSwgS2F0aGxlZW4gTW9yaWFydHkgd3JvdGU6DQo+Pj4NCj4+PiBIaSBB ZGFtLA0KPj4+DQo+Pj4gSSB0aGluayBJIHNlZSB3aGVyZSB3ZSBhcmUgY29taW5nIHRvIGRpZmZl cmVudCBjb25jbHVzaW9ucy4uLi4NCj4+Pg0KPj4+IE9uIFdlZCwgQXByIDI2LCAyMDE3IGF0IDQ6 MTggUE0sIEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+IHdyb3RlOg0KPj4+Pg0KPj4+PiBP biA0LzI2LzE3IDI6MzYgUE0sIEthdGhsZWVuIE1vcmlhcnR5IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+ IE9uIFdlZCwgQXByIDI2LCAyMDE3IGF0IDI6NDIgUE0sIEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1 bS5jb20+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4gT24gNC8yNi8xNyAxMTozNCBBTSwgS2F0aGxl ZW4gTW9yaWFydHkgd3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFNpbmNlIHRoZSBmb2xsb3dpbmcg dGV4dCBpbnQgaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcw0KPj4+Pj4+PmEN Cj4+Pj4+Pj4gcmVjb21tZW5kYXRpb24sIElNTyBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZHJvcCAi b3Igb3RoZXJ3aXNlDQo+Pj4+Pj4+IG9iZnVzY2F0ZWQiDQo+Pj4+Pj4+IGZyb20gdGhlIHNlbnRl bmNlIGFzIGVuY3J5cHRpbmcgdGhlIGtleXMgcmVhbGx5IHNob3VsZCBiZSB0aGUNCj4+Pj4+Pj4g cmVjb21tZW5kYXRpb24uICBDYW4gd2UgbWFrZSB0aGlzIHVwZGF0ZT8NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gICAgICAgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCBrZXlzIGJlIGVuY3J5cHRlZCBvciBvdGhl cndpc2UNCj4+Pj4+Pj5vYmZ1c2NhdGVkDQo+Pj4+Pj4+IHdoZW4NCj4+Pj4+Pj4gICAgICAgc3Rv cmVkIGludGVybmFsbHkgb24gYSBuZXR3b3JrIGRldmljZSBzdXBwb3J0aW5nIHRoaXMNCj4+Pj4+ Pj4gc3BlY2lmaWNhdGlvbi4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSWYgb2JmdXNjYXRpb24gaXMgd2hh dCBoYXBwZW5zIG1vcmUgb2Z0ZW4gaW4gcHJhY3RpY2UsIG1heWJlDQo+Pj4+Pj4+bWVudGlvbg0K Pj4+Pj4+PiB0aGlzDQo+Pj4+Pj4+IGFzIGEgZmFsbGJhY2sgZnJvbSB0aGUgcmVjb21tZW5kYXRp b24sIGJ1dCBub3QgbWFrZSB0aGVtIHNvdW5kDQo+Pj4+Pj4+IGVxdWl2YWxlbnQ/DQo+Pj4+Pj4N Cj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gVG8gYmUgY2xlYXIgLS0gdGhlIGN1cnJlbnQgZ3VpZGFu Y2UgZnJvbSB0aGUgc2VjdXJpdHkgYXJlYSBpcyB0bw0KPj4+Pj4+IHBlcmZvcm0NCj4+Pj4+PiB0 aGlzIGtpbmQgb2YgZW5jcnlwdGlvbiwgd2hlcmUgeW91IGhhdmUgZW5jcnlwdGVkIG1hdGVyaWFs IGxpdmluZw0KPj4+Pj4+IHNpZGUtYnktc2lkZSB3aXRoIHRoZSBrZXkgbmVjZXNzYXJ5IHRvIGRl Y3J5cHQgaXQ/DQo+Pj4+Pg0KPj4+Pj4gV2UgYXJlIHRhbGtpbmcgYWJvdXQgdXNpbmcgYSBrZXkg ZW5jcnlwdGluZyBrZXkgKEtFSykgYW5kIHN0b3JpbmcNCj4+Pj4+IHRoYXQsIG5vdCBzdG9yaW5n IHRoZSByYXcga2V5IG5leHQgdG8gdGhlIGVuY3J5cHRlZCBkYXRhIGFzIGZhciBhcyBJDQo+Pj4+ PiBjYW4gdGVsbC4NCj4+Pj4NCj4+Pj4NCj4+Pj4gUmlnaHQuDQo+Pj4+DQo+Pj4+PiBBZGRpdGlv bmFsbHksIEkgaGF2ZW4ndCBzZWVuIGEgZGlzY3Vzc2lvbiBvbiB0aGUgaGFyZHdhcmUNCj4+Pj4+ IHRoaXMgaXMgZXhwZWN0ZWQgdG8gcnVuIG9uLg0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGF0IG1pZ2h0 IGJlIGFwcHJvcHJpYXRlIG1hdHRlciBmb3IgdGhlIGRyYWZ0LCBpZiBpdCBpcyBnb2luZyB0byBt YWtlDQo+Pj4+IHRoaXMNCj4+Pj4gcmVjb21tZW5kYXRpb24uDQo+Pj4+DQo+Pj4+PiBTb21lIGlt cGxlbWVudGF0aW9ucyBvZiBLRUsgc29sdXRpb25zIHVzZSBkZWRpY2F0ZWQgaGFyZHdhcmUgZm9y IHRoZQ0KPj4+Pj4gS0VLIGFuZCByZXF1aXJlIGF1dGhlbnRpY2F0aW9uIGZvciBhY2Nlc3MgdG8g dGhlIGtleSwgaGVuY2UNCj4+Pj4+cHJldmVudGluZw0KPj4+Pj4gZ2VuZXJpYyBhY2Nlc3MgYW5k IHNpZGUtYnktc2lkZSBzdG9yYWdlIG9mIHRoZSBLRUsncyBwcm90ZWN0ZWQga2V5LA0KPj4+Pj4g YW5kIGVuY3J5cHRlZCBkYXRhLiAgSSdkIHJhdGhlciBzZWUgYSBLRUsgdXNlZCB0aGFuIGp1c3Qg YSBrZXkgc3RvcmVkDQo+Pj4+PiBpbiBhbnkgY2FzZS4gIEFyZSB5b3UgYXJndWluZyBmb3Igbm90 IHVzaW5nIGFueSBlbmNyeXB0aW9uIGF0IGFsbD8NCj4+Pj4NCj4+Pj4NCj4+Pj4gSSdsbCBkZWZl ciB0byB5b3UsIG9mIGNvdXJzZSwgc2luY2UgeW91IGhhdmUgcHJlc3VtYWJseSBnaXZlbiB0aGUN Cj4+Pj50b3BpYw0KPj4+PiBtb3JlDQo+Pj4+IHRob3VnaHQgdGhhbiBJIGhhdmUsIGJ1dDogeWVz Lg0KPj4+Pg0KPj4+PiBBYnNlbnQgc29tZXRoaW5nIGxpa2UgYW4gSFNNIG9yIGZvcmNpbmcgaHVt YW4gaW50ZXJ2ZW50aW9uIHdoZW5ldmVyIGENCj4+Pj4gcHJvY2VzcyBzdGFydHMgKG9yIHJlc3Rh cnRzKSwgaXQgc2VlbXMgdGhhdCB0aGUgc2NoZW1lIGRlc2NyaWJlZCBpbg0KPj4+PiBzZWN0aW9u DQo+Pj4+IDUgZG9lc24ndCBhY3R1YWxseSBkZXRlciBhIGNvbXBldGVudCBhdHRhY2tlciBmcm9t IG9idGFpbmluZyB0aGUNCj4+Pj5rZXlzLiBNeQ0KPj4+PiBpbXByZXNzaW9uIGlzIHRoYXQgc3Rv cmluZyBpbmZvcm1hdGlvbiBpbiBhbiBlbmNyeXB0ZWQgZm9ybSB0aGF0IGNhbg0KPj4+PmJlDQo+ Pj4+IHRyaXZpYWxseSBkZWNyeXB0ZWQgYnkgYW4gYXR0YWNrZXIgcHJvdmlkZXMgYSBmYWxzZSBz ZW5zZSBvZiBzZWN1cml0eQ0KPj4+PnRvDQo+Pj4+IGVxdWlwbWVudCBvcGVyYXRvcnMuDQo+Pj4+ DQo+Pj4+IElmIHRoZSBzY2hlbWUgaW4gc2VjdGlvbiA1ICpkb2VzKiByZXF1aXJlIHRoZSBraW5k IG9mIHByZXJlcXVpc2l0ZXMNCj4+Pj55b3UNCj4+Pj4gcG9zaXQsIHN1Y2ggYXMgZGVkaWNhdGVk IHNlY3VyaXR5IGhhcmR3YXJlLCBpdCBzZWVtcyB0aGF0IHN1Y2gNCj4+Pj4gcHJlcmVxdWlzaXRl cw0KPj4+PiBzaG91bGQgYmUgbWVudGlvbmVkIGFsb25nc2lkZSB0aGUgcmVjb21tZW5kYXRpb24u DQo+Pj4+DQo+Pj4+PiBGb3IgWUFORyBtb2R1bGVzLCBjb3VsZG4ndCB0aGUgYXBwbGljYXRpb24g dmlhIE5FVENPTkYvUkVTVENPTkYNCj4+Pj4+IGFjY2Vzc2luZyB0aGUgbW9kdWxlIHByb3ZpZGUg dGhlIGNyZWRlbnRpYWxzIHRvIGFjY2VzcyB0aGUga2V5DQo+Pj4+PiBwcm90ZWN0ZWQgYnkgdGhl IEtFSz8NCj4+Pj4NCj4+Pj4NCj4+Pj4gVGhhdCBzb2x2ZXMgdGhlIGlzc3VlcyB3aXRoIHByb3Zp c2lvbmluZywgYnV0IGRvZXNuJ3Qgc2VlbSB0byBoZWxwIHRoZQ0KPj4+PiBwcm9jZXNzZXMgYWN0 dWFsbHkgaW52b2x2ZWQgaW4gcm91dGluZy4NCj4+Pj4NCj4+Pj4+IFNvbWUgaW1wbGVtZW50YXRp b25zIGNvdWxkIHN0b3JlIHRoZSBLRUsgaW4NCj4+Pj4+IGRlZGljYXRlZCBoYXJkd2FyZSBhcyB3 ZWxsLiBJbiB0aGlzIHdheSwgc3RvcmluZyB0aGUgS0VLIGFuZCBkYXRhDQo+Pj4+PiB0b2dldGhl ciBpcyBub3QgdGhlIHNhbWUgYXMgc3RvcmluZyBhIGtleSByaWdodCBuZXh0IHRvIHRoZSBkYXRh IGl0DQo+Pj4+PmlzDQo+Pj4+PiBwcm90ZWN0aW5nLg0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGlzIG1h a2VzIHBlcmZlY3Qgc2Vuc2U7IGFuZCBpdCBzaG91bGQgcHJvYmFibHkgYmUgaW4gdGhlIGRvY3Vt ZW50Lg0KPj4+Pg0KPj4+Pj4gVXNlIG9mIGEgS0VLIGlzIGJldHRlciB0aGVuIG5vdCBlbmNyeXB0 aW5nIGFuZCBjYW4gYmUgZG9uZQ0KPj4+Pj4gd2VsbC4NCj4+Pj4NCj4+Pj4NCj4+Pj4gSXQgY2Fu IGFsc28gYmUgZG9uZSBwb29ybHksIGFuZCB0aGUgbWVudGlvbiBvZiBvYmZ1c2NhdGlvbiAoYWxv bmcgd2l0aA0KPj4+PiB0aGUNCj4+Pj4gZXhjaGFuZ2UgSSBjaXRlIGJlbG93KSBsZWFkcyBtZSB0 byBiZWxpZXZlIHRoYXQgLS0gYWJzZW50IGNvbmNyZXRlDQo+Pj4+IGd1aWRhbmNlDQo+Pj4+IHRv IHRoZSBjb250cmFyeSAtLSBpbXBsZW1lbnRvcnMgd2lsbCBjaG9vc2UgdG8gZG8gaXQgcG9vcmx5 LiBJdCdzIG5vdA0KPj4+PiBjbGVhcg0KPj4+PiB0aGF0IGRvaW5nIHRoaXMgcG9vcmx5IHByb3Zp ZGVzIGFueSBiZW5lZml0LCBhbmQgaXQgc2VlbXMgdG8gbWUgdGhhdA0KPj4+Pml0DQo+Pj4+IG1h eQ0KPj4+PiBjYXVzZSBoYXJtOiBpZiBzb21ldGhpbmcgX2xvb2tzXyBzZWN1cmUgYnV0IGlzbid0 LCBkb2Vzbid0IHRoYXQgaGF2ZQ0KPj4+PnRoZQ0KPj4+PiBwb3RlbnRpYWwgZm9yIG9wZXJhdG9y cyB0byBpbmNvcnJlY3RseSB0cmVhdCBpdCBhcyBzZWN1cmU/IEFnYWluLA0KPj4+PnRoaXMgaXMN Cj4+Pj4gbW9yZSB5b3VyIGFyZWEgdGhhbiBtaW5lIGFuZCBzbyBJIHdpbGwgZGVmZXIgdG8geW91 ciBvcGluaW9uIG9uIHRoZQ0KPj4+PiB0b3BpYzsNCj4+Pj4gYnV0IGZyb20gYSBsYXkgcGVyc3Bl Y3RpdmUsIHRoaXMgc2VlbXMgbGlrZWx5IHRvIHJlc3VsdCBpbiB0aGUgbGFjayBvZg0KPj4+PiBn dWFyZGluZyBhZ2FpbnN0IGNvbXByb21pc2Ugb2YgdGhlIGVuY3J5cHRlZCBpbmZvcm1hdGlvbiB1 bmRlciB0aGUNCj4+Pj4gbWlzdGFrZW4NCj4+Pj4gaW1wcmVzc2lvbiB0aGF0IGl0IGNhbid0IGJl IGRlY3J5cHRlZCB0cml2aWFsbHkuDQo+Pj4+DQo+Pj4gVGhlIHdheSBJIHJlYWQgdGhlIHRocmVh ZCBmcm9tIEFjZWUgaXMgdGhhdCB0aGVyZSBhcmVuJ3QgYW55IEtFSw0KPj4+IGltcGxlbWVudGF0 aW9ucyB3aXRoIHdpdGggcGFydGljdWxhciBZQU5HIG1vZHVsZSwgaG93ZXZlciBCcmlhbiBzYXlz DQo+Pj4gdGhlcmUgaXMgd2l0aCBvdGhlciBZQU5HIG1vZHVsZXMuICBJICp0aGluayogd2hlbiBB Y2VlIGlzIHJlZmVycmluZyB0bw0KPj4+IG9iZnVzY2F0aW9uIGFuZCBsZXNzIHRoYW4gaWRlYWwg c2NlbmFyaW9zLCBpdCBpcyB3aXRoIHRoZSBjdXJyZW50bHkNCj4+PiBkZXBsb3llZCBpbXBsZW1l bnRhdGlvbnMgdGhhdCBkb24ndCB1c2UgS0VLcy4gIEJ1dCB0aGUgdGV4dCBhbmQNCj4+PiByZXNw b25zZXMgZGlkIHNlZW0gdG8gYmUgY29tbWluZ2xlZCBhIGJpdCB0b28gbXVjaC4NCj4+Pg0KPj4+ Pj4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8gIFdhcyB0aGVyZSBzb21ldGhpbmcgaW1wbGVtZW50 YXRpb24gc3BlY2lmaWMNCj4+Pj4+IHRoYXQgaGFzIHRoZSByYXcga2V5IHN0b3JlZCB3aXRoIHRo ZSBlbmNyeXB0ZWQgZGF0YT8NCj4+Pj4NCj4+Pj4NCj4+Pj4gUGVyaGFwcyB0aGUgZm9sbG93aW5n IGV4Y2hhbmdlIHdpdGggdGhlIGF1dGhvcjoNCj4+Pj4NCj4+Pj4gQWRhbTogIkJ5IG15IHJlYWRp bmcsIHRoaXMgaXMganVzdCB0YWxraW5nIGFib3V0IGVuY3J5cHRpbmcgJ29uIHRoZQ0KPj4+PmRp c2snDQo+Pj4+IHN0b3JhZ2Ugb24gdGhlIGRldmljZS4gQW55IHByb2Nlc3NlcyBpbnZvbHZlZCBp biBwcm92aXNpb25pbmcgdGhlDQo+Pj4+dmFsdWVzDQo+Pj4+IG9yDQo+Pj4+IHVzaW5nIHRoZW0g dG8gcHJvY2VzcyB0cmFmZmljIHdvdWxkIGhhdmUgYWNjZXNzIHRvIHRoZSBwbGFpbnRleHQsDQo+ Pj4+IHByZXN1bWFibHkNCj4+Pj4gYnkgcmVhZGluZyB0aGUgZW5jcnlwdGVkIGZvcm0gb2ZmIGRp c2ssIHJlYWRpbmcgc29tZSBrZXlpbmcgbWF0ZXJpYWwNCj4+Pj5vZmYNCj4+Pj4gZGlzaywgYW5k IGNvbWJpbmluZyB0aGVtIHRvIHJldHJpZXZlIHRoZSBwbGFpbnRleHQga2V5LiINCj4+Pg0KPj4+ IEl0IGxvb2tzIGxpa2UgdmVyc2lvbiAyMCBoYWQgZGlmZmVyZW50IGFzc3VtcHRpb25zIGFib3V0 IHVzaW5nIHRoZQ0KPj4+IEtFSy4gIEkgKnRoaW5rKiB0aGlzIGlzIGRlc2NyaWJpbmcgdXNhZ2Ug d2l0aG91dCBhIEtFSyBhbmQgbWF5IGJlIHBhcnQNCj4+PiBvZiB3aHkgQWNlZSBpcyBhc2tpbmcg Zm9yIG1vcmUgaW1wbGVtZW50YXRpb24gZ3VpZGFuY2UuLi4gc28gSSdsbCBrZWVwDQo+Pj4gbXkg ZGlzY3VzcyB0byBzZWUgaWYgd2UgY2FuIHNoYXBlIHRoYXQgdXAgbW9yZS4gIFRoaXMgaXMgaGVs cGZ1bCBhcyBJDQo+Pj4gdGhpbmsgSSBzZWUgdGhlIGdhcCBtb3JlIG5vdyBhcyB0byB3aGF0IGhl IG1pZ2h0IGJlIGxvb2tpbmcgZm9yIGluDQo+Pj4gdGVybXMgb2YgZ3VpZGFuY2UuDQo+Pj4NCj4+ PiBIZXJlJ3MgdGhlIHRleHQgZnJvbSAtMjA6DQo+Pj4NCj4+PiBXaGVuIGNvbmZpZ3VyZWQsIHRo ZSBrZXktc3RyaW5ncyBjYW4gYmUgZW5jcnlwdGVkIHVzaW5nIHRoZSBBRVMgS2V5DQo+Pj4gICAg IFdyYXAgYWxnb3JpdGhtIFtBRVMtS0VZLVdSQVBdLiAgVGhlIEFFUyBrZXktZW5jcnlwdGlvbiBr ZXkgKEtFSykgaXMNCj4+PiAgICAgbm90IGluY2x1ZGVkIGluIHRoZSBZQU5HIG1vZGVsIGFuZCBt dXN0IGJlIHNldCBvciBkZXJpdmVkDQo+Pj5pbmRlcGVuZGVudA0KPj4+DQo+Pj4gTGluZGVtLCBl dCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIwLCAyMDE3ICAgICAgICAgICAgICAgW1Bh Z2UNCj4+PjE1XQ0KPj4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgWUFORyBLZXkgQ2hh aW4gICAgICAgICAgICAgICAgICAgQXByaWwNCj4+PjIwMTcNCj4+Pg0KPj4+ICAgICBvZiBrZXkt Y2hhaW4gY29uZmlndXJhdGlvbi4gIFdoZW4gQUVTIGtleS1lbmNyeXB0aW9uIGlzIHVzZWQsIHRo ZQ0KPj4+ICAgICBoZXgta2V5LXN0cmluZyBmZWF0dXJlIGlzIGFsc28gcmVxdWlyZWQgc2luY2Ug dGhlIGVuY3J5cHRlZCBrZXlzDQo+Pj53aWxsDQo+Pj4gICAgIGNvbnRhaW4gY2hhcmFjdGVycyB0 aGF0IGFyZSBub3QgcmVwcmVzZW50YWJsZSBpbiB0aGUgWUFORyBzdHJpbmcNCj4+PiAgICAgYnVp bHQtaW4gdHlwZSBbWUFOR10uICBBRVMga2V5LWVuY3J5cHRpb24gTUFZIGJlIHVzZWQgZm9yIGFk ZGVkIGtleQ0KPj4+ICAgICBzZWN1cml0eSBpbiBzaXR1YXRpb25zIHdoZXJlIHRoZSBORVRDT05G IEFjY2VzcyBDb250cm9sIE1vZGUgaXMgbm90DQo+Pj4gICAgIGF2YWlsYWJsZS4NCj4+Pg0KPj4+ PiBBY2VlOiAiVGhpcyBpcyB0aGUgY29ycmVjdCBpbnRlcnByZXRhdGlvbi4iDQo+Pj4+DQo+Pj4+ IC9hDQo+Pj4NCj4+PiBUaGFua3MuDQo+Pj4NCj4+DQo+DQo+DQo+DQo+LS0gDQo+DQo+QmVzdCBy ZWdhcmRzLA0KPkthdGhsZWVuDQoNCg== From nobody Thu Apr 27 07:03:17 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA4B129512; Thu, 27 Apr 2017 07:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltl0bC1dJFyO; Thu, 27 Apr 2017 07:03:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5574129528; Thu, 27 Apr 2017 07:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17046; q=dns/txt; s=iport; t=1493301786; x=1494511386; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=M3JJOoWgbVn0f7e/VfzDw8bM52h78We4WXYgO9KMsRg=; b=UQ+JymczD36T1vImZxjsIzFHc4ehwRrDBBPAE8SJglT6Az8k01wiBZ3f O5loF+PZ0xQD7z+zKDa0W2XLsTAb8117gQPPVlK8k/a0AatoZcn/qrW8Z VByGG+FETibmQPwKQ/A0fJOhYQ1bt2c8SpP6KhaYeTasionhSnDsWOV0X E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQAk+QFZ/4MNJK1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNVYYEMB4NhihiRSogijUqCDyyFeAIag38/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRYBBSMRRRACAQgYAgImAgICHxEVEAIEAQ0FG4lqAxUOrFaCJocwDYNfAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR+BC4cngg+BC4JTgVQKEQEIFBcKJoI/gl8FnRU7AY4?= =?us-ascii?q?/hEyCAoU3g2WGQIh0giWJDQEfOH8LbxVEhHEcGYFKdQGGUA4XgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,384,1488844800"; d="scan'208";a="228011816" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2017 14:03:05 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3RE34Hk008753 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Apr 2017 14:03:05 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Apr 2017 10:03:03 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 27 Apr 2017 10:03:04 -0400 From: "Acee Lindem (acee)" To: Kathleen Moriarty , "Brian Weis (bew)" CC: Adam Roach , Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Index: AQHSvsRbaK6mr1jQpUuQYLHDV2KBn6HYWesAgAADZoD//7+ggIAARUkA//++/wCAAGFERYAAveuA Date: Thu, 27 Apr 2017 14:03:04 +0000 Message-ID: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="utf-8" Content-ID: <25AC264D4B6A4745BF24B0BCFAD58503@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:03:09 -0000 SGkgS2F0aGxlZW4sIEJyaWFuLA0KDQpPbiA0LzI2LzE3LCAxMDo0MiBQTSwgIkthdGhsZWVuIE1v cmlhcnR5Ig0KPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KPkhp IEJyaWFuICYgQWNlZSwNCj4NCj5PbiBXZWQsIEFwciAyNiwgMjAxNyBhdCA4OjQ5IFBNLCBCcmlh biBXZWlzIChiZXcpIDxiZXdAY2lzY28uY29tPiB3cm90ZToNCj4+IEhpIEthdGhsZWVuIGFuZCBB Y2VlLA0KPj4NCj4+IEp1c3QgYSBjbGFyaWZpY2F0aW9uIG9uIHdoYXQgSSBoYWQgc2FpZCBlYXJs aWVyLg0KPj4NCj4+PiBPbiBBcHIgMjYsIDIwMTcsIGF0IDE6NTUgUE0sIEFjZWUgTGluZGVtIChh Y2VlKSA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4+DQo+Pj4gS2F0aGxlZW4sDQo+Pj4NCj4+ PiBPbiA0LzI2LzE3LCA0OjQ3IFBNLCAiS2F0aGxlZW4gTW9yaWFydHkiDQo+Pj4gPGthdGhsZWVu Lm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4+Pg0KPj4+PiBBY2VlLA0KPj4+Pg0K Pj4+Pg0KPj4+Pg0KPj4+PiBPbiBXZWQsIEFwciAyNiwgMjAxNyBhdCA0OjM5IFBNLCBBY2VlIExp bmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPg0KPj4+PiB3cm90ZToNCj4+Pj4+IEthdGhsZWVu LCBCcmlhbiwNCj4+Pj4+DQo+Pj4+PiBTaW5jZSBLRUsgYXMgZGVzY3JpYmVkIGluIFJGQyA1NjQ5 IGlzIG5vdCByZWFkeSBmb3IgcHJpbWUgdGltZSwgd2h5DQo+Pj4+PiBkb27igJl0DQo+Pj4+DQo+ Pj4+IFRoaXMgaXMgd2lkZWx5IGRlcGxveWVkIGluIG90aGVyIHVzZSBjYXNlcywNCj4+Pg0KPj4+ IE5vbmUgb2YgdGhlc2UgdXNlIGNhc2VzIGFyZSBkb2N1bWVudGVkIGluIElFVEYgUkZDcyBvciBk cmFmdHMuDQo+Pg0KPj4gVGhlIEFFUyBrZXkgd3JhcCBtZXRob2QgaXRzZWxmIGlzIHdlbGwgdW5k ZXJzdG9vZCwgYW5kIGlmIHlvdSBsb29rIGF0DQo+PnRoZSBjaXRhdGlvbnMgZm9yIFJGQyAzMzk0 IGF0DQo+PjxodHRwOi8vd3d3LmFya2tvLmNvbS90b29scy9hbGxzdGF0cy9jaXRhdGlvbnMtcmZj MzM5NC5odG1sPiBpdCBpcw0KPj5hY3R1YWxseSB1c2VkIGluIGEgbnVtYmVyIG9mIElFVEYgcHJv dG9jb2xzLiBUaGlzIGlzIHRoZSBiYXNpcyBmb3Igd2h5IEkNCj4+b3JpZ2luYWxseSBzdWdnZXN0 ZWQgdGhhdCBpdCBtYWRlIHNlbnNlIHRvIGluY2x1ZGUgaXQgaW4gYSBZQU5HIG1vZGVsDQo+PnRo YXQgZGlzdHJpYnV0ZXMga2V5cy4NCj4+DQo+DQo+VGhhbmtzIGZvciBzYXZpbmcgbWUgYSBzdGVw LCBJIHdhcyBnb2luZyB0byB1c2UgSmFyaSdzIHRvb2wgb25jZSBJIGdvdA0KPmJhY2sgb25saW5l IGZvciB0aGUgc2FtZSBwdXJwb3NlLg0KPg0KPj4+DQo+Pj4+IHNvIEkgYW0gbm90IGZvbGxvd2lu ZyB0aGlzDQo+Pj4+IHN0YXRlbWVudCB0aGF0IGl0IGlzbid0IHJlYWR5IGZvciBwcmltZSB0aW1l LiAgUkZDNTY0OSBpcw0KPj4+PiBzdHJhaWdodGZvcndhcmQuICBXaGF0IGlzIHRoZSBnYXAgZm9y IHlvdXIgdXNhZ2UgdGhhdCByZXF1aXJlcw0KPj4+PiBhZGRpdGlvbmFsIGd1aWRhbmNlPyAgQnJp YW4gc2F5cyB0aGlzIGluIGluIHVzZSBmb3Igb3RoZXIgWUFORyBtb2R1bGVzDQo+Pj4+IGFscmVh ZHkgYXMgd2VsbC4NCj4+DQo+PiBBcG9sb2dpZXMsIEkgd2FzIHVuY2xlYXIgaW4gd2hhdCBJIHNh aWQuIEkgYW0gbm90IGFjdHVhbGx5IGF3YXJlIG9mIGl0DQo+PmJlaW5nIHVzZWQgaW4gb3RoZXIg WUFORyBtb2R1bGVzIOKApiBJIG1lYW50IHRvIGNvbW11bmljYXRlIHdoYXQgS2F0aGxlZW4NCj4+ c2FpZCBtb3JlIHN1Y2NpbmN0bHksIHdoaWNoIGlzIHRoYXQgdGhlIFJGQyAzMzk0IGFuZCBSRkMg NTY0OSBhcmUNCj4+aW1wbGVtZW50ZWQgZm9yIHRoZSBzYW1lIHB1cnBvc2UgaW4gb3RoZXIgKG5v bi1ZQU5HIG1vZHVsZSkgcHJvdG9jb2xzLg0KPj5Ob25lIG9mIHRoZSBjaXRhdGlvbnMgaW4gdGhl IGxpc3QgYWJvdmUgYXBwZWFyIHRvIGJlIFlBTkcgbW9kdWxlcywgYnV0DQo+PnRoZW4gSeKAmW0g bm90IHN1cmUgd2hldGhlciBvciBub3QgYW55IG90aGVyIFlBTkcgbW9kdWxlcyBkaXN0cmlidXRl IGtleXMNCj4+ZWl0aGVyLg0KPg0KPlRoYW5rcywgQnJpYW4sIHRoYXQgaXMgaGVscGZ1bC4NCj4N Cj5BY2VlLCBhZnRlciBhIGxpdHRsZSBtb3JlIHJlYWRpbmcsIGlzIHRoZSBnYXAgZm9yIGltcGxl bWVudGF0aW9uDQo+Z3VpZGFuY2Ugb24gaG93IHRvIHVzZS9hY2Nlc3MgdGhlIGtleSBlbmNyeXB0 aW5nIGtleSBiZWNhdXNlIG9mIHRoZQ0KPmZvbGxvd2luZyBzZW50ZW5jZSBpbiAtMjA/DQo+DQo+ ICAgVGhlIEFFUyBrZXktZW5jcnlwdGlvbiBrZXkgKEtFSykgaXMNCj4gICBub3QgaW5jbHVkZWQg aW4gdGhlIFlBTkcgbW9kZWwgYW5kIG11c3QgYmUgc2V0IG9yIGRlcml2ZWQgaW5kZXBlbmRlbnQN Cj4gICBvZiBrZXktY2hhaW4gY29uZmlndXJhdGlvbi4NCj4NCj5UaGlzIGlzIGFuIGltcG9ydGFu dCBzdGVwLCBJJ20gZ3Vlc3NpbmcgQnJpYW4gaGVscGVkIHdpdGggdGhpcyB0ZXh0DQo+YW5kIHRo YXQgbWF5IGJlIHdoZXJlIHlvdSBuZWVkIHNvbWUgZ3VpZGFuY2UgZm9yIGltcGxlbWVudGluZyB0 aGUga2V5DQo+ZGlzdHJpYnV0aW9uIGZ1bmN0aW9ucyB3aXRoIGEgc3RvcmVkIEtFSyBpbnN0ZWFk IG9mIHRoZSBrZXkgb2JmdXNjYXRlZA0KPmluIHNvbWUgd2F5LiAgUGVyc29uYWxseSwgSSdkIGxl YXZlIHRoaXMgYXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMNCj5hbmQgdGhlIGd1aWRhbmNlIGhl cmUgaXMgZW5vdWdoIGZvciB0aGUgZHJhZnQsIGJ1dCB2ZW5kb3JzDQo+aW1wbGVtZW50aW5nIHdv dWxkIGhhdmUgdG8gZmlndXJlIG91dCBob3cgdGhleSB3YW50IHRvIGRvIHRoaXMuDQo+QmVmb3Jl IGdvaW5nIGZ1cnRoZXIsIGNhbiBJIGNvbmZpcm0gd2l0aCB5b3UgdGhhdCB0aGlzIGlzIHRoZSBw bGFjZQ0KPndoZXJlIHlvdSdkIGxpa2UgZ3VpZGFuY2U/DQo+DQo+VGhlIGd1aWRhbmNlIEkgcHJv dmlkZWQgZWFybGllciB0aGF0IGlzIG5vdCBpbiB0aGUgZHJhZnQgaXMgYXMgZm9sbG93cw0KPihi dXQgbWlnaHQgbm90IGFuc3dlciB5b3VyIHF1ZXN0aW9uKToNCj4NCj4gICAgSWYgeW91IHdhbnQg dG8gd3JhcCBhbiBBRVMga2V5IGFuZCBub3RoaW5nIGVsc2UsIHVzZSBSRkMgMzM5NA0KPiAgICBJ ZiB5b3Ugd2FudCB0byB3cmFwIGFuIEFFUyBrZXkgYW5kIHNvbWUgb3RoZXIgYXR0cmlidXRlcyB0 b28sIHVzZSBSRkMNCj41NjQ5DQoNCkluIHRoaXMgY2FzZSwgaXQgaXMgb25seSB0aGUga2V5cywg c28gSSBzaG91bGQgY2hhbmdlIHRoZSByZWZlcmVuY2UgdG8gUkZDDQozMzk0Pw0KDQpUaGFua3Ms DQpBY2VlIA0KDQo+DQo+VGhhbmsgeW91LA0KPkthdGhsZWVuDQo+DQo+Pg0KPj4gSG9wZSB0aGF0 IGhlbHBzLA0KPj4gQnJpYW4NCj4+DQo+Pj4+IENvdWxkIHlvdSBwbGVhc2UgYmUgbW9yZSBleHBs aWNpdCBpbiB0ZXJtcyBvZiB3aGF0DQo+Pj4+IHlvdSBuZWVkIGZvciBndWlkYW5jZS4gIEkgb2Zm ZXJlZCBhIHN1Z2dlc3Rpb24sIGlmIHRoYXQgaXNuJ3QgZW5vdWdoLA0KPj4+PiBjb3VsZCB5b3Ug cGxlYXNlIGV4cGxhaW4gdGhlIGdhcCBhcyB5b3Ugc2VlIGl0IHNvIHdlIGNhbiBhc3Npc3Q/DQo+ Pj4NCj4+PiBTb3JyeSwgSSBtdXN0IGhhdmUgbWlzc2VkIHRoZSB0ZXh0IHlvdSByZWNvbW1lbmRl ZC4gUGxlYXNlIHByb3ZpZGUgaXQNCj4+PiBhZ2FpbiBhbmQgSSB3aWxsIHJlc3RvcmUgdGhlIG9w dGlvbiB3aXRoIHRoZSBndWlkYW5jZSB0aGF0IGlzIG1pc3NpbmcNCj4+PmZyb20NCj4+PiBSRkMg NTY0OS4NCj4+Pg0KPj4+IFRoYW5rcywNCj4+PiBBY2VlDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+ Pj4NCj4+Pj4gVGhhbmsgeW91LA0KPj4+PiBLYXRobGVlbg0KPj4+Pg0KPj4+Pj4geW91IHRha2Ug dGhpcyB1cCBhcyBhIHNlcGFyYXRlIGRyYWZ0IHJhdGhlciB0aGFuIHRyeWluZyB0byBob2xkIHRo aXMNCj4+Pj4+IGltcG9ydGFudCBkb2N1bWVudCBob3N0YWdlPyBXZSBoYXZlIHRoZSBORVRDT05G IEFjY2VzcyBDb250cm9sIE1vZGVsDQo+Pj4+PiAoTkFDTSkgdG8gcHJvdGVjdCB0aGUga2V5cyBk dXJpbmcgdHJhbnNwb3J0ICh3aGljaCBoYXMgYmVlbg0KPj4+Pj4gaW1wbGVtZW50ZWQpLg0KPj4+ Pj4gT2J2aW91c2x5LCBrZXktc3RyaW5ncyBhcmUgc3RvcmVkIG9uIGRldmljZXMgdG9kYXkgc2lu Y2UgdGhleSBhcmUNCj4+Pj4+YmVpbmcNCj4+Pj4+IHVzZWQgZm9yIHByb3RvY29sIGF1dGhlbnRp Y2F0aW9uIGFuZCBlbmNyeXB0aW9uIHNvIHRoaXMgaXMgdG90YWxseQ0KPj4+Pj4gb3J0aG9nb25h bCB0byB0aGUgWUFORyBtb2RlbCBiZWluZyB1c2VkIHRvIHByb3Zpc2lvbiB0aGVtLg0KPj4+Pj4N Cj4+Pj4+IFRoYW5rcywNCj4+Pj4+IEFjZWUNCj4+Pj4+DQo+Pj4+PiBPbiA0LzI2LzE3LCA0OjMw IFBNLCAiS2F0aGxlZW4gTW9yaWFydHkiDQo+Pj4+PiA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBn bWFpbC5jb20+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PiBIaSBBZGFtLA0KPj4+Pj4+DQo+Pj4+Pj4g SSB0aGluayBJIHNlZSB3aGVyZSB3ZSBhcmUgY29taW5nIHRvIGRpZmZlcmVudCBjb25jbHVzaW9u cy4uLi4NCj4+Pj4+Pg0KPj4+Pj4+IE9uIFdlZCwgQXByIDI2LCAyMDE3IGF0IDQ6MTggUE0sIEFk YW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+DQo+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4gT24gNC8y Ni8xNyAyOjM2IFBNLCBLYXRobGVlbiBNb3JpYXJ0eSB3cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiBPbiBXZWQsIEFwciAyNiwgMjAxNyBhdCAyOjQyIFBNLCBBZGFtIFJvYWNoIDxhZGFtQG5vc3Ry dW0uY29tPg0KPj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE9uIDQvMjYvMTcg MTE6MzQgQU0sIEthdGhsZWVuIE1vcmlhcnR5IHdyb3RlOg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PiBTaW5jZSB0aGUgZm9sbG93aW5nIHRleHQgaW50IGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z IHNlY3Rpb24NCj4+Pj4+Pj4+Pj5pcw0KPj4+Pj4+Pj4+PiBhDQo+Pj4+Pj4+Pj4+IHJlY29tbWVu ZGF0aW9uLCBJTU8gaXQgd291bGQgYmUgYmV0dGVyIHRvIGRyb3AgIm9yIG90aGVyd2lzZQ0KPj4+ Pj4+Pj4+PiBvYmZ1c2NhdGVkIg0KPj4+Pj4+Pj4+PiBmcm9tIHRoZSBzZW50ZW5jZSBhcyBlbmNy eXB0aW5nIHRoZSBrZXlzIHJlYWxseSBzaG91bGQgYmUgdGhlDQo+Pj4+Pj4+Pj4+IHJlY29tbWVu ZGF0aW9uLiAgQ2FuIHdlIG1ha2UgdGhpcyB1cGRhdGU/DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ ICAgICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGtleXMgYmUgZW5jcnlwdGVkIG9yIG90aGVyd2lz ZQ0KPj4+Pj4+Pj4+PiBvYmZ1c2NhdGVkDQo+Pj4+Pj4+Pj4+IHdoZW4NCj4+Pj4+Pj4+Pj4gICAg IHN0b3JlZCBpbnRlcm5hbGx5IG9uIGEgbmV0d29yayBkZXZpY2Ugc3VwcG9ydGluZyB0aGlzDQo+ Pj4+Pj4+Pj4+IHNwZWNpZmljYXRpb24uDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IElmIG9iZnVz Y2F0aW9uIGlzIHdoYXQgaGFwcGVucyBtb3JlIG9mdGVuIGluIHByYWN0aWNlLCBtYXliZQ0KPj4+ Pj4+Pj4+PiBtZW50aW9uDQo+Pj4+Pj4+Pj4+IHRoaXMNCj4+Pj4+Pj4+Pj4gYXMgYSBmYWxsYmFj ayBmcm9tIHRoZSByZWNvbW1lbmRhdGlvbiwgYnV0IG5vdCBtYWtlIHRoZW0gc291bmQNCj4+Pj4+ Pj4+Pj4gZXF1aXZhbGVudD8NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+PiBUbyBiZSBjbGVhciAtLSB0aGUgY3VycmVudCBndWlkYW5jZSBmcm9tIHRoZSBzZWN1cml0 eSBhcmVhIGlzIHRvDQo+Pj4+Pj4+Pj4gcGVyZm9ybQ0KPj4+Pj4+Pj4+IHRoaXMga2luZCBvZiBl bmNyeXB0aW9uLCB3aGVyZSB5b3UgaGF2ZSBlbmNyeXB0ZWQgbWF0ZXJpYWwgbGl2aW5nDQo+Pj4+ Pj4+Pj4gc2lkZS1ieS1zaWRlIHdpdGggdGhlIGtleSBuZWNlc3NhcnkgdG8gZGVjcnlwdCBpdD8N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBXZSBhcmUgdGFsa2luZyBhYm91dCB1c2luZyBhIGtleSBlbmNy eXB0aW5nIGtleSAoS0VLKSBhbmQgc3RvcmluZw0KPj4+Pj4+Pj4gdGhhdCwgbm90IHN0b3Jpbmcg dGhlIHJhdyBrZXkgbmV4dCB0byB0aGUgZW5jcnlwdGVkIGRhdGEgYXMgZmFyDQo+Pj4+Pj4+PmFz IEkNCj4+Pj4+Pj4+IGNhbiB0ZWxsLg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBSaWdodC4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4+IEFkZGl0aW9uYWxseSwgSSBoYXZlbid0IHNlZW4gYSBkaXNjdXNz aW9uIG9uIHRoZSBoYXJkd2FyZQ0KPj4+Pj4+Pj4gdGhpcyBpcyBleHBlY3RlZCB0byBydW4gb24u DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoYXQgbWlnaHQgYmUgYXBwcm9wcmlhdGUgbWF0 dGVyIGZvciB0aGUgZHJhZnQsIGlmIGl0IGlzIGdvaW5nIHRvDQo+Pj4+Pj4+bWFrZQ0KPj4+Pj4+ PiB0aGlzDQo+Pj4+Pj4+IHJlY29tbWVuZGF0aW9uLg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gU29tZSBp bXBsZW1lbnRhdGlvbnMgb2YgS0VLIHNvbHV0aW9ucyB1c2UgZGVkaWNhdGVkIGhhcmR3YXJlIGZv cg0KPj4+Pj4+Pj50aGUNCj4+Pj4+Pj4+IEtFSyBhbmQgcmVxdWlyZSBhdXRoZW50aWNhdGlvbiBm b3IgYWNjZXNzIHRvIHRoZSBrZXksIGhlbmNlDQo+Pj4+Pj4+PiBwcmV2ZW50aW5nDQo+Pj4+Pj4+ PiBnZW5lcmljIGFjY2VzcyBhbmQgc2lkZS1ieS1zaWRlIHN0b3JhZ2Ugb2YgdGhlIEtFSydzIHBy b3RlY3RlZA0KPj4+Pj4+Pj5rZXksDQo+Pj4+Pj4+PiBhbmQgZW5jcnlwdGVkIGRhdGEuICBJJ2Qg cmF0aGVyIHNlZSBhIEtFSyB1c2VkIHRoYW4ganVzdCBhIGtleQ0KPj4+Pj4+Pj5zdG9yZWQNCj4+ Pj4+Pj4+IGluIGFueSBjYXNlLiAgQXJlIHlvdSBhcmd1aW5nIGZvciBub3QgdXNpbmcgYW55IGVu Y3J5cHRpb24gYXQgYWxsPw0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBJJ2xsIGRlZmVyIHRv IHlvdSwgb2YgY291cnNlLCBzaW5jZSB5b3UgaGF2ZSBwcmVzdW1hYmx5IGdpdmVuIHRoZQ0KPj4+ Pj4+PiB0b3BpYw0KPj4+Pj4+PiBtb3JlDQo+Pj4+Pj4+IHRob3VnaHQgdGhhbiBJIGhhdmUsIGJ1 dDogeWVzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBBYnNlbnQgc29tZXRoaW5nIGxpa2UgYW4gSFNNIG9y IGZvcmNpbmcgaHVtYW4gaW50ZXJ2ZW50aW9uDQo+Pj4+Pj4+d2hlbmV2ZXIgYQ0KPj4+Pj4+PiBw cm9jZXNzIHN0YXJ0cyAob3IgcmVzdGFydHMpLCBpdCBzZWVtcyB0aGF0IHRoZSBzY2hlbWUgZGVz Y3JpYmVkIGluDQo+Pj4+Pj4+IHNlY3Rpb24NCj4+Pj4+Pj4gNSBkb2Vzbid0IGFjdHVhbGx5IGRl dGVyIGEgY29tcGV0ZW50IGF0dGFja2VyIGZyb20gb2J0YWluaW5nIHRoZQ0KPj4+Pj4+PmtleXMu DQo+Pj4+Pj4+IE15DQo+Pj4+Pj4+IGltcHJlc3Npb24gaXMgdGhhdCBzdG9yaW5nIGluZm9ybWF0 aW9uIGluIGFuIGVuY3J5cHRlZCBmb3JtIHRoYXQNCj4+Pj4+Pj5jYW4NCj4+Pj4+Pj4gYmUNCj4+ Pj4+Pj4gdHJpdmlhbGx5IGRlY3J5cHRlZCBieSBhbiBhdHRhY2tlciBwcm92aWRlcyBhIGZhbHNl IHNlbnNlIG9mDQo+Pj4+Pj4+c2VjdXJpdHkNCj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4gZXF1aXBtZW50 IG9wZXJhdG9ycy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSWYgdGhlIHNjaGVtZSBpbiBzZWN0aW9uIDUg KmRvZXMqIHJlcXVpcmUgdGhlIGtpbmQgb2YgcHJlcmVxdWlzaXRlcw0KPj4+Pj4+PiB5b3UNCj4+ Pj4+Pj4gcG9zaXQsIHN1Y2ggYXMgZGVkaWNhdGVkIHNlY3VyaXR5IGhhcmR3YXJlLCBpdCBzZWVt cyB0aGF0IHN1Y2gNCj4+Pj4+Pj4gcHJlcmVxdWlzaXRlcw0KPj4+Pj4+PiBzaG91bGQgYmUgbWVu dGlvbmVkIGFsb25nc2lkZSB0aGUgcmVjb21tZW5kYXRpb24uDQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBG b3IgWUFORyBtb2R1bGVzLCBjb3VsZG4ndCB0aGUgYXBwbGljYXRpb24gdmlhIE5FVENPTkYvUkVT VENPTkYNCj4+Pj4+Pj4+IGFjY2Vzc2luZyB0aGUgbW9kdWxlIHByb3ZpZGUgdGhlIGNyZWRlbnRp YWxzIHRvIGFjY2VzcyB0aGUga2V5DQo+Pj4+Pj4+PiBwcm90ZWN0ZWQgYnkgdGhlIEtFSz8NCj4+ Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhhdCBzb2x2ZXMgdGhlIGlzc3VlcyB3aXRoIHByb3Zp c2lvbmluZywgYnV0IGRvZXNuJ3Qgc2VlbSB0byBoZWxwDQo+Pj4+Pj4+dGhlDQo+Pj4+Pj4+IHBy b2Nlc3NlcyBhY3R1YWxseSBpbnZvbHZlZCBpbiByb3V0aW5nLg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4g U29tZSBpbXBsZW1lbnRhdGlvbnMgY291bGQgc3RvcmUgdGhlIEtFSyBpbg0KPj4+Pj4+Pj4gZGVk aWNhdGVkIGhhcmR3YXJlIGFzIHdlbGwuIEluIHRoaXMgd2F5LCBzdG9yaW5nIHRoZSBLRUsgYW5k IGRhdGENCj4+Pj4+Pj4+IHRvZ2V0aGVyIGlzIG5vdCB0aGUgc2FtZSBhcyBzdG9yaW5nIGEga2V5 IHJpZ2h0IG5leHQgdG8gdGhlIGRhdGENCj4+Pj4+Pj4+aXQNCj4+Pj4+Pj4+IGlzDQo+Pj4+Pj4+ PiBwcm90ZWN0aW5nLg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGlzIG1ha2VzIHBlcmZl Y3Qgc2Vuc2U7IGFuZCBpdCBzaG91bGQgcHJvYmFibHkgYmUgaW4gdGhlDQo+Pj4+Pj4+ZG9jdW1l bnQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBVc2Ugb2YgYSBLRUsgaXMgYmV0dGVyIHRoZW4gbm90IGVu Y3J5cHRpbmcgYW5kIGNhbiBiZSBkb25lDQo+Pj4+Pj4+PiB3ZWxsLg0KPj4+Pj4+Pg0KPj4+Pj4+ Pg0KPj4+Pj4+PiBJdCBjYW4gYWxzbyBiZSBkb25lIHBvb3JseSwgYW5kIHRoZSBtZW50aW9uIG9m IG9iZnVzY2F0aW9uIChhbG9uZw0KPj4+Pj4+PndpdGgNCj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+IGV4 Y2hhbmdlIEkgY2l0ZSBiZWxvdykgbGVhZHMgbWUgdG8gYmVsaWV2ZSB0aGF0IC0tIGFic2VudCBj b25jcmV0ZQ0KPj4+Pj4+PiBndWlkYW5jZQ0KPj4+Pj4+PiB0byB0aGUgY29udHJhcnkgLS0gaW1w bGVtZW50b3JzIHdpbGwgY2hvb3NlIHRvIGRvIGl0IHBvb3JseS4gSXQncw0KPj4+Pj4+Pm5vdA0K Pj4+Pj4+PiBjbGVhcg0KPj4+Pj4+PiB0aGF0IGRvaW5nIHRoaXMgcG9vcmx5IHByb3ZpZGVzIGFu eSBiZW5lZml0LCBhbmQgaXQgc2VlbXMgdG8gbWUNCj4+Pj4+Pj50aGF0DQo+Pj4+Pj4+IGl0DQo+ Pj4+Pj4+IG1heQ0KPj4+Pj4+PiBjYXVzZSBoYXJtOiBpZiBzb21ldGhpbmcgX2xvb2tzXyBzZWN1 cmUgYnV0IGlzbid0LCBkb2Vzbid0IHRoYXQNCj4+Pj4+Pj5oYXZlDQo+Pj4+Pj4+IHRoZQ0KPj4+ Pj4+PiBwb3RlbnRpYWwgZm9yIG9wZXJhdG9ycyB0byBpbmNvcnJlY3RseSB0cmVhdCBpdCBhcyBz ZWN1cmU/IEFnYWluLA0KPj4+Pj4+PnRoaXMNCj4+Pj4+Pj4gaXMNCj4+Pj4+Pj4gbW9yZSB5b3Vy IGFyZWEgdGhhbiBtaW5lIGFuZCBzbyBJIHdpbGwgZGVmZXIgdG8geW91ciBvcGluaW9uIG9uIHRo ZQ0KPj4+Pj4+PiB0b3BpYzsNCj4+Pj4+Pj4gYnV0IGZyb20gYSBsYXkgcGVyc3BlY3RpdmUsIHRo aXMgc2VlbXMgbGlrZWx5IHRvIHJlc3VsdCBpbiB0aGUNCj4+Pj4+Pj5sYWNrIG9mDQo+Pj4+Pj4+ IGd1YXJkaW5nIGFnYWluc3QgY29tcHJvbWlzZSBvZiB0aGUgZW5jcnlwdGVkIGluZm9ybWF0aW9u IHVuZGVyIHRoZQ0KPj4+Pj4+PiBtaXN0YWtlbg0KPj4+Pj4+PiBpbXByZXNzaW9uIHRoYXQgaXQg Y2FuJ3QgYmUgZGVjcnlwdGVkIHRyaXZpYWxseS4NCj4+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IFRo ZSB3YXkgSSByZWFkIHRoZSB0aHJlYWQgZnJvbSBBY2VlIGlzIHRoYXQgdGhlcmUgYXJlbid0IGFu eSBLRUsNCj4+Pj4+PiBpbXBsZW1lbnRhdGlvbnMgd2l0aCB3aXRoIHBhcnRpY3VsYXIgWUFORyBt b2R1bGUsIGhvd2V2ZXIgQnJpYW4gc2F5cw0KPj4+Pj4+IHRoZXJlIGlzIHdpdGggb3RoZXIgWUFO RyBtb2R1bGVzLiAgSSAqdGhpbmsqIHdoZW4gQWNlZSBpcyByZWZlcnJpbmcNCj4+Pj4+PnRvDQo+ Pj4+Pj4gb2JmdXNjYXRpb24gYW5kIGxlc3MgdGhhbiBpZGVhbCBzY2VuYXJpb3MsIGl0IGlzIHdp dGggdGhlIGN1cnJlbnRseQ0KPj4+Pj4+IGRlcGxveWVkIGltcGxlbWVudGF0aW9ucyB0aGF0IGRv bid0IHVzZSBLRUtzLiAgQnV0IHRoZSB0ZXh0IGFuZA0KPj4+Pj4+IHJlc3BvbnNlcyBkaWQgc2Vl bSB0byBiZSBjb21taW5nbGVkIGEgYml0IHRvbyBtdWNoLg0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+ Pj4+PiBBbSBJIG1pc3Npbmcgc29tZXRoaW5nPyAgV2FzIHRoZXJlIHNvbWV0aGluZyBpbXBsZW1l bnRhdGlvbg0KPj4+Pj4+Pj5zcGVjaWZpYw0KPj4+Pj4+Pj4gdGhhdCBoYXMgdGhlIHJhdyBrZXkg c3RvcmVkIHdpdGggdGhlIGVuY3J5cHRlZCBkYXRhPw0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+ PiBQZXJoYXBzIHRoZSBmb2xsb3dpbmcgZXhjaGFuZ2Ugd2l0aCB0aGUgYXV0aG9yOg0KPj4+Pj4+ Pg0KPj4+Pj4+PiBBZGFtOiAiQnkgbXkgcmVhZGluZywgdGhpcyBpcyBqdXN0IHRhbGtpbmcgYWJv dXQgZW5jcnlwdGluZyAnb24gdGhlDQo+Pj4+Pj4+IGRpc2snDQo+Pj4+Pj4+IHN0b3JhZ2Ugb24g dGhlIGRldmljZS4gQW55IHByb2Nlc3NlcyBpbnZvbHZlZCBpbiBwcm92aXNpb25pbmcgdGhlDQo+ Pj4+Pj4+IHZhbHVlcyBvcg0KPj4+Pj4+PiB1c2luZyB0aGVtIHRvIHByb2Nlc3MgdHJhZmZpYyB3 b3VsZCBoYXZlIGFjY2VzcyB0byB0aGUgcGxhaW50ZXh0LA0KPj4+Pj4+PiBwcmVzdW1hYmx5DQo+ Pj4+Pj4+IGJ5IHJlYWRpbmcgdGhlIGVuY3J5cHRlZCBmb3JtIG9mZiBkaXNrLCByZWFkaW5nIHNv bWUga2V5aW5nDQo+Pj4+Pj4+bWF0ZXJpYWwNCj4+Pj4+Pj4gb2ZmDQo+Pj4+Pj4+IGRpc2ssIGFu ZCBjb21iaW5pbmcgdGhlbSB0byByZXRyaWV2ZSB0aGUgcGxhaW50ZXh0IGtleS4iDQo+Pj4+Pj4N Cj4+Pj4+PiBJdCBsb29rcyBsaWtlIHZlcnNpb24gMjAgaGFkIGRpZmZlcmVudCBhc3N1bXB0aW9u cyBhYm91dCB1c2luZyB0aGUNCj4+Pj4+PiBLRUsuICBJICp0aGluayogdGhpcyBpcyBkZXNjcmli aW5nIHVzYWdlIHdpdGhvdXQgYSBLRUsgYW5kIG1heSBiZQ0KPj4+Pj4+cGFydA0KPj4+Pj4+IG9m IHdoeSBBY2VlIGlzIGFza2luZyBmb3IgbW9yZSBpbXBsZW1lbnRhdGlvbiBndWlkYW5jZS4uLiBz byBJJ2xsDQo+Pj4+Pj5rZWVwDQo+Pj4+Pj4gbXkgZGlzY3VzcyB0byBzZWUgaWYgd2UgY2FuIHNo YXBlIHRoYXQgdXAgbW9yZS4gIFRoaXMgaXMgaGVscGZ1bCBhcw0KPj4+Pj4+SQ0KPj4+Pj4+IHRo aW5rIEkgc2VlIHRoZSBnYXAgbW9yZSBub3cgYXMgdG8gd2hhdCBoZSBtaWdodCBiZSBsb29raW5n IGZvciBpbg0KPj4+Pj4+IHRlcm1zIG9mIGd1aWRhbmNlLg0KPj4+Pj4+DQo+Pj4+Pj4gSGVyZSdz IHRoZSB0ZXh0IGZyb20gLTIwOg0KPj4+Pj4+DQo+Pj4+Pj4gV2hlbiBjb25maWd1cmVkLCB0aGUg a2V5LXN0cmluZ3MgY2FuIGJlIGVuY3J5cHRlZCB1c2luZyB0aGUgQUVTIEtleQ0KPj4+Pj4+ICBX cmFwIGFsZ29yaXRobSBbQUVTLUtFWS1XUkFQXS4gIFRoZSBBRVMga2V5LWVuY3J5cHRpb24ga2V5 IChLRUspIGlzDQo+Pj4+Pj4gIG5vdCBpbmNsdWRlZCBpbiB0aGUgWUFORyBtb2RlbCBhbmQgbXVz dCBiZSBzZXQgb3IgZGVyaXZlZA0KPj4+Pj4+aW5kZXBlbmRlbnQNCj4+Pj4+Pg0KPj4+Pj4+IExp bmRlbSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMCwgMjAxNw0KPj4+Pj4+W1Bh Z2UgMTVdDQo+Pj4+Pj4gSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBZQU5HIEtleSBDaGFp biAgICAgICAgICAgICAgICAgICBBcHJpbA0KPj4+Pj4+MjAxNw0KPj4+Pj4+DQo+Pj4+Pj4gIG9m IGtleS1jaGFpbiBjb25maWd1cmF0aW9uLiAgV2hlbiBBRVMga2V5LWVuY3J5cHRpb24gaXMgdXNl ZCwgdGhlDQo+Pj4+Pj4gIGhleC1rZXktc3RyaW5nIGZlYXR1cmUgaXMgYWxzbyByZXF1aXJlZCBz aW5jZSB0aGUgZW5jcnlwdGVkIGtleXMNCj4+Pj4+PndpbGwNCj4+Pj4+PiAgY29udGFpbiBjaGFy YWN0ZXJzIHRoYXQgYXJlIG5vdCByZXByZXNlbnRhYmxlIGluIHRoZSBZQU5HIHN0cmluZw0KPj4+ Pj4+ICBidWlsdC1pbiB0eXBlIFtZQU5HXS4gIEFFUyBrZXktZW5jcnlwdGlvbiBNQVkgYmUgdXNl ZCBmb3IgYWRkZWQga2V5DQo+Pj4+Pj4gIHNlY3VyaXR5IGluIHNpdHVhdGlvbnMgd2hlcmUgdGhl IE5FVENPTkYgQWNjZXNzIENvbnRyb2wgTW9kZSBpcyBub3QNCj4+Pj4+PiAgYXZhaWxhYmxlLg0K Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFjZWU6ICJUaGlzIGlzIHRoZSBjb3JyZWN0IGludGVy cHJldGF0aW9uLiINCj4+Pj4+Pj4NCj4+Pj4+Pj4gL2ENCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcy4N Cj4+Pj4+Pg0KPj4+Pj4+IC0tDQo+Pj4+Pj4NCj4+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4+Pj4g S2F0aGxlZW4NCj4+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IC0tDQo+Pj4+DQo+Pj4+IEJl c3QgcmVnYXJkcywNCj4+Pj4gS2F0aGxlZW4NCj4+Pg0KPj4NCj4+IC0tDQo+PiBCcmlhbiBXZWlz DQo+PiBTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zDQo+PiBUZWxlcGhvbmU6ICsxIDQwOCA1 MjYgNDc5Ng0KPj4gRW1haWw6IGJld0BjaXNjby5jb20NCj4+DQo+DQo+DQo+DQo+LS0gDQo+DQo+ QmVzdCByZWdhcmRzLA0KPkthdGhsZWVuDQoNCg== From nobody Thu Apr 27 07:05:38 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76E612941C for ; Thu, 27 Apr 2017 07:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id De5nJilSzQWn for ; Thu, 27 Apr 2017 07:05:35 -0700 (PDT) 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 943BB12704B for ; Thu, 27 Apr 2017 07:05:35 -0700 (PDT) Received: from Orochi.local (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 v3RE5XBu090460 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 27 Apr 2017 09:05:34 -0500 (CDT) (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 Orochi.local Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Alia Atlas Cc: Kathleen Moriarty , Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , draft-ietf-rtgwg-yang-key-chain@ietf.org, "rtgwg@ietf.org" References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> From: Adam Roach Message-ID: Date: Thu, 27 Apr 2017 09:05:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:05:37 -0000 On 4/26/17 23:02, Alia Atlas wrote: > First, the YANG model is primarily for information in motion - either > for configuration to the device > or to read from the device. It is much less likely to represent the > data structure and storage in the device. > I believe that this draft's context is strictly for information in motion. Thanks; I understand all that. I'm trying to focus on the final paragraph of section 5, though, which appears to be an exception to what you say above. /a From nobody Thu Apr 27 07:16:09 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5FF1279EB; Thu, 27 Apr 2017 07:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqxIlZo6oug8; Thu, 27 Apr 2017 07:16:00 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F694126CC7; Thu, 27 Apr 2017 07:15:59 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id r190so19975156wme.1; Thu, 27 Apr 2017 07:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6xetieyuji6A+07NK9QEm8hAk1miTNf6z0WEcL3162Q=; b=ZmHIf4m0niEslbgGZ3fmDTYg5AAPPm/T/sRsP+AY7EqdDD//tuokVqp+svdFBPJ77U fJtKbSoAZrtwlSoDV8KQ7AzS+HWedBohqUT9V76BnwTBAdDdfKzgBqaXtDn7N6//a/Wj 4TL/QylKEREOVsCi3VHva6JMtDQy/0HxJFTayzqzQNRcFIdZT/zRtcVDf3e1EyT9OQiz ktQQXRgkrfSgrqBgi2jgkLTHmpma93ZxiGvatdFojhOhXOTZ9tVhPX0uGvobm6SnG+Nz tiKaOWS5OldXWvVsuCeR59Pc06IcMoRLQUSFLI+SoTfDhQdyAuZI9VFHnIUD/6VkP0Ca MUKQ== 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=6xetieyuji6A+07NK9QEm8hAk1miTNf6z0WEcL3162Q=; b=ABVl7QFQszHklsAjlEUZNz8U1tTwibIHBqhZNxq8SU1LFJD1anMR3BwNqmx//vz4qH r8pMmPRMyDunahkIKsN7XCXgb486qdsKBEYVhTJAaRWNn+17bp8TO0TmoQljioq6xPve noHGAngYPiz85DKeUVnqP55QcL5jKN02mHJ8jjJmqrtQTm8dgZF9cN4L2lF1aXotHkl0 RqoxOyu0vg8XbFrbKKDGfTOTFgiT99vWpb2TTcm3Zqgbb/wX2IdJpRr1xdxd/xo1Rlah EuwfvJlgV4tGNHZTVs+R+imTiHQqLfUFne8XvyhZ5dFBoc9I9LmdWfUEFDQ+2gR6m1St q9oA== X-Gm-Message-State: AN3rC/5TqavNcumYK2hUb7TmObQiEbzBwIaK/4JEu09Tkiw/4ANsndsV OzJLJTRqhIyUSXYomh45cZFNF30BndWf X-Received: by 10.28.19.6 with SMTP id 6mr2454873wmt.96.1493302557850; Thu, 27 Apr 2017 07:15:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.120 with HTTP; Thu, 27 Apr 2017 07:15:57 -0700 (PDT) In-Reply-To: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> From: Alia Atlas Date: Thu, 27 Apr 2017 10:15:57 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Adam Roach Cc: Kathleen Moriarty , Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , draft-ietf-rtgwg-yang-key-chain@ietf.org, "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=001a11468f0280c735054e269884 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:16:01 -0000 --001a11468f0280c735054e269884 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 27, 2017 at 10:05 AM, Adam Roach wrote: > On 4/26/17 23:02, Alia Atlas wrote: > >> First, the YANG model is primarily for information in motion - either for >> configuration to the device >> or to read from the device. It is much less likely to represent the >> data structure and storage in the device. >> I believe that this draft's context is strictly for information in motion. >> > > > Thanks; I understand all that. I'm trying to focus on the final paragraph > of section 5, though, which appears to be an exception to what you say > above. I don't understand why - IMHO, that paragraph is simply saying - this model passes keys around (in motion). Of course, a system shouldn't store such keys unencrypted. From what Acee says, this "motherhood and apple pie" additional advice was added due to secdir review. Regards, Alia > /a > > --001a11468f0280c735054e269884 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 27, 2017 at 10:05 AM, Adam Roach <adam@nostrum.com> w= rote:
On 4/26/17 23:02, = Alia Atlas wrote:
First, the YANG model is primarily for information in motion - either for c= onfiguration to the device
or to read from the device.=C2=A0 =C2=A0It is much less likely to represent= the data structure and storage in the device.
I believe that this draft's context is strictly for information in moti= on.


 Thanks; I understand all that. I'm trying to focus on the final paragra= ph of section 5, though, which appears to be an exception to what you say a= bove.

I don't understand why - IMHO, th= at paragraph is simply saying =C2=A0- this model passes keys around (in mot= ion).=C2=A0 Of course, a system shouldn't store such keys unencrypted.= =C2=A0 From what Acee says, this "motherhood and apple pie" addit= ional advice was added due to secdir review.

Regar= ds,
Alia

=C2=A0
/a


--001a11468f0280c735054e269884-- From nobody Thu Apr 27 07:17:54 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05E61279EB for ; Thu, 27 Apr 2017 07:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 FfGeYb4zlum0 for ; Thu, 27 Apr 2017 07:17:46 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E0C12952E for ; Thu, 27 Apr 2017 07:17:44 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l18so16210262ywh.3 for ; Thu, 27 Apr 2017 07:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=upw2q5JsRUzhmsW0znBQM1beEoTkEGs2HeV2CgSa4fc=; b=nfXbEU1/ofN3dkEPWZhI0eZ+KXMH45WsG9ig0wRYqnNRyb6AqTzHBVIiI/mTO7IO1m All7gaoZ07rR+s9xxa1tV7rVswcpg1IItyEYEFBlRwCuav45dMdniABqgsHp0xmnd6VZ 2JIVLGEpUFfSUuL8/Cm83ydt6+wmAWuMtZ03V5os6gxCkI+XP/DW42lluXOcQvnaPa1K UHIGHf9fKyFdfA1fny7Fc73Fc227D9AfRfKhVYRadyCgXl6Kbcm7EC7giLzacmtLuRod Hy+wAe/RO23FyWIfta/BmK4CowrNY6Tl9sE2kg2euc6WHgiGODoHkEqZpRFCOuM2gPaw /Ynw== 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=upw2q5JsRUzhmsW0znBQM1beEoTkEGs2HeV2CgSa4fc=; b=kFDsiSTgIl3p8oNAQ7kVkaO5sB7Y+sGCUwmOQwefvGrCer8LwnOfh0TSodkh2Sl0xD FM4qgwhiovUHNbHw/Sn+9VXqTsXVe115wFrKMAevBJpi+N+HNF6XOyqQheghECaXNKra La2Ucr16SLBtkiN06EoH9dGUDn6mGQMKDBzwk42bRw/zsh9K+gMkaFebobHCSv1wQo/6 p8BIemszf8DSubY28mq4AtXCdynvnZb3SCAJ2cekrJO/JXULoNFA1G+vh+jbbUTvzJmK YZBEJLO9VTcX2Pkv52WLz5EL1U8B30ZTTxY4wF8gP26UZejkTgAszB1mXvFVxSIjwNXF laWQ== X-Gm-Message-State: AN3rC/7pL9D3oB49dzs1ZViCBQaWu4fZ3UYWBWbguzrMb/sACrK78tt1 FrBW5CdQ48vqINfIslhf32Ht3O6HGg== X-Received: by 10.129.95.68 with SMTP id t65mr4657137ywb.74.1493302663346; Thu, 27 Apr 2017 07:17:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 27 Apr 2017 07:17:02 -0700 (PDT) In-Reply-To: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> From: Eric Rescorla Date: Thu, 27 Apr 2017 07:17:02 -0700 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Alia Atlas Cc: Adam Roach , "rtgwg-chairs@ietf.org" , draft-ietf-rtgwg-yang-key-chain@ietf.org, Kathleen Moriarty , The IESG , Jeff Tantsura , "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=001a1147e56eca9f75054e269e67 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:17:47 -0000 --001a1147e56eca9f75054e269e67 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 27, 2017 at 7:15 AM, Alia Atlas wrote: > On Thu, Apr 27, 2017 at 10:05 AM, Adam Roach wrote: > >> On 4/26/17 23:02, Alia Atlas wrote: >> >>> First, the YANG model is primarily for information in motion - either >>> for configuration to the device >>> or to read from the device. It is much less likely to represent the >>> data structure and storage in the device. >>> I believe that this draft's context is strictly for information in >>> motion. >>> >> >> >> Thanks; I understand all that. I'm trying to focus on the final paragraph >> of section 5, though, which appears to be an exception to what you say >> above. > > > I don't understand why - IMHO, that paragraph is simply saying - this > model passes keys around (in motion). Of course, a system shouldn't store > such keys unencrypted. From what Acee says, this "motherhood and apple > pie" additional advice was added due to secdir review. > I thought Adam's point was that storing keys encrypted with a key that's adjacent to them was not useful. -Ekr > > Regards, > Alia > > > >> /a >> >> > --001a1147e56eca9f75054e269e67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 27, 2017 at 7:15 AM, Alia Atlas <akatlas@gmail.com>= wrote:
On Thu, Apr 27, 2017 at = 10:05 AM, Adam Roach <adam@nostrum.com> wrote:
On 4/26/17 23:02, Alia Atlas wrote:
First, the YANG model is primarily for information in motion - either for c= onfiguration to the device
or to read from the device.=C2=A0 =C2=A0It is much less likely to represent= the data structure and storage in the device.
I believe that this draft's context is strictly for information in moti= on.


 Thanks; I understand all that. I'm trying to focus on the final paragra= ph of section 5, though, which appears to be an exception to what you say a= bove.

I don't understand why - I= MHO, that paragraph is simply saying =C2=A0- this model passes keys around = (in motion).=C2=A0 Of course, a system shouldn't store such keys unencr= ypted.=C2=A0 From what Acee says, this "motherhood and apple pie"= additional advice was added due to secdir review.
<= /blockquote>

I thought Adam's point was that storing= keys encrypted with a key that's adjacent to them was not useful.

-Ekr
=C2=A0
=

Regards,
Alia

=C2=A0=
/a



--001a1147e56eca9f75054e269e67-- From nobody Thu Apr 27 07:21:29 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38461294EE; Thu, 27 Apr 2017 07:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DI9AzLD84_ur; Thu, 27 Apr 2017 07:21:19 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 56E2C126CC7; Thu, 27 Apr 2017 07:21:19 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id l50so18086097wrc.3; Thu, 27 Apr 2017 07:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2D27RQoOLz/E5PtYK8GmdZfqsUbWkoW0OJBZtOogBgI=; b=VHCuvTN+T7Zkr9kSYpeFN7Qnc0g+jTdrsrrEfA0ZeEhCBIACcZ7jmikdW0VyG5y504 o5ob1qI8rdgzR2dFusY/+uS0rSgfJqUZ9ms2J2OalXsOGVt9K0Es9tt8AbXwGllsjqeR Vld0IDsntlna0ONGMz4dJajST3Y1pwJ+a9gmx73yH3Yo/EKq4FpCbbNKTBA3n7D5438X 1BIAiBYfauC3goEnwtBIgchqOF+DkSh8idBm97TxewKLLLNtH3SprLeKlMWVajeyg1ux jlpcZNEQlgr7W7WIs+sId+ZqAHLOguFqOQ2ugsP4KMyII/avEdYcD9Y2n8qDrVTsxDtV hTng== 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=2D27RQoOLz/E5PtYK8GmdZfqsUbWkoW0OJBZtOogBgI=; b=NjM1hM7COg3M/qu5UTSHEjpjs/+BQPC+gQSKroDEFD1dKjeBiBMwbPLckmzvF9G2zn 9ealYUzLZrDJjcNOda30N91LugJh6VmjomWi1DrHzpkqjyqIHG8Qed56sXXEsK2AUs0r 8KIwdeqAWIkTp7cptU7hr4Mp0iWh1BUT75ez31Q7kevTC6EXhHsnhw+U2fCXeCApPHrA PMtEVTdRvdVg0ZcGwmZEAWLMU3amNyqQQDdmAI3a3I6eMHWZLcz3NDo1mlMBljP8A7/h j9Wh54BNb327a8BGwD1AvQzBuEhXCDiQuVq+ER8cOT8xaqPtrU1EUKy0V4MuywGgkdiB oGUg== X-Gm-Message-State: AN3rC/5FEdr5DVU4gKV4+DWY4P8y8h0wOmSogkLVDXa16g2muBzhvV3r G/xSOhhbAosT4c+yyAHyZFm3dL8wrA== X-Received: by 10.223.148.5 with SMTP id 5mr847674wrq.44.1493302877658; Thu, 27 Apr 2017 07:21:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.120 with HTTP; Thu, 27 Apr 2017 07:21:16 -0700 (PDT) In-Reply-To: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> From: Alia Atlas Date: Thu, 27 Apr 2017 10:21:16 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Eric Rescorla Cc: Adam Roach , "rtgwg-chairs@ietf.org" , draft-ietf-rtgwg-yang-key-chain@ietf.org, Kathleen Moriarty , The IESG , Jeff Tantsura , "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0d22ee90a535054e26abac Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:21:20 -0000 --94eb2c0d22ee90a535054e26abac Content-Type: text/plain; charset=UTF-8 On Thu, Apr 27, 2017 at 10:17 AM, Eric Rescorla wrote: > > > On Thu, Apr 27, 2017 at 7:15 AM, Alia Atlas wrote: > >> On Thu, Apr 27, 2017 at 10:05 AM, Adam Roach wrote: >> >>> On 4/26/17 23:02, Alia Atlas wrote: >>> >>>> First, the YANG model is primarily for information in motion - either >>>> for configuration to the device >>>> or to read from the device. It is much less likely to represent the >>>> data structure and storage in the device. >>>> I believe that this draft's context is strictly for information in >>>> motion. >>>> >>> >>> >>> Thanks; I understand all that. I'm trying to focus on the final >>> paragraph of section 5, though, which appears to be an exception to what >>> you say above. >> >> >> I don't understand why - IMHO, that paragraph is simply saying - this >> model passes keys around (in motion). Of course, a system shouldn't store >> such keys unencrypted. From what Acee says, this "motherhood and apple >> pie" additional advice was added due to secdir review. >> > > I thought Adam's point was that storing keys encrypted with a key that's > adjacent to them was not useful. > This is not at all in scope for this document. It isn't giving implementation-specific advice on how to manage and store keys. It is providing a model to configure and read keys. Alia > -Ekr > > >> >> Regards, >> Alia >> >> >> >>> /a >>> >>> >> > --94eb2c0d22ee90a535054e26abac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 27, 2017 at 10:17 AM, Eric Rescorla <ekr@rtfm.com> wrot= e:


On Thu, Apr 27, 2= 017 at 7:15 AM, Alia Atlas <akatlas@gmail.com> wrote:
On Thu, Apr 27, 2017 at 10:05 AM, Adam Roach = <adam@nostrum.com> wrote:
<= span>On 4/26/17 23:02, Alia Atlas wrote:
First, the YANG model is primarily for information in motion - either for c= onfiguration to the device
or to read from the device.=C2=A0 =C2=A0It is much less likely to represent= the data structure and storage in the device.
I believe that this draft's context is strictly for information in moti= on.


Thanks; I understand all that. I'm trying to focus on the final paragra= ph of section 5, though, which appears to be an exception to what you say a= bove.

I don't understand why - I= MHO, that paragraph is simply saying =C2=A0- this model passes keys around = (in motion).=C2=A0 Of course, a system shouldn't store such keys unencr= ypted.=C2=A0 From what Acee says, this "motherhood and apple pie"= additional advice was added due to secdir review.
<= /blockquote>

I thought Adam's point was that = storing keys encrypted with a key that's adjacent to them was not usefu= l.

This is not at a= ll in scope for this document.=C2=A0 It isn't giving implementation-spe= cific advice on how to manage and store keys.
It is providing a m= odel to configure and read keys.

Alia
=C2=A0
-Ekr
=C2=A0

Regards,=
Alia

=C2=A0
/a




--94eb2c0d22ee90a535054e26abac-- From nobody Thu Apr 27 07:23:52 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E968129530; Thu, 27 Apr 2017 07:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sE2vNyLodOeA; Thu, 27 Apr 2017 07:23:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59172129535; Thu, 27 Apr 2017 07:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12541; q=dns/txt; s=iport; t=1493303020; x=1494512620; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VWqwB4U6c4SeK2BwTGDz9FpxlsvtnhIXK2Ndxc5egzo=; b=T2GHIX2mwjXy9arbAlDZW91eHkapR2M7cl2tjeG4zEG0+ZsGXiI5KlzX taF2c3kPhzLMYvBc5QdxckDBDzMcUNsmr3641aQyIVhEisGAKNDdb0B8Z f+suXPj1/PsmGdfpZYE//q7FOCSsgDZ/7fAzqo/tFnuIQlgh1/jMhCrrG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQCG/gFZ/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5ngW0Hg2GKGJFKiCKIE4U3gg+GJAIahAE/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRUBAQEBAyNWEAIBCA4DAwECKAMCAgIfERQJCAIEAQ0FigUDFaxvgiaHMA2DX?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBAR2IMoMaglOBeDQYgk6CXwWdFTsBjj+ETII?= =?us-ascii?q?CiRyGQIsZiQ0BHziBCm8VhWqBSnUBhlCBL4ENAQEB?= X-IronPort-AV: E=Sophos; i="5.37,384,1488844800"; d="scan'208,217"; a="20435817" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2017 14:23:19 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3RENJIx026638 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Apr 2017 14:23:19 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Apr 2017 10:23:18 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 27 Apr 2017 10:23:18 -0400 From: "Acee Lindem (acee)" To: Eric Rescorla , Alia Atlas CC: Adam Roach , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Kathleen Moriarty , The IESG , Jeff Tantsura , "rtgwg@ietf.org" Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) Thread-Index: AQHSvv7NaK6mr1jQpUuQYLHDV2KBn6HYydWAgAARVgCAAKiLAIAAAu6AgAAATQD//76sgA== Date: Thu, 27 Apr 2017 14:23:18 +0000 Message-ID: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: multipart/alternative; boundary="_000_D5277644ABE74aceeciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:23:42 -0000 --_000_D5277644ABE74aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29t Pj4NCkRhdGU6IFRodXJzZGF5LCBBcHJpbCAyNywgMjAxNyBhdCAxMDoxNyBBTQ0KVG86IEFsaWEg QXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzpha2F0bGFzQGdtYWlsLmNvbT4+DQpDYzog QWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+LCAi cnRnd2ctY2hhaXJzQGlldGYub3JnPG1haWx0bzpydGd3Zy1jaGFpcnNAaWV0Zi5vcmc+IiA8cnRn d2ctY2hhaXJzQGlldGYub3JnPG1haWx0bzpydGd3Zy1jaGFpcnNAaWV0Zi5vcmc+PiwgImRyYWZ0 LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW5AaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtcnRn d2cteWFuZy1rZXktY2hhaW5AaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1j aGFpbkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbkBpZXRm Lm9yZz4+LCBLYXRobGVlbiBNb3JpYXJ0eSA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5j b208bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPj4sIFRoZSBJRVNHIDxp ZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPj4sIEplZmYgVGFudHN1cmEgPGplZmZ0 YW50LmlldGZAZ21haWwuY29tPG1haWx0bzpqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4+LCBSb3V0 aW5nIFdHIDxydGd3Z0BpZXRmLm9yZzxtYWlsdG86cnRnd2dAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IEthdGhsZWVuIE1vcmlhcnR5J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmct a2V5LWNoYWluLTIwOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KUmVzZW50LUZyb206IDxh bGlhcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphbGlhcy1ib3VuY2VzQGlldGYub3JnPj4NClJl c2VudC1UbzogQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNv bT4+LCBKZWZmcmV5IFpoYW5nIDx6emhhbmdAanVuaXBlci5uZXQ8bWFpbHRvOnp6aGFuZ0BqdW5p cGVyLm5ldD4+LCBEZXJlayBZZXVuZyA8ZGVyZWtAYXJyY3VzLmNvbTxtYWlsdG86ZGVyZWtAYXJy Y3VzLmNvbT4+LCBZaW5nemhlbiBRdSA8eWluZ3poZW4ucXVAaHVhd2VpLmNvbTxtYWlsdG86eWlu Z3poZW4ucXVAaHVhd2VpLmNvbT4+LCBJbmctV2hlciBDaGVuIDxJbmctV2hlcl9DaGVuQGphYmls LmNvbTxtYWlsdG86SW5nLVdoZXJfQ2hlbkBqYWJpbC5jb20+Pg0KUmVzZW50LURhdGU6IFRodXJz ZGF5LCBBcHJpbCAyNywgMjAxNyBhdCAxMDoxNyBBTQ0KDQoNCg0KT24gVGh1LCBBcHIgMjcsIDIw MTcgYXQgNzoxNSBBTSwgQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFrYXRs YXNAZ21haWwuY29tPj4gd3JvdGU6DQpPbiBUaHUsIEFwciAyNywgMjAxNyBhdCAxMDowNSBBTSwg QWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+IHdy b3RlOg0KT24gNC8yNi8xNyAyMzowMiwgQWxpYSBBdGxhcyB3cm90ZToNCkZpcnN0LCB0aGUgWUFO RyBtb2RlbCBpcyBwcmltYXJpbHkgZm9yIGluZm9ybWF0aW9uIGluIG1vdGlvbiAtIGVpdGhlciBm b3IgY29uZmlndXJhdGlvbiB0byB0aGUgZGV2aWNlDQpvciB0byByZWFkIGZyb20gdGhlIGRldmlj ZS4gICBJdCBpcyBtdWNoIGxlc3MgbGlrZWx5IHRvIHJlcHJlc2VudCB0aGUgZGF0YSBzdHJ1Y3R1 cmUgYW5kIHN0b3JhZ2UgaW4gdGhlIGRldmljZS4NCkkgYmVsaWV2ZSB0aGF0IHRoaXMgZHJhZnQn cyBjb250ZXh0IGlzIHN0cmljdGx5IGZvciBpbmZvcm1hdGlvbiBpbiBtb3Rpb24uDQoNCg0KVGhh bmtzOyBJIHVuZGVyc3RhbmQgYWxsIHRoYXQuIEknbSB0cnlpbmcgdG8gZm9jdXMgb24gdGhlIGZp bmFsIHBhcmFncmFwaCBvZiBzZWN0aW9uIDUsIHRob3VnaCwgd2hpY2ggYXBwZWFycyB0byBiZSBh biBleGNlcHRpb24gdG8gd2hhdCB5b3Ugc2F5IGFib3ZlLg0KDQpJIGRvbid0IHVuZGVyc3RhbmQg d2h5IC0gSU1ITywgdGhhdCBwYXJhZ3JhcGggaXMgc2ltcGx5IHNheWluZyAgLSB0aGlzIG1vZGVs IHBhc3NlcyBrZXlzIGFyb3VuZCAoaW4gbW90aW9uKS4gIE9mIGNvdXJzZSwgYSBzeXN0ZW0gc2hv dWxkbid0IHN0b3JlIHN1Y2gga2V5cyB1bmVuY3J5cHRlZC4gIEZyb20gd2hhdCBBY2VlIHNheXMs IHRoaXMgIm1vdGhlcmhvb2QgYW5kIGFwcGxlIHBpZSIgYWRkaXRpb25hbCBhZHZpY2Ugd2FzIGFk ZGVkIGR1ZSB0byBzZWNkaXIgcmV2aWV3Lg0KDQpJIHRob3VnaHQgQWRhbSdzIHBvaW50IHdhcyB0 aGF0IHN0b3Jpbmcga2V5cyBlbmNyeXB0ZWQgd2l0aCBhIGtleSB0aGF0J3MgYWRqYWNlbnQgdG8g dGhlbSB3YXMgbm90IHVzZWZ1bC4NCg0KUmlnaHQuIEnigJltIG5vdCBzdXJlIHdoYXQgdGhlIGRl ZmluaXRpb24gb2Yg4oCcYWRqYWNlbnTigJ0gaXMgaGVyZSBzaW5jZSBpdCBpcyB2ZXJ5IGltcGxl bWVudGF0aW9uIHNwZWNpZmljLiBJIHdpbGwgcmVtb3ZlIHRoZSBmaW5hbCBwYXJhZ3JhcGggaW4g dGhlIG5leHQgcmV2aXNpb24gd2hlbiBJIGFkZCBLRUsgYmFjayAoYXNzdW1pbmcgd2UgY2FuIGFn cmVlIG9uIHJlYXNvbmFibGUgZ3VpZGFuY2UgYW5kIHdoaWNoIFJGQyB0byByZWZlcmVuY2UpLiBX aGF0IEnigJltIHN0cm9uZ2x5IG9wcG9zZWQgdG8gaXMgcHVzaGluZyB0aGlzIGJhY2sgaW4gdGhl IHByb2Nlc3MgZm9yIHN1Y2ggYSBjaGFuZ2UuDQoNCkFjZWUNCg0KDQotRWtyDQoNCg0KUmVnYXJk cywNCkFsaWENCg0KDQovYQ0KDQoNCg0K --_000_D5277644ABE74aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxp Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5LCBBcHJpbCAyNywgMjAx NyBhdCAxMDoxNyBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9z cGFuPkFsaWEgQXRsYXMgJmx0OzxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+YWth dGxhc0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5DYzogPC9zcGFuPkFkYW0gUm9hY2ggJmx0OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0u Y29tIj5hZGFtQG5vc3RydW0uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpydGd3 Zy1jaGFpcnNAaWV0Zi5vcmciPnJ0Z3dnLWNoYWlyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpydGd3Zy1jaGFpcnNAaWV0Zi5vcmciPnJ0Z3dnLWNoYWlyc0BpZXRmLm9y ZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtl eS1jaGFpbkBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLWtleS1jaGFpbkBpZXRmLm9y ZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcnRnd2cteWFuZy1r ZXktY2hhaW5AaWV0Zi5vcmciPmRyYWZ0LWlldGYtcnRnd2cteWFuZy1rZXktY2hhaW5AaWV0Zi5v cmc8L2E+Jmd0OywgS2F0aGxlZW4gTW9yaWFydHkgJmx0OzxhIGhyZWY9Im1haWx0bzprYXRobGVl bi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSI+a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5j b208L2E+Jmd0OywgVGhlIElFU0cgJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIj5p ZXNnQGlldGYub3JnPC9hPiZndDssDQogSmVmZiBUYW50c3VyYSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmplZmZ0YW50LmlldGZAZ21haWwuY29tIj5qZWZmdGFudC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7 LCBSb3V0aW5nIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cnRnd2dAaWV0Zi5vcmciPnJ0Z3dnQGll dGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVj dDogPC9zcGFuPlJlOiBLYXRobGVlbiBNb3JpYXJ0eSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1y dGd3Zy15YW5nLWtleS1jaGFpbi0yMDogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+UmVzZW50LUZyb206IDwvc3Bhbj4mbHQ7PGEg aHJlZj0ibWFpbHRvOmFsaWFzLWJvdW5jZXNAaWV0Zi5vcmciPmFsaWFzLWJvdW5jZXNAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5SZXNlbnQtVG86 IDwvc3Bhbj5BY2VlIExpbmRlbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29tIj5h Y2VlQGNpc2NvLmNvbTwvYT4mZ3Q7LCBKZWZmcmV5IFpoYW5nICZsdDs8YSBocmVmPSJtYWlsdG86 enpoYW5nQGp1bmlwZXIubmV0Ij56emhhbmdAanVuaXBlci5uZXQ8L2E+Jmd0OywgRGVyZWsgWWV1 bmcgJmx0OzxhIGhyZWY9Im1haWx0bzpkZXJla0BhcnJjdXMuY29tIj5kZXJla0BhcnJjdXMuY29t PC9hPiZndDssDQogWWluZ3poZW4gUXUgJmx0OzxhIGhyZWY9Im1haWx0bzp5aW5nemhlbi5xdUBo dWF3ZWkuY29tIj55aW5nemhlbi5xdUBodWF3ZWkuY29tPC9hPiZndDssIEluZy1XaGVyIENoZW4g Jmx0OzxhIGhyZWY9Im1haWx0bzpJbmctV2hlcl9DaGVuQGphYmlsLmNvbSI+SW5nLVdoZXJfQ2hl bkBqYWJpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5S ZXNlbnQtRGF0ZTogPC9zcGFuPlRodXJzZGF5LCBBcHJpbCAyNywgMjAxNyBhdCAxMDoxNyBBTTxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBz b2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2IGRpcj0ibHRyIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgQXByIDI3LCAyMDE3IGF0IDc6MTUgQU0sIEFsaWEg QXRsYXMgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFrYXRsYXNAZ21haWwuY29tPC9hPiZndDs8L3NwYW4+IHdy b3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow IDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0K PGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+PHNwYW4+T24gVGh1LCBBcHIgMjcsIDIwMTcgYXQgMTA6MDUgQU0sIEFkYW0g Um9hY2ggPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0u Y29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhbUBub3N0cnVtLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90 ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxz cGFuPk9uIDQvMjYvMTcgMjM6MDIsIEFsaWEgQXRsYXMgd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpGaXJzdCwgdGhlIFlBTkcgbW9kZWwg aXMgcHJpbWFyaWx5IGZvciBpbmZvcm1hdGlvbiBpbiBtb3Rpb24gLSBlaXRoZXIgZm9yIGNvbmZp Z3VyYXRpb24gdG8gdGhlIGRldmljZTxicj4NCm9yIHRvIHJlYWQgZnJvbSB0aGUgZGV2aWNlLiZu YnNwOyAmbmJzcDtJdCBpcyBtdWNoIGxlc3MgbGlrZWx5IHRvIHJlcHJlc2VudCB0aGUgZGF0YSBz dHJ1Y3R1cmUgYW5kIHN0b3JhZ2UgaW4gdGhlIGRldmljZS48YnI+DQpJIGJlbGlldmUgdGhhdCB0 aGlzIGRyYWZ0J3MgY29udGV4dCBpcyBzdHJpY3RseSBmb3IgaW5mb3JtYXRpb24gaW4gbW90aW9u Ljxicj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjxicj4NCjwvc3Bhbj5UaGFua3M7IEkgdW5kZXJz dGFuZCBhbGwgdGhhdC4gSSdtIHRyeWluZyB0byBmb2N1cyBvbiB0aGUgZmluYWwgcGFyYWdyYXBo IG9mIHNlY3Rpb24gNSwgdGhvdWdoLCB3aGljaCBhcHBlYXJzIHRvIGJlIGFuIGV4Y2VwdGlvbiB0 byB3aGF0IHlvdSBzYXkgYWJvdmUuPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwv c3Bhbj4NCjxkaXY+SSBkb24ndCB1bmRlcnN0YW5kIHdoeSAtIElNSE8sIHRoYXQgcGFyYWdyYXBo IGlzIHNpbXBseSBzYXlpbmcgJm5ic3A7LSB0aGlzIG1vZGVsIHBhc3NlcyBrZXlzIGFyb3VuZCAo aW4gbW90aW9uKS4mbmJzcDsgT2YgY291cnNlLCBhIHN5c3RlbSBzaG91bGRuJ3Qgc3RvcmUgc3Vj aCBrZXlzIHVuZW5jcnlwdGVkLiZuYnNwOyBGcm9tIHdoYXQgQWNlZSBzYXlzLCB0aGlzICZxdW90 O21vdGhlcmhvb2QgYW5kIGFwcGxlIHBpZSZxdW90OyBhZGRpdGlvbmFsIGFkdmljZSB3YXMgYWRk ZWQgZHVlDQogdG8gc2VjZGlyIHJldmlldy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgdGhvdWdodCBBZGFtJ3Mg cG9pbnQgd2FzIHRoYXQgc3RvcmluZyBrZXlzIGVuY3J5cHRlZCB3aXRoIGEga2V5IHRoYXQncyBh ZGphY2VudCB0byB0aGVtIHdhcyBub3QgdXNlZnVsLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlJpZ2h0LiBJ4oCZbSBub3Qgc3VyZSB3aGF0IHRoZSBkZWZpbml0aW9uIG9m IOKAnGFkamFjZW504oCdIGlzIGhlcmUgc2luY2UgaXQgaXMgdmVyeSBpbXBsZW1lbnRhdGlvbiBz cGVjaWZpYy4gSSB3aWxsIHJlbW92ZSB0aGUgZmluYWwgcGFyYWdyYXBoIGluIHRoZSBuZXh0IHJl dmlzaW9uIHdoZW4gSSBhZGQgS0VLIGJhY2sgKGFzc3VtaW5nIHdlIGNhbiBhZ3JlZSBvbiByZWFz b25hYmxlIGd1aWRhbmNlIGFuZCB3aGljaCBSRkMgdG8gcmVmZXJlbmNlKS4NCiBXaGF0IEnigJlt IHN0cm9uZ2x5IG9wcG9zZWQgdG8gaXMgcHVzaGluZyB0aGlzIGJhY2sgaW4gdGhlIHByb2Nlc3Mg Zm9yIHN1Y2ggYSBjaGFuZ2UuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5B Y2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9E WV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAg MCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pi1Fa3I8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPg0K PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+QWxpYTwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxzcGFuIGNsYXNzPSJtXzgzNjk1OTg3MTk1MjMwMjU4 MThtXzQwNzU4Nzk3MzU3NDc3NjM4NjRIT0VuWmIiPjxmb250IGNvbG9yPSIjODg4ODg4Ij4vYTxi cj4NCjxicj4NCjwvZm9udD48L3NwYW4+PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_D5277644ABE74aceeciscocom_-- From nobody Thu Apr 27 07:29:40 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3DD129ADC for ; Thu, 27 Apr 2017 07:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 aKw9BbwYiOLI for ; Thu, 27 Apr 2017 07:29:35 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BCC1295A0 for ; Thu, 27 Apr 2017 07:28:43 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id 203so16366237ywe.0 for ; Thu, 27 Apr 2017 07:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R1a8iwLwWEmaP8DO10SkkOYBbG4/Yud2Zcd84RQq5Zk=; b=mrT6adDi8qOI0xdq/Ex500CY0d/7luZyIv3vfG4cbSv+ijEz8CbJVdmaGivX0KDX3e Cfwaie+Wlqmqe+ynDqhFYXtsFA9wBUetUqNHYDlVjW3OQ3yhKbXl8oCytBq4SgRAjCID IYFSHDk+i+Mzq8utw0KdxJPjJOgG0vRZ5gkbCdLtErfBXEQ0dm3TiopbicQm/gbPWWTl bangF2ix74P44saFX4PdGrYzOlOgic8Uub5/8mIaibAtlroyoGOkZi3njMdQEspXxhxY 6w46GQGvlk4A5fguvrikPxm21F39zjidhi+hje3Vkm+xiGk2QmzqzPPosBp7DOhvS0HH 0T9g== 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=R1a8iwLwWEmaP8DO10SkkOYBbG4/Yud2Zcd84RQq5Zk=; b=aHAGxenzGiufaaMfGNZP99XZbjvs5iV3yi85yiv6hvuCza+GVnKoV/1xyhZ5VyH+k2 oXYlB+KVwxvley+qIMFRdID0171dA73scByoQkA7qRRPb0P5LKLPCyH+7l0pbufNdaim dXGhLAUVOIZJb51gH6XxHuCwke9dA40yPjYYPU/s1QQNuSvobfWSkah3RPtOAWRkE9Vs savK87vYWxZln84F44pU5kkIU1DQuUvfviHwVxdy+pVyK8pt3LUjHGE/VNK7wbTKXNkN rW96wCW62yT2fSM+MUYeRZxN+8zSGH+vpY/xG3FQjcA0Y47uGDlff37Vz0V5RijNrlpF JQGQ== X-Gm-Message-State: AN3rC/4mfn4gL0tVj2FjBAgtWyeni559BKeBlCUXphUsWOCkQjU9ZM78 NYOcN1EgtA/ECf/x50AQjoT9PMbq3w== X-Received: by 10.129.146.2 with SMTP id j2mr4851776ywg.3.1493303322379; Thu, 27 Apr 2017 07:28:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 27 Apr 2017 07:28:01 -0700 (PDT) In-Reply-To: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> From: Eric Rescorla Date: Thu, 27 Apr 2017 07:28:01 -0700 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: "Acee Lindem (acee)" Cc: Alia Atlas , Adam Roach , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , Kathleen Moriarty , The IESG , Jeff Tantsura , "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c093d1e12b45d054e26c62a Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:29:38 -0000 --94eb2c093d1e12b45d054e26c62a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 27, 2017 at 7:23 AM, Acee Lindem (acee) wrote: > > > From: Eric Rescorla > Date: Thursday, April 27, 2017 at 10:17 AM > To: Alia Atlas > Cc: Adam Roach , "rtgwg-chairs@ietf.org" < > rtgwg-chairs@ietf.org>, "draft-ietf-rtgwg-yang-key-chain@ietf.org" < > draft-ietf-rtgwg-yang-key-chain@ietf.org>, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com>, The IESG , Jeff > Tantsura , Routing WG > Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-cha= in-20: > (with DISCUSS and COMMENT) > Resent-From: > Resent-To: Acee Lindem , Jeffrey Zhang , > Derek Yeung , Yingzhen Qu , > Ing-Wher Chen > Resent-Date: Thursday, April 27, 2017 at 10:17 AM > > > > On Thu, Apr 27, 2017 at 7:15 AM, Alia Atlas wrote: > >> On Thu, Apr 27, 2017 at 10:05 AM, Adam Roach wrote: >> >>> On 4/26/17 23:02, Alia Atlas wrote: >>> >>>> First, the YANG model is primarily for information in motion - either >>>> for configuration to the device >>>> or to read from the device. It is much less likely to represent the >>>> data structure and storage in the device. >>>> I believe that this draft's context is strictly for information in >>>> motion. >>>> >>> >>> >>> Thanks; I understand all that. I'm trying to focus on the final >>> paragraph of section 5, though, which appears to be an exception to wha= t >>> you say above. >> >> >> I don't understand why - IMHO, that paragraph is simply saying - this >> model passes keys around (in motion). Of course, a system shouldn't sto= re >> such keys unencrypted. From what Acee says, this "motherhood and apple >> pie" additional advice was added due to secdir review. >> > > I thought Adam's point was that storing keys encrypted with a key that's > adjacent to them was not useful. > > > Right. I=E2=80=99m not sure what the definition of =E2=80=9Cadjacent=E2= =80=9D is here since it is > very implementation specific. I will remove the final paragraph in the ne= xt > revision when I add KEK back (assuming we can agree on reasonable guidanc= e > and which RFC to reference). What I=E2=80=99m strongly opposed to is push= ing this > back in the process for such a change. > I'm not arguing for any particular outcome, merely making a technical observation about what is and is not useful from a security perspective. -Ekr > Acee > > > -Ekr > > >> >> Regards, >> Alia >> >> >> >>> /a >>> >>> >> > --94eb2c093d1e12b45d054e26c62a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 27, 2017 at 7:23 AM, Acee Lindem (acee) &= lt;acee@cisco.com&g= t; wrote:


From: Eric Rescorla <ekr@rtfm.com>
Date: Thursday, April 27, 2017 at 1= 0:17 AM
To: Alia Atlas <akatlas@gmail.com>
Cc: Adam Roach <adam@nostrum.com>, "rtgwg-chairs@ietf.org= " <r= tgwg-chairs@ietf.org>, "draft-ietf-rtgwg-yang-key-chain= @ietf.org" <draft-ietf-rtgwg-yang-key-chain@ietf.org>, Kathleen Mor= iarty <kathleen.moriarty.ietf@gmail.com>, The IESG <iesg@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, Routing WG <rtgwg@ietf.org>
Subject: Re: Kathleen Moriarty'= s Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COM= MENT)
Resent-From: <alias-bounces@ietf.org> Resent-To: Acee Lindem <acee@cisco.com>, Jeffre= y Zhang <zzhang@= juniper.net>, Derek Yeung <derek@arrcus.com>, Yingzhen Qu <yingzhen.qu@huawei.com>, Ing-Wher Chen <Ing-Wher_Chen@jabil.com>
Resent-Date: Thursday, April 27, 20= 17 at 10:17 AM



On Thu, Apr 27, 2017 at 7:15 AM, Alia Atlas <akatlas@gmail.co= m> wrote:
On Thu, Apr 27, 2017 at 10:05 AM, Adam Roa= ch <adam@nostrum.com<= /a>> wrote:
On 4/26/17 23:02, Alia Atlas wrote:
First, the YANG model is primarily for information in motion - either for c= onfiguration to the device
or to read from the device.=C2=A0 =C2=A0It is much less likely to represent= the data structure and storage in the device.
I believe that this draft's context is strictly for information in moti= on.


Thanks; I understand all that. I'm trying to focus on the final = paragraph of section 5, though, which appears to be an exception to what yo= u say above.
I don't understand why - IMHO, that paragraph is simply saying =C2= =A0- this model passes keys around (in motion).=C2=A0 Of course, a system s= houldn't store such keys unencrypted.=C2=A0 From what Acee says, this &= quot;motherhood and apple pie" additional advice was added due to secdir review.

I thought Adam's point was that storing keys encrypted with a key = that's adjacent to them was not useful.

Right. I=E2=80=99m not sure what the definition of =E2=80=9Cadjacent= =E2=80=9D is here since it is very implementation specific. I will remove t= he final paragraph in the next revision when I add KEK back (assuming we ca= n agree on reasonable guidance and which RFC to reference). What I=E2=80=99m strongly opposed to is pushing this back in the process f= or such a change.=C2=A0



Acee=C2=A0


-Ekr
=C2=A0

Regards,
Alia

=C2=A0
/a

--94eb2c093d1e12b45d054e26c62a-- From nobody Thu Apr 27 08:13:09 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00153129AC7; Thu, 27 Apr 2017 08:13:01 -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, 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 lr0u7g5X-MsN; Thu, 27 Apr 2017 08:12:59 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1907B12960D; Thu, 27 Apr 2017 08:11:56 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id c198so29757324pfc.1; Thu, 27 Apr 2017 08:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eSCoGY1r2ZQN9qlwXg7+RQbUn3HsWlBg2wOAc9wEL60=; b=dui/+9bUe1aPuLhGkUJHZN4+wofhLzXdmWl8em/9QooKhwCk5w1d0G3NUhNNFbFeK2 cRYknqhgrc12epPsdozSzi2dS5brrLctWBJruFmsXTNDb6EimvI3I1YPwW3yltH02Yf6 Iqqv9BZf3BtBmXd/Z3IF8656Lhs9GoK5SSiNRPgsYk0GpPHgMNjeVC1+cdcWdOkXhhgw A8SZ2Z1JLcwY0bmxbAJuvGJAIR01qDIaGTV/zXKvL7969E6wjSgdMOf2NtqDQvtOKgJp sKU3h1s2ybcZ/6jeMDKpHt3LfZzYBnQ6GB0xd1e5EwxYkLycVjEIZMAkEcOiyDV1Tooq HRvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eSCoGY1r2ZQN9qlwXg7+RQbUn3HsWlBg2wOAc9wEL60=; b=b5xZVZOVhz3tBmlMeScCqSpZh1tbrG6ntsFXl4HQ3pnR+ecmfcGe5uHWr4XM+XpigT GVEdsYhmlTuFea6YdAVdUL4CuIK4Gx1nS4jooCLanWIpkOjB9XG2rmMUOk89Z3y0hHd7 mNmwoafUFqwuFl8rqDvQHW+0K316daC+fTPI0QbHndjaKxZ7gcJFgyTQpGI7+sFtCQS9 dBEfaRbgB9Vz6oTvc0dVyrirArI6c01jjH1F4VfCFGZ99fjRaTS/roc/eOpsKKEHZwP9 fAHbHy6Gh5g5tPEJKUPGfh73fAxYQYGURh3q1nc/S6mJwRaZq9gD7W/u2P3GIZdwLBV8 hXgA== X-Gm-Message-State: AN3rC/7vvdYa38kK7lVTI2OyMF7TcgRsxESbZSEzeZCQhRc8FWTIfa5A 8ZMTRcdvB4QfLY8jRGqX5gX+sNfu8A== X-Received: by 10.99.160.73 with SMTP id u9mr6381016pgn.176.1493305915483; Thu, 27 Apr 2017 08:11:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Thu, 27 Apr 2017 08:11:14 -0700 (PDT) In-Reply-To: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> From: Kathleen Moriarty Date: Thu, 27 Apr 2017 11:11:14 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: "Acee Lindem (acee)" Cc: "Brian Weis (bew)" , Adam Roach , Jeff Tantsura , "rtgwg-chairs@ietf.org" , The IESG , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , "rtgwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:13:02 -0000 On Thu, Apr 27, 2017 at 10:03 AM, Acee Lindem (acee) wrote= : > Hi Kathleen, Brian, > > On 4/26/17, 10:42 PM, "Kathleen Moriarty" > wrote: > >>Hi Brian & Acee, >> >>On Wed, Apr 26, 2017 at 8:49 PM, Brian Weis (bew) wrote: >>> Hi Kathleen and Acee, >>> >>> Just a clarification on what I had said earlier. >>> >>>> On Apr 26, 2017, at 1:55 PM, Acee Lindem (acee) wrote= : >>>> >>>> Kathleen, >>>> >>>> On 4/26/17, 4:47 PM, "Kathleen Moriarty" >>>> wrote: >>>> >>>>> Acee, >>>>> >>>>> >>>>> >>>>> On Wed, Apr 26, 2017 at 4:39 PM, Acee Lindem (acee) >>>>> wrote: >>>>>> Kathleen, Brian, >>>>>> >>>>>> Since KEK as described in RFC 5649 is not ready for prime time, why >>>>>> don=E2=80=99t >>>>> >>>>> This is widely deployed in other use cases, >>>> >>>> None of these use cases are documented in IETF RFCs or drafts. >>> >>> The AES key wrap method itself is well understood, and if you look at >>>the citations for RFC 3394 at >>> it is >>>actually used in a number of IETF protocols. This is the basis for why I >>>originally suggested that it made sense to include it in a YANG model >>>that distributes keys. >>> >> >>Thanks for saving me a step, I was going to use Jari's tool once I got >>back online for the same purpose. >> >>>> >>>>> so I am not following this >>>>> statement that it isn't ready for prime time. RFC5649 is >>>>> straightforward. What is the gap for your usage that requires >>>>> additional guidance? Brian says this in in use for other YANG module= s >>>>> already as well. >>> >>> Apologies, I was unclear in what I said. I am not actually aware of it >>>being used in other YANG modules =E2=80=A6 I meant to communicate what K= athleen >>>said more succinctly, which is that the RFC 3394 and RFC 5649 are >>>implemented for the same purpose in other (non-YANG module) protocols. >>>None of the citations in the list above appear to be YANG modules, but >>>then I=E2=80=99m not sure whether or not any other YANG modules distribu= te keys >>>either. >> >>Thanks, Brian, that is helpful. >> >>Acee, after a little more reading, is the gap for implementation >>guidance on how to use/access the key encrypting key because of the >>following sentence in -20? >> >> The AES key-encryption key (KEK) is >> not included in the YANG model and must be set or derived independent >> of key-chain configuration. >> >>This is an important step, I'm guessing Brian helped with this text >>and that may be where you need some guidance for implementing the key >>distribution functions with a stored KEK instead of the key obfuscated >>in some way. Personally, I'd leave this as implementation specific >>and the guidance here is enough for the draft, but vendors >>implementing would have to figure out how they want to do this. >>Before going further, can I confirm with you that this is the place >>where you'd like guidance? >> >>The guidance I provided earlier that is not in the draft is as follows >>(but might not answer your question): >> >> If you want to wrap an AES key and nothing else, use RFC 3394 >> If you want to wrap an AES key and some other attributes too, use RFC >>5649 > > In this case, it is only the keys, so I should change the reference to RF= C > 3394? Yes, thanks. > > Thanks, > Acee > >> >>Thank you, >>Kathleen >> >>> >>> Hope that helps, >>> Brian >>> >>>>> Could you please be more explicit in terms of what >>>>> you need for guidance. I offered a suggestion, if that isn't enough, >>>>> could you please explain the gap as you see it so we can assist? >>>> >>>> Sorry, I must have missed the text you recommended. Please provide it >>>> again and I will restore the option with the guidance that is missing >>>>from >>>> RFC 5649. >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>> >>>> >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>>> you take this up as a separate draft rather than trying to hold this >>>>>> important document hostage? We have the NETCONF Access Control Model >>>>>> (NACM) to protect the keys during transport (which has been >>>>>> implemented). >>>>>> Obviously, key-strings are stored on devices today since they are >>>>>>being >>>>>> used for protocol authentication and encryption so this is totally >>>>>> orthogonal to the YANG model being used to provision them. >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> >>>>>> On 4/26/17, 4:30 PM, "Kathleen Moriarty" >>>>>> wrote: >>>>>> >>>>>>> Hi Adam, >>>>>>> >>>>>>> I think I see where we are coming to different conclusions.... >>>>>>> >>>>>>> On Wed, Apr 26, 2017 at 4:18 PM, Adam Roach >>>>>>>wrote: >>>>>>>> On 4/26/17 2:36 PM, Kathleen Moriarty wrote: >>>>>>>>> >>>>>>>>> On Wed, Apr 26, 2017 at 2:42 PM, Adam Roach >>>>>>>>>wrote: >>>>>>>>>> >>>>>>>>>> On 4/26/17 11:34 AM, Kathleen Moriarty wrote: >>>>>>>>>>> >>>>>>>>>>> Since the following text int he Security Considerations section >>>>>>>>>>>is >>>>>>>>>>> a >>>>>>>>>>> recommendation, IMO it would be better to drop "or otherwise >>>>>>>>>>> obfuscated" >>>>>>>>>>> from the sentence as encrypting the keys really should be the >>>>>>>>>>> recommendation. Can we make this update? >>>>>>>>>>> >>>>>>>>>>> It is RECOMMENDED that keys be encrypted or otherwise >>>>>>>>>>> obfuscated >>>>>>>>>>> when >>>>>>>>>>> stored internally on a network device supporting this >>>>>>>>>>> specification. >>>>>>>>>>> >>>>>>>>>>> If obfuscation is what happens more often in practice, maybe >>>>>>>>>>> mention >>>>>>>>>>> this >>>>>>>>>>> as a fallback from the recommendation, but not make them sound >>>>>>>>>>> equivalent? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> To be clear -- the current guidance from the security area is to >>>>>>>>>> perform >>>>>>>>>> this kind of encryption, where you have encrypted material livin= g >>>>>>>>>> side-by-side with the key necessary to decrypt it? >>>>>>>>> >>>>>>>>> We are talking about using a key encrypting key (KEK) and storing >>>>>>>>> that, not storing the raw key next to the encrypted data as far >>>>>>>>>as I >>>>>>>>> can tell. >>>>>>>> >>>>>>>> >>>>>>>> Right. >>>>>>>> >>>>>>>>> Additionally, I haven't seen a discussion on the hardware >>>>>>>>> this is expected to run on. >>>>>>>> >>>>>>>> >>>>>>>> That might be appropriate matter for the draft, if it is going to >>>>>>>>make >>>>>>>> this >>>>>>>> recommendation. >>>>>>>> >>>>>>>>> Some implementations of KEK solutions use dedicated hardware for >>>>>>>>>the >>>>>>>>> KEK and require authentication for access to the key, hence >>>>>>>>> preventing >>>>>>>>> generic access and side-by-side storage of the KEK's protected >>>>>>>>>key, >>>>>>>>> and encrypted data. I'd rather see a KEK used than just a key >>>>>>>>>stored >>>>>>>>> in any case. Are you arguing for not using any encryption at all= ? >>>>>>>> >>>>>>>> >>>>>>>> I'll defer to you, of course, since you have presumably given the >>>>>>>> topic >>>>>>>> more >>>>>>>> thought than I have, but: yes. >>>>>>>> >>>>>>>> Absent something like an HSM or forcing human intervention >>>>>>>>whenever a >>>>>>>> process starts (or restarts), it seems that the scheme described i= n >>>>>>>> section >>>>>>>> 5 doesn't actually deter a competent attacker from obtaining the >>>>>>>>keys. >>>>>>>> My >>>>>>>> impression is that storing information in an encrypted form that >>>>>>>>can >>>>>>>> be >>>>>>>> trivially decrypted by an attacker provides a false sense of >>>>>>>>security >>>>>>>> to >>>>>>>> equipment operators. >>>>>>>> >>>>>>>> If the scheme in section 5 *does* require the kind of prerequisite= s >>>>>>>> you >>>>>>>> posit, such as dedicated security hardware, it seems that such >>>>>>>> prerequisites >>>>>>>> should be mentioned alongside the recommendation. >>>>>>>> >>>>>>>>> For YANG modules, couldn't the application via NETCONF/RESTCONF >>>>>>>>> accessing the module provide the credentials to access the key >>>>>>>>> protected by the KEK? >>>>>>>> >>>>>>>> >>>>>>>> That solves the issues with provisioning, but doesn't seem to help >>>>>>>>the >>>>>>>> processes actually involved in routing. >>>>>>>> >>>>>>>>> Some implementations could store the KEK in >>>>>>>>> dedicated hardware as well. In this way, storing the KEK and data >>>>>>>>> together is not the same as storing a key right next to the data >>>>>>>>>it >>>>>>>>> is >>>>>>>>> protecting. >>>>>>>> >>>>>>>> >>>>>>>> This makes perfect sense; and it should probably be in the >>>>>>>>document. >>>>>>>> >>>>>>>>> Use of a KEK is better then not encrypting and can be done >>>>>>>>> well. >>>>>>>> >>>>>>>> >>>>>>>> It can also be done poorly, and the mention of obfuscation (along >>>>>>>>with >>>>>>>> the >>>>>>>> exchange I cite below) leads me to believe that -- absent concrete >>>>>>>> guidance >>>>>>>> to the contrary -- implementors will choose to do it poorly. It's >>>>>>>>not >>>>>>>> clear >>>>>>>> that doing this poorly provides any benefit, and it seems to me >>>>>>>>that >>>>>>>> it >>>>>>>> may >>>>>>>> cause harm: if something _looks_ secure but isn't, doesn't that >>>>>>>>have >>>>>>>> the >>>>>>>> potential for operators to incorrectly treat it as secure? Again, >>>>>>>>this >>>>>>>> is >>>>>>>> more your area than mine and so I will defer to your opinion on th= e >>>>>>>> topic; >>>>>>>> but from a lay perspective, this seems likely to result in the >>>>>>>>lack of >>>>>>>> guarding against compromise of the encrypted information under the >>>>>>>> mistaken >>>>>>>> impression that it can't be decrypted trivially. >>>>>>>> >>>>>>> >>>>>>> The way I read the thread from Acee is that there aren't any KEK >>>>>>> implementations with with particular YANG module, however Brian say= s >>>>>>> there is with other YANG modules. I *think* when Acee is referring >>>>>>>to >>>>>>> obfuscation and less than ideal scenarios, it is with the currently >>>>>>> deployed implementations that don't use KEKs. But the text and >>>>>>> responses did seem to be commingled a bit too much. >>>>>>> >>>>>>>> >>>>>>>>> Am I missing something? Was there something implementation >>>>>>>>>specific >>>>>>>>> that has the raw key stored with the encrypted data? >>>>>>>> >>>>>>>> >>>>>>>> Perhaps the following exchange with the author: >>>>>>>> >>>>>>>> Adam: "By my reading, this is just talking about encrypting 'on th= e >>>>>>>> disk' >>>>>>>> storage on the device. Any processes involved in provisioning the >>>>>>>> values or >>>>>>>> using them to process traffic would have access to the plaintext, >>>>>>>> presumably >>>>>>>> by reading the encrypted form off disk, reading some keying >>>>>>>>material >>>>>>>> off >>>>>>>> disk, and combining them to retrieve the plaintext key." >>>>>>> >>>>>>> It looks like version 20 had different assumptions about using the >>>>>>> KEK. I *think* this is describing usage without a KEK and may be >>>>>>>part >>>>>>> of why Acee is asking for more implementation guidance... so I'll >>>>>>>keep >>>>>>> my discuss to see if we can shape that up more. This is helpful as >>>>>>>I >>>>>>> think I see the gap more now as to what he might be looking for in >>>>>>> terms of guidance. >>>>>>> >>>>>>> Here's the text from -20: >>>>>>> >>>>>>> When configured, the key-strings can be encrypted using the AES Key >>>>>>> Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) i= s >>>>>>> not included in the YANG model and must be set or derived >>>>>>>independent >>>>>>> >>>>>>> Lindem, et al. Expires October 20, 2017 >>>>>>>[Page 15] >>>>>>> Internet-Draft YANG Key Chain April >>>>>>>2017 >>>>>>> >>>>>>> of key-chain configuration. When AES key-encryption is used, the >>>>>>> hex-key-string feature is also required since the encrypted keys >>>>>>>will >>>>>>> contain characters that are not representable in the YANG string >>>>>>> built-in type [YANG]. AES key-encryption MAY be used for added ke= y >>>>>>> security in situations where the NETCONF Access Control Mode is no= t >>>>>>> available. >>>>>>> >>>>>>>> >>>>>>>> Acee: "This is the correct interpretation." >>>>>>>> >>>>>>>> /a >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Best regards, >>>>>>> Kathleen >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>>> >>> >>> -- >>> Brian Weis >>> Security, CSG, Cisco Systems >>> Telephone: +1 408 526 4796 >>> Email: bew@cisco.com >>> >> >> >> >>-- >> >>Best regards, >>Kathleen > --=20 Best regards, Kathleen From nobody Thu Apr 27 08:14:57 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3C3129AD3; Thu, 27 Apr 2017 08:14:52 -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, 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 4J115bslljyl; Thu, 27 Apr 2017 08:14:50 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BF01298A1; Thu, 27 Apr 2017 08:13:47 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id 194so29721698pfv.3; Thu, 27 Apr 2017 08:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BVK8heuen4Jb6aQnT0Dh0GlBDa/EA4L3xjXFHPBgaa0=; b=qSfmdMYS/Bo6N0IsdQH1bIbkR/Zg0JPSIcDGuyRFu714wEBhQSv1gX+abBk+f4D8Lt MsCtjE5v1jQubptJl5Mex2813l4/GCdZ68gnMPBAPl+Dd6To5G9UO3PY+gcBCxHiuRhW DjEgrMSweKnrHkkcQKPth5dDx42NohSY072jL/c4phziSDs4hvyCnYQ7qf6lPxRUpOij 4Xj2tJHA7l6grdvHYuFilAVpUZl5+FLb/cnW8gYd0SoNtBzxgVWuUwWc0VMO5ZYZTC0E v9RR0giGShTbvOh4r2TmVHgSJBRpch239CYjslOnJoNndry8NyuxSBDV71c0fkq6dPZt pBtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BVK8heuen4Jb6aQnT0Dh0GlBDa/EA4L3xjXFHPBgaa0=; b=omD15inGyDtaFCgCAnoFjZr4Ys+esmM9pQwZ0GItbUBcpTcDYUErC3EbjbUcBfcBY3 ZF6vODCelI8r75zwbVwObmgOWiH0nAMrEY0s2LbZyDtj3RN4OpJGswLbsvh8CtagpOZs wJLVET2r9NPlyQG4YO6FBYtwh7oF6k17yeRwN94pkxgqZMszeAPbpGfKWfuJV7Rz5Dmp AHutOytnMKlnwpw+L77wAqv8Uowm/jUx3LyHH1MyXX22wU4aq7oAiaoJfaYAVsP7WF5V OALfcetoTnSbMZc+9F7JfBCAk94XvSCMy0QP8azjUtVsG7jv6Xw03P84gH0xXYzTAxNZ xbCg== X-Gm-Message-State: AN3rC/5TrixGBrgvWPkMPA1Mu+O0qyoKTZwZa6LqIrCdcqLSpxNvrDvI DHo/trH/RqJJfp/his66q+govT+UHA== X-Received: by 10.99.2.9 with SMTP id 9mr6320965pgc.69.1493306027379; Thu, 27 Apr 2017 08:13:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Thu, 27 Apr 2017 08:13:06 -0700 (PDT) In-Reply-To: References: <149322447211.30122.5870367500760951821.idtracker@ietfa.amsl.com> <89d1c702-7830-1f5a-1176-0b894e2d99e9@nostrum.com> <0c744357-0d94-62a8-c16b-81a02ef5db45@nostrum.com> From: Kathleen Moriarty Date: Thu, 27 Apr 2017 11:13:06 -0400 Message-ID: Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) To: Eric Rescorla Cc: "Acee Lindem (acee)" , Alia Atlas , Adam Roach , "rtgwg-chairs@ietf.org" , "draft-ietf-rtgwg-yang-key-chain@ietf.org" , The IESG , Jeff Tantsura , "rtgwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:14:52 -0000 On Thu, Apr 27, 2017 at 10:28 AM, Eric Rescorla wrote: > > > On Thu, Apr 27, 2017 at 7:23 AM, Acee Lindem (acee) wrot= e: >> >> >> >> From: Eric Rescorla >> Date: Thursday, April 27, 2017 at 10:17 AM >> To: Alia Atlas >> Cc: Adam Roach , "rtgwg-chairs@ietf.org" >> , "draft-ietf-rtgwg-yang-key-chain@ietf.org" >> , Kathleen Moriarty >> , The IESG , Jeff Tants= ura >> , Routing WG >> Subject: Re: Kathleen Moriarty's Discuss on >> draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT) >> Resent-From: >> Resent-To: Acee Lindem , Jeffrey Zhang >> , Derek Yeung , Yingzhen Qu >> , Ing-Wher Chen >> Resent-Date: Thursday, April 27, 2017 at 10:17 AM >> >> >> >> On Thu, Apr 27, 2017 at 7:15 AM, Alia Atlas wrote: >>> >>> On Thu, Apr 27, 2017 at 10:05 AM, Adam Roach wrote: >>>> >>>> On 4/26/17 23:02, Alia Atlas wrote: >>>>> >>>>> First, the YANG model is primarily for information in motion - either >>>>> for configuration to the device >>>>> or to read from the device. It is much less likely to represent the >>>>> data structure and storage in the device. >>>>> I believe that this draft's context is strictly for information in >>>>> motion. >>>> >>>> >>>> >>>> Thanks; I understand all that. I'm trying to focus on the final >>>> paragraph of section 5, though, which appears to be an exception to wh= at you >>>> say above. >>> >>> >>> I don't understand why - IMHO, that paragraph is simply saying - this >>> model passes keys around (in motion). Of course, a system shouldn't st= ore >>> such keys unencrypted. From what Acee says, this "motherhood and apple= pie" >>> additional advice was added due to secdir review. >> >> >> I thought Adam's point was that storing keys encrypted with a key that's >> adjacent to them was not useful. >> >> >> Right. I=E2=80=99m not sure what the definition of =E2=80=9Cadjacent=E2= =80=9D is here since it is >> very implementation specific. I will remove the final paragraph in the n= ext >> revision when I add KEK back (assuming we can agree on reasonable guidan= ce >> and which RFC to reference). What I=E2=80=99m strongly opposed to is pus= hing this >> back in the process for such a change. > > > I'm not arguing for any particular outcome, merely making a technical > observation about what is and is not useful from a security perspective. As I understand it, the KEK is not generated on device, so they are not stored together. The KEK would be out-of-band and how it's accessed will be implementation specific. > > -Ekr > >> >> Acee >> >> >> -Ekr >> >>> >>> >>> Regards, >>> Alia >>> >>> >>>> >>>> /a >>>> >>> >> > --=20 Best regards, Kathleen From nobody Fri Apr 28 09:14:18 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEB412EB2A; Fri, 28 Apr 2017 09:14:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-yang-key-chain-22.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149339604048.2947.13724062304216056513@ietfa.amsl.com> Date: Fri, 28 Apr 2017 09:14:00 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 16:14:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Routing Key Chain YANG Data Model Authors : Acee Lindem Yingzhen Qu Derek Yeung Ing-Wher Chen Jeffrey Zhang Filename : draft-ietf-rtgwg-yang-key-chain-22.txt Pages : 23 Date : 2017-04-28 Abstract: This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-22 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-key-chain-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-yang-key-chain-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 28 13:26:38 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D89B129535; Fri, 28 Apr 2017 13:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 TenPJjYE7TZZ; Fri, 28 Apr 2017 13:26:32 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0100.outbound.protection.outlook.com [104.47.42.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA2E129A9D; Fri, 28 Apr 2017 13:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OE1rNn1zEIhqX0O4QYUIDaPIvu9Bh9Z+mhKHkvE/rX0=; b=bXlTalcZkuk+8ppJ25WrXeOsijEsOuowGy/AB2J1hO3NSkGZmD9oR+MQdUKhCTn2BWoS52ishV5VyPVfuZsiinjKIO3Bqnzr6MZKNE6wQrPdd19RCYNXUKEYRbsVrm8O62WW4nPG8DD9BeNMkEZ0GSDIXpuboG+vUOzrBJESWaI= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received: from pvakharwala-sslvpn-nc.jnpr.net (66.129.241.11) by BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Fri, 28 Apr 2017 20:24:01 +0000 From: "John G. Scudder" Content-Type: multipart/mixed; boundary="Apple-Mail=_E8A9E5BB-0E2D-42E0-BE69-AE11A09B0D3B" Subject: Routing Directorate review of draft-ietf-rtgwg-ni-model-02 Date: Fri, 28 Apr 2017 16:23:57 -0400 Message-ID: CC: , , To: MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN6PR13CA0041.namprd13.prod.outlook.com (10.171.172.27) To BN3PR05MB2497.namprd05.prod.outlook.com (10.167.3.26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fbdf7874-23b5-4514-73ec-08d48e7482ab X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 3:6wHCXzN8zgMd1JRplCwcVVcrlN2ljRtZBrkdYs3UfG3tYGUv04kGjjt96x7KJKa3a23PPs6AfZL8CmyU0Cs5VOOuYILr8huV6TABeveR/jWqVdT8WsRKgA4WX8e2Bs4cvDWWpZy7yj+UiugQIZUJRDvk2bBZ4le593JBgOU+3pT8RniJZkrqipnIvGtxWECUy1vLwdlR8tjxMqSJu3JVg9rQb5xud7WpMtD2WHN1aCK3h//nSjv1xbutaNyiNYG5AiyswAMND5jBAloQNZsNU6JIlvoaMovM/uoiW/oc2mO9elhp2UWZIYtNiC9urV05QN/kELzDnNhWBTMuwqJMn3YynJae3rG/1c21RnlCEsU=; 25:d+DbAmaaChHNGGPtoxly4NdGTyOl1zqSTI8xPztEFZBZZLGg6AktirKjypP9aM7/c3sUc635BFcuso4DFrKHEyCi3ALoPkomnoi4++Q5BAhctuRvD6iJZ1ebyFL+px5tVwRyHYmtbbpJXqfPAlUeEHZNOEmA64elFwB4TqSVe48fvzTs7U51hC2vCJPfdW7iI9q1VGRuvqxhQrTs6KWY/n/VXNWLmSkWOFih6IfVeDmoL4aoQL6JmTg4jA9vWKaeDK0gtiGNTtu5TV/nXiAqdq6XsL1Gq24r8jJrgrzg8OsVQDT86m5m1p7F2IOtZt5/0ejaM48E/NFXmxD32hEEG88lTPtmxJNnnZub6+3vx9KDUDIMW6BaHDmMIDNLsEJ9flNfTN1VEGDQrmuJV2oVbdQxYOrGFXsZhYMLZ9dvIXhU/ltai69d8AENpFgmy8nacoz+NsN6EJ39nkz4Om6M5aMxNfX0qySjh1nGdrC+ik8giRI44//fbu86gLi82597hJxfiWx6zcsqx3fF1D3WIg== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 31:rkESdtDaXki/nBdsbAy/ObbrDZZuXwLdIKBYuXhmgG/IizKRODIvAXYhGHzkgSSDsRdthcAz6pci9vmHKqtME+wOoWvSrUQTTpr71VCchg9u37W+Irm61rsO95KMf6AQsJ4ya7Gw4BtAfMezQxrTp5RLs20ZqR4KSHgahEm5OxDKEKk4FYvS9dqAlFfAHp+cKjyf72dc1latI/jSbVJPRS6fqS10Uqu1fUfFLZqdAUJ0U2L7TQYcIrkroMvXpQ/R79CfPJ0h7vU/LoaYKAvKLL48e6TNMBGrXJGNRWAIpLOIQtxbp2W7CeL/bQi1O88uj8g80mdWTMBkxzvwRQXyfA== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 20:Xd4SQBlVTb/jJr52SG2WKBbP49+CBbVMgT1ipsoLqW9Jh4sx3+WmpeDmBIC9qKspwhUgW+Q57/4VXzqLWFyI4GU0cWVSpJFct55+MwRsIfPx9xMK8Q271uqrFxZ+ho6OQtEWmh5wyN6BoedMqKP8bCvxGrn3GtIQpZYNlKMXIvfWGqaemrpOtB1vz08Ys9SxgJ9w5yUk0nAlam8cuWk6wiuXQCCz0davKxIDVonGD69R1RW7R5AXao1Qdmsd4IXWR5Ufezs32eb8Vb344yiQtZbpppS3JuvevvnkFhMRIVORCu/t9LbNmlZztlKXDb7ySzO+K6PB0CoBWYKNCGLqrejziY0cgj/X1TGUQKhbwzJTshzUQfbCD+oE9zAQOjrFcYlh8dmTnH3wGn5cujdOvO8vRfwO8qgp3VOYwQqW5UxpLbHOVNoE+UDe7f79+hOxT+XtFfOH6LsUae4a8RMeW7wNm7sJ4gaFhzlYYsDJTF9o3GSuXolsQX1mPEJ6lPBVbZNZ+V05s9TDNJlkyQqELaaf9lWBLi1MWlgVKgyVWDx06ORy4T8X3nd7MYsKW2QnPBiHWE05IVoroFIQ7jGe6tfpcsKLg/ttIM74XWBKCbc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(6072148); SRVR:BN3PR05MB2497; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2497; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 4:D7FDyDUGlKo4AhqgcJ1ZGaA2IMSsvaoX/3knDPcVFoa9WxEjg6+SOBjBSMfYfD7Oe5jjlziw9IqtNpWzuFw2XcrPx7ohkgaSkouG8cVPH4fy5wGAIiLDCQqvWWlVmla4ebKlPAOtkmhTzETjmElWW738nZOG0VkvOv4KLTNt0uBgVQ+VHrqRhE8Ha0VBLL3fQ4smV44V9IfNdpRM/ztmhaxkRkdMCMmJnM+avKz47NJiDa9gbG4DiRUl2wlga1TjzRs+hw4DpB3jZlSGeuEt6/TAbGpk81D9jCiN4n7pCQhF09yTLWLzSTEH+HCyj+RuVNabqedtVSwgnM16BUf2gn8lB8V3JSQ30106XkA5P7y8furaYRta84j8jPcATAFMz6c1Hk+vjBsiQF1JRa72g93UslOGsaXPAV5Jg2UinH0NKtYkp985hrC31QVtSuYqWXYugSxMqu7JX5eFQI1qSa8CNgEBcLWE+BrDBVG06uSbDotdPKU9GLlEsABrCbAN5TnMcU0cloBAqEyyGavV7N3QnSZfYUrERJ1EsGk8JkqVl/SC6/G2ACVQHQxhqg/SlFGY5TT8NszELVzISno0VMvsP4kSu808fdL1T/teF2k7svMlQlEgTpGk31dbpMk6B7Ylko39teH8ButLGAfV6vEUEL7nfqqxEqqCm8Mk2zOY9m0yWGugYFEwy8jdoK7BIAHQAPHm0lwqOpwoK8wD4xyeA2p5acYXWGvRVdySVipTMDrZaWLYdmphQmXHVmbVvzCaUOmffb2RJNkIDcG/TULVX/u8YbhYzCeQjgMA3RGiiT3T9ZMRy8aFyaxiMh7D9Qz8YtVZJATM8UeeluJhkiTxvQVzuP5Z8DW3f36gXcD/HHviE34gLDhBAHBe4sOj X-Forefront-PRVS: 029174C036 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39840400002)(39850400002)(39450400003)(39410400002)(39400400002)(39860400002)(53754006)(305945005)(86362001)(50986999)(4610100001)(7736002)(512874002)(5660300001)(69556001)(2351001)(6512007)(189998001)(6916009)(21480400002)(6486002)(6666003)(568964002)(82746002)(54906002)(6306002)(6506006)(1720100001)(84326002)(83716003)(450100002)(4326008)(33656002)(6116002)(25786009)(3846002)(36756003)(5890100001)(81166006)(66066001)(53936002)(8676002)(53416004)(50226002)(38730400002)(2906002)(42186005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2497; H:pvakharwala-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2497; 23:jPZaZVXAkycox8oH2ZjPABEiCGCRV2lDIEanz5dPo?= =?us-ascii?Q?G7InMzZFX1S15VSO66UVrikD0YyXpnn+GiDqJ/sN/uywyrFEGe9K/WFwCsd4?= =?us-ascii?Q?mhc9rnzq0fKv2AI0jbzUi207AWTluwmapWCksIr9ZtCqtMYrL3ifzZXyLhsL?= =?us-ascii?Q?Lsl4IzabXTQAHfn0h1UbG3RQjotFQA+LpWxfZPtJQe/nF0vjxWZfXYBFFTjr?= =?us-ascii?Q?NTX+TxhfDL8PIyz4bDHCYJj0JwgrLMkHZDSNxADsuYL45keW3Nr14peD760J?= =?us-ascii?Q?Vo0OwPVBU9HjhynUPJDRj2UCysSJOrCoWM0MWwtKlsUcRqLVQlNiNz8D16s0?= =?us-ascii?Q?XZ4UTyiRTkuCnAhPKtVL4TCpfo6i58nvGyeCQeWG7V9iVD+O6HT2Zin73mI8?= =?us-ascii?Q?hhckk+E4ur2ZYkzb8sduIuNdf7HHs90jCOoGb+rVYcNGn4O4xw9qCedbMNmo?= =?us-ascii?Q?pmt/pzfe/x+ci1zl/YlHAa4uG3Q64yUg33cev8Eup/MS7Sz6VQRjgLq2plr3?= =?us-ascii?Q?xJfgAqSDyVa1VDtBLlj6CoYIam85MmDrcXH8cltwhftW+NyceUO0StOfNd1M?= =?us-ascii?Q?C1Y5eMpDc4DGb4R0SqzFVA1p/ityDB22KsFnOCRVryHnfwH3huEnZfjMPp/y?= =?us-ascii?Q?1EeDXgRws4zBo3tW0Pwwh1NAX/rRhCX5cei0on9kUqwQCpRTUXNWeztK5/D0?= =?us-ascii?Q?07JSdvhJCeoyJsrGuEye9hOekByNPgrujZhj8getgkpY/FoKzQc6Z3FrLCJi?= =?us-ascii?Q?ssXfZbRjSLuGl/EcKoHw5UpvQeLc3LyoZGhtkc894yz2agFQRGQzbkG7FRv5?= =?us-ascii?Q?KaqTZqfNMNA8ySTWye6HEBWcnP/AjalYa8WaglRTfUZyk3oOpCKSN5P2ZLSA?= =?us-ascii?Q?aka18Q8aSuk91So0jn4eHbgJr12FqMDb5xhl4KK/6Xru2+V19C/7U4+9SJIs?= =?us-ascii?Q?6idQpkzf8hliy02iWRSEoUHJOYFd+DBIcI1yNNZW4kDKOvx1L5UcThAt9y6c?= =?us-ascii?Q?UuKyiaFniHVpMQFSuFLYIcm9byIK6sDGhEdLml1OH1qjjFmdcoXel5RZQK2G?= =?us-ascii?Q?4OWvaDtQfy2UNDTSa2EHK5yo4zgATrR1I7k+9ANvb0OprcFlGrdIIsnvd/EM?= =?us-ascii?Q?ysA+EendGfOdNYsHnxR/1bf+3X96TH9AKUqgv4OmCXZ5rR12vEAoO+z0t417?= =?us-ascii?Q?EC+IxCawv8apPHzI9E3eTLhsRTDvN9J8YPNX7ATo54biO5oYMmtCvk1gtOCc?= =?us-ascii?Q?fguPVqrvChydopKnrY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 6:EZqVowQncv/t6uhZkRMB5G7oYnCVPk5MlKDBDxm1TWa4YvoC5VvTZdOufx2SRIulBhgGczJxzNnUdmH/TTxPY+JGoMpT91hUBBdYmyX/kSZ7vtEkNB+g94JYvi1aSu+dvcX9m08E3FqvTD7Kn2GZmL49tnhKY6pYFyi6+vhPwGMNu6sbOuVEuN3yk8EuwF5IEq80l2goHDjWjUc+5PrEXzCFJuCpm1mYCIAyvBOVHGHINnketWlueTxj3b6og+46LYCnqMZLPqQ1BUqz2hA/OH8CnsGvfG/d5tQoqutAWfNWkqO/ySb1kTra8SbJOFO7TrDEG4IWgLd3rGPDkPxEPSYTGIYdMXkWMYHnYgKSj6zkiWnowHcozpjP+Paihcr5J9gqV2sBpZ4F2eAEurM9/hYrDLQxqTiPjCfcLe2/hkgoUPDCAbLl57vR9RwcDi6jSSKCbYleQtAXRycilOJEDiLoSSTRkkSzRjwhXhUKUcABKEZ78cjx7Tt+SSacNTh68kLt3rkel/SAZ4oCLsAkXsQisvJ03YfafF8e9F1ihqo=; 5:D+nr+x/Z2bDkEXSSu7Q/ke5mgAoPhjYw/vWg7lmCxJuEmV6USXwRo/Sq1I4AY82Wp03kU3jYJVKK5l1D1GiF9kDlXoRA72Xqfmi7QrZavIxZ3oJx0WOVFdlcoepDedmdF2ADpR9vsVdvRJAhcam29Zkd0BlF35gUAYRARgATQ2g=; 24:yRa7yg/l3By36udBfEXiF3lyg/vJIeXuGkNCfevFNHmz1p4DfI3vPkhJGX/rHku7UaUnG+uQ2iJssUnHcQSe+y9Gwctm22czH3M9xm2DXTo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2497; 7:oK2gwTvS9ivKjPlc0vluqO7hxyy+hPf124VeN4xkrFhqri98z3VwrdoygIIo9+VibSzK+PyQ59OKRHLo8OLgXsLbuWsQiT6oIGml0z9d0cjKsxU18xHZvHQxkc2+PmEDfcxYp16DJSJuxCrI4aQQc2d/r7AAEfzYbQgOVvEMs76jKdlZexP2mcBZ8VZRt8LKSsKKDiGQ8xJaQGixzKR3lipnr0AjPTGU/5LbkvaVvY5rXRAbgxlqNTtgaypAQhSIzCNLjQoIF0pvBuDFDzskk9AiK1dycrVK70HXAB5X3hasThYwQUdUzInQQlCbIDLS6hDEWk6BoPN7/OiYDq694Q== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2017 20:24:01.8101 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2497 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 20:26:37 -0000 --Apple-Mail=_E8A9E5BB-0E2D-42E0-BE69-AE11A09B0D3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi All, =20 I have been selected to do a routing directorate aQA review of this = draft. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ =20 The QA review is described = (https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa) as: "The WG Draft Quality Assurance process exists to provide cross-WG and = expert review early in the IETF process after a WG has adopted a WG = draft or while the WG is deciding to adopt a draft. Since a WG adopts a = draft as a good starting point for the work, providing early excellent = review of such drafts allows for good technical discussion and the = ability to enhance the WG draft to solve identified issues. The earlier = in the process that substantial issues (technical or editorial) are = resolved, the more quickly and smoothly a WG draft is likely to = proceed." =20 For more information about the Routing Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Document: draft-ietf-rtgwg-ni-model-02.txt=20 Reviewer: John Scudder Review Date: April 28, 2017 Summary:=20 I found the document easy to follow, clear and almost painless to read, = thank you. Note that my level of Yang expertise is pretty low, so you should be = looking elsewhere for a critique of anything other than the grossest = Yang-specific aspects of the document. (I found the schema-mount example = in section 3.2 particularly opaque.) Comments and Questions: 1. There's a significant amount of duplication of explanatory and = background text between this document and draft-ietf-rtgwg-lne-model-01. = In reading it, I tried to consider whether it would be OK to cut out = some of the text explaining what an LNE is, but on the whole I think = it's better left in -- the document would have been more difficult to = read without having that context in-line. However, it does lead to the = question, is there some good reason the two documents are separate, = instead of a single document? The duplication between them suggests = there's at least some motivation to refactor them into one. (I realize = there may be many reasons to keep them separate, including "seriously, = John? The cost/benefit just isn't there", but I had to ask.) 2. The abstract is almost a copy of the abstract for = draft-ietf-rtgwg-lne-model-01. Comments in #1 above notwithstanding, I = do think brevity is the soul of wit when it comes to an abstract, so I = suggest removing the LNE definition here, and just define the stuff = *this* doc is about. (Similar suggestion applies to the companion doc's = abstract.) 3. It seems to me the "TBD" for network-instance-policy represents a = significant open issue and deserves to be included in your open issues = list (section 1.1). Other TBDs sprinkled throughout don't seem to rise = to this level, but of course do represent open issues. 4. Speaking of network instance policy, although since it's left TBD = there's not much to be said, the examples you give (RTs, RDs, VNIs, VPLS = neighbors) mostly don't seem like what I think of as "policy". I suppose = it's one of the most overloaded terms in our industry, so maybe someone = else does think of it that way, but this choice of terminology was a = speed bump for my understanding of the doc. 5. The example given in section 3.2 doesn't seem to follow the same = pattern as the one given in section 3. I'm too much of a Yang neophyte = to know if there might be some Yang feature in play that makes this make = sense, but on the face of it the example in section 3 seems to tell me = I'm supposed to bind a network-instance-name to a specific instance of = an interface (so, if:interfaces/if:interface), whereas what I see in 3.2 = is a network-instance-name at the if:interfaces level -- which doesn't = make a lot of intuitive sense, either. Minor Issues and Nits: 6. I've edited various minor suggestions into a copy of = draft-ietf-rtgwg-ni-model-02.txt and attached it, you can look at them = using your diff tool of choice. 7. This sentence isn't quite right: Network instance policies are used to control how NI information is represented at the device level, VRF routing policies, and VRF/VSI identifiers. Without knowing your intent I'm not able to offer you a rewrite. = Possibly it would be enough to reorder the items in your list, to put = the big compound one at the end, as in "Network instance policies are = used to control VRF routing policies, VRF/VSI identifiers, and how NI = information is represented at the device level"?=20 8. This sentence no verb: For layer 3, this consistent with the routing-instance definition in ietf-routing Again, without knowing your intent I can't offer a rewrite. Maybe the = verb "to be" is what you want? --Apple-Mail=_E8A9E5BB-0E2D-42E0-BE69-AE11A09B0D3B Content-Disposition: attachment; filename="draft-ietf-rtgwg-ni-model-02.txt" Content-Type: text/plain; name="draft-ietf-rtgwg-ni-model-02.txt" Content-Transfer-Encoding: quoted-printable Network Working Group L. Berger Internet-Draft LabN Consulting, L.L.C. Intended status: Standards Track C. Hopps Expires: September 14, 2017 Deutsche Telekom A. Lindem Cisco Systems D. Bogdanovic March 13, 2017 YANG Network Instances draft-ietf-rtgwg-ni-model-02 Abstract This document defines a network instance module. This module along with the logical network element module can be used to manage the logical and virtual resource representations that may be present on a network device. Examples of common industry terms for logical resource representations are Logical Systems or Logical Routers. Examples of common industry terms for virtual resource representations are Virtual Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 14, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Berger, et al. Expires September 14, 2017 [Page 1] =0C Internet-Draft YANG NIs March 2017 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Status of Work and Open Issues . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Network Instances . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Network Instance Policy . . . . . . . . . . . . . . . . . 6 3.2. Network Instance Management . . . . . . . . . . . . . . . 7 3.3. Network Instance Instantiation . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Network Instance Model . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction This document defines the second of two new modules that are defined to support the configuration and operation of network devices that allow for the partitioning of resources from both, or either, management and networking perspectives. Both make use of the YANG functionality enabled by YANG Schema Mount [I-D.ietf-netmod-schema-mount]. Two forms of resource partitioning are supported: The first form, which is defined in [I-D.ietf-rtgwg-lne-model], provides a logical partitioning of a network device where each partition is separately managed as essentially an independent network element which is 'hosted' by the base network device. These hosted network elements are referred to as logical network elements, or LNEs, and are supported by the logical-network-element module defined in [I-D.ietf-rtgwg-lne-model]. The module is used to identify LNEs and associate resources from the network-device with each LNE. LNEs themselves are represented in YANG as independent network devices; each accessed independently. Optionally, and when supported by the Berger, et al. Expires September 14, 2017 [Page 2] =0C Internet-Draft YANG NIs March 2017 implementation, they may also be accessed from the host system. Examples of vendor terminology for an LNE include logical system or logical router, and virtual switch, chassis, or fabric. The second form, which is defined in this document, provides support = for what is commonly referred to as Virtual Routing and Forwarding (VRF) instances as well as Virtual Switch Instances (VSI), see [RFC4026]. In this form of resource partitioning multiple control plane and forwarding/bridging instances are provided by and managed via a single (physical or logical) network device. This form of resource partitioning is referred to as Network Instances and is supported by the network-instance module defined below. Configuration and operation of each network-instance is always via the network device and the network-instance module. This document was motivated by, and derived from, [I-D.ietf-rtgwg-device-model]. 1.1. Status of Work and Open Issues The top open issues are: 1. This document will need to match the evolution and standardization of [I-D.openconfig-netmod-opstate] or [I-D.ietf-netmod-opstate-reqs] by the Netmod WG. 2. Overview In this document, we consider network devices that support protocols and functions defined within the IETF Routing Area, e.g, routers, firewalls and hosts. Such devices may be physical or virtual, e.g., a classic router with custom hardware or one residing within a server-based virtual machine implementing a virtual network function (VNF). Each device may sub-divide their resources into logical network elements (LNEs) each of which provides a managed logical device. Examples of vendor terminology for an LNE include logical system or logical router, and virtual switch, chassis, or fabric. Each LNE may also support virtual routing and forwarding (VRF) and virtual switching instance (VSI) functions, which are referred to below as a network instances (NIs). This breakdown is represented in Figure 1. Berger, et al. Expires September 14, 2017 [Page 3] =0C Internet-Draft YANG NIs March 2017 ,''''''''''''''''''''''''''''''''''''''''''''''`. | Network Device (Physical or Virtual) | | ..................... ..................... | | : Logical Network : : Logical Network : | | : Element : : Element : | | :+-----+-----+-----+: :+-----+-----+-----+: | | :| Net | Net | Net |: :| Net | Net | Net |: | | :|Inst.|Inst.|Inst.|: :|Inst.|Inst.|Inst.|: | | :+-----+-----+-----+: :+-----+-----+-----+: | | : | | | | | | : : | | | | | | : | | :..|.|...|.|...|.|..: :..|.|...|.|...|.|..: | | | | | | | | | | | | | | | `'''|'|'''|'|'''|'|'''''''''|'|'''|'|'''|'|''''' | | | | | | | | | | | | Interfaces Interfaces Figure 1: Module Element Relationships A model for LNEs is described in [I-D.ietf-rtgwg-lne-model] and the model for network instances is covered in Section 3. For more information on how these models may be used within an overall device model structure, see [I-D.ietf-rtgwg-device-model]. The interface management model [RFC7223] is an existing model that is impacted by the definition of LNEs and network instances. This document and [I-D.ietf-rtgwg-lne-model] define augmentations to the interface module to support LNEs and NIs. Similar elements, although perhaps only for LNEs, may also need to be included as part of the definition of the hardware and QoS modules. Interfaces are a crucial part of any network device's configuration and operational state. They generally include a combination of raw physical interfaces, link-layer interfaces, addressing configuration, and logical interfaces that may not be tied to any physical interface. Several system services, and layer 2 and layer 3 protocols may also associate configuration or operational state data with different types of interfaces (these relationships are not shown for simplicity). The interface management model is defined by [RFC7223]. The logical-network-element and network-instance modules augment the existing interface management model in two ways: The first, by the logical-network-element module, adds an identifier which is used on physical interface types to identify an associated LNE. The second, by the network-instance module, adds a name which is used on interface or sub-interface types to identify an associated network instance. Similarly, this name is also added for IPv4 and IPv6 types, as defined in [RFC7277]. Berger, et al. Expires September 14, 2017 [Page 4] =0C Internet-Draft YANG NIs March 2017 The interface related augmentations are as follows: module: ietf-logical-network-element augment /if:interfaces/if:interface: +--rw bind-lne-name? string module: ietf-network-instance augment /if:interfaces/if:interface: +--rw bind-network-instance-name? string augment /if:interfaces/if:interface/ip:ipv4: +--rw bind-network-instance-name? string augment /if:interfaces/if:interface/ip:ipv6: +--rw bind-network-instance-name? string The following is an example of envisioned combined usage. The interfaces container includes a number of commonly used components as examples: +--rw if:interfaces | +--rw interface* [name] | +--rw name string | +--rw lne:bind-lne-name? string | +--rw ethernet | | +--rw ni:bind-network-instance-name? string | | +--rw aggregates | | +--rw rstp | | +--rw lldp | | +--rw ptp | +--rw vlans | +--rw tunnels | +--rw ipv4 | | +--rw ni:bind-network-instance-name? string | | +--rw arp | | +--rw icmp | | +--rw vrrp | | +--rw dhcp-client | +--rw ipv6 | +--rw ni:bind-network-instance-name? string | +--rw vrrp | +--rw icmpv6 | +--rw nd | +--rw dhcpv6-client The [RFC7223] defined interface model is structured to include all interfaces in a flat list, without regard to logical or virtual instances (e.g., VRFs) supported on the device. The bind-lne-name and bind-network-instance-name leaves provide the association between an interface and its associated LNE and NI (e.g., VRF or VSI). Berger, et al. Expires September 14, 2017 [Page 5] =0C Internet-Draft YANG NIs March 2017 3. Network Instances The network instance container is used to represent virtual routing and forwarding instances (VRFs) and virtual switching instances (VSIs), [RFC4026]. VRFs and VSIs are commonly used to isolate routing and switching domains, for example to create virtual private networks, each with their own active protocols and routing/switching policies. The model represents both core/provider and virtual instances. Network instances reuse and build on [RFC8022] and are shown below: module: ietf-network-instance +--rw network-instances +--rw network-instance* [name] +--rw name string +--rw type? identityref +--rw enabled? boolean +--rw description? string +--rw network-instance-policy | ... +--rw root? yang-schema-mount | ... augment /if:interfaces/if:interface: +--rw bind-network-instance-name? string augment /if:interfaces/if:interface/ip:ipv4: +--rw bind-network-instance-name? string augment /if:interfaces/if:interface/ip:ipv6: +--rw bind-network-instance-name? string A network instance is identified by a `name` string. This string is used both as an index within the network-instance module and to associate resources with a network instance as shown above in the interface augmentation. Type is used to indicate the type of NI, = such as L3-VRF, VPLS, L2-VSI, etc. Network instance policy and root are discussed in greater detail below. 3.1. Network Instance Policy Network instance policies are used to control how NI information is represented at the device level, VRF routing policies, and VRF/VSI identifiers. Examples include BGP route targets (RTs) and route distinguishers (RDs), virtual network identifiers (VN-IDs), VPLS neighbors, etc. The structure is expected to be: Berger, et al. Expires September 14, 2017 [Page 6] =0C Internet-Draft YANG NIs March 2017 module: ietf-network-instance +--rw network-instances +--rw network-instance* [name] +--rw network-instance-policy (TBD) 3.2. Network Instance Management Modules that may be used to represent network instance specific information will be available under `root`. As with LNEs, actual module availability is expected to be implementation dependent. The use-schema mechanism defined as part of the Schema Mount module [I-D.ietf-netmod-schema-mount] is expected to be the primary method used to identify supported modules. Resource related control and assignment is expected to be managed at the network-device level, not the network instance level, based on the `bind-network-instance-name` augmentation mentioned above. Mounted modules will access such information, as well as any other information contained within a module at the device root, by using the parent-reference mechanism defined in [I-D.ietf-netmod-schema-mount]. As an example, consider the case where a network instance with a `name` of "green" is defined on a network device. In this case the following logical structure might be made available: +--rw yanglib:modules-state [RFC7895] +--rw if:interfaces [RFC7223] | +--rw bind-network-instance-name=3D"green" string +--rw network-instances +--rw network-instance* [name] +--rw name=3D"green" string +--rw type? identityref +--rw enabled=3Dtrue boolean +--rw description=3D"The Green VRF" string +--rw network-instance-policy | ... (RT=3D1000:1, RD=3D1.2.3.4) +--rw root? yang-schema-mount with a corresponding logical structure in the schema-mount module: Berger, et al. Expires September 14, 2017 [Page 7] =0C Internet-Draft YANG NIs March 2017 module: ietf-yang-schema-mount +--ro schema-mounts : +--ro mount-point* [module name] | +--ro module=3D"ietf-network-instance" | +--ro name=3D"root" | +--ro config=3Dtrue | +--ro (schema-ref)? | +--:(use-schema) | +--ro use-schema* [name] | +--ro name=3D"ni-vrf" : : : +--ro schema* [name] +--ro name=3D"ni-vrf" string +--ro module* [name revision] | +--ro name=3D"mm:network-services" : : | +--ro name=3D"nn:oam-protocols" : : | +--ro name=3D"oo:routing" : : | +--ro name=3D"pp:mpls" : : +--ro mount-point* [network-instance] : All modules that represent control-plane and data-plane information may be present at the `root`, and be accessible via paths modified per [I-D.ietf-netmod-schema-mount]. The list of available modules is expected to be implementation dependent, as is the method used by an implementation to support NIs. 3.3. Network Instance Instantiation Network instances may be controlled by clients using existing list operations. When list entries are created, a new instance is instantiated. The models mounted under a NI root are expected to be dependent on the server implementation. When a list entry is deleted, an existing network instance is destroyed. For more information see [RFC7950] Section 7.8.6. 4. Security Considerations TBD Berger, et al. Expires September 14, 2017 [Page 8] =0C Internet-Draft YANG NIs March 2017 5. IANA Considerations This document registers a URI in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration is requested to be made. URI: urn:ietf:params:xml:ns:yang:ietf-network-instance Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry [RFC6020]. name: ietf-network-instance namespace: urn:ietf:params:xml:ns:yang:ietf-network-instance prefix: ni reference: RFC XXXX 6. Network Instance Model The structure of the model defined in this document is described by the YANG module below. file "ietf-network-instance@2017-03-13.yang" module ietf-network-instance { yang-version 1.1; // namespace namespace "urn:ietf:params:xml:ns:yang:ietf-network-instance"; prefix ni; // import some basic types import ietf-interfaces { prefix if; } import ietf-ip { prefix ip; } import ietf-yang-schema-mount { prefix yangmnt; } Berger, et al. Expires September 14, 2017 [Page 9] =0C Internet-Draft YANG NIs March 2017 // meta organization "IETF Routing Area Working Group (rtgwg)"; contact "Routing Area Working Group - "; description "This module is used to support multiple network instances within a single physical or virtual device. Network instances are commonly known as VRFs (virtual routing and forwarding) and VSIs (virtual switching instances)."; revision "2017-03-13" { description "Initial revision."; reference "RFC TBD"; } // extension statements feature bind-network-instance-name { description "Network Instance to which an interface instance is bound"; } // identity statements identity network-instance-type { description "Base identity from which identities describing network instance types are derived"; } identity ipv4-interface-protocol-type { description "Base identity for derivation of IPv4 interface protocols"; } identity ipv6-interface-protocol-type { description "Base identity for derivation of IPv6 interface protocols"; } // typedef statements // grouping statements Berger, et al. Expires September 14, 2017 [Page 10] =0C Internet-Draft YANG NIs March 2017 grouping interface-ip-common { description "interface-specific configuration for IP interfaces, IPv4 and IPv6"; } grouping ipv4-interface-protocols { container ipv4-interface-protocols { list ipv4-interface-protocol { key "type"; leaf type { type identityref { base ipv4-interface-protocol-type; } mandatory true; description "ARP, ICMP, VRRP, DHCP Client, etc."; } description "List of IPv4 protocols configured on an interface"; } description "Container for list of IPv4 protocols configured on an interface"; } description "Grouping for IPv4 protocols configured on an interface"; } grouping ipv6-interface-protocols { description "Grouping for IPv6 protocols configured on an interface."; container ipv6-interface-protocols { description "Container for list of IPv6 protocols configured on an interface."; list ipv6-interface-protocol { key "type"; description "List of IPv6 protocols configured on an interface"; leaf type { type identityref { base ipv6-interface-protocol-type; } Berger, et al. Expires September 14, 2017 [Page 11] =0C Internet-Draft YANG NIs March 2017 mandatory true; description "ND, ICMPv6, VRRP, DHCPv6 Client, etc."; } } } } grouping network-instance-policy { description "Network instance policies such as route distinguisher, route targets, VPLS ID and neighbor, Ethernet ID, etc. "; reference "RFC 4364 - BGP/MPLS Virtual Private Networks (VPNs) RFC 6074 - Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) RFC 7432 - BGP MPLS-Based Ethernet VPN"; container network-instance-policy { description "Network Instance Policy -- details TBD, perhaps based on BESS model"; } } // top level device definition statements container network-instances { description "Network instances each of which have an independent IP/IPv6 addressing space and protocol instantiations. For layer 3, this consistent with the routing-instance definition in ietf-routing"; reference "RFC 8022 - A YANG Data Model for Routing Management"; list network-instance { key name; description "List of network-instances"; leaf name { type string; description "device scoped identifier for the network instance"; } leaf type { type identityref { base network-instance-type; } description Berger, et al. Expires September 14, 2017 [Page 12] =0C Internet-Draft YANG NIs March 2017 "The network instance type -- details TBD Likely types include core, L3-VRF, VPLS, L2-cross-connect, L2-VSI, etc."; } leaf enabled { type boolean; default "true"; description "Flag indicating whether or not the network instance is enabled."; } leaf description { type string; description "Description of the network instance and its intended purpose"; } uses network-instance-policy; yangmnt:mount-point root { description "Root for models supported per network instance. This will typically not be an inline type mount point."; } } } // augment statements augment "/if:interfaces/if:interface" { description "Add a node for the identification of the logical network instance (which is within the interface's identified logical network element) associated with the IP information configured on an interface"; leaf bind-network-instance-name { type string; description "Network Instance to which an interface is bound"; } } augment "/if:interfaces/if:interface/ip:ipv4" { description Berger, et al. Expires September 14, 2017 [Page 13] =0C Internet-Draft YANG NIs March 2017 "Add a node for the identification of the logical network instance (which is within the interface's identified physical or virtual device) associated with the IP information configured on an interface"; leaf bind-network-instance-name { type string; description "Network Instance to which IPv4 interface is bound"; } } augment "/if:interfaces/if:interface/ip:ipv6" { description "Add a node for the identification of the logical network instance (which is within the interface's identified physical or virtual device) associated with the IP information configured on an interface"; leaf bind-network-instance-name { type string; description "Network Instance to which IPv6 interface is bound"; } } // rpc statements // notification statements } 7. References 7.1. Normative References [I-D.ietf-netmod-schema-mount] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- ietf-netmod-schema-mount-04 (work in progress), March 2017. [I-D.ietf-rtgwg-lne-model] Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic, "YANG Logical Network Elements", draft-ietf-rtgwg-lne- model-01 (work in progress), October 2016. Berger, et al. Expires September 14, 2017 [Page 14] =0C Internet-Draft YANG NIs March 2017 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, . [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 7277, DOI 10.17487/RFC7277, June 2014, . 7.2. Informative References [I-D.ietf-netmod-opstate-reqs] Watsen, K. and T. Nadeau, "Terminology and Requirements for Enhanced Handling of Operational State", draft-ietf- netmod-opstate-reqs-04 (work in progress), January 2016. [I-D.ietf-rtgwg-device-model] Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, "Network Device YANG Organizational Models", draft-ietf- rtgwg-device-model-01 (work in progress), October 2016. [I-D.openconfig-netmod-opstate] Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling of Operational State Data in YANG", draft-openconfig- netmod-opstate-01 (work in progress), July 2015. [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, . [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . Berger, et al. Expires September 14, 2017 [Page 15] =0C Internet-Draft YANG NIs March 2017 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", RFC 8022, DOI 10.17487/RFC8022, November 2016, . Appendix A. Acknowledgments The Routing Area Yang Architecture design team members included Acee Lindem, Anees Shaikh, Christian Hopps, Dean Bogdanovic, Lou Berger, Qin Wu, Rob Shakir, Stephane Litkowski, and Yan Gang. The RFC text was produced using Marshall Rose's xml2rfc tool. Berger, et al. Expires September 14, 2017 [Page 16] =0C Internet-Draft YANG NIs March 2017 Appendix B. Contributors Contributors' Addresses TBD Authors' Addresses Lou Berger LabN Consulting, L.L.C. Email: lberger@labn.net Christan Hopps Deutsche Telekom Email: chopps@chopps.org Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 USA Email: acee@cisco.com Dean Bogdanovic Email: ivandean@gmail.com Berger, et al. Expires September 14, 2017 [Page 17] --Apple-Mail=_E8A9E5BB-0E2D-42E0-BE69-AE11A09B0D3B-- From nobody Fri Apr 28 13:44:14 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52742129577 for ; Fri, 28 Apr 2017 13:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weOg2HOKGG0S for ; Fri, 28 Apr 2017 13:44:07 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0118.outbound.protection.outlook.com [104.47.42.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53C2129AF4 for ; Fri, 28 Apr 2017 13:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com; s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P+i0SqiBMlrsatIHTdyMdfTdzmQ9xMbEKuJ4sMp6vJ8=; b=2azanrAq9jOvaKDdreoDDxsaB8z8xB3+aOlmCuDMSlZD4u6sgcg8cnel7Ickf7fCqP6hZagGa4m/jV5l+EvbFvnHElilpW6lALHCbavkj5YUos750RZVa7Tqwaqi8MJBLGvY+i+rjmZf6mryh67l0sQAMzpMbGjYg8KuRI5kaM0= Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by DM2PR02MB1369.namprd02.prod.outlook.com (10.161.143.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Fri, 28 Apr 2017 20:41:34 +0000 Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1047.019; Fri, 28 Apr 2017 20:41:31 +0000 From: Xufeng Liu To: Henning Rogge CC: Jonathan Hardwick , Athanasios Kyparlis , "parikhr@vmware.com" , "zhangmingui@huawei.com" , Routing WG Subject: RE: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp Thread-Topic: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp Thread-Index: AQHSvM5DkWzkWiy5OUyGyrzZT7T+E6HWF3bAgAAEdICAAYkXIIADoFyA Date: Fri, 28 Apr 2017 20:41:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=jabil.com; x-originating-ip: [98.191.72.170] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR02MB1369; 7:BxHwIyAII2P7v7PSSrkiMTi6FSfrt3Fprk0e3VRmTnzTQ7xeQ14KbOimGzNrn4wk+bdfAouFDqMzq+k60E5KZ8Bgv0QRFzg27RMV7qAklFupj3ZFKGM5bbR1vuGRAUcG6e65y8RcvLrCd4mASpPXji+eKQGlA/yeAvymfuGLsDYhGRane9u4n7W6hWOBvNtvDhvN4AT5yjbsgvY1ErjiM2EAkYsraAQzxrR8P71cAFcdnZWfXofd+fBdS1dxAth6K1il8NhBzjtPFJhu6Ld3aL5GVmv7TVQghI6gpwGWeaRRwDFYPK8Z0eRxUoHNNT4tGTiXLozGLTKO94sjtB4uQQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(979002)(6009001)(39850400002)(39840400002)(39860400002)(39450400003)(39400400002)(39410400002)(377454003)(24454002)(13464003)(66654002)(77096006)(9686003)(99286003)(6306002)(80792005)(66066001)(54906002)(99936001)(50986999)(6436002)(6506006)(55016002)(229853002)(2900100001)(38730400002)(110136004)(54356999)(76176999)(74316002)(102836003)(6116002)(561944003)(39060400002)(3846002)(7736002)(2906002)(53546009)(25786009)(3280700002)(1411001)(305945005)(6246003)(4326008)(33656002)(5660300001)(3660700001)(230783001)(93886004)(81166006)(2950100002)(6916009)(8936002)(122556002)(8676002)(7696004)(5890100001)(86362001)(53936002)(189998001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR02MB1369; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: ffa8244c-3749-41bc-c04b-08d48e76f3e2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM2PR02MB1369; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(120809045254105)(50582790962513)(21534305686606); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(6072148); SRVR:DM2PR02MB1369; BCL:0; PCL:0; RULEID:; SRVR:DM2PR02MB1369; x-forefront-prvs: 029174C036 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_BN3PR0201MB0867C158109E11A94E820227F1130BN3PR0201MB0867_" MIME-Version: 1.0 X-OriginatorOrg: jabil.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2017 20:41:31.1438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1369 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 20:44:12 -0000 --_002_BN3PR0201MB0867C158109E11A94E820227F1130BN3PR0201MB0867_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGVubmluZywNCg0KUGxlYXNlIHJldmlldyBpZiB0aGUgYXR0YWNoZWQgY2hhbmdlIHByb3Bv c2FsIGlzIG9rLg0KVGhhbmtzLA0KLSBYdWZlbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBYdWZlbmcgTGl1DQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjYsIDIw MTcgOToxOCBBTQ0KPiBUbzogJ0hlbm5pbmcgUm9nZ2UnIDxocm9nZ2VAZ21haWwuY29tPg0KPiBD YzogSm9uYXRoYW4gSGFyZHdpY2sgPEpvbmF0aGFuLkhhcmR3aWNrQG1ldGFzd2l0Y2guY29tPjsg QXRoYW5hc2lvcw0KPiBLeXBhcmxpcyA8QXRoYW5hc2lvc19LeXBhcmxpc0BqYWJpbC5jb20+OyBw YXJpa2hyQHZtd2FyZS5jb207DQo+IHpoYW5nbWluZ3VpQGh1YXdlaS5jb207IFJvdXRpbmcgV0cg PHJ0Z3dnQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSRTogUm91dGluZyBkaXJlY3RvcmF0ZSBRQSBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLXZycnANCj4gDQo+IEhpIEhlbm5pbmcsDQo+ IA0KPiBZZXMuIFdlIHdpbGwgYWRkIHNvbWUgZXhwbGFuYXRpb25zLg0KPiBUaGFua3MsDQo+IC0g WHVmZW5nDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogSGVu bmluZyBSb2dnZSBbbWFpbHRvOmhyb2dnZUBnbWFpbC5jb21dDQo+ID4gU2VudDogVHVlc2RheSwg QXByaWwgMjUsIDIwMTcgOTo1MCBBTQ0KPiA+IFRvOiBYdWZlbmcgTGl1IDxYdWZlbmdfTGl1QGph YmlsLmNvbT4NCj4gPiBDYzogSm9uYXRoYW4gSGFyZHdpY2sgPEpvbmF0aGFuLkhhcmR3aWNrQG1l dGFzd2l0Y2guY29tPjsgQXRoYW5hc2lvcw0KPiA+IEt5cGFybGlzIDxBdGhhbmFzaW9zX0t5cGFy bGlzQGphYmlsLmNvbT47IHBhcmlraHJAdm13YXJlLmNvbTsNCj4gPiB6aGFuZ21pbmd1aUBodWF3 ZWkuY29tOyBSb3V0aW5nIFdHIDxydGd3Z0BpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBSZTogUm91 dGluZyBkaXJlY3RvcmF0ZSBRQSByZXZpZXcgb2YNCj4gPiBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmct dnJycA0KPiA+DQo+ID4gT24gVHVlLCBBcHIgMjUsIDIwMTcgYXQgMzo0NyBQTSwgWHVmZW5nIExp dSA8WHVmZW5nX0xpdUBqYWJpbC5jb20+IHdyb3RlOg0KPiA+ID4NCj4gPiA+IEhpIEhlbm5pbmcs DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBUaGFuayB5b3UgbXVjaCBmb3IgdGhlIHJldmll dy4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IFlvdSBhcmUgcmlnaHQgYWJvdXQgdGhlIG1h cHBpbmcgZm9yICJhZGRyZXNzIG9mIHRoZSB2aXJ0dWFsIHJvdXRlciIuDQo+ID4gPiBUaGUNCj4g PiBleGlzdGluZyBZQU5HIGRhdGEgbW9kZWwgZm9yIGNvbmZpZ3VyaW5nIGFuZCBtYW5hZ2luZyBJ UCBhZGRyZXNzZXMgaXMNCj4gPiBSRkM3Mjc3LCB3aGljaCBhdWdtZW50cyB0aGUgaWV0Zi1pbnRl cmZhY2VzIG1vZGVsIHNwZWNpZmllZCBieQ0KPiA+IFJGQzcyMjMuIFRoaXMgVlJSUCBtb2RlbCBm b2xsb3dzIHRoZSBzYW1lIHBhcmFkaWdtLiBTdWNoIGEgc3RydWN0dXJlDQo+ID4gaXMgYWxzbyBW UlJQIHByb3RvY29scyBhcmUgdXN1YWxseSBpbXBsZW1lbnRlZC4NCj4gPg0KPiA+IE1heWJlIHRo ZSBuYW1pbmcgb2YgdGhlIHZhcmlhYmxlcyBvciB0aGUgZXhwbGFuYXRpb24gb2YgdGhlbSBjb3Vs ZCBiZQ0KPiA+IGltcHJvdmVkIHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhpcy4NCj4gPg0KPiA+IEhl bm5pbmcNCj4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gV2Ugd2lsbCBmaXggdGhlIGVy cm9yIGluICBBcHBlbmRpeCBBLiBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCj4gPiA+DQo+ID4gPg0K PiA+ID4NCj4gPiA+IFJlZ2FyZHMsDQo+ID4gPg0KPiA+ID4gLSBYdWZlbmcNCj4gPiA+DQo+ID4g Pg0KPiA+ID4NCj4gPiA+IEZyb206IEhlbm5pbmcgUm9nZ2UgW21haWx0bzpocm9nZ2VAZ21haWwu Y29tXQ0KPiA+ID4gU2VudDogTW9uZGF5LCBBcHJpbCAyNCwgMjAxNyAzOjQxIEFNDQo+ID4gPiBU bzogSm9uYXRoYW4gSGFyZHdpY2sgPEpvbmF0aGFuLkhhcmR3aWNrQG1ldGFzd2l0Y2guY29tPjsg WHVmZW5nIExpdQ0KPiA+ID4gPFh1ZmVuZ19MaXVAamFiaWwuY29tPjsgQXRoYW5hc2lvcyBLeXBh cmxpcw0KPiA+ID4gPEF0aGFuYXNpb3NfS3lwYXJsaXNAamFiaWwuY29tPjsgcGFyaWtockB2bXdh cmUuY29tOw0KPiA+ID4gemhhbmdtaW5ndWlAaHVhd2VpLmNvbQ0KPiA+ID4gQ2M6IFJvdXRpbmcg V0cgPHJ0Z3dnQGlldGYub3JnPg0KPiA+ID4gU3ViamVjdDogUmU6IFJvdXRpbmcgZGlyZWN0b3Jh dGUgUUEgcmV2aWV3IG9mDQo+ID4gPiBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmctdnJycA0KPiA+ID4N Cj4gPiA+DQo+ID4gPg0KPiA+ID4gSGksDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBKb25h dGhhbiBIYXJkd2ljayBhc2tlZCBtZSB0byBkbyBhbiBlYXJseSByZXZpZXcgb2YgdGhlDQo+ID4g PiBkcmFmdC1pZXRmLXJ0Z3dnLQ0KPiA+IHlhbmctdnJycCBkb2N1bWVudCAoY3VycmVudGx5IHJl dmlzaW9uIDAyKSBmb3IgdGhlIHJvdXRpbmcgZGlyZWN0b3JhdGUuDQo+ID4gPg0KPiA+ID4NCj4g PiA+DQo+ID4gPiBUaGUgZHJhZnQgaXRzZWxmIGlzIHByZXR0eSBzdHJhaWdodCBmb3J3YXJkIGFu ZCBjb21wYWN0LCBlc3BlY2lhbGx5DQo+ID4gPiB3aGVuIHlvdQ0KPiA+IGNvbnNpZGVyIHRoYXQg YSBsb3Qgb2YgdGV4dCBoYXMgdG8gYmUgcmVwZWF0ZWQgdHdvIG9yIGZvdXIgdGltZXMNCj4gPiAo SVB2NC9JUHY2LCBjb25maWcgdnMuIHJlYWQtb25seSBzdGF0ZSkuDQo+ID4gPg0KPiA+ID4NCj4g PiA+DQo+ID4gPiBCdXQgSSBoYWQgcXVpdGUgYSBiaXQgb2YgdHJvdWJsZSBtYXBwaW5nIHRoZSBw aHJhc2VzIGZyb20gdGhlIG5ldw0KPiA+ID4gZHJhZnQtaWV0Zi0NCj4gPiBydGd3Zy15YW5nLXZy cnAtMDIgZG9jdW1lbnQgdG8gdGhlIGV4aXN0aW5nIFZSUlAgZG9jdW1lbnRzIChlLmcuIFJGQzU3 OTgpLg0KPiA+IFRoaXMgbWlnaHQgY29tZSBmcm9tIG15IHVuZmFtaWxhcml0eSB3aXRoIFZSUlAu DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBUaGUgZHJhZnQgWUFORyBtb2RlbCBhbGxvd3Mg dG8gcmVhZCAoaWY6aW50ZXJmYWNlcy1zdGF0ZSkgYW5kDQo+ID4gPiBjb25maWd1cmUNCj4gPiAo aWY6aW50ZXJmYWNlcykgdmlydHVhbCBJUCBhZGRyZXNzZXMsIGJ1dCB0aGlzIGRvZXMgbm90IHNl ZW0gdG8gYmUgYQ0KPiA+IGNvbW1vbiBwaHJhc2UgZnJvbSB0aGUgUkZDcy4gSXMgaXQgdGhlIHNh bWUgYXMgImFkZHJlc3Mgb2YgdGhlIHZpcnR1YWwNCj4gPiByb3V0ZXIiIG9mdGVuIG1lbnRpb25l ZCBpbiBSRkM1Nzk4Pw0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gSW4gYWRkaXRpb24gdG8g dGhpcywgSSBmb3VuZCAoSSB0aGluaykgYSB0eXBvIG9yIGluY29uc2lzdGVuY3kgaW4gQXBwZW5k aXggQToNCj4gPiA+DQo+ID4gPiB0aGUgYXNjaWkgYXJ0IHNheXMgImV0aDAiIGJ1dCB0cmVlIHNh eXMgImV0aDEiLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gSGVubmluZyBSb2dnZQ0KPiA+ ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24gTW9uLCBNYXIgMjcsIDIwMTcgYXQgNTo0MyBQTSwg Sm9uYXRoYW4gSGFyZHdpY2sNCj4gPiA8Sm9uYXRoYW4uSGFyZHdpY2tAbWV0YXN3aXRjaC5jb20+ IHdyb3RlOg0KPiA+ID4NCj4gPiA+IEhpIEhlbm5pbmcNCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4g PiA+IFBsZWFzZSB3b3VsZCB5b3UgZG8gYSByb3V0aW5nIGRpcmVjdG9yYXRlIGVhcmx5IHJldmll dyBvZiB0aGlzDQo+ID4gPiBkcmFmdD8gIFdvdWxkDQo+ID4geW91IGJlIGFibGUgdG8gZG8gaXQg aW4gMiB0byAzIHdlZWtzPw0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gTWFueSB0aGFua3MN Cj4gPiA+DQo+ID4gPiBKb24NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ ID4gUGxlYXNlIHdvdWxkIHlvdSBkbyBhIHJvdXRpbmcgZGlyZWN0b3JhdGUgUUEgcmV2aWV3IG9m IHRoaXMgZHJhZnQ/DQo+ID4gPg0KPiA+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLXZycnAvDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4g PiBUaGUgZHJhZnQgaXMgc3RpbGwgaW4gdGhlIFJUR1dHIGFuZCBpcyByZWFkeSBmb3IgV0cgbGFz dCBjYWxsLiAgVGhlDQo+ID4gPiBXRyBjaGFpcnMNCj4gPiBoYXZlIGFza2VkIGZvciBhIFFBIHJl dmlldyBmcm9tIHRoZSBkaXJlY3RvcmF0ZS4gIFRoZSBmb2xsb3dpbmcgbGluaw0KPiA+IHByb3Zp ZGVzIGd1aWRhbmNlIG9uIFFBIHJldmlld3MuDQo+ID4gPg0KPiA+ID4gaHR0cHM6Ly90cmFjLmll dGYub3JnL3RyYWMvcnRnL3dpa2kvUnRnRGlyRG9jUWENCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4g PiA+DQo+ID4gPg0KPiA+ID4NCg== --_002_BN3PR0201MB0867C158109E11A94E820227F1130BN3PR0201MB0867_ Content-Type: text/html; name="draft-ietf-rtgwg-yang-vrrp-03-b-from-a.diff.html" Content-Description: draft-ietf-rtgwg-yang-vrrp-03-b-from-a.diff.html Content-Disposition: attachment; filename="draft-ietf-rtgwg-yang-vrrp-03-b-from-a.diff.html"; size=61769; creation-date="Fri, 28 Apr 2017 20:37:39 GMT"; modification-date="Fri, 28 Apr 2017 20:37:39 GMT" Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPiAKPCEtLSBHZW5lcmF0ZWQgYnkgcmZjZGlmZiAxLjQ1OiByZmNkaWZmICAtLT4gCjwh LS0gPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsIiA+IC0tPgo8IS0tIFN5c3RlbTogTUlOR1czMl9OVC02LjIgWExJVS1VUyAxLjAuMTIoMC40 Ni8zLzIpIDIwMTItMDctMDUgMTQ6NTYgaTY4NiB1bmtub3duIC0tPiAKPCEtLSBVc2luZyBhd2s6 IC9iaW4vZ2F3azogR05VIEF3ayAzLjAuNCAtLT4gCjwhLS0gVXNpbmcgZGlmZjogL2Jpbi9kaWZm OiBkaWZmIC0gR05VIGRpZmZ1dGlscyB2ZXJzaW9uIDIuNyAtLT4gCjwhLS0gVXNpbmcgd2RpZmY6 IDogIC0tPiAKPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPiAKPGhl YWQ+IAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PVVURi04IiAvPiAKICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVN0eWxlLVR5 cGUiIGNvbnRlbnQ9InRleHQvY3NzIiAvPiAKICA8dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1ydGd3 Zy15YW5nLXZycnAtMDMtYS50eHQgLSBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmctdnJycC0wMy1iLnR4 dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+IAogICAgYm9keSAgICB7IG1hcmdp bjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAKICAgIHRyICAgICAgeyB9IAogICAgdGQg ICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5OiBtb25vc3BhY2U7IHZlcnRpY2Fs LWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gCiAgICB0aCAgICAgIHsgZm9udC1zaXpl OiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1zaXplOiAwLjZlbTsgZm9udC1zdHlsZTog aXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyB9IAog ICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAucmlnaHQgIHsgYmFj a2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAj Q0NGOyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNCRkI7IH0gCiAgICAucmJs b2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAgIC5pbnNlcnQgeyBiYWNrZ3JvdW5k LWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tncm91bmQtY29sb3I6ICNBQ0Y7IH0g CiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGQjsgfSAKICAgIC5jb250ICAgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmViciB7IGJhY2tncm91bmQtY29sb3I6 ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsgYmFja2dyb3VuZC1jb2xvcjogI0ZG RjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmlnaHQ7IHBhZGRpbmc6IDAgMnB4OyB9 IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGVmdCAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAgICAucmlnaHQgLmNvbnQgeyBiYWNrZ3Jv dW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAuY29udCB7IGJhY2tncm91bmQtY29sb3I6 ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RENjsgfSAK ICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjMEREOyB9IAogICAgLmRlbGV0 ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0gCiAgICAuc3RhdHMsIC5zdGF0cyB0 ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgcGFkZGluZzogMnB4IDA7IH0g CiAgICBzcGFuLmhpZGUgeyBkaXNwbGF5OiBub25lOyBjb2xvcjogI2FhYTt9ICAgIGE6aG92ZXIg c3BhbiB7IGRpc3BsYXk6IGlubGluZTsgfSAgICB0ci5jaGFuZ2UgeyBiYWNrZ3JvdW5kLWNvbG9y OiBncmF5OyB9IAogICAgdHIuY2hhbmdlIGEgeyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNvbG9y OiBibGFjayB9IAogIDwvc3R5bGU+IAogICAgIDxzY3JpcHQ+CnZhciBjaHVua19pbmRleCA9IDA7 CnZhciBvbGRfY2h1bmsgPSBudWxsOwoKZnVuY3Rpb24gZm9ybWF0X2NodW5rKGluZGV4KSB7CiAg ICB2YXIgcHJlZml4ID0gImRpZmYiOwogICAgdmFyIHN0ciA9IGluZGV4LnRvU3RyaW5nKCk7CiAg ICBmb3IgKHg9MDsgeDwoNC1zdHIubGVuZ3RoKTsgKyt4KSB7CiAgICAgICAgcHJlZml4Kz0nMCc7 CiAgICB9CiAgICByZXR1cm4gcHJlZml4ICsgc3RyOwp9CgpmdW5jdGlvbiBmaW5kX2NodW5rKG4p ewogICAgcmV0dXJuIGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3IoJ3RyW2lkJD0iJyArIG4gKyAnIl0n KTsKfQoKZnVuY3Rpb24gY2hhbmdlX2NodW5rKG9mZnNldCkgewogICAgdmFyIGluZGV4ID0gY2h1 bmtfaW5kZXggKyBvZmZzZXQ7CiAgICB2YXIgbmV3X3N0cjsKICAgIHZhciBuZXdfY2h1bms7Cgog ICAgbmV3X3N0ciA9IGZvcm1hdF9jaHVuayhpbmRleCk7CiAgICBuZXdfY2h1bmsgPSBmaW5kX2No dW5rKG5ld19zdHIpOwogICAgaWYgKCFuZXdfY2h1bmspIHsKICAgICAgICByZXR1cm47CiAgICB9 CiAgICBpZiAob2xkX2NodW5rKSB7CiAgICAgICAgb2xkX2NodW5rLnN0eWxlLm91dGxpbmUgPSAi IjsKICAgIH0KICAgIG9sZF9jaHVuayA9IG5ld19jaHVuazsKICAgIG9sZF9jaHVuay5zdHlsZS5v dXRsaW5lID0gIjFweCBzb2xpZCByZWQiOwogICAgd2luZG93LmxvY2F0aW9uLmhhc2ggPSAiIyIg KyBuZXdfc3RyOwogICAgd2luZG93LnNjcm9sbEJ5KDAsLTEwMCk7CiAgICBjaHVua19pbmRleCA9 IGluZGV4Owp9Cgpkb2N1bWVudC5vbmtleWRvd24gPSBmdW5jdGlvbihlKSB7CiAgICBzd2l0Y2gg KGUua2V5Q29kZSkgewogICAgY2FzZSA3ODoKICAgICAgICBjaGFuZ2VfY2h1bmsoMSk7CiAgICAg ICAgYnJlYWs7CiAgICBjYXNlIDgwOgogICAgICAgIGNoYW5nZV9jaHVuaygtMSk7CiAgICAgICAg YnJlYWs7CiAgICB9Cn07CiAgIDwvc2NyaXB0PiAKPC9oZWFkPiAKPGJvZHkgPiAKICA8dGFibGUg Ym9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dHIgaWQ9InBh cnQtMSIgYmdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+Jm5ic3A7ZHJhZnQtaWV0Zi1ydGd3 Zy15YW5nLXZycnAtMDMtYS50eHQmbmJzcDs8L3RoPjx0aD4gPC90aD48dGg+Jm5ic3A7ZHJhZnQt aWV0Zi1ydGd3Zy15YW5nLXZycnAtMDMtYi50eHQmbmJzcDs8L3RoPjx0aD48L3RoPjwvdHI+IAog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0icGFydC0xIiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxz bWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTEiPjxlbT4g cGFnZSAyLCBsaW5lIDE4PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+ PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxh IGhyZWY9IiNwYXJ0LTEiPjxlbT4gcGFnZSAyLCBsaW5lIDE4PHNwYW4gY2xhc3M9ImhpZGUiPiAm cGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5UYWJsZSBvZiBDb250ZW50czwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlRhYmxlIG9mIENvbnRlbnRzPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAxLjEuICBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICAyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAxLjEu ICBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICAyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDEuMi4gIFRyZWUgRGlhZ3Jh bXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDEuMi4gIFRyZWUgRGlhZ3JhbXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgMS4zLiAgUHJlZml4ZXMgaW4gRGF0YSBOb2RlIE5hbWVzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgMS4zLiAgUHJlZml4ZXMgaW4gRGF0YSBOb2RlIE5hbWVzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMi4gIERl c2lnbiBvZiB0aGUgRGF0YSBNb2RlbCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMi4gIERlc2lnbiBvZiB0 aGUgRGF0YSBNb2RlbCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDIuMS4gIFNjb3BlIG9mIHRoZSBNb2RlbCAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDIuMS4gIFNjb3BlIG9mIHRoZSBNb2RlbCAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgMi4yLiAgUmVsYXRpb25zIHdpdGggSW50ZXJmYWNlIE1vZGVsIGFuZCBJUCBNb2Rl bCAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg Mi4yLiAgUmVsYXRpb25zIHdpdGggSW50ZXJmYWNlIE1vZGVsIGFuZCBJUCBNb2RlbCAuIC4gLiAu IC4gLiAuICAgNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAyLjMuICBQcm90b2Nv bCBDb25maWd1cmF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAyLjMuICBQcm90b2NvbCBDb25maWd1 cmF0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDAxIj48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgICAgMi40LiAgUHJvdG9jb2wgU3RhdGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Nzwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAyLjQuICBQcm90b2NvbCBTdGF0ZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij44 PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDIuNS4gIE5vdGlmaWNh dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPjg8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgICAgMi41LiAgTm90aWZpY2F0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+OTwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgMy4gIFlBTkcgTW9kdWxlIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPiA5PC9z cGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAzLiAgWUFORyBNb2R1bGUg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4g Y2xhc3M9Imluc2VydCI+MTA8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg IDQuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAzPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgNC4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA1LiAgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzxzcGFuIGNs YXNzPSJkZWxldGUiPjI8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IDUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAzPHNwYW4gY2xhc3M9Imluc2VydCI+Mzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgNi4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM8c3BhbiBjbGFzcz0iZGVsZXRlIj4yPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA2LiAgUmVmZXJlbmNlcyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzxzcGFuIGNs YXNzPSJpbnNlcnQiPjM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAg Ni4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAzPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Mjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgICA2LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4zPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgIDYuMi4gIEluZm9ybWF0aXZlIFJl ZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzxzcGFuIGNsYXNz PSJkZWxldGUiPjM8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAg Ni4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAzPHNwYW4gY2xhc3M9Imluc2VydCI+NTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgQXBwZW5kaXggQS4gIENvbXBsZXRlIE1vZGVsIFRyZWUgU3RydWN0dXJl ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM8c3BhbiBjbGFzcz0iZGVsZXRlIj41PC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBBcHBlbmRpeCBBLiAgQ29tcGxldGUg TW9kZWwgVHJlZSBTdHJ1Y3R1cmUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMzxzcGFuIGNsYXNz PSJpbnNlcnQiPjY8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEFwcGVu ZGl4IEIuICBEYXRhIFRyZWUgRXhhbXBsZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAzPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ODwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgQXBwZW5kaXggQi4gIERhdGEgVHJlZSBFeGFtcGxlICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDM8c3BhbiBjbGFzcz0iaW5zZXJ0Ij45PC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNDxzcGFuIGNsYXNzPSJk ZWxldGUiPjE8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEF1dGhv cnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA0PHNwYW4gY2xhc3M9Imluc2VydCI+Mjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg VGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgWUFORyBbUkZDNjAyMF1bUkZDNzk1MF0gZGF0YSBt b2RlbCBmb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50 IGludHJvZHVjZXMgYSBZQU5HIFtSRkM2MDIwXVtSRkM3OTUwXSBkYXRhIG1vZGVsIGZvcjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVmlydHVhbCBSb3V0ZXIgUmVkdW5kYW5jeSBQcm90 b2NvbCAoVlJSUCkgW1JGQzM3NjhdW1JGQzU3OThdLiAgVlJSUDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIFZpcnR1YWwgUm91dGVyIFJlZHVuZGFuY3kgUHJvdG9jb2wgKFZSUlAp IFtSRkMzNzY4XVtSRkM1Nzk4XS4gIFZSUlA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHByb3ZpZGVzIGhpZ2hlciByZXNpbGllbmN5IGJ5IHNwZWNpZnlpbmcgYW4gZWxlY3Rpb24gcHJv dG9jb2wgdGhhdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHByb3ZpZGVzIGhp Z2hlciByZXNpbGllbmN5IGJ5IHNwZWNpZnlpbmcgYW4gZWxlY3Rpb24gcHJvdG9jb2wgdGhhdDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZHluYW1pY2FsbHkgYXNzaWducyByZXNwb25z aWJpbGl0eSBmb3IgYSB2aXJ0dWFsIHJvdXRlciB0byBvbmUgb2YgdGhlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgZHluYW1pY2FsbHkgYXNzaWducyByZXNwb25zaWJpbGl0eSBm b3IgYSB2aXJ0dWFsIHJvdXRlciB0byBvbmUgb2YgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBWUlJQIHJvdXRlcnMgb24gYSBMQU4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgVlJSUCByb3V0ZXJzIG9uIGEgTEFOLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBUaGlzIFlBTkcgbW9kZWwgc3VwcG9ydHMgYm90aCB2ZXJzaW9uIDIgYW5kIHZl cnNpb24gMyBvZiBWUlJQLiAgVlJSUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFRoaXMgWUFORyBtb2RlbCBzdXBwb3J0cyBib3RoIHZlcnNpb24gMiBhbmQgdmVyc2lvbiAzIG9m IFZSUlAuICBWUlJQPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0ciBpZD0icGFydC0yIiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTIiPjxlbT4gcGFnZSA1LCBs aW5lIDE1PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+ IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNw YXJ0LTIiPjxlbT4gcGFnZSA1LCBsaW5lIDE1PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3Nw YW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtb2R1bGU6IGlldGYtaW50ZXJmYWNlczwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1vZHVsZTogaWV0Zi1pbnRlcmZhY2VzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICArLS1ydyBpbnRlcmZhY2VzPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKy0tcncgaW50ZXJmYWNlczwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgfCAgKy0tcncgaW50ZXJmYWNlKiBbbmFtZV08L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB8ICArLS1ydyBpbnRlcmZhY2UqIFtuYW1l XTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgLi4uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgLi4uPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICB8ICAgICArLS1ydyBpcDppcHY0ITwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgIHwgICAgICstLXJ3IGlwOmlwdjQhPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICB8ICAgICB8ICArLS1ydyBpcDphZGRyZXNzKiBbaXBdPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAgfCAgKy0tcncgaXA6YWRkcmVz cyogW2lwXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAg Li4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAg Li4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB8ICAgICB8ICArLS1ydyB2cnJw OnZycnA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB8ICAgICB8ICArLS1y dyB2cnJwOnZycnA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgIHwgICAg ICstLXJ3IHZycnA6dnJycC1pbnN0YW5jZSogW3ZyaWRdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgfCAgICAgfCAgICAgKy0tcncgdnJycDp2cnJwLWluc3RhbmNlKiBbdnJp ZF08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgIHwgICAgICAgICstLXJ3 IHZycnA6dnJpZCAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50ODwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHwgICAgIHwgICAgICAgICstLXJ3IHZycnA6dnJpZCAg ICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50ODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgfCAgICAgfCAg ICAgICAgKy0tcncgdnJycDp2aXJ0dWFsLWlwdjQtYWRkcmVzc2VzPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB8ICAgICArLS1ydyBpcDppcHY2ITwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHwgICAgICstLXJ3IGlwOmlwdjYhPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB8ICAgICAgICArLS1ydyBpcDphZGRyZXNz KiBbaXBdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAgICAgKy0t cncgaXA6YWRkcmVzcyogW2lwXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICAgICAgICAgLi4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAg ICAgICAgICAgICAgLi4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB8ICAgICAg ICArLS1ydyB2cnJwOnZycnA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICB8 ICAgICAgICArLS1ydyB2cnJwOnZycnA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg IHwgICAgICAgICAgICstLXJ3IHZycnA6dnJycC1pbnN0YW5jZSogW3ZyaWRdPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAgICAgICAgKy0tcncgdnJycDp2cnJwLWlu c3RhbmNlKiBbdnJpZF08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgICAg ICAgICAgICstLXJ3IHZycnA6dnJpZCAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50ODwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHwgICAgICAgICAgICAgICstLXJ3 IHZycnA6dnJpZCAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50ODwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMyI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg ICAgfCAgICAgICAgICAgICAgKy0tcncgdnJycDp2aXJ0dWFsLWlwdjYtYWRkcmVzc2VzPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg Li4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgLi4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICArLS1ybyBpbnRlcmZh Y2VzLXN0YXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKy0tcm8gaW50 ZXJmYWNlcy1zdGF0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgKy0tcm8g aW50ZXJmYWNlKiBbbmFtZV08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICArLS1ybyBpbnRlcmZhY2UqIFtuYW1lXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgICAgICAgLi4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAg ICAgICAgLi4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICB8ICArLS1ybyBp cDppcHY0ITwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIHwgICstLXJv IGlwOmlwdjQhPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICB8ICB8ICArLS1y byBpcDphZGRyZXNzKiBbaXBdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgfCAgfCAgKy0tcm8gaXA6YWRkcmVzcyogW2lwXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgICAgICAgICAgICAgICAgLi4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgICAgICAgICAgLi4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICAgICAgICB8ICB8ICArLS1ybyB2cnJwOnZycnA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICB8ICB8ICArLS1ybyB2cnJwOnZycnA8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgIHwgIHwgICAgICstLXJvIHZycnA6dnJycC1pbnN0YW5jZSogW3ZyaWRd PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgfCAgfCAgICAgKy0tcm8g dnJycDp2cnJwLWluc3RhbmNlKiBbdnJpZF08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgIHwgIHwgICAgICAgICstLXJvIHZycnA6dnJpZCAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1aW50ODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIHwgIHwg ICAgICAgICstLXJvIHZycnA6dnJpZCAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50ODwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwNCI+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgICAgICAgfCAgfCAgICAgICAgKy0tcm8gdnJycDp2aXJ0dWFsLWlwdjQtYWRk cmVzc2VzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgLi4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgLi4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg ICB8ICArLS1ybyBpcDppcHY2ITwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgIHwgICstLXJvIGlwOmlwdjYhPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg ICB8ICAgICArLS1ybyBpcDphZGRyZXNzKiBbaXBdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgfCAgICAgKy0tcm8gaXA6YWRkcmVzcyogW2lwXTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgLi4uPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgLi4uPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICB8ICAgICArLS1ybyB2cnJwOnZycnA8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICB8ICAgICArLS1ybyB2cnJwOnZycnA8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIHwgICAgICAgICstLXJvIHZycnA6dnJycC1pbnN0 YW5jZSogW3ZyaWRdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgfCAg ICAgICAgKy0tcm8gdnJycDp2cnJwLWluc3RhbmNlKiBbdnJpZF08L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgIHwgICAgICAgICAgICstLXJvIHZycnA6dnJpZCAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1aW50ODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgICAgIHwgICAgICAgICAgICstLXJvIHZycnA6dnJpZCAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1aW50ODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlk PSJkaWZmMDAwNSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgfCAgICAgICAgICAgKy0tcm8gdnJycDp2aXJ0 dWFsLWlwdjYtYWRkcmVzc2VzPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgLi4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICAgICArLS1ybyB2cnJwOnZycnAtZ2xvYmFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgKy0tcm8gdnJycDp2cnJwLWdsb2JhbDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgLi4uPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgLi4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIEluIHRoZSBhYm92ZSBmaWd1cmUsIGEgdHJlZSBub2RlIHdpdGhvdXQgYSBw cmVmaXggaXMgZnJvbSB0aGUgbW9kZWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBJbiB0aGUgYWJvdmUgZmlndXJlLCBhIHRyZWUgbm9kZSB3aXRob3V0IGEgcHJlZml4IGlzIGZy b20gdGhlIG1vZGVsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAiaWV0Zi1pbnRlcmZh Y2VzIi4gIEEgdHJlZSBub2RlIHdpdGggcHJlZml4ICJpcDoiIGlzIGZyb20gdGhlIG1vZGVsPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgImlldGYtaW50ZXJmYWNlcyIuICBBIHRy ZWUgbm9kZSB3aXRoIHByZWZpeCAiaXA6IiBpcyBmcm9tIHRoZSBtb2RlbDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgImlldGYtaXAiLiAgQSB0cmVlIG5vZGUgd2l0aCBwcmVmaXggInZy cnA6IiBpcyBmcm9tIHRoZSBWUlJQIG1vZGVsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgImlldGYtaXAiLiAgQSB0cmVlIG5vZGUgd2l0aCBwcmVmaXggInZycnA6IiBpcyBmcm9t IHRoZSBWUlJQIG1vZGVsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzcGVjaWZpZWQg aW4gdGhpcyBkb2N1bWVudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzcGVj aWZpZWQgaW4gdGhpcyBkb2N1bWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgVGhlICJ2cnJwIiBjb250YWluZXIgY29udGFpbnMgYSBsaXN0IG9mIHZycnAtaW5zdGFuY2Ug bm9kZXMsIHdoaWNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlICJ2cnJw IiBjb250YWluZXIgY29udGFpbnMgYSBsaXN0IG9mIHZycnAtaW5zdGFuY2Ugbm9kZXMsIHdoaWNo PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhcmUgaW5zdGFudGlhdGVkIHVuZGVyIGFu IGludGVyZmFjZSBmb3IgYSBzcGVjaWZpZWQgYWRkcmVzcyBmYW1pbHk8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBhcmUgaW5zdGFudGlhdGVkIHVuZGVyIGFuIGludGVyZmFjZSBm b3IgYSBzcGVjaWZpZWQgYWRkcmVzcyBmYW1pbHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIChJUHY0IG9yIElQdjYpLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChJ UHY0IG9yIElQdjYpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgaWQ9ImRpZmYwMDA2Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBFYWNoIHZycnAtaW5zdGFuY2Ugbm9kZSBy ZXByZXNlbnRzIGEgVlJSUCByb3V0ZXIgc3RhdGUgbWFjaGluZTwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDYuNCBvZiBbUkZDNTc5OF0s IHByb3ZpZGluZyB0aGUgY29uZmlndXJhdGlvbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIGFuZCBzdGF0ZSBpbmZvcm1hdGlvbiBmb3IgdGhlIGVsZWN0aW9uIHByb2Nlc3Mg b2YgYSB2aXJ0dWFsIHJvdXRlci48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICBUaGUgSVAgYWRkcmVzc2VzIG9uIHRoZSBhdWdtZW50ZWQgaW50ZXJmYWNlIGFyZSB0aGUgcmVh bCBhZGRyZXNzZXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB0aHJvdWdo IHdoaWNoIHRoZSBWUlJQIHJvdXRlciBvcGVyYXRlcy4gIFRoZSBJUHY0IG9yIElQdjYgYWRkcmVz cyhlcyk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBhc3NvY2lhdGVkIHdp dGggYSB2aXJ0dWFsIHJvdXRlciAoZGVzY3JpYmVkIGluIFNlY3Rpb24gMSBvZjwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFtSRkM1Nzk4XSkgYXJlIG1vZGVsZWQgYXMgYSBs aXN0IG9mIElQdjQgb3IgSVB2NiBhZGRyZXNzZXMgdW5kZXIgdGhlPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgdnJycC1pbnN0YW5jZS48L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+Mi4zLiAgUHJvdG9jb2wgQ29uZmlndXJhdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjIuMy4gIFByb3RvY29sIENvbmZpZ3VyYXRpb248L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIG1vZGVsIHN0cnVjdHVyZSBmb3IgdGhlIHByb3RvY29s IGNvbmZpZ3VyYXRpb24gaXMgYXMgc2hvd24gYmVsb3c6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgVGhlIG1vZGVsIHN0cnVjdHVyZSBmb3IgdGhlIHByb3RvY29sIGNvbmZpZ3Vy YXRpb24gaXMgYXMgc2hvd24gYmVsb3c6PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIGF1Z21lbnQgL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlL2lwOmlwdjQ6PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXVnbWVudCAvaWY6aW50ZXJmYWNlcy9pZjppbnRl cmZhY2UvaXA6aXB2NDo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICstLXJ3IHZy cnA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICArLS1ydyB2cnJwPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICArLS1ydyB2cnJwLWluc3RhbmNlKiBbdnJp ZF08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICArLS1ydyB2cnJwLWlu c3RhbmNlKiBbdnJpZF08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICst LXJ3IHZyaWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDg8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICArLS1ydyB2cmlkICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHVpbnQ4PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICB8 ICAgICAuLi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICB8ICAg ICAuLi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICstLXJ3IHRyYWNr PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgKy0tcncgdHJhY2s8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0 LTMiIGNsYXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5n ZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMyI+PGVtPiBwYWdlIDYsIGxpbmUgNDc8c3BhbiBj bGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iI3BhcnQtMyI+PGVtPiBw YWdlIDcsIGxpbmUgNDM8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48 L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgIHwgICstLXJ3IG5ldHdvcmtzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgfCAgKy0tcncgbmV0d29ya3M8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgIHwgICAgICstLXJ3IG5ldHdvcmsqIFtwcmVm aXhdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgfCAgICAgKy0t cncgbmV0d29yayogW3ByZWZpeF08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAg ICAgIHwgICAgICAgICstLXJ3IHByZWZpeCAgICAgICAgICAgICAgICBpbmV0OmlwdjYtcHJlZml4 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgfCAgICAgICAgKy0t cncgcHJlZml4ICAgICAgICAgICAgICAgIGluZXQ6aXB2Ni1wcmVmaXg8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgIHwgICAgICAgICAgICAgIC4uLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgIHwgICAgICAgICAgICAgIC4uLjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgKy0tcncgdmlydHVhbC1pcHY2LWFkZHJl c3NlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICstLXJ3IHZp cnR1YWwtaXB2Ni1hZGRyZXNzZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAg ICAgICAgICstLXJ3IHZpcnR1YWwtaXB2Ni1hZGRyZXNzKiBbaXB2Ni1hZGRyZXNzXTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICstLXJ3IHZpcnR1YWwtaXB2 Ni1hZGRyZXNzKiBbaXB2Ni1hZGRyZXNzXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgICAgICAgICAgKy0tcncgaXB2Ni1hZGRyZXNzICAgIGluZXQ6aXB2Ni1hZGRyZXNzPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgKy0tcncgaXB2 Ni1hZGRyZXNzICAgIGluZXQ6aXB2Ni1hZGRyZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFRoZSBtb2RlbCBhbGxvd3MgdG8gY29uZmlndXJlIHRoZSBmb2xsb3dpbmcgcHJv dG9jb2wgZW50aXRpZXM6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIG1v ZGVsIGFsbG93cyB0byBjb25maWd1cmUgdGhlIGZvbGxvd2luZyBwcm90b2NvbCBlbnRpdGllczo8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZm MDAwNyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBvICBWUlJQIGluc3RhbmNlICh2ZXJzaW9uIDIgb3IgdmVyc2lv biAzKTxzcGFuIGNsYXNzPSJkZWxldGUiPi48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIG8gIFZSUlAgaW5zdGFuY2UgKHZlcnNpb24gMiBvciB2ZXJzaW9uIDMpPHNw YW4gY2xhc3M9Imluc2VydCI+LCByZXByZXNlbnRpbmcgYSBWUlJQPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgICAgcm91dGVyLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwOCI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBvICBWaXJ0dWFsIElQdjQgb3IgSVB2NiBhZGRyZXNzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBvICBWaXJ0dWFsIElQdjQgb3IgSVB2NiBhZGRyZXNzPHNwYW4gY2xhc3M9 Imluc2VydCI+IGFzc29jaWF0ZWQgd2l0aCBhIHZpcnR1YWwgcm91dGVyPC9zcGFuPi48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwOSI+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBvICBUcmFja2luZyBpbnRlcmZhY2UuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIG8gIFRyYWNraW5nIGludGVyZmFjZTxzcGFuIGNsYXNzPSJpbnNlcnQi PiwgdG8gZGV0ZWN0IGludGVyZmFjZSBjb25uZWN0aXZpdHkgZmFpbHVyZXM8L3NwYW4+LjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDEw Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIG8gIFRyYWNraW5nIG5ldHdvcmsuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIG8gIFRyYWNraW5nIG5ldHdvcms8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4s IHRvIGRldGVjdCBpbnRlcmZhY2UgY29ubmVjdGl2aXR5IGZhaWx1cmVzPC9zcGFuPi48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Mi40LiAgUHJvdG9jb2wgU3RhdGVzPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Mi40LiAgUHJvdG9jb2wgU3RhdGVzPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBtb2RlbCBzdHJ1Y3R1cmUgZm9yIHRoZSBwcm90 b2NvbCBzdGF0ZXMgaXMgYXMgc2hvd24gYmVsb3c6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgVGhlIG1vZGVsIHN0cnVjdHVyZSBmb3IgdGhlIHByb3RvY29sIHN0YXRlcyBpcyBh cyBzaG93biBiZWxvdzo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXVnbWVu dCAvaWY6aW50ZXJmYWNlcy1zdGF0ZS9pZjppbnRlcmZhY2UvaXA6aXB2NDo8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhdWdtZW50IC9pZjppbnRlcmZhY2VzLXN0YXRlL2lmOmlu dGVyZmFjZS9pcDppcHY0OjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgKy0tcm8g dnJycDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICstLXJvIHZycnA8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICstLXJvIHZycnAtaW5zdGFuY2UqIFt2 cmlkXTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICstLXJvIHZycnAt aW5zdGFuY2UqIFt2cmlkXTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAg Ky0tcm8gdnJpZCAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50ODwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICstLXJvIHZyaWQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdWludDg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg IHwgICAgIC4uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgIHwg ICAgIC4uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIg aWQ9InBhcnQtNCIgY2xhc3M9ImNoYW5nZSIgPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC00Ij48ZW0+IHBhZ2UgOCwgbGluZSAx NzxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3Ro Pjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC00 Ij48ZW0+IHBhZ2UgOSwgbGluZSAxMzxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwv ZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgKy0tcm8gJmx0O3BlciBpbnN0YW5j ZSBzdGF0aXN0aWNzJmd0OzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAg ICAgICAgICstLXJvICZsdDtwZXIgaW5zdGFuY2Ugc3RhdGlzdGljcyZndDs8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXVnbWVudCAvaWY6aW50ZXJmYWNlcy1zdGF0ZTo8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhdWdtZW50IC9pZjppbnRlcmZhY2VzLXN0 YXRlOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgKy0tcm8gdnJycC1nbG9iYWw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICArLS1ybyB2cnJwLWdsb2JhbDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgKy0tcm8gJmx0O2dsb2JhbCBvcGVy YXRpb25hbCBzdGF0ZXMmZ3Q7PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgKy0tcm8gJmx0O2dsb2JhbCBvcGVyYXRpb25hbCBzdGF0ZXMmZ3Q7PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICArLS1ybyBzdGF0aXN0aWNzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgKy0tcm8gc3RhdGlzdGljczwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgKy0tcm8gJmx0O2dsb2JhbCBzdGF0aXN0aWNzJmd0Ozwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICstLXJvICZsdDtnbG9i YWwgc3RhdGlzdGljcyZndDs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhl IG1vZGVsIGFsbG93cyB0byByZXRyaWV2ZSBwcm90b2NvbCBzdGF0ZXMgYXQgdGhlIGZvbGxvd2lu ZyBsZXZlbHM6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIG1vZGVsIGFs bG93cyB0byByZXRyaWV2ZSBwcm90b2NvbCBzdGF0ZXMgYXQgdGhlIGZvbGxvd2luZyBsZXZlbHM6 PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlm ZjAwMTEiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+ICAgbyAgVlJSUCBpbnN0YW5jZSAodmVyc2lvbiAyIG9yIHZlcnNp b24gMyk8c3BhbiBjbGFzcz0iZGVsZXRlIj4uPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBvICBWUlJQIGluc3RhbmNlICh2ZXJzaW9uIDIgb3IgdmVyc2lvbiAzKTxz cGFuIGNsYXNzPSJpbnNlcnQiPiwgcmVwcmVzZW50aW5nIGEgVlJSUDwvc3Bhbj48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxz cGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIHJvdXRlci48L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTIiPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgbyAgVmlydHVhbCBJUHY0IG9yIElQdjYgYWRkcmVzcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgbyAgVmlydHVhbCBJUHY0IG9yIElQdjYgYWRkcmVzczxzcGFuIGNsYXNz PSJpbnNlcnQiPiBhc3NvY2lhdGVkIHdpdGggYSB2aXJ0dWFsIHJvdXRlcjwvc3Bhbj4uPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTMi Pjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgbyAgVHJhY2tpbmcgaW50ZXJmYWNlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICBvICBUcmFja2luZyBpbnRlcmZhY2U8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4sIHRvIGRldGVjdCBpbnRlcmZhY2UgY29ubmVjdGl2aXR5IGZhaWx1cmVzPC9zcGFuPi48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAx NCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBvICBUcmFja2luZyBuZXR3b3JrLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICBvICBUcmFja2luZyBuZXR3b3JrPHNwYW4gY2xhc3M9Imluc2VydCI+ LCB0byBkZXRlY3QgaW50ZXJmYWNlIGNvbm5lY3Rpdml0eSBmYWlsdXJlczwvc3Bhbj4uPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIEdsb2JhbCBzdGF0ZXMgYW5kIHN0YXRp c3RpY3Mgc3VtbWFyaXppbmcgYWxsIGluc3RhbmNlcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBvICBHbG9iYWwgc3RhdGVzIGFuZCBzdGF0aXN0aWNzIHN1bW1hcml6aW5nIGFs bCBpbnN0YW5jZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjIuNS4gIE5vdGlm aWNhdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4yLjUuICBOb3RpZmljYXRp b25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgbW9kZWwgZGVmaW5l cyB0aGUgZm9sbG93aW5nIFZSUlAgc3BlY2lmaWMgbm90aWZpY2F0aW9uczo8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIG1vZGVsIGRlZmluZXMgdGhlIGZvbGxvd2luZyBW UlJQIHNwZWNpZmljIG5vdGlmaWNhdGlvbnM6PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIG5vdGlmaWNhdGlvbnM6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg bm90aWZpY2F0aW9uczo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICstLS1uIHZy cnAtbmV3LW1hc3Rlci1ldmVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICstLS1uIHZycnAtbmV3LW1hc3Rlci1ldmVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgfCAgKy0tcm8gbWFzdGVyLWlwLWFkZHJlc3MgICAgaW5ldDppcC1hZGRyZXNzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgKy0tcm8gbWFzdGVyLWlwLWFkZHJl c3MgICAgaW5ldDppcC1hZGRyZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0icGFydC01IiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxz bWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTUiPjxlbT4g cGFnZSA5LCBsaW5lIDM0PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+ PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxh IGhyZWY9IiNwYXJ0LTUiPjxlbT4gcGFnZSAxMCwgbGluZSAyOTxzcGFuIGNsYXNzPSJoaWRlIj4g JnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBTdWJzY3JpYmUg bm90aWZpY2F0aW9ucyBvbiBhIHBlciBjbGllbnQgYmFzaXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgbyAgU3Vic2NyaWJlIG5vdGlmaWNhdGlvbnMgb24gYSBwZXIgY2xpZW50 IGJhc2lzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBTcGVjaWZ5IHN1 YnRyZWUgZmlsdGVycyBvciB4cGF0aCBmaWx0ZXJzIHNvIHRoYXQgb25seSBpbnRlcmVzdGVkPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgU3BlY2lmeSBzdWJ0cmVlIGZpbHRl cnMgb3IgeHBhdGggZmlsdGVycyBzbyB0aGF0IG9ubHkgaW50ZXJlc3RlZDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgY29udGVudHMgd2lsbCBiZSBzZW50LjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGNvbnRlbnRzIHdpbGwgYmUgc2VudC48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgU3BlY2lmeSBlaXRoZXIgcGVyaW9kaWMgb3Ig b24tZGVtYW5kIG5vdGlmaWNhdGlvbnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgbyAgU3BlY2lmeSBlaXRoZXIgcGVyaW9kaWMgb3Igb24tZGVtYW5kIG5vdGlmaWNhdGlvbnMu PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjMuICBZQU5HIE1vZHVsZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjMuICBZQU5HIE1vZHVsZTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE1Ij48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgICZsdDtDT0RFIEJFR0lOUyZndDsgZmlsZSAiaWV0Zi12cnJwQDIwMTctMDQtMjxzcGFuIGNs YXNzPSJkZWxldGUiPjQ8L3NwYW4+LnlhbmciPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgICZsdDtDT0RFIEJFR0lOUyZndDsgZmlsZSAiaWV0Zi12cnJwQDIwMTctMDQtMjxzcGFu IGNsYXNzPSJpbnNlcnQiPjc8L3NwYW4+LnlhbmciPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBtb2R1bGUgaWV0Zi12cnJwIHs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBtb2R1bGUgaWV0Zi12cnJwIHs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgeWFu Zy12ZXJzaW9uIDEuMTs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIHlhbmct dmVyc2lvbiAxLjE7PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIG5hbWVzcGFjZSAi dXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtdnJycCI7PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICBuYW1lc3BhY2UgInVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFu ZzppZXRmLXZycnAiOzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICBwcmVmaXggInZy cnAiOzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgcHJlZml4ICJ2cnJwIjs8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICBpbXBvcnQgaWV0Zi1pbmV0LXR5 cGVzIHs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIGltcG9ydCBpZXRmLWlu ZXQtdHlwZXMgezwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIHByZWZpeCAiaW5l dCI7PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIHByZWZpeCAiaW5ldCI7 PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIH08L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgIH08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICBp bXBvcnQgaWV0Zi15YW5nLXR5cGVzIHs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgIGltcG9ydCBpZXRmLXlhbmctdHlwZXMgezwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtNiIgY2xhc3M9ImNoYW5nZSIgPjx0ZD48L3Rk Pjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC02 Ij48ZW0+IHBhZ2UgMTAsIGxpbmUgMzk8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48 L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwv c21hbGw+PGEgaHJlZj0iI3BhcnQtNiI+PGVtPiBwYWdlIDExLCBsaW5lIDM1PHNwYW4gY2xhc3M9 ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgIEVkaXRv cjogICBBY2VlIExpbmRlbTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAg RWRpdG9yOiAgIEFjZWUgTGluZGVtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg ICAgICAgICAgICAmbHQ7bWFpbHRvOmFjZWVAY2lzY28uY29tJmd0OzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICZsdDttYWlsdG86YWNlZUBjaXNjby5j b20mZ3Q7PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgRWRpdG9yOiAg IE1pbmd1aSBaaGFuZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgRWRp dG9yOiAgIE1pbmd1aSBaaGFuZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICAgICAgJmx0O21haWx0bzp6aGFuZ21pbmd1aUBodWF3ZWkuY29tJmd0OyI7PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgJmx0O21haWx0bzp6aGFu Z21pbmd1aUBodWF3ZWkuY29tJmd0OyI7PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgZGVzY3JpcHRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIGRl c2NyaXB0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgIlRoaXMgWUFORyBt b2R1bGUgZGVmaW5lcyBhIG1vZGVsIGZvciBtYW5hZ2luZyBWaXJ0dWFsIFJvdXRlcjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAiVGhpcyBZQU5HIG1vZHVsZSBkZWZpbmVz IGEgbW9kZWwgZm9yIG1hbmFnaW5nIFZpcnR1YWwgUm91dGVyPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgIFJlZHVuZGFuY3kgUHJvdG9jb2wgKFZSUlApIHZlcnNpb24gMiBhbmQg dmVyc2lvbiAzLiI7PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICBSZWR1 bmRhbmN5IFByb3RvY29sIChWUlJQKSB2ZXJzaW9uIDIgYW5kIHZlcnNpb24gMy4iOzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE2Ij48 dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPiAgICAgcmV2aXNpb24gMjAxNy0wNC0yPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NDwv c3Bhbj4gezwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgIHJldmlzaW9uIDIw MTctMDQtMjxzcGFuIGNsYXNzPSJpbnNlcnQiPjc8L3NwYW4+IHs8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICBkZXNjcmlwdGlvbiAiSW5pdGlhbCByZXZpc2lvbiI7PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIGRlc2NyaXB0aW9uICJJbml0aWFsIHJldmlz aW9uIjs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICByZWZlcmVuY2U8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICAiUkZDIFhYWFg6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBW aXJ0dWFsIFJvdXRlciBSZWR1bmRhbmN5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgIlJGQyBYWFhYOiBBIFlBTkcgRGF0YSBNb2RlbCBmb3IgVmlydHVhbCBSb3V0ZXIg UmVkdW5kYW5jeTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgIFByb3RvY29s IChWUlJQKS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgUHJvdG9j b2wgKFZSUlApLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgIFJGQyAyNzg3 OiBEZWZpbml0aW9ucyBvZiBNYW5hZ2VkIE9iamVjdHMgZm9yIHRoZSBWaXJ0dWFsPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgIFJGQyAyNzg3OiBEZWZpbml0aW9ucyBv ZiBNYW5hZ2VkIE9iamVjdHMgZm9yIHRoZSBWaXJ0dWFsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICAgICAgUm91dGVyIFJlZHVuZGFuY3kgUHJvdG9jb2wuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgIFJvdXRlciBSZWR1bmRhbmN5IFByb3RvY29sLjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgIFJGQyAzNzY4OiBWaXJ0dWFsIFJv dXRlciBSZWR1bmRhbmN5IFByb3RvY29sIChWUlJQKS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICAgUkZDIDM3Njg6IFZpcnR1YWwgUm91dGVyIFJlZHVuZGFuY3kgUHJv dG9jb2wgKFZSUlApLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgIFJGQyA1 Nzk4OiBWaXJ0dWFsIFJvdXRlciBSZWR1bmRhbmN5IFByb3RvY29sIChWUlJQKSBWZXJzaW9uIDMu PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgIFJGQyA1Nzk4OiBWaXJ0 dWFsIFJvdXRlciBSZWR1bmRhbmN5IFByb3RvY29sIChWUlJQKSBWZXJzaW9uIDMuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgUkZDIDY1Mjc6IERlZmluaXRpb25zIG9mIE1h bmFnZWQgT2JqZWN0cyBmb3IgdGhlIFZpcnR1YWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgUkZDIDY1Mjc6IERlZmluaXRpb25zIG9mIE1hbmFnZWQgT2JqZWN0cyBm b3IgdGhlIFZpcnR1YWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICBSb3V0 ZXIgUmVkdW5kYW5jeSBQcm90b2NvbCBWZXJzaW9uIDMgKFZSUlB2MykuIjs8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgUm91dGVyIFJlZHVuZGFuY3kgUHJvdG9jb2wg VmVyc2lvbiAzIChWUlJQdjMpLiI7PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0icGFydC03IiBjbGFzcz0iY2hhbmdlIiA+PHRkPjwvdGQ+PHRoPjxz bWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTciPjxlbT4g cGFnZSAyMCwgbGluZSAyMTxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9h PjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48 YSBocmVmPSIjcGFydC03Ij48ZW0+IHBhZ2UgMjEsIGxpbmUgMTk8c3BhbiBjbGFzcz0iaGlkZSI+ ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgbWF4LWVsZW1l bnRzIDE2OzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgbWF4LWVs ZW1lbnRzIDE2OzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICBkZXNjcmlw dGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgZGVzY3JpcHRp b248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAiVmlydHVhbCBJUCBh ZGRyZXNzZXMgZm9yIGEgc2luZ2xlIFZSUlAgaW5zdGFuY2UuIEZvciBhPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICJWaXJ0dWFsIElQIGFkZHJlc3NlcyBmb3Ig YSBzaW5nbGUgVlJSUCBpbnN0YW5jZS4gRm9yIGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgVlJSUCBvd25lciByb3V0ZXIsIHRoZSB2aXJ0dWFsIGFkZHJlc3MgbXVz dCBtYXRjaCBvbmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAg IFZSUlAgb3duZXIgcm91dGVyLCB0aGUgdmlydHVhbCBhZGRyZXNzIG11c3QgbWF0Y2ggb25lPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIG9mIHRoZSBJUCBhZGRyZXNz ZXMgY29uZmlndXJlZCBvbiB0aGUgaW50ZXJmYWNlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgICAgICBvZiB0aGUgSVAgYWRkcmVzc2VzIGNvbmZpZ3VyZWQgb24gdGhl IGludGVyZmFjZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBjb3Jy ZXNwb25kaW5nIHRvIHRoZSB2aXJ0dWFsIHJvdXRlci4iOzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgY29ycmVzcG9uZGluZyB0byB0aGUgdmlydHVhbCByb3V0 ZXIuIjs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICBsZWFmIGlw djQtYWRkcmVzcyB7PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICBs ZWFmIGlwdjQtYWRkcmVzcyB7PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgdHlwZSBpbmV0OmlwdjQtYWRkcmVzczs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICAgICAgdHlwZSBpbmV0OmlwdjQtYWRkcmVzczs8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgICBkZXNjcmlwdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICBkZXNjcmlwdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxNyI+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAg ICAgICAiPHNwYW4gY2xhc3M9ImRlbGV0ZSI+VmlydHVhbCBJUHY0IGFkZHJlc3M8L3NwYW4+LiI7 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICI8c3BhbiBj bGFzcz0iaW5zZXJ0Ij5BbiBJUHY0IGFkZHJlc3MgYXNzb2NpYXRlZCB3aXRoIGEgdmlydHVhbCBy b3V0ZXI8L3NwYW4+LiI7PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAg cmVmZXJlbmNlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAg ICAgIlJGQyA1Nzk4OiBWaXJ0dWFsIFJvdXRlciBSZWR1bmRhbmN5IFByb3RvY29sIChWUlJQKTwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgICBWZXJzaW9u IDMuIFNlY3Rpb24gMS4yLiI7PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgICB9PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICB9PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICB9IC8vIHZpcnR1YWwtaXB2NC1hZGRy ZXNzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgfSAvLyB2aXJ0dWFs LWlwdjQtYWRkcmVzczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIH0gLy8gdmly dHVhbC1pcHY0LWFkZHJlc3NlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICB9IC8vIHZpcnR1YWwtaXB2NC1hZGRyZXNzZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgfSAvLyBncm91cGluZyB2cnJwLWlwdjQtYXR0cmlidXRlczwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgfSAvLyBncm91cGluZyB2cnJwLWlwdjQtYXR0cmlidXRlczwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIGdyb3VwaW5nIHZycnAtaXB2Ni1h dHRyaWJ1dGVzIHs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIGdyb3VwaW5n IHZycnAtaXB2Ni1hdHRyaWJ1dGVzIHs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICBkZXNjcmlwdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBkZXNj cmlwdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgIkdyb3VwIG9mIFZS UlAgYXR0cmlidXRlcyBmb3IgSVB2Ni4iOzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICAgICJHcm91cCBvZiBWUlJQIGF0dHJpYnV0ZXMgZm9yIElQdjYuIjs8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIHVzZXMgdnJycC1jb21tb24tYXR0cmlidXRl czs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgdXNlcyB2cnJwLWNvbW1v bi1hdHRyaWJ1dGVzOzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgaWQ9InBhcnQtOCIgY2xhc3M9ImNoYW5nZSIgPjx0ZD48L3RkPjx0aD48c21hbGw+c2tp cHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSIjcGFydC04Ij48ZW0+IHBhZ2UgMjIs IGxpbmUgMzM8c3BhbiBjbGFzcz0iaGlkZSI+ICZwYXJhOzwvc3Bhbj48L2VtPjwvYT48L3RoPjx0 aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0i I3BhcnQtOCI+PGVtPiBwYWdlIDIzLCBsaW5lIDM2PHNwYW4gY2xhc3M9ImhpZGUiPiAmcGFyYTs8 L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgIGtleSAiaXB2Ni1hZGRyZXNz Ijs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgIGtleSAiaXB2Ni1h ZGRyZXNzIjs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgbWF4LWVsZW1l bnRzIDI7PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICBtYXgtZWxl bWVudHMgMjs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgZGVzY3JpcHRp b248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgIGRlc2NyaXB0aW9u PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIlR3byBJUHY2IGFkZHJl c3NlcyBhcmUgYWxsb3dlZC4gVGhlIGZpcnN0IG9uZSBtdXN0IGJlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICJUd28gSVB2NiBhZGRyZXNzZXMgYXJlIGFsbG93 ZWQuIFRoZSBmaXJzdCBvbmUgbXVzdCBiZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgICAgICBhIGxpbmstbG9jYWwgYWRkcmVzcyBhbmQgdGhlIHNlY29uZCBvbmUgY2FuIGJl IGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIGEgbGluay1s b2NhbCBhZGRyZXNzIGFuZCB0aGUgc2Vjb25kIG9uZSBjYW4gYmUgYTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBsaW5rLWxvY2FsIG9yIGdsb2JhbCBhZGRyZXNzLiI7 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBsaW5rLWxvY2Fs IG9yIGdsb2JhbCBhZGRyZXNzLiI7PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgbGVhZiBpcHY2LWFkZHJlc3MgezwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICAgICAgbGVhZiBpcHY2LWFkZHJlc3MgezwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgIHR5cGUgaW5ldDppcHY2LWFkZHJlc3M7PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgIHR5cGUgaW5ldDppcHY2LWFkZHJlc3M7PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgZGVzY3JpcHRpb248L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgZGVzY3JpcHRpb248L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTgiPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgICAgICAgICAgICAgIjxzcGFuIGNsYXNzPSJkZWxldGUiPlZpcnR1YWwgSVB2NiBh ZGRyZXNzPC9zcGFuPi4iOzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAg ICAgICAgICAiPHNwYW4gY2xhc3M9Imluc2VydCI+QW4gSVB2NiBhZGRyZXNzIGFzc29jaWF0ZWQg d2l0aCBhIHZpcnR1YWwgcm91dGVyPC9zcGFuPi4iOzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgICAgICAgICAgIHJlZmVyZW5jZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgICAgICAgICAgICAgICJSRkMgNTc5ODogVmlydHVhbCBSb3V0ZXIgUmVkdW5kYW5jeSBQ cm90b2NvbCAoVlJSUCk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAg ICAgICAgICAgVmVyc2lvbiAzLiBTZWN0aW9uIDEuMy4iOzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgfTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICAgICAgfTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgfSAvLyB2 aXJ0dWFsLWlwdjYtYWRkcmVzczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgIH0gLy8gdmlydHVhbC1pcHY2LWFkZHJlc3M8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICB9IC8vIHZpcnR1YWwtaXB2Ni1hZGRyZXNzZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgfSAvLyB2aXJ0dWFsLWlwdjYtYWRkcmVzc2VzPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIH0gLy8gZ3JvdXBpbmcgdnJycC1pcHY2LWF0dHJpYnV0ZXM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIH0gLy8gZ3JvdXBpbmcgdnJycC1p cHY2LWF0dHJpYnV0ZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICBncm91 cGluZyB2cnJwLXN0YXRlLWF0dHJpYnV0ZXMgezwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgZ3JvdXBpbmcgdnJycC1zdGF0ZS1hdHRyaWJ1dGVzIHs8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICBkZXNjcmlwdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICBkZXNjcmlwdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgIkdyb3VwIG9mIFZSUlAgc3RhdGUgYXR0cmlidXRlcy4iOzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICJHcm91cCBvZiBWUlJQIHN0YXRlIGF0dHJpYnV0ZXMu Ijs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIGxlYWYgc3RhdGUgezwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICBsZWFmIHN0YXRlIHs8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTkiIGNs YXNzPSJjaGFuZ2UiID48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwv c21hbGw+PGEgaHJlZj0iI3BhcnQtOSI+PGVtPiBwYWdlIDM5LCBsaW5lIDExPHNwYW4gY2xhc3M9 ImhpZGUiPiAmcGFyYTs8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9IiNwYXJ0LTkiPjxlbT4gcGFnZSA0 MCwgbGluZSAxMTxzcGFuIGNsYXNzPSJoaWRlIj4gJnBhcmE7PC9zcGFuPjwvZW0+PC9hPjwvdGg+ PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBUaGlzIHNlY3Rpb24gY29udGFpbnMgYW4gZXhhbXBsZSBvZiBhbiBp bnN0YW5jZSBkYXRhIHRyZWUgaW4gdGhlIEpTT048L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBUaGlzIHNlY3Rpb24gY29udGFpbnMgYW4gZXhhbXBsZSBvZiBhbiBpbnN0YW5jZSBk YXRhIHRyZWUgaW4gdGhlIEpTT048L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGVuY29k aW5nIFtSRkM3OTUxXSwgY29udGFpbmluZyBib3RoIGNvbmZpZ3VyYXRpb24gYW5kIHN0YXRlIGRh dGEuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZW5jb2RpbmcgW1JGQzc5NTFd LCBjb250YWluaW5nIGJvdGggY29uZmlndXJhdGlvbiBhbmQgc3RhdGUgZGF0YS48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICBWaXJ0dWFsIHJvdXRlciBJ UCBhZGRyZXNzOiAxMC4wLjAuMTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgICAgICAgICAgVmlydHVhbCByb3V0ZXIgSVAgYWRkcmVzczogMTAuMC4wLjE8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0t KzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAg ICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIHwg Um91dGVyIDEuMS4xLjEgIHwgICAgICAgIHwgUm91dGVyIDEuMS4xLjIgIHw8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIHwgUm91dGVyIDEuMS4xLjEgIHwgICAg ICAgIHwgUm91dGVyIDEuMS4xLjIgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgfDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0rICAgICAgICArLS0tLS0tLS0r LS0tLS0tLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAr LS0tLS0tLS0rLS0tLS0tLS0rICAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0rPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE5Ij48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgICAgICAgICAgICAgICAgICAgICAgfGV0aDxzcGFuIGNsYXNzPSJkZWxldGUiPjAgICAgICAg ICAgICAgICAgICAgICAgfGV0aDA8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgICAgICAgICAgICAgICAgICAgICAgfGV0aDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEgICAg ICAgICAgICAgICAgICAgICAgfGV0aDE8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgICAgICAgICAgICAgICAgIHwxMC4wLjEuMSAgICAgICAgICAgICAgICAgIHwxMC4w LjIuMTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAg ICAgfDEwLjAuMS4xICAgICAgICAgICAgICAgICAgfDEwLjAuMi4xPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICAgIC0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgIHwxMC4wLjIuMSAgICAgICAgICAgICAg ICAgIHwxMC4wLjIuMjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgICAgICAgICAgfDEwLjAuMi4xICAgICAgICAgICAgICAgICAgfDEwLjAuMi4yPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICstLS0tLS0tLSstLS0tLS0tLSsgICAg ICAgICstLS0tLS0tLSstLS0tLS0tLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICAgICAgICAgICstLS0tLS0tLSstLS0tLS0tLSsgICAgICAgICstLS0tLS0tLSstLS0tLS0t LSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgfCAgICAgSG9zdCAx ICAgICAgfCAgICAgICAgfCAgICAgSG9zdCAyICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgfCAgICAgSG9zdCAxICAgICAgfCAgICAgICAgfCAgICAg SG9zdCAyICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICB8 IERlZmF1bHQgZ2F0ZXdheTp8ICAgICAgICB8IERlZmF1bHQgZ2F0ZXdheTp8PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICB8IERlZmF1bHQgZ2F0ZXdheTp8ICAg ICAgICB8IERlZmF1bHQgZ2F0ZXdheTp8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgIHwgICAgIDEwLjAuMC4xICAgIHwgICAgICAgIHwgICAgIDEwLjAuMC4xICAgIHw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIHwgICAgIDEwLjAu MC4xICAgIHwgICAgICAgIHwgICAgIDEwLjAuMC4xICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKzwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgoKICAgICA8dHI+PHRkPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZD48L3RkPjwv dHI+CiAgICAgPHRyIGlkPSJlbmQiIGJnY29sb3I9ImdyYXkiPjx0aCBjb2xzcGFuPSI1IiBhbGln bj0iY2VudGVyIj4mbmJzcDtFbmQgb2YgY2hhbmdlcy4gMTkgY2hhbmdlIGJsb2Nrcy4mbmJzcDs8 L3RoPjwvdHI+CiAgICAgPHRyIGNsYXNzPSJzdGF0cyI+PHRkPjwvdGQ+PHRoPjxpPjI0IGxpbmVz IGNoYW5nZWQgb3IgZGVsZXRlZDwvaT48L3RoPjx0aD48aT4gPC9pPjwvdGg+PHRoPjxpPjQ1IGxp bmVzIGNoYW5nZWQgb3IgYWRkZWQ8L2k+PC90aD48dGQ+PC90ZD48L3RyPgogICAgIDx0cj48dGQg Y29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciIgY2xhc3M9InNtYWxsIj48YnIvPlRoaXMgaHRtbCBk aWZmIHdhcyBwcm9kdWNlZCBieSByZmNkaWZmIDEuNDUuIFRoZSBsYXRlc3QgdmVyc2lvbiBpcyBh dmFpbGFibGUgZnJvbSA8YSBocmVmPSJodHRwOi8vd3d3LnRvb2xzLmlldGYub3JnL3Rvb2xzL3Jm Y2RpZmYvIiA+aHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvPC9hPiA8L3RkPjwv dHI+CiAgIDwvdGFibGU+CiAgIDwvYm9keT4KICAgPC9odG1sPgo= --_002_BN3PR0201MB0867C158109E11A94E820227F1130BN3PR0201MB0867_-- From nobody Fri Apr 28 17:06:47 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10520129492; Fri, 28 Apr 2017 17:06:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-yang-key-chain-23.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149342440502.3032.6886071340581934834@ietfa.amsl.com> Date: Fri, 28 Apr 2017 17:06:45 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 00:06:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Routing Key Chain YANG Data Model Authors : Acee Lindem Yingzhen Qu Derek Yeung Ing-Wher Chen Jeffrey Zhang Filename : draft-ietf-rtgwg-yang-key-chain-23.txt Pages : 24 Date : 2017-04-28 Abstract: This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-23 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-key-chain-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-yang-key-chain-23 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 Sat Apr 29 07:11:12 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A001294DF; Sat, 29 Apr 2017 07:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA81FVeDCZwy; Sat, 29 Apr 2017 07:11:05 -0700 (PDT) Received: from mgw030.noc.ntt.com (mgw030.noc.ntt.com [210.160.55.3]) by ietfa.amsl.com (Postfix) with ESMTP id D92B312947D; Sat, 29 Apr 2017 07:10:41 -0700 (PDT) Received: from c0043i0.coe.ntt.com (c0043i0.nc.agilit-hosting.com [10.18.161.12]) by mgw030.noc.ntt.com (NTT Com MailSV) with ESMTP id 66FC81C58950; Sat, 29 Apr 2017 23:10:40 +0900 (JST) Received: from C0147I0.coe.ntt.com (10.18.160.111) by c0043i0.coe.ntt.com (10.18.161.12) with Microsoft SMTP Server (TLS) id 14.3.339.0; Sat, 29 Apr 2017 23:10:40 +0900 Received: from C0561I0.coe.ntt.com ([169.254.1.133]) by C0147I0.coe.ntt.com ([10.18.160.111]) with mapi id 14.03.0339.000; Sat, 29 Apr 2017 23:10:39 +0900 From: Tomonori Takeda To: "'rtg-ads@ietf.org'" CC: "'rtg-dir@ietf.org'" <'rtg-dir@ietf.org'>, "'draft-ietf-rtgwg-spf-uloop-pb-statement.all@ietf.org'" , "rtgwg@ietf.org" Subject: RTG-DIR QA review: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt Thread-Topic: RTG-DIR QA review: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt Thread-Index: AdLA7qLGXj0F8yDgRaK42VOyHjaunA== Date: Sat, 29 Apr 2017 14:10:38 +0000 Message-ID: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: rtg-ads@ietf.org x-ccmail-original-cc: 'rtg-dir@ietf.org', draft-ietf-rtgwg-spf-uloop-pb-statement.all@ietf.org, rtgwg@ietf.org x-originating-ip: [10.25.154.86] Content-Type: text/plain; charset="iso-2022-jp" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 14:11:09 -0000 Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt Reviewer: Tomonori Takeda Review Date: April 29, 2017 Intended Status: Standards Track Here are my comments. Overall, the document is well organized and clear about problem statement and analysis of SPF triggers and SPF delays impact on micro-loops. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for such analysis document to be Standards Track. 2) Just a nits, but in page 12, it says "In the figure 5", but it seems figures are not numbered. 3) In Section 4.2. Exponential backoff, it is not clear what is a condition (or conditions) to move from FM to BM. Thanks, Tomonori Takeda From nobody Sat Apr 29 07:45:18 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05F6129458 for ; Sat, 29 Apr 2017 07:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 9fbCe1L7Sz6C for ; Sat, 29 Apr 2017 07:45:15 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 45DD71294DF for ; Sat, 29 Apr 2017 07:44:55 -0700 (PDT) Received: (qmail 13075 invoked by uid 0); 29 Apr 2017 14:44:49 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 29 Apr 2017 14:44:48 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id EEkk1v00U2SSUrH01EknR6; Sat, 29 Apr 2017 08:44:48 -0600 X-Authority-Analysis: v=2.2 cv=QdwWhoTv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=AzvcPWV-tVgA:10 a=48vgC7mUAAAA:8 a=L35N5iEh9iDEk8KDZvMA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qybVsJO03rxB1XJvQxF8c9T7KVhEoh00ytwIwW+TbqU=; b=Wg2nSRidEOotoppil5XMcwwMLS ZoRLGIdu9O3/Td576oSGyrTfVC0vJGSLr7B+62bg2sGtAvYKNJ7KuYH30H5Iin3dULh0Ut+hDNI46 INOCU0vzewook2y/RVrlrQf1r; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:56054 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1d4Tc2-0005bT-GK; Sat, 29 Apr 2017 08:44:44 -0600 Subject: Re: Routing Directorate review of draft-ietf-rtgwg-ni-model-02 To: "John G. Scudder" , draft-ietf-rtgwg-ni-model@ietf.org References: Cc: rtg-dir@ietf.org, rtgwg-chairs@ietf.org, rtgwg@ietf.org From: Lou Berger Message-ID: <4298c8ad-d44e-6f37-b321-4bf62b6eb145@labn.net> Date: Sat, 29 Apr 2017 10:44:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1d4Tc2-0005bT-GK X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:56054 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 14:45:17 -0000 Thanks for the review! We'll address your (much appreciated!) comments as part of our next planned update which will also include: - update to next rev of schema mount (which gates this works) - more informational text / examples Thanks, Lou On 4/28/2017 4:23 PM, John G. Scudder wrote: > Hi All, > > I have been selected to do a routing directorate aQA review of this draft. > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/ > > The QA review is described (https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa) as: > > "The WG Draft Quality Assurance process exists to provide cross-WG and expert review early in the IETF process after a WG has adopted a WG draft or while the WG is deciding to adopt a draft. Since a WG adopts a draft as a good starting point for the work, providing early excellent review of such drafts allows for good technical discussion and the ability to enhance the WG draft to solve identified issues. The earlier in the process that substantial issues (technical or editorial) are resolved, the more quickly and smoothly a WG draft is likely to proceed." > > For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Document: draft-ietf-rtgwg-ni-model-02.txt > Reviewer: John Scudder > Review Date: April 28, 2017 > > Summary: > > I found the document easy to follow, clear and almost painless to read, thank you. > > Note that my level of Yang expertise is pretty low, so you should be looking elsewhere for a critique of anything other than the grossest Yang-specific aspects of the document. (I found the schema-mount example in section 3.2 particularly opaque.) > > > Comments and Questions: > > 1. There's a significant amount of duplication of explanatory and background text between this document and draft-ietf-rtgwg-lne-model-01. In reading it, I tried to consider whether it would be OK to cut out some of the text explaining what an LNE is, but on the whole I think it's better left in -- the document would have been more difficult to read without having that context in-line. However, it does lead to the question, is there some good reason the two documents are separate, instead of a single document? The duplication between them suggests there's at least some motivation to refactor them into one. (I realize there may be many reasons to keep them separate, including "seriously, John? The cost/benefit just isn't there", but I had to ask.) > > 2. The abstract is almost a copy of the abstract for draft-ietf-rtgwg-lne-model-01. Comments in #1 above notwithstanding, I do think brevity is the soul of wit when it comes to an abstract, so I suggest removing the LNE definition here, and just define the stuff *this* doc is about. (Similar suggestion applies to the companion doc's abstract.) > > 3. It seems to me the "TBD" for network-instance-policy represents a significant open issue and deserves to be included in your open issues list (section 1.1). Other TBDs sprinkled throughout don't seem to rise to this level, but of course do represent open issues. > > 4. Speaking of network instance policy, although since it's left TBD there's not much to be said, the examples you give (RTs, RDs, VNIs, VPLS neighbors) mostly don't seem like what I think of as "policy". I suppose it's one of the most overloaded terms in our industry, so maybe someone else does think of it that way, but this choice of terminology was a speed bump for my understanding of the doc. > > 5. The example given in section 3.2 doesn't seem to follow the same pattern as the one given in section 3. I'm too much of a Yang neophyte to know if there might be some Yang feature in play that makes this make sense, but on the face of it the example in section 3 seems to tell me I'm supposed to bind a network-instance-name to a specific instance of an interface (so, if:interfaces/if:interface), whereas what I see in 3.2 is a network-instance-name at the if:interfaces level -- which doesn't make a lot of intuitive sense, either. > > > Minor Issues and Nits: > > 6. I've edited various minor suggestions into a copy of draft-ietf-rtgwg-ni-model-02.txt and attached it, you can look at them using your diff tool of choice. > > 7. This sentence isn't quite right: > > Network instance policies are used to control how NI information is > represented at the device level, VRF routing policies, and VRF/VSI > identifiers. > > Without knowing your intent I'm not able to offer you a rewrite. Possibly it would be enough to reorder the items in your list, to put the big compound one at the end, as in "Network instance policies are used to control VRF routing policies, VRF/VSI identifiers, and how NI information is represented at the device level"? > > 8. This sentence no verb: > > For layer 3, > this consistent with the routing-instance > definition in ietf-routing > > Again, without knowing your intent I can't offer a rewrite. Maybe the verb "to be" is what you want? > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From nobody Sat Apr 29 10:58:03 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B19128954; Sat, 29 Apr 2017 10:58:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-yang-key-chain-24.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149348868175.2907.16460031295442653359@ietfa.amsl.com> Date: Sat, 29 Apr 2017 10:58:01 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 17:58:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group of the IETF. Title : Routing Key Chain YANG Data Model Authors : Acee Lindem Yingzhen Qu Derek Yeung Ing-Wher Chen Jeffrey Zhang Filename : draft-ietf-rtgwg-yang-key-chain-24.txt Pages : 24 Date : 2017-04-29 Abstract: This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list of elements each containing a key string, send lifetime, accept lifetime, and algorithm (authentication or encryption). By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-yang-key-chain-24 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-key-chain-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-yang-key-chain-24 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 30 05:19:58 2017 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA48312954C; Sun, 30 Apr 2017 05:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O2pOEl2fkE0; Sun, 30 Apr 2017 05:19:53 -0700 (PDT) Received: from mgw030.noc.ntt.com (mgw030.noc.ntt.com [210.160.55.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4A442129454; Sun, 30 Apr 2017 05:18:23 -0700 (PDT) Received: from c0044i0.coe.ntt.com (c0044i0.nc.agilit-hosting.com [10.18.161.13]) by mgw030.noc.ntt.com (NTT Com MailSV) with ESMTP id 296831C581DD; Sun, 30 Apr 2017 21:18:22 +0900 (JST) Received: from C0039I0.coe.ntt.com (10.18.160.43) by c0044i0.coe.ntt.com (10.18.161.13) with Microsoft SMTP Server (TLS) id 14.3.339.0; Sun, 30 Apr 2017 21:18:21 +0900 Received: from C0561I0.coe.ntt.com ([169.254.1.133]) by C0039I0.coe.ntt.com ([10.18.160.43]) with mapi id 14.03.0339.000; Sun, 30 Apr 2017 21:18:21 +0900 From: Tomonori Takeda To: "'rtg-ads@ietf.org'" CC: "'rtg-dir@ietf.org'" , "'draft-ietf-rtgwg-spf-uloop-pb-statement.all@ietf.org'" , "'rtgwg@ietf.org'" Subject: RE: RTG-DIR QA review: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt Thread-Topic: RTG-DIR QA review: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt Thread-Index: AdLA7qLGXj0F8yDgRaK42VOyHjaunAAvOLJg Date: Sun, 30 Apr 2017 12:18:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: rtg-ads@ietf.org x-ccmail-original-cc: rtg-dir@ietf.org, draft-ietf-rtgwg-spf-uloop-pb-statement.all@ietf.org, rtgwg@ietf.org x-originating-ip: [10.25.153.185] Content-Type: text/plain; charset="iso-2022-jp" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 12:19:57 -0000 # Resend since it seems my previous email was not delivered correctly... Hi, I have been selected as the Routing Directorate QA reviewer for this draft. Document: draft-ietf-rtgwg-spf-uloop-pb-statement-03.txt Reviewer: Tomonori Takeda Review Date: April 29, 2017 Intended Status: Standards Track Here are my comments. Overall, the document is well organized and clear about problem statement and analysis of SPF triggers and SPF delays impact on micro-loops. Some specific comments. 1) The document is intended to be Standards Track. I do not think it is common for such analysis document to be Standards Track. 2) Just a nits, but in page 12, it says "In the figure 5", but it seems figures are not numbered. 3) In Section 4.2. Exponential backoff, it is not clear what is a condition (or conditions) to move from FM to BM. Thanks, Tomonori Takeda