From nobody Mon Jun  1 18:55:25 2020
Return-Path: <bill.wu@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3D23A0809 for <netconf@ietfa.amsl.com>; Mon,  1 Jun 2020 18:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 bICGG6kiS-JX for <netconf@ietfa.amsl.com>; Mon,  1 Jun 2020 18:55:20 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959893A080B for <netconf@ietf.org>; Mon,  1 Jun 2020 18:55:20 -0700 (PDT)
Received: from lhreml719-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BFB6310C4008E65AB7F2; Tue,  2 Jun 2020 02:55:17 +0100 (IST)
Received: from lhreml719-chm.china.huawei.com (10.201.108.70) by lhreml719-chm.china.huawei.com (10.201.108.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 2 Jun 2020 02:55:17 +0100
Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml719-chm.china.huawei.com (10.201.108.70) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 2 Jun 2020 02:55:17 +0100
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.233]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0487.000; Tue, 2 Jun 2020 09:55:12 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Kent Watsen <kent@watsen.net>, Xufeng Liu <xufeng.liu.ietf@gmail.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] [netmod] <get-data> operation with "table join" capability
Thread-Index: AdY4gBgWjdkAiAh8S4qQaSFtKM9ZGg==
Date: Tue, 2 Jun 2020 01:55:11 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD725E61@dggeml511-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.123]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD725E61dggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/jUs9Rp7QbzmRm8yM6qOHOQEztak>
Subject: Re: [netconf] [netmod] <get-data> operation with "table join" capability
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2020 01:55:24 -0000

--_000_B8F9A780D330094D99AF023C5877DABAAD725E61dggeml511mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGksIEtlbnQgYW5kIFh1ZmVuZzoNClNob3VsZCB0aGlzIHRhYmxlIGpvaW4gY2FwYWJpbGl0eSBi
ZSBhbHNvIGFwcGxpZWQgdG8gWUFORyBQdXNoIHN1YnNjcmlwdGlvbiwgc28gd2UgY2FuIHVzZSBZ
QU5HIFB1c2ggTm90aWZpY2F0aW9uIHRvIGdldCBhbGwgYXR0cmlidXRlcyBvZiB0aGUgb2JqZWN0
IGNvbnRhaW5pbmcgdGhlIGxlYWZyZWYgYW5kIHRoZSBhdHRyaWJ1dGVzIHJlZmVyZW5jZWQgYnkg
dGhlIGxlYWZyZWYgc3RhdGVtZW50Lg0KSSByYWlzZWQgdGhpcyBpc3N1ZSBiZWZvcmUNCmh0dHBz
Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0Y29uZi80UEhpUzdFWXFlaFpPejNs
SXhGTWFMWjZyQW8vDQoNCi1RaW4NCreivP7IyzogbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91
bmNlc0BpZXRmLm9yZ10gtPqx7SBLZW50IFdhdHNlbg0Kt6LLzcqxvOQ6IDIwMjDE6jXUwjIxyNUg
MjE6MzYNCsrVvP7IyzogWHVmZW5nIExpdSA8eHVmZW5nLmxpdS5pZXRmQGdtYWlsLmNvbT4NCrOt
y806IG5ldGNvbmZAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbbmV0Y29uZl0gW25ldG1vZF0gPGdldC1k
YXRhPiBvcGVyYXRpb24gd2l0aCAidGFibGUgam9pbiIgY2FwYWJpbGl0eQ0KDQpbbW92aW5nICdu
ZXRtb2QnIHRvIEJDQyBzaW5jZSB0aGlzIHF1ZXN0aW9uIGhhcyBubyBtb2RlbGluZyBpbXBhY3Rd
DQoNCg0KVGhlIGRlc2lyZWQgY2FwYWJpbGl0eSBpczoNCg0KV2hlbiBhIGxlYWZyZWYgb3IgbXVs
dGlwbGUgbGVhZnJlZnMgcmVmZXJlbmNlIG9uZSBvciBtb3JlIG9iamVjdHMgc3BlY2lmaWVkIGlu
IG90aGVyIHBhcnRzIG9mIHRoZSBzY2hlbWEsIHRoZSBvcGVyYXRvciBjYW4gdXNlIGEgc2luZ2xl
IDxnZXQtZGF0YT4gb3BlcmF0aW9uIHRvIHJldHJpZXZlIGFsbCBhdHRyaWJ1dGVzIG9mIHRoZSBv
YmplY3QgY29udGFpbmluZyB0aGUgbGVhZnJlZiBhbmQgdGhlIGF0dHJpYnV0ZXMgcmVmZXJlbmNl
ZCBieSB0aGUgbGVhZnJlZiBzdGF0ZW1lbnQuDQoNClRoZSBtb3RpdmF0aW9uIGlzIGNsZWFyLg0K
DQpBIHNvbHV0aW9uIHdvdWxkIGxpa2VseSBlbnRhaWwgcmV0dXJuaW5nIGEgbXVsdGktcGFydCBy
ZXNwb25zZSwgcGVyaGFwcyBhIHNpbmdsZSB0cmVlIGZvciBORVRDT05GLiAgIE5vdGUgdGhhdCB0
aGUgcmVzb2x1dGlvbnMgbWF5IHRoZW1zZWx2ZXMgaW5jbHVkZSBsZWFmcmVmcywgYSBmdWxsLXJl
c3BvbnNlIG1heSBiZSBOIGxldmVscyBkZWVwLg0KDQpLLg0KDQo=

--_000_B8F9A780D330094D99AF023C5877DABAAD725E61dggeml511mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:=CE=A2=C8=ED=D1=C5=BA=DA;
	panose-1:2 11 5 3 2 2 4 2 2 4;}
@font-face
	{font-family:"\@=CE=A2=C8=ED=D1=C5=BA=DA";
	panose-1:2 11 5 3 2 2 4 2 2 4;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Hi, Kent and Xufeng:<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Should this table join=
 capability be also applied to YANG Push subscription, so we can use YANG P=
ush Notification to get all attributes of the object
 containing the leafref and the attributes referenced by the leafref statem=
ent.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">I raised this issue be=
fore<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><a href=3D"https://mai=
larchive.ietf.org/arch/msg/netconf/4PHiS7EYqehZOz3lIxFMaLZ6rAo/">https://ma=
ilarchive.ietf.org/arch/msg/netconf/4PHiS7EYqehZOz3lIxFMaLZ6rAo/</a><o:p></=
o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">-Qin<o:p></o:p></span>=
</p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;=CE=A2=C8=ED=D1=C5=BA=DA&quot;,sans-serif">=B7=A2=BC=FE=C8=CB<span lang=3D=
"EN-US">:</span></span></b><span lang=3D"EN-US" style=3D"font-size:11.0pt;f=
ont-family:&quot;=CE=A2=C8=ED=D1=C5=BA=DA&quot;,sans-serif"> netconf [mailt=
o:netconf-bounces@ietf.org]
</span><b><span style=3D"font-size:11.0pt;font-family:&quot;=CE=A2=C8=ED=D1=
=C5=BA=DA&quot;,sans-serif">=B4=FA=B1=ED </span>
</b><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;=CE=A2=
=C8=ED=D1=C5=BA=DA&quot;,sans-serif">Kent Watsen<br>
</span><b><span style=3D"font-size:11.0pt;font-family:&quot;=CE=A2=C8=ED=D1=
=C5=BA=DA&quot;,sans-serif">=B7=A2=CB=CD=CA=B1=BC=E4<span lang=3D"EN-US">:<=
/span></span></b><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family=
:&quot;=CE=A2=C8=ED=D1=C5=BA=DA&quot;,sans-serif"> 2020</span><span style=
=3D"font-size:11.0pt;font-family:&quot;=CE=A2=C8=ED=D1=C5=BA=DA&quot;,sans-=
serif">=C4=EA<span lang=3D"EN-US">5</span>=D4=C2<span lang=3D"EN-US">21</sp=
an>=C8=D5<span lang=3D"EN-US">
 21:36<br>
</span><b>=CA=D5=BC=FE=C8=CB<span lang=3D"EN-US">:</span></b><span lang=3D"=
EN-US"> Xufeng Liu &lt;xufeng.liu.ietf@gmail.com&gt;<br>
</span><b>=B3=AD=CB=CD<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> netconf@ietf.org<br>
</span><b>=D6=F7=CC=E2<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> Re: [netconf] [netmod] &lt;get-data&gt; operation with &quot;table join&q=
uot; capability<o:p></o:p></span></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">[moving 'netmod' to BCC since t=
his question has no modeling impact]<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The desired capability is:<o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">When a leafref or multiple leaf=
refs reference one or more objects specified in other parts of the schema, =
the operator can use a single &lt;get-data&gt; operation to retrieve all at=
tributes of the object containing the leafref
 and the attributes referenced by the leafref statement.<o:p></o:p></span><=
/p>
</div>
</div>
</div>
</blockquote>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The motivation is clear.<o:p></=
o:p></span></p>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">A solution would likely entail =
returning a multi-part response, perhaps a single tree for NETCONF. &nbsp; =
Note that the resolutions may themselves include leafrefs, a full-response =
may be N levels deep. &nbsp;&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">K.<o:p></o:p></span></p>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_B8F9A780D330094D99AF023C5877DABAAD725E61dggeml511mbschi_--


From nobody Mon Jun  1 19:26:22 2020
Return-Path: <bill.wu@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2CB3A084E for <netconf@ietfa.amsl.com>; Mon,  1 Jun 2020 19:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 YQmjcSiOO4MI for <netconf@ietfa.amsl.com>; Mon,  1 Jun 2020 19:26:18 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1AB83A084D for <netconf@ietf.org>; Mon,  1 Jun 2020 19:26:18 -0700 (PDT)
Received: from lhreml732-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 45D66C6DF782FBDB8E59; Tue,  2 Jun 2020 03:26:16 +0100 (IST)
Received: from lhreml732-chm.china.huawei.com (10.201.108.83) by lhreml732-chm.china.huawei.com (10.201.108.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 2 Jun 2020 03:26:15 +0100
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml732-chm.china.huawei.com (10.201.108.83) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 2 Jun 2020 03:26:15 +0100
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.233]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0487.000; Tue, 2 Jun 2020 10:26:08 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Kent Watsen <kent@watsen.net>, Xufeng Liu <xufeng.liu.ietf@gmail.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] [netmod] <get-data> operation with "table join" capability
Thread-Index: AdY4hL8emLYJvZGdSGSUR7byfA88UQ==
Date: Tue, 2 Jun 2020 02:26:08 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD726EEC@dggeml511-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.123]
Content-Type: multipart/related; boundary="_004_B8F9A780D330094D99AF023C5877DABAAD726EECdggeml511mbschi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/M_fFPyf48XlY3exRUEkbgp2Tvn8>
Subject: Re: [netconf] [netmod] <get-data> operation with "table join" capability
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2020 02:26:21 -0000

--_004_B8F9A780D330094D99AF023C5877DABAAD726EECdggeml511mbschi_
Content-Type: multipart/alternative;
 boundary="_000_B8F9A780D330094D99AF023C5877DABAAD726EECdggeml511mbschi_"

--_000_B8F9A780D330094D99AF023C5877DABAAD726EECdggeml511mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

T25lIGZ1cnRoZXIgcXVlc3Rpb24sIHdoZW4gdGhlIGxlYWYgYmIgaW4gdGhlIG1vZHVsZSBiYXIg
dXNlcyBsZWFmcmVmIHRvIHJlZmVyZW5jZSBhYSBpbiBtb2R1bGUgZm9vLA0KQ2FuIHdlIHVzZSBn
ZXQtZGF0YSBvcGVyYXRpb24gdG8gcmV0cmlldmUgYWxsIGRhdGEgbm9kZXMgYXNzb2NpYXRlZCB3
aXRoIKGwbXlhYmOhsSBsaXN0IGluIG1vZHVsZSBiYXINCmFuZCBhbGwgZGF0YSBub2RlcyBhc3Nv
Y2lhdGVkIHdpdGggobBmb29pbnOhsSBsaXN0IGluIG1vZHVsZSBmb28sZS5nLiwNCmZvby9mb29p
bnNbYWEgPSAvYmFyL215YWJjL2JiXS97IGFhLGRlc2NyLGFkbWluLHJ1bGVzfQ0KW2NpZDppbWFn
ZTAwMS5wbmdAMDFENjM4QzguMzlDNTYyMjBdDQoNCi1RaW4NCreivP7IyzogbmV0Y29uZiBbbWFp
bHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBRaW4gV3UNCreiy83KsbzkOiAyMDIw
xOo21MIyyNUgOTo1NQ0KytW8/sjLOiBLZW50IFdhdHNlbiA8a2VudEB3YXRzZW4ubmV0PjsgWHVm
ZW5nIExpdSA8eHVmZW5nLmxpdS5pZXRmQGdtYWlsLmNvbT4NCrOty806IG5ldGNvbmZAaWV0Zi5v
cmcNCtb3zOI6IFJlOiBbbmV0Y29uZl0gW25ldG1vZF0gPGdldC1kYXRhPiBvcGVyYXRpb24gd2l0
aCAidGFibGUgam9pbiIgY2FwYWJpbGl0eQ0KDQpIaSwgS2VudCBhbmQgWHVmZW5nOg0KU2hvdWxk
IHRoaXMgdGFibGUgam9pbiBjYXBhYmlsaXR5IGJlIGFsc28gYXBwbGllZCB0byBZQU5HIFB1c2gg
c3Vic2NyaXB0aW9uLCBzbyB3ZSBjYW4gdXNlIFlBTkcgUHVzaCBOb3RpZmljYXRpb24gdG8gZ2V0
IGFsbCBhdHRyaWJ1dGVzIG9mIHRoZSBvYmplY3QgY29udGFpbmluZyB0aGUgbGVhZnJlZiBhbmQg
dGhlIGF0dHJpYnV0ZXMgcmVmZXJlbmNlZCBieSB0aGUgbGVhZnJlZiBzdGF0ZW1lbnQuDQpJIHJh
aXNlZCB0aGlzIGlzc3VlIGJlZm9yZQ0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo
L21zZy9uZXRjb25mLzRQSGlTN0VZcWVoWk96M2xJeEZNYUxaNnJBby8NCg0KLVFpbg0Kt6K8/sjL
OiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEtlbnQgV2F0
c2VuDQq3osvNyrG85DogMjAyMMTqNdTCMjHI1SAyMTozNg0KytW8/sjLOiBYdWZlbmcgTGl1IDx4
dWZlbmcubGl1LmlldGZAZ21haWwuY29tPG1haWx0bzp4dWZlbmcubGl1LmlldGZAZ21haWwuY29t
Pj4NCrOty806IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQrW98zi
OiBSZTogW25ldGNvbmZdIFtuZXRtb2RdIDxnZXQtZGF0YT4gb3BlcmF0aW9uIHdpdGggInRhYmxl
IGpvaW4iIGNhcGFiaWxpdHkNCg0KW21vdmluZyAnbmV0bW9kJyB0byBCQ0Mgc2luY2UgdGhpcyBx
dWVzdGlvbiBoYXMgbm8gbW9kZWxpbmcgaW1wYWN0XQ0KDQoNClRoZSBkZXNpcmVkIGNhcGFiaWxp
dHkgaXM6DQoNCldoZW4gYSBsZWFmcmVmIG9yIG11bHRpcGxlIGxlYWZyZWZzIHJlZmVyZW5jZSBv
bmUgb3IgbW9yZSBvYmplY3RzIHNwZWNpZmllZCBpbiBvdGhlciBwYXJ0cyBvZiB0aGUgc2NoZW1h
LCB0aGUgb3BlcmF0b3IgY2FuIHVzZSBhIHNpbmdsZSA8Z2V0LWRhdGE+IG9wZXJhdGlvbiB0byBy
ZXRyaWV2ZSBhbGwgYXR0cmlidXRlcyBvZiB0aGUgb2JqZWN0IGNvbnRhaW5pbmcgdGhlIGxlYWZy
ZWYgYW5kIHRoZSBhdHRyaWJ1dGVzIHJlZmVyZW5jZWQgYnkgdGhlIGxlYWZyZWYgc3RhdGVtZW50
Lg0KDQpUaGUgbW90aXZhdGlvbiBpcyBjbGVhci4NCg0KQSBzb2x1dGlvbiB3b3VsZCBsaWtlbHkg
ZW50YWlsIHJldHVybmluZyBhIG11bHRpLXBhcnQgcmVzcG9uc2UsIHBlcmhhcHMgYSBzaW5nbGUg
dHJlZSBmb3IgTkVUQ09ORi4gICBOb3RlIHRoYXQgdGhlIHJlc29sdXRpb25zIG1heSB0aGVtc2Vs
dmVzIGluY2x1ZGUgbGVhZnJlZnMsIGEgZnVsbC1yZXNwb25zZSBtYXkgYmUgTiBsZXZlbHMgZGVl
cC4NCg0KSy4NCg0K

--_000_B8F9A780D330094D99AF023C5877DABAAD726EECdggeml511mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:=CE=A2=C8=ED=D1=C5=BA=DA;
	panose-1:2 11 5 3 2 2 4 2 2 4;}
@font-face
	{font-family:"\@=CE=A2=C8=ED=D1=C5=BA=DA";
	panose-1:2 11 5 3 2 2 4 2 2 4;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">One further question, =
when the leaf bb in the module bar uses leafref to reference aa in module f=
oo,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Can we use get-data op=
eration to retrieve all data nodes associated with =A1=B0myabc=A1=B1 list i=
n module bar<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">and all data nodes ass=
ociated with =A1=B0fooins=A1=B1 list in module foo,e.g.,<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">foo/fooins[aa =3D /bar=
/myabc/bb]/{ aa,descr,admin,rules}<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><img width=3D"496" hei=
ght=3D"620" id=3D"=CD=BC=C6=AC_x0020_1" src=3D"cid:image001.png@01D638C8.39=
C56220"></span><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&=
quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">-Qin<o:p></o:p></span>=
</p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;=CE=A2=C8=ED=D1=C5=BA=DA&quot;,sans-serif">=B7=A2=BC=FE=C8=CB<span lang=3D=
"EN-US">:</span></span></b><span lang=3D"EN-US" style=3D"font-size:11.0pt;f=
ont-family:&quot;=CE=A2=C8=ED=D1=C5=BA=DA&quot;,sans-serif"> netconf [mailt=
o:netconf-bounces@ietf.org]
</span><b><span style=3D"font-size:11.0pt;font-family:&quot;=CE=A2=C8=ED=D1=
=C5=BA=DA&quot;,sans-serif">=B4=FA=B1=ED </span>
</b><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;=CE=A2=
=C8=ED=D1=C5=BA=DA&quot;,sans-serif">Qin Wu<br>
</span><b><span style=3D"font-size:11.0pt;font-family:&quot;=CE=A2=C8=ED=D1=
=C5=BA=DA&quot;,sans-serif">=B7=A2=CB=CD=CA=B1=BC=E4<span lang=3D"EN-US">:<=
/span></span></b><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family=
:&quot;=CE=A2=C8=ED=D1=C5=BA=DA&quot;,sans-serif"> 2020</span><span style=
=3D"font-size:11.0pt;font-family:&quot;=CE=A2=C8=ED=D1=C5=BA=DA&quot;,sans-=
serif">=C4=EA<span lang=3D"EN-US">6</span>=D4=C2<span lang=3D"EN-US">2</spa=
n>=C8=D5<span lang=3D"EN-US">
 9:55<br>
</span><b>=CA=D5=BC=FE=C8=CB<span lang=3D"EN-US">:</span></b><span lang=3D"=
EN-US"> Kent Watsen &lt;kent@watsen.net&gt;; Xufeng Liu &lt;xufeng.liu.ietf=
@gmail.com&gt;<br>
</span><b>=B3=AD=CB=CD<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> netconf@ietf.org<br>
</span><b>=D6=F7=CC=E2<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> Re: [netconf] [netmod] &lt;get-data&gt; operation with &quot;table join&q=
uot; capability<o:p></o:p></span></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Hi, Kent and Xufeng:<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Should this table join=
 capability be also applied to YANG Push subscription, so we can use YANG P=
ush Notification to get all attributes of the object
 containing the leafref and the attributes referenced by the leafref statem=
ent.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">I raised this issue be=
fore<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><a href=3D"https://mai=
larchive.ietf.org/arch/msg/netconf/4PHiS7EYqehZOz3lIxFMaLZ6rAo/">https://ma=
ilarchive.ietf.org/arch/msg/netconf/4PHiS7EYqehZOz3lIxFMaLZ6rAo/</a><o:p></=
o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">-Qin<o:p></o:p></span>=
</p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;=CE=A2=C8=ED=D1=C5=BA=DA&quot;,sans-serif">=B7=A2=BC=FE=C8=CB<span lang=3D=
"EN-US">:</span></span></b><span lang=3D"EN-US" style=3D"font-size:11.0pt;f=
ont-family:&quot;=CE=A2=C8=ED=D1=C5=BA=DA&quot;,sans-serif"> netconf [<a hr=
ef=3D"mailto:netconf-bounces@ietf.org">mailto:netconf-bounces@ietf.org</a>]
</span><b><span style=3D"font-size:11.0pt;font-family:&quot;=CE=A2=C8=ED=D1=
=C5=BA=DA&quot;,sans-serif">=B4=FA=B1=ED </span>
</b><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;=CE=A2=
=C8=ED=D1=C5=BA=DA&quot;,sans-serif">Kent Watsen<br>
</span><b><span style=3D"font-size:11.0pt;font-family:&quot;=CE=A2=C8=ED=D1=
=C5=BA=DA&quot;,sans-serif">=B7=A2=CB=CD=CA=B1=BC=E4<span lang=3D"EN-US">:<=
/span></span></b><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family=
:&quot;=CE=A2=C8=ED=D1=C5=BA=DA&quot;,sans-serif"> 2020</span><span style=
=3D"font-size:11.0pt;font-family:&quot;=CE=A2=C8=ED=D1=C5=BA=DA&quot;,sans-=
serif">=C4=EA<span lang=3D"EN-US">5</span>=D4=C2<span lang=3D"EN-US">21</sp=
an>=C8=D5<span lang=3D"EN-US">
 21:36<br>
</span><b>=CA=D5=BC=FE=C8=CB<span lang=3D"EN-US">:</span></b><span lang=3D"=
EN-US"> Xufeng Liu &lt;<a href=3D"mailto:xufeng.liu.ietf@gmail.com">xufeng.=
liu.ietf@gmail.com</a>&gt;<br>
</span><b>=B3=AD=CB=CD<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> <a href=3D"mailto:netconf@ietf.org">
netconf@ietf.org</a><br>
</span><b>=D6=F7=CC=E2<span lang=3D"EN-US">:</span></b><span lang=3D"EN-US"=
> Re: [netconf] [netmod] &lt;get-data&gt; operation with &quot;table join&q=
uot; capability<o:p></o:p></span></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">[moving 'netmod' to BCC since t=
his question has no modeling impact]<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The desired capability is:<o:p>=
</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">When a leafref or multiple leaf=
refs reference one or more objects specified in other parts of the schema, =
the operator can use a single &lt;get-data&gt; operation to retrieve all at=
tributes of the object containing the leafref
 and the attributes referenced by the leafref statement.<o:p></o:p></span><=
/p>
</div>
</div>
</div>
</blockquote>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The motivation is clear.<o:p></=
o:p></span></p>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">A solution would likely entail =
returning a multi-part response, perhaps a single tree for NETCONF. &nbsp; =
Note that the resolutions may themselves include leafrefs, a full-response =
may be N levels deep. &nbsp;&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">K.<o:p></o:p></span></p>
</div>
<div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</div>
</div>
</body>
</html>

--_000_B8F9A780D330094D99AF023C5877DABAAD726EECdggeml511mbschi_--

--_004_B8F9A780D330094D99AF023C5877DABAAD726EECdggeml511mbschi_
Content-Type: image/png; name="image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename="image001.png"; size=17741;
 creation-date="Tue, 02 Jun 2020 02:26:08 GMT";
 modification-date="Tue, 02 Jun 2020 02:26:08 GMT"
Content-ID: <image001.png@01D638C8.39C56220>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAfAAAAJsCAYAAAAC4PFDAAAAAXNSR0IArs4c6QAAAARnQU1BAACx
jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAETiSURBVHhe7d1buqq6Eobh0S4bZHtsDdezH9yu
i90Ld1VxSiCBBIIS/N7nYc+lIofgyE8h2/z9999/b53U//7HxMTExMTEVMNEgDMxMTExMVU4eQEO
AADqQIADAFAhAhwAgAoR4AAAVIgABwCgQgQ4AAAV+kqAvx5/77+/v/fj1fbP5GjeT3mvvn//MvI0
z8+tCwCAFF6AD8H69/d8z6NqfO3x6p85pn09DgdiiWWk+uS6jpOTHD1ehY4VAOB6ZhW4VrcSVNL5
e2HVPOU5fb5cIBDg59Ft/Xs2/SMAwB0FAvz5biSw3SpcLyE/X69lgLevrtLrL2f/PZ7vUMa1LzkB
GOaRE4SnzOQGogXOrLofn5P5Y7m5FarNc1hGNz1k+5r47KuGdbV6MjMus9sXT9u8X7Jed56HhOli
tdbG3Tyate5yH8/Xcv4MW+0CAKhfOMAlPvSSuYWAhLQGd9v/O7KqfB40rYWmW/xZmHgBJvPocxpU
bsjMl997SeUfy6K1oBrX666i0XXo/uWz5fVXIcZlyn/o9vnbICE/2yT7Dj2wb6p7TU409OSnP7to
m0DgZyDAAeD+IgGu/9lV4S+tvvWJWcBGg9Wbz1nejAbXeQEeX6/tl3uGkUjXFQ7hNr6uQWTfVNcO
+duzhgAHgPuLB7gEk924JpWhRUFiMHuvrQTXImRKBrguq78cHZwi27RmLRS9bWxl/7Wi9tYXC/8u
wHecT0TIMbOvDR67vyoAANRhJcBnZgF77Qo8oSrOpOsKh7C7j7pe/Qqh7U56BpF9U2UDvLN2sgEA
uIfdAa6XovWx931v/52wG0gWJvLENNvKd+DODWutVbJawe4JcBHavn7dey+hb38Hru3nb++4HwQ4
AKCgKcAtQJ3Lvk6qTP//cJ2cgJL3HLkL3R476/Hm62/qGtY9BNL4vtA0S0K9ac3bPlt3flpqyOr7
dRtC++Ly71KX9+hNc3rznD2eTo6GZS6mSNDnIMAB4P5mFTjuwE5ySpf1AIBLIcBvaf2yPQCgfgQ4
AAAVIsABAKgQAQ4AQIUIcAAAKkSAAwBQIQIcAIAKEeAAAFSIAAcAoEIEOAAAFVoNcP0dcn5TG9/C
5w8A4gjwHfwBTfQnS5+Mv50htf34/AFA3L0voa+Mw72bjdp29cC+8G+hV9F+n2ej7umJTP8YALYQ
4LnOWGZhlx6NrIL2+5YzxoYHcF+BAJfqzbm8ubiE2TzHy56vZzc290N6nWkc7Id0Qt17csbRNtK5
b44vPqxfJu3s3PG3H8/Xu5t9Gkd8Me0ND6scA8uTadHppuyHSp0vU2w88KzjkdTOnab/HAyTjYE+
X31y+218/ow7T1+1usuXYxx615bt/diz3uE9+nfRPxWhxye8vwCwtFqBx4Jg6LQeL+2R+rAcOjvr
+J9jR2bLeMgkvZe7pGa+bA2IRQfYWqca6vgsjGS5Fnp9L9s2/jpsO0tXe1vLTN2PzP3NET1uIvl4
9Lba2Zany3Le2jbaRn3AzWUck7X9kFflc9ete2ABvGjTNOn7kbteAhzAOfYHuNMJex2PhfvU6eky
wpdzW+nYpvm0Uwz2XZEOv1vnRo+YERbJNpaZuh+5+5tjLfhSj8dgvZ01nCJBrSdyofVk7N/afgy6
8JSTC/nXDdU8+ftRZr0+a+tCywJwfx8J8FgnPIXYSgcaeU3XudnXFQjDhdVlpu5H/v6mkepQg0Wq
vcUl7F7a8ZistrMda60uI1OonTKOSUqA6z53N+xNV32y7dmPEuuda5tuO2R9xZYJ4LaqrsCvF+D3
rMDj7Rx+z6qM/dsMcAm8p7SjzqPf0dv30iuzx2XuR8Z6rb2jJwE++zva/FADQOczFbh2dtIxuUuK
fgfuziQPNOhCfVpygLudq3W80pke6SS3Aih1PzL3N8da8CUfj95mO4f2Q5asyzv1ErpWq9ZWzut2
vCMnRltS9yNzvd3NlGnb5P0dAcCGRYBrp7m4hDhM2pFJRzc913VM2vGMr1tnNr02dMLuXcx2Q0+o
o5L3bt2VPa5rPkVCYXm39VoarfD2258WOZWwHyZ1vkybAS6vbR2PnHbWm728/Qi1c2L7bX7+VOAz
qG057U/CyV3A5n7krrd/LTWUCXAAOVYr8BLWwqQa0gl7Pv04k4VgJMFucTwqYcdBq/r+8ZaXBPie
Ew8Av4kATzWE6qf/3aX/qiBULRPgF6RfnejxyvgeHsDPOzXAF5dhay8v5qF69uPCbnc8AOCHnV6B
AwCA8ghwAAAqRIADAFAhAhwAgAoR4AAAVIgABwCgQgQ4AAAVIsABAKjQRwNcf22KXwEDAOC4AwGu
41ZPv+qVEswEeGf4RTTaAgCwV5EK/OO/r62jPEVGH6vFuW0W/y10AMA9EOBfcmab6bL5nXMAuLcP
BHjGpXYJ5vn42Pp4yqJ+1CZnedO8mYE+jO2sY3A/uzGoH7KiaZzsh6x32FZ3H/pxoJU7FvSwkW1j
y5vGiJb/1uV2r46GNksbJ10ranecbJ1P3hfZ54+fUAEAPu6jFfj6fK2EpBuaopXnvADvlarA+wB+
vHQFzpCOugkW8M8peG1eJ7wHOp+3LRLKs3nsO+/Z9lpbSCjrfozzy3+89DlvJXryIOt120XW0cj7
YyctBDgA3N+FAjwUVBElA9xZjgbtuH0W2P74zMsg7kJ/cYIxF9hebYtwAOuJzLReb5sSEeAAcH8X
CnDhXU7WsIxdUv5OgMscdil9DGytvufpvbjc3e1HsAKPtIVW4cNLuk2bJwgjOaGwrwMe3VUEAMBt
XSvAPXopWsPw5EvoWQHe7YOGsWydF7Sd6WsA/+nl9g7LWdKTBCpwAMC6ywS4BdrT+T5Y2XfCkQDX
kBvm7YM++87rHQHeBaxs0zNQfdtrfqgPJyHBClxOAHT9q9+B23bMvlqQ+Rq9iS1SaRPgAHB/uwPc
Ate9TOxOTrDlzPeQALewG+eJXEIXrQWYO19meNtNatP7dTUa4PZYt8uCc3rN1e3T8nnl31UuJwR6
U1wzLKs7IRjWoyG73I/gQmeX5bu28k52HAQ4ANxfkQq8WhKGnsTH3cmGRPHO949KP+7ZCcbi6gAA
4E5+O8DVEIIZ/+pl8pT5PvqvJ3zZHgBwHwS4modg4PF4eV1f6/8di1x9zvXpxwCAn0OAAwBQIQIc
AIAKEeAAAFSIAAcAoEIEOAAAFSLAAQCoEAEOAECFCHAAACpEgO+gA6zwW+MAgG+6TIB3A4TU8fOf
uQGu8+u+EfoAgFKuVYHPhve8E0YIAwCURIB/CAEOACjpsgE+XlK3yR97u3m6r/VjbnvZ2LyfofeO
Y3zLlD3cprvM9cvhoTG+CXAAQEnXDfBGQnARzF2w61jcrfN82+j7ZN7+sbGw9oPfyHKPfs++Fsbj
9vWP5Zl3o89FQt9GOWPsbgBApgsGuASxVtgSsoG4kyp4FtQDDeZZEFo4emHd2g1lR/MyHuDx7dNt
mb9HlzNU9GQ4ACDH9QJcK1W9azuUaO4l8NC0qKy7y97jogIhv0c0wJ0rCHNrVTsAALkuewldq/Bl
4LXxCjzCqlyr5rX6DlxS36FUBQ4AwF6XDXANaw3cRejZd+MSyN7T3ffM4eq6r8KfZapvtVZN22uy
nunVle/AxysKeSclAABcJsCtUnYvg88ul7vhpzetPfsfR+kmvdM7HoHdso9V3+P2habZiUHsLvTF
vOM+lrkyAAD4HdeqwE8yVMW7Sch6ij3urg7oYy+/k98PAPhVPxDgGpIFKtwhNK/6LwDgp9w2wO3/
Qibh5k6HvwKfh+XVHgMAfsZPXEIHAOBuCHAAACpEgAMAUCECHACAChHgAABUiAAHAKBCBDgAABUi
wAEAqBABfiIde5wRyOrDcQNQgwsFePe74MOvpn2jA/UHIZHp8Xw3BzYjNwh0/m/tOyafD3D57PfH
3o7/U4e/BYB1l6zAbfCRT4eYjQx2LLBLKLPvfSCMQ7Pu5A3vimxJ7bccp77VIXMP/+5vGjtp1BPV
/jGAehDgg4uEVYl912UUGfucAD8mpf2C8+jVqM+Fqo4b8KHzBQAFVRngzdMfm/sRutTdNu+XzOeO
y61VzWKp2oE6y3KnfZ1a+lcBsXHDSwT4sWVoVTjtgzd5YePuq1NFum0qjTgMLKPbFNrnuaTjm8BO
ZHQZzjaPzy1GqEs4blIZd6/r9vRXOfpl+Z+V1PZTut7ZtvShvmOXd9Hjc/QzB+Dzqgtwe02D2Hm5
bbTDm1csEhazRViQLDrQXkq1lClpP/rHur2NPied/NHOdG29WVLaxMI6MFyrhp3zXtumx3yfZbbZ
tqYf30SRfZhftnatt18XuHYC0J9V2PbJ4+VJZEL7KZtP26c7WVk7YbHPsH+2cBgBDtSpsgDXzjPS
kWtgbHVsax1qamebYc9+lOhM1wMoQ2KbLE+MugrUPRy6TeHj0zptcfD4hkT24ViAL6/OBJeX3H6z
fZb3ha5MWBv2lfyepoixz1zJBQL4iLoCXDvEvgMLTm5naZc4pw6ve10exzrUxM42x+p+RNa1Hh5b
JDjt8nOgGtwjuU1moRYI27X9GsMv5/imiuzDsQBfnmTsDvDgPCsnMmeQvxVrd9mO2F4DuJ7KKnC3
Wluj8+n3kq3fIa11qCmdbab4fsQ76BorcKXr7AJgeVe1steDVZ57TFOPb4bIPlwqwAPt8tr7lcEO
VOBAneq7iU2qO+0U/e+3u++Pp4DQTtbvUNvhpqNYh/rRAO9fk+2dXr3od+AaVsOihjYMdvba5lKF
P8OXum2bJOT8fZZ3zbc16fhmsH2YPgvj52D2+XCtt5/uZ0aAb7afnLTM3mv/N7LQZ9GWp9teNtxL
nDQC+LzLBLh2msHLpjrNOm69aWi6A1gnvZt5Po97t7N0UFrR2M1G+tjpAPVyrzOfO+3Li4z9iNyF
Hpo3x3oA5VluY3y7um0PB+OwTf5x6fZ5LuX45vD2QT4HevPZcJf40E5Jx837rAz72Z24DM/P2z2p
/caTin4ZsR9yGQM8fvKxBwEO1OmSFTiOsTA6cAKwl4V0ZL1DgOOI/mRBr1D0z5TwkgD/wscFwEEE
+C31FV3hrwTWabjEK0MC/Ir6KxEf/L4dQDkEOA7Ry6/Dpd9hmldzi3ko9wDgMAIcAIAKEeAAAFSI
AAcAoEIEOAAAFSLAAQCoEAEOAECFCHAAACpEgAMAUCECHJjRXyfjV+MAXN2FAnx9UIhP8AeekEl/
YpJ+/OcQ4ABqcMkK/Cu/mz0f+vGSNn7jXPfho79//mW/tr+C3y4HMCDABxWEgbbL6u+IE+A/QX9b
np+TB1BlgDdPf+xmG+t7PnvbvF8ynzsWsw51uViqhoCzLHfa3Una+M7uNuo40M9l2KTO14u3yzS+
9WLyluV+TeGMHOa2gez0MPiIris0Zvlc0vHIIdvjjQcuy9PH0/FI3V/hjOGt73fHI/fH3U74Cmdc
lu5ffzXEHku7BD4ri3HI9T394+X8w2vhZbkYvxuAqi7A7TXp4Vrn5bbRSmx+WVHCZ7YIC6ZYxVas
mtOOWMLRS7D23Wj1vAjTlPkmWyc2SftgYR0Y9lPDyXmvrUtOLuYnPbp97jakH49UrbXL020XWbgf
4L2MY9Yde21bCdJ+2W0TOKET6+3cHTc7ARqX07Wpt8lDu/SPdR+6k45A2xsCHECeygJcO7lIMGgA
bfV8ax1+oQBP7Vz3dMLrwSIS92F5ItOFi9t8uq5we2rADsfg4PEICp3YRGQG+OOVtj3bAb48mXjJ
ycH0lki76PZGAzyd7cuutgVwJ3UFuHWAWqVEJrczX1ye1tfj1W1OGKzRzjWlb02dryMBa5ep/Spv
IXkfZiEUCNu1EBvDKud45JDt8ZYr6wtdus85ZjntvR3gy3D2Ajy6Xfre4wGun21rH1nH0UUBqFdl
Fbhb/a2ZLsN6S1nr8DPCYE1X6W13q6nzudaDRWTsgy6rCwCtvpehYq8HE889BqnH4wj9KkRPxgIB
fNUAj8xj2xsJcGvvxJMe++yk7gyA26rvJjatzjR4vJf7747HTm1Z6QwhcHYFPnbS3heiun1aVToV
dOp8jvVgEbZMCY5xHf0+Bzt7bSMJtWf4UretS0Jp6zvwtOORzoJMby5zlycP5pf4Tcb+fjbA+2W4
bdfvQ+w78PXvx317Tv4A3M9lAtw67uGS6Xya9bx605B11OM8eol1Po9/GdZuqrKbjfSx0wHr5WNn
PndK7fAXLEjc/dHOfB5yInW+3nqwdJZ3jcd3omvzcGgM6/LbMXwpO+V4pOqCL7S88H5v7a+G3bQc
Z5qdrCV9/rzPytBu3YnQ8Lx7fMJ3oQfa205E0kOZAAegLlmBI8xCZvdZxVIXluHlDQGOksIBbsdV
r2L0j7e8Mq4mALgvArwqWrFrNVfgUn8kTAYEeHlakecE9VJ/GX73/0UPwJ0Q4D8mdEl5Xs0t5qHc
26e/ND62owYv50QACiHAAQCoEAEOAECFCHAAACpEgAMAUCECHACAChHgAABUiAAHAKBCBDgAABUi
wAEAqNCFAjw+KMSn+ANj5P9y1vALZlvbnjofAAAxl6zAv/I73POhKXdK3fZz97Hkb6YDAK6IAB9o
gBcIvCsEuC6b3y8HgHurMsCbpz92s431PZ+9bd4vmc8dK1qHzlwsdT7ghDPtycBh27fG0U6db48z
Tw4AANdQXYDbaxrEzstto9XzfIhFCcfZIuy751iVXbICf+j0mtYv//HS55x9Sp1vDwIcAO6vsgDX
G93mQd2TSnbzsvFaSBcM8PBJQutte+p8exDgAHB/dQX4yuVum9xAbPVGLv9S+58+/kCAx8JTq+vh
pdT58kgFb18vPBh3GgBurrIKPLU61fke76ekmLeUr1bg/tWD1Pn2WDs5AADcQ303selNXxJ8/vfb
7bvRQBwvoWsI+lVsaxX5rEp3lazA9Xtsdxv5DhwAUNhlAlxDx7vc7U6z77b1pjUL43EevXt7Po//
oyx2k5ve7GaPnQpXvzt35nOn3LvQ3R9o8X8Uxr+7PHW+vQhwALi/S1bg1ZIQ9hx9vJOdDOWefQAA
qkKAlzaEcKl/d9n4ugAAUD0C/Azz8D36GACAGQIcAIAKEeAAAFSIAAcAoEIEOAAAFaouwP/9+9f/
FwAAv4sKHACAClGBAwBQISpwAAAqRAUOAECFqMB/jo7UNgye0g2o8mn+AC76k6/Pj4xf/q31AsAZ
qMBzFBpy9Cq+MmqZtqGOBvfp4DxlvfzmPIDvoQLPQYAf9602PGG9jPoG4JuowJO075c3/rgzeaHg
Xp5+vMdstOqvf146/NzxwJunP1a6jW1eIHe3AjxpvW3zfsl87j48ZB8XS3XbYDZ5GeiMz67Pu+O6
P54vb7lp25e43h2+cgIEAD0q8BwpVZwFhhPeAw0m573W+T+WYdfMQsHm03mcmdpGt0PCqn+811oA
pa9XTkJmi7ATlFg7pbSh6JYhAS3re/Wp3DZTW2W3S+J6c6y1HwCcjQo8R1b4uPN1Fbxb8WnnH778
2koVP4SQVvSRQNITguD708UD6OB619opow0fr9h6dmwfAQ7gZqjAcySHQHcpfcyRQKisdf4vqTzt
JV3f7LKvNx0MpOg25Ky3lX3VStl7XSvnyLZlBHj0PGFPuyQfuxRyQmaX7x+fvxkPAHpU4DkyQsAq
bJm3tep7eUndXg8mlFuBu/9dXvwkInW9Ot9Dglb30rHWTiUCfE+7FA3wztpJGACcjQo8h4aABsfQ
Z1v1KRVfMGn6KvwZvqRrnb8E+9Z34Fq9a/D43zO3Nl94velWAyhpvbqP/slJO7TJqQEuctuFAAdw
M1TgmZZ3jcdTRjt47250x9D5u3dZx+5C15uzLBQT17um2yZ3Wc40C76U9frb398JrjeT2WOnSpb5
puX4k7tau38gME/ohCCpXRLXuwcBDuCbqMBPZB18JCW+0vlLaHl43P/HPnYydPQsAAB2ogI/zfLy
sutr1dsQWvzr/7vLxtcFAHAiKvDCQpeA50XaYp5PV3GyTs+vPwaAClGBAwBQISpwAAAqRAUOAECF
qMABAKgQFXhhXCEAAHwCFTgAABWiAi+MChwA8AlU4AAAVIgKvDAq8G/qRkfj58kB/AIq8B9iv939
91f8pz9f/YAi9tOw4+AhmcN9FnD33ya/SjsDuAYq8MK+un0pQ2aeMKzm8NOwlp025Ko8/vjvg6//
9vwdXKOdAVwFFfidfCnAu8p+CE8NUgmWD1fCvzAy2BXaGcB1UIEXlrJ9QyWll0KX44vPSsi2eb+e
D28eHaLUn6sdL68upnlY9wG+WO+BHOiC5dlvU7ctnx1pbb36bqT93DaxMcu9efswtKm/JD1UuDpp
e9l8jnEc9PmyeknHTaTOJ/LaedinY8cWwHVRgX+JdsaPx7KzbvR5r1OWkJ/10XYCEKqiUytw7dg1
lPrlthZGj3AQVWCt+rZ21jZ29q1ttJ3m3x1rIHbzDiz4Q+GttgI8+bhlHN8sBDhwd1TghaVuXzx0
9E7qebjMxII6NcADoaTh9dGiuZi16ltfi7Sl3gQWaP8utJ9dVVw6+VKOj0qdD8BPowL/EqsMI4np
hWkrISSPu8ur/aSPDwb4XK0BvlZ927667Tafgm0lJ1D6dYSE+KHmSD1uOccXABxU4IWVrcC7/1/z
s2n9MIkF9c8F+Fr1rRKuZrj6MLV7E+z/phW7PL4l9bhlHt8M9vmyk4FjywFwXVTgX2IVuIaFhLjb
efvfgS8DqrWQiXTM2vG7oTPM654ofDvAx++ON9aXMN9q9T3Q5cj++t8zt9bOfrs0djw0TEfWnpH1
j9sXCvnU45Z5fDN0NzVutDGAqlGBF5ZTgQ+V3nSZVwJk1uP6r/d3UOtNWPZ4WV0u72qf5hirMu+9
GiLDcx+4ezwhmM3mfMvwi9Gb1iwUx/3020XX5b5my7Twnt6zOE8Yty8U4OnHLff4Jum3/fRjCeCr
qMC/ZAhw7JNUfX+LhKfn6ONM1jZ61aF/DOCeqMALy63AcVNDCJf6FwBmqMC/YPghl3G6aiWJY+bh
e/QxADiowAu7+vYBAO6BChwAgApRgRdGBQ4A+AQqcAAAKkQFDgBAhajAAQCoEBU4AAAVogIHAKBC
VOAAAFSIChwAgApRgWeyYRp1xKj+MQAA30AFvoP+ljk/Xw4A+CYq8B00wBlJDADwTVTgOxDgAIBv
owLfwQKca+gAgC+iAt+jbd6PP72Z7fWmDgcAfAMV+A5U4ACAb6MC34HvwAEA30YFvgMBDgD4Nirw
HV4S4FxBBwB8ExV4lpZfYgMAXAIVOAAAFaICBwCgQlTgAABUiAocAIAKUYEDAFAhKnAAACpEBQ4A
QIWowAEAqBAVOAAAFaICBwCgQlTgAABU6PYVOL9dDgC4o5+owHX4T0YPAwDcyU98B8743QCAu/mZ
CpwABwDcye9U4FxDBwDcyE9U4O+2eT/+9Ga215s6HABwB1TgAABUiO/AAQCo0O9U4AQ4AOBGfqIC
f0mAcwUdAHAnN6/AW36JDQBwSz9RgQMAcDc/8R04AAB3QwUOAECFqMABAKgQFTgAABUiwAEAqBAB
DgBAhQhwAAAqRIADAFAhAhwAgAoR4AAAVCga4PyGOAAA17VageswnIziBQDA9WwGOONoAwBwPQQ4
AAAV2g5wrqEDAHA5qwH+bpv3409vZnu9qcMBALgOKnAAACrEd+AAAFSIAAcAoEKrAf6SAOcKOgAA
1xMJ8JZfYgMA4MJWK3AAAHBNBDgAABUiwAEAqBABDgBAhQhwAAAqRIADAFAhAhwAgAoR4AAAVIgA
BwCgQgQ4AAAVIsABAKgQAQ4AQIUIcAAAKkSAAwBQIQIcAIAKEeAAAFSIAAcAoEIEOAAAFSLAAQCo
EAEOAECFCHAAACpEgAMAUCECHACAChHgAABUiAAHAKBCBDgAABUiwAEAqBABDgBAhQhwAAAqRIAD
AFAhAhwAgAoR4AAAVOgrAf56/L3//v7ej1fbP5OjeT/lvfr+/cs4pn093w9nG/4ez3fz+c0AAPww
L8CHYP37e77neTS+9nj1zxzTvh6Hw7fEMrK1Lwnvqwe2nOTo8Sp0rAAA1zOrwLW6lVCUzt8LxkYq
zoc+Xy4Qqg7wiwejtsvfs+kfAQDuKBDgUl1KYLtVePP8ez9fgeCSMLNKz7mUHMpT/5LzQ5bVeuFr
gTOr7sfnZP5YRm8FePMcltFNjyOXuq3ynpblTousTGyX5PkybbULAKB+4QCX6NZL5hYCfcXZ9v+O
rCqX5/uHndZC0w00CxN5YppP5tHnJLC8kJkvv/eSyj+WRWtBNa7XXUWj69D9OyCynaPEdkmebwcC
HADuLxLg+p9dFf7S6lufmAVXNFi9+ZzlzWhVf16Ax9dr+3UkITcCPK1d0ufbgwAHgPuLB7hUg3bj
mlSsFgWJwey9thJGi5CJzLsrwHVZw2Xp0HQkIFcDNrFdkufLJcfMvjZ4cFc8ANzcSoDPzILr2hV4
eyAEN6wGOBU4AOAzdge4XorWx+53zPpAg8m9Qm1hIk9Ms618B+7csNa2si12g9eeABeh7evXfeYl
9NR2SZ5vBwIcAO5vCnALUOcys5Mi0/8/XCcnUOU9R+5Ct8fOerz5dFlNfxlfHg+BNL4vNM2ST29a
87bP1r0zHfW7c3ddzrQI3MR2SZ4vEwEOAPc3q8ARJOHq+fTjTHaSc7SMBwBcGgGeagjVT/+7S//1
w9qlfgBA1QjwHPNQPfsxAAARBDgAABUiwAEAqBABDgBAhQhwAAAqVF2A//v3r/8vAAB+FxU4AAAV
ogIHAKBCVOAAAFSICtyhv7vOb4jvR/sBwOfcuALXkdWmgUJSguUuAeQPHqM/qfr8yPjgBDgAfM5P
VOAfH51ra8jRM9mocp8J7PrwG/EA7uMnvgP/uQAnoIIYpQ3AnVCB51xqD4zfrY+nTJjGL19MZ4eq
Vd6B9cp07njlCe03jqWuVwb6KtgeP5bbpjbbeZ+Pn8gBwImowB3r87USVBo4zuutPBcKFg3Tq1bg
Eqb6ur+XrTw9C9PU+RzbJ0pSAcv06tuwbfSk4zG73J/RzpkIcAB3QgXuSAmgIXxWXTjAXw/Zh9Au
zN6XOp9ru/2WIbxcT0Y7ZyLAAdwJFbhjcz6tSofLunZpVyrF0PyXDXANx6f8b4j7Wup8vu0AX74v
eKKQ2s7J2vfr2VX/J5wXAMBXUIE78iq09t323+fWdAn9uxV4YoB7Vto5U97xBYBrowJ3rM2nr/09
X/p17EQe6E1rwQDXsBrmHW7cOppAKbZOHobvthf7EfkOfGs+R4kAz2rnTKmfAwCowW0rcAsC9zKs
OzlJkDPfQ4LFgnicJ35p1/8xFZ3vYPpskcCdtsufFsEnIe/tx4G70JPaz9u2IbA10Kd5h2DNbecc
tuwCywGAK/iJCvz2JOQ8d3+8k51sHC3jAeAifuI78J8whNyv/LtL/1XG2lcMAFAJKvA7mYfb3R8D
wA+jAgcAoEJU4AAAVIgKHACAClGBAwBQISpwAAAqRAUOAECFqMABAKgQFTgAABWiAgcAoEJU4IWN
g3vwc50AgBNRgZ9ha0hPAAAOogI/AwEOADgZFfgZnAD3x8sexsLuNE9/LO3H4/luvOGq3TGznffq
8ofnc4fHbJv3S9brjlX+kGUsRslOnW80bOtjOf44AKA4KvAzuAHePAPBrLP0geg83zb6Ppm3f2ws
rP3gN7Lcfd+zt946VfOU4F0sK3W+AQEOAJ9EBX4GC3AJYq2wJfDm2duF3SyoBxrMswRcBmf7fj3+
ygWlc8KxKnU+AMDpqMDPYFWzXhKX4A2lbP96d2k6MC1Csqtux0UFQj5ZK8t6+Jfu//TxfJ2p8wEA
voIK/AxOpapV+GNx/buNV+AR9l26LLO16jtwST2JrlcvcetSHIvKOnW+Cf/3OQD4LCrwM3hB1wXu
IsTtu3EJZD8h340GYbC67qvw54Hq25bhh39rlfY8eFPnm+glfe9GOwDAqajAC1tUorPL5W6Q601r
Forj61L1vuLh3C37WEjaTXXu9uh39XrznD2ergqkzmf6fVxeaQAAnIUKvCLDneu7Sch6jj7uTZf3
AQCfQgVejeVl7V2GEC71LwDgK6jAL87+L2QSlu50pAg38/A9+hgA8HFU4AAAVIgKHACAClGBAwBQ
ISpwAAAqRAUOAECFqMABAKgQFTgAABWiAgcAoEJU4AAAVIgKvDj9ydPpV9O+McBH+/IHIvnTgUj4
oXIAuBUq8BPZ4COfDnAbGewugb0+hCkA/DIq8BN9LcBvEng2ytnhH34HgHuiAj/RVoA3z37s8H6y
Mbfns7fN+yXzTZfEuyFFF0udjTvuTrsyMHm9ifPt8JUTIACoBBX4idYCyF7ToHNebhutniXE+8ed
1ptH2QhlsSq7WAWeut7M7ctAgANAHBX4ieIBpDe6zYO61zy3LxuvhfSZl9BTl11oGwhwAIijAj9R
NIA04MZLzoHJDb9Wb+TyL7X/6eOzAzx1vbnbl6S1y/J6OZ675wEgjAr8RPEKso1X4B6d7/F+Sop5
S1kL6SIBnrreHduXgQocAOKowE+0GkDN00LO//64fTfynukSul5qf7zdRbRW8WqVe2aAp653x/Zl
IMABII4KvDANHe9ysjvNvtvWm9Ys7MZ5pJp9zefxf5TFbnLTm93ssVPF63fnznzutPWVekjqepO3
bwcCHADiqMCxJOHrOfp4JzsZ2nP2AQA/gAocYUMIl/p3l3KX4wHgbqjAETcP36OPAQDFUIEDAFAh
KnAAACpEBQ4AQIWowAEAqBAVeGFcIQAAfAIVOAAAFaICL4wKHADwCVTgAABUiAq8MCrw63o9/vht
dQC3QQWOn0GAA7gTKvDCTtm+QuNrV+PX9hcAdqACrwEBDgCYoQIvrOz2tXbZdxhr25u8gGvez/G1
x3u8SqxBODz/bN7Ns/tvvYzcvtxxvHUc8uWl5ebpj21uY30fuQIt2+ONfy7L08fTiKGp+yuc8c/1
/e645I/nS5Y0cNsmcgl9XJbuXz8Cmj2WdgmMZuq1nezDS9/TP17OP7wWXhYA7EUFXoOUitTC2gnv
gYaT814dY/vxkEnSxJ210eedN9t8Oo8zU9vodkjI9Y/ztBJkGmLuAuU5L8B7GRW4nZTI/liQ9stu
G3/fBrZPoQA3GrR6wiJtOC6na1Nvk4d26R/rPnQnHYG2NwQ4gHNQgRf2ze/AuzBz5+vCxQ0ODSCt
xpc0YIdw1tCJBLWeEOxKoi4gh3BclRngj1fa9mwH+PJk4iUnB9NbIu0SO3kCgBNRgdcgOdBmIRQI
27UQG8PKAkmrxsiUGK4LzmXubjnhS/fp+6uLDF22DtsO8GU4ewEe3a7+5CS2aAA4ARV4Yd+swJVV
2DJva9X3MlTSKnD3v88iW9h/37zYnKsGeGQe295IgFt7HznpAYAIKvAaWEBIcAwBMdxoFUwuDRkJ
tWf4UreFmITS1nfgVi3riYAXSq3Nt+cSenfiMFte//3xYnEZ+/vZAO+X4bbdxnfg69+PA8B+VOCF
nbV9y7vG46nVVX3xilBDzL1ru1vecma9iWu6I3t7vWu64AstL5xsW/tr3/ePrzvTrNLt2iIwn05D
8utXDePzQ7t1J0LD827wh+9CD7S3nYhE7nwHgIOowG9oqBJDhgBHSeEAt5MH+zoDAMqjAi/s+9sX
qQZ7BHh5WpET1AA+jQr8JkKXlOdF+GKe1C+P4esvjY/tqP/feNIbwIdRgRd29e0DANwDFTgAABWi
Ai+MChwA8AlU4AAAVIgKHACAClGBAwBQISpwAAAqRAUOAECFqMABAKgQFTgAABWiAj+JDSOpP7HZ
PwYAoCQq8BPljFUNAEAOKvATaYAz8hcA4AxU4CciwAEAZ6ECP5EFONfQAQAnoAI/U9t040Y/Xm/q
cABASVTgJ6ICBwCchQr8RHwHDgA4CxX4iQhwAMBZqMBP9JIA5wo6AOAMVOCnaPklNgDAqajAAQCo
EBU4AAAVogIHAKBCVOAAAFSIChwAgApRgQMAUCEqcAAAKkQFDgBAhajAAQCoEBU4gEvTXzVkTAFg
iQq8uOb91DHA++kbHU/7enbjkA+T/qRrgc2wn4f90j7hdxHgQBgV+Ina1+PzHU/7kvAuE9ghX9mn
j5OTMPst+1f/eCc9FkeXUZNf21/BmAf4JirwE30twE/sRH8hwHUf/0oMI0eA/wQdNphRB/ENVOAn
2gq75ilB4VzqfoQudbfN+yXzTZfE5b+lt1gsVTtPZ1nutLdz8S/FP95P2ZfQPiXth5JttMp2mFfm
08eL7ZN9fj7cZeq6ZVvccGie4+v6/lYeD9v6eL6W7ZPh+ElKPxpdvz3e5AWc+3XL4z2u0j2WsnMa
EPrfuk2hYzKXfDxSbR631P0Vycct4auocVm6f/1VE3ss7RL4zHttJ/vw0vf0j5fzD6+Fl+Vi3H98
CxX4idaCwF6TnqF1Xm4brWDml+Ok054twjr0WKVTqAoat69/rNvR6HPSqbn7lLMfT+sM3RnlOS8I
lHacEmZe4nTrDu1z1xb6mnTI/XvaJnCCk+F4gPdSjoWFtRPeAw0n5722TbKf85M3Oya7jkeq1OMm
Mj57Ocdt/Xh0nxc7ARqX07Wpt8lDu/SPdR+6k45A2xsCHNdHBX6ieMejnUOkQ9WOe6vHWOsoiwR4
fPv8zipnP7qO1g/mpdzOsJt/o70yrQdGhsRj0YWZO18XLm7z6TaFPxcasMMxOPi5Cko7biYzwFOP
23aAL08mXnJyML0l0i66vdEAT2f7sqttgWOowE8U7Xis49Cz+8jkdoKLy8n6ulYukY6yRICvLMPb
p5z9UBIi3vyyH/NLwNoZ5vSFufOvk+C0y89+9bZb8rGYhVAgbNdCbAyr3OORKuG4mYzPXs5x2w7w
ZTh7AR7dLn3v8QDXv1FrH1nH0UUBOajATxTveNyqac10+dJbylpHmdGJxkUqFtFVTmPPmLgfIfrV
gJ6c+B25v/xtZQO8sx4YGTKOha6zCwCtvpehYq8Hd9Q9BkeOR6rwcTNXDfDIPLa9kQC39k486bHP
bOkPIZCACvxEqx2PVjXaYXsv99/1jp2Bdjx+BzN0ntGOpUiA99su2zGtOvwdeNp+dMv705uU3Pn6
7yG9vm/oVL0vMHV5WgUuK+PLB7gGx7Co4dgFN1iPtezLM3yp27ZJQsk/JvKu+bYmHo9UycdNZezv
ZwO8X4bbdv0+xL4DX/9+3GcBnjIjUBgVeGHW4emZe2ia9Vh6s411cOM8emlyPo9/+dJuRrKbdPSx
03HJfNNy/Cm1o5yL3YVuj52FJu2HdaCh+QIdn3X8bjt273VDRDvN6XVnKnXyUqhDXrZh/GB0bRsO
jWGb/M9DuP1SjkeqrOMmtvY39bh1bRGYT6fhs+d95od2606Ehufd4xi+Cz3Q3nYikh7KBDi+hQoc
S9J5eWp/nMnCY+9ZzwFdWIbXOwQ4SgoHuB1/vYrRP97yyriaAJREBY6wIQRr/3cXvQKgVdrxaj5d
pBrsEeDlaUWeE9RL/WX43f8XPeAYKnDEzUOwtscVCF1Snldzi3ko9/bpL42P7ajByzkRKkYFDgBA
hajAAQCoEBU4AAAVogIHAKBCVOAAAFSIChwAgApRgQMAUCEqcAAAKkQFjsvSX7ni18fui+MLHEMF
Xlx8MIVP8QeU+PwvTnUjOR3fdzr4eyt3fPufvu0/7zbwTf8KcGdU4Cf6yu9Xz4d0/JK6f7u70G+h
67H46O+p30xS+y3HT7cR2z70c7N2sspvoeNLqMBP9LUAv0Bo1Bzguu1Ffm+cAD8mpf2C8+hVsM+F
qv5WPT9Pj2+gAj/RVog1T3/MYxvrez5727xfMp87xrJWF4ulakfmLMuddnUuqesVyzGgu3HDbd+H
MZtl33R5+t+2nHFca5nf2+mEryDGcaC1vdzLp7qsfp4Djp989KNUOfsxTl7YuPvqVJHusZQdGgYz
0W0KtfVc0ucqgZ3I6DKcbR6fc7c363gkHN/k9lO6vNkobn2oh3d5WH+Zz4piPHB8CxX4idaCwF7T
IHNebhvteOaVg3Tas0VYh77oyHopVUuStPWO+9E/1vc1+px0kuO+94H0eOmeOUMw6svW+T+d90/W
2q/riDVMpPPu08naTx7vCSvX+nozpBwLa5tZACltF+e9tk2PeVvLbLNtTf9cJYrsw/yy9Z7jsdnO
qZ9lm0/bpztZWT9hIcBxH1TgJ4p3UNqJRDpU7bi3epa1ji2109tjsez4fnid2ux9i9ciy1jv4LuO
eN5Uy2DJtxksqRKPxfLEqDvJcfdNtyn8uWidY3DwcxUS2YdwgOcdj1IB3jxn+yzvC12ZOIt9nve0
LXAQFfiJoh2UhZZWAZHJ7bTskuRw2XJ4XR7HOrbETm9TynpX1uXt+2y+cgG+fN+xAJfgtMvPx6t4
k3wsZuEXCNu1thj32drSOV7zac/nIrIP4QDPOx5FAjw4T3hbTiN/K9bush0rewMURwV+ongH5VZN
a3Q+vdTX+h3DWseW0ultSl1vvKP8TAWeFxipNoMlVcax0HV2AaDV93If7PVgled+llI/Vxki+3Cp
AA+0yyvylYG1496TmQgqcHwLFfiJVjsoqbK0c/K/Z+6+P546au0U/Q6wHW4SinVAGaERl75e20fZ
3mnWyHfgzvt+KsB1G4dFDW0Y7Ox1f6QKf4Yvdds2yb75bS3vmm9r0ucqg+3D1Kbj52D2+dhzPDbb
Oan95KRltg67QTLyN9DdHHf8M+LyPs/AB1GBF6ad0uLS5TDNOlC9yafrDIdJql670Wsy3a3dTXaD
jt0cpI+dDlMvuzrzudOufjt1vSJ2F/rw3mnqOk7t8Oyxbph10tNrSe3n7evQGXcBODx/pEPdDJYM
y7aJH4xu38PhMmyTf1y6tp5L+Vzl8PZBPgd6k9pwl7i1U8bxSDq+jqT2G08quin6Qy79Z63UsR0Q
4PgWKnAsSSfnqf1xJguZPWc9B1lIR9Y7BDj2s+OqVyf6x6W8JMC/8HEBqMARMYRg7f/u0ld0kcuw
59CKNVx9KwL8ipz/S2T/DPBJVOCIm4dgbY8rMH6d4Ezzam4xD+UeAEEFDgBAhajAAQCoEBU4AAAV
ogIHAKBCVOAAAFSIChwAgApRgQMAUCEqcAAAKkQFfgH6a078yhYAIAcVeHH5g2r8RoDntwsAII4K
/EQf//1qHW3po7/fvc/1f9f7G7+FDgB5qMBPRICHXT3Adfv4vXEAV0cFfqL1oMq4pCzB7I3v/Hja
4yljpvGZF9PeQHfGeNb1uONQD+MtW9DN1jE+d2BkreY5LKNfn472FJp9s1322do+ALgCKvATpQbB
+nytDTP5dBOsledCQXVCBW4jYT10HOXn+9VvQ9s005jKkXW+5D17Atxekx2TXRy1ja5jPmRjRrtk
IsAB1IAK/ERlArwfJzpYgs6cFOCP10oiFg1w3dfI2Mp6RcBL5ox2yUSAA6gBFfiJygS4cC5fd5eK
pfIMzX9SgK9WtCUDXJfl7ud8mq8ntV2Ste+XXb5/hC/ZA8CFUIGfqFiAe9p323Z3SX/qEvrHAtwu
i0cq8E0r7ZIp73gAwHdQgZ+oRIDra39605j7sjzQm9aCAa4BOMzbB9qRO6qTAlwvZffrHEJ0901s
WlXLCYG3vxLOjbXDtCFZ7ZIp9bgBwDdRgRdmweJe1nWneQCF5tFpNp/e9d2F4jDFLxW3L/eyss63
L83s5rVxOc4UqLa9dfY3uw13xQ9BmLq/Sm9aW+7vbJ7MdslhyybAAVwcFTgwYycbR8t4ADgZFTiw
0H8NUPh+AgAoiQocAIAKUYEDAFAhKnAAACpEBQ4AQIWowAEAqBAVeGFcIQAAfAIVOAAAFaICL4wK
HADwCVTgAABUiAq8MCpwzOnvwvPb6uBzgNKowG+jeT/HQT2+01H4A6noT5E6I6N9zffbJbfjng8E
g3sgwFEaFXhhV9i+r4ymNR/K9IJqGmWszLYW+k33E8aZv7Rf298MdnKpJ+b9Y3wXFfgNfS3AL97p
/VqA6zKKjKpGgMOhQw0zWN81UIEXVkMF3jz9sbkfoUvdbfN+yXzu2OIP+atdLFU7O2dZ7rTrj7x5
eu9v5fGwfB3/W9dvwaTPOZ3s+JxsZ2zXi7RLsvRL98sx3NvNbU1xfBnTuO6LyQs4d1+d9nc/G3Iw
hzHmdZtC+zxX9ngI2R5v/HhZnj6ePqep+ysSPqedhM/BuCzdv/6qiT2Wdgn8DS3G39f39I+X8w+v
hZe1hx7Ho59NlEEFfkNrHbe9Jn/JrfNy22jFMb8sJp3sbBHWAccqk8JVS7cu6cC1g+p77bZxTiAi
63vJe2J9S5l2yZe03v6xPPNu9DnpdI92kmvrzZJybC2sA22v4eS817ZJjtH8ZND22Xlz+ePRSpBp
iLkLlOe8AO9lfJY3P6eO9eOhQasnLNKG43K6NvU2eWiX/rHuQ3fSEfvcE+B3RgVe2LUrcP1jjnSA
2tFu/YWvdWwZnV6KrpNY2Z7I+vYFeHq7WIfdVzuLKdJ+e9ZbopNcD4wMice2CzN3vi5c3GbRbQq3
kwbs0BYHP6dBuswpHFdlBvjq59Sxfjx0+5YnE/7nOdIuur3RAC/P9nnXMUBpVOA3FO0o7A99Fjru
5HZadinPv4TZVRqRji2j00uhncRqHxFZ364Az2mXHVbXG1n2eme/RYLTLj/71dtuycd2FkKBsF3b
r/HYnXU8ZHu85cr6Qpfu0/c34XPqWD+m4XD2Ps/R7dL3fi7AtW+wdpRt+dQqEUYFXti1K3C3ylkz
XW70lrLWsWV0eik+GuDJ7bJPfL2Rikp0lV1kRxKtB0aGjGOr6+w6dq2+l8fCXg8eWPcYnHs8OvoV
kZ6kBj5nGfv70QCPzGPbGwlwa+8jJz0B9tlM3Wmcigr8hlY7Cq1CtIP1Xu6+d5061uUZ/dDZRTuC
bwS4s43j9q1UIsfbZZ+19dprsvzp1Yt+B67BMSxqaOtgu+hnR47dM3yp27ZJQsnfZ3nXfFsLHw9d
75/eXOYur//+eLG4jP39bID3y3Dbrt+H2Od+/fvxfUqcXKIMKvDCvrV91kHpmXZomvUwenNMF3bD
pJcS5/P4lxvt5iG7qUYfOx2NzDctx59SOzaXdg6hZYVOHBZ340qP23VYUwdTul1SZa03chd6aN4c
1tkX6miX2xjfrm7bw6ExbJP/+er2ea708dC7w5fLC7fP1v6mfk7H4xiahmPr/Q0N7dadCA3Pu8cx
fBd6oL3tRKR82BLg10EFDtyUhceBE4C9urAMr3cIcJQUDnA7/noVo39cyivjqgPORQVe2NW3D7+k
v/QbuHpxnkg12CPAy9OK/IygXuqvcO3+v/KhNCpwAIeFLinPq7TFPJRx+/SXxsd21EDlnOgnUYEX
RgUOAPgEKnAAACpEBV4YFTgA4BOowAEAqBAVeGFU4ACAT6ACBwCgQlTghVGBAwA+gQocAIAKUYEX
RgUOIER/xYxfoUNJVOC3ER/84FP8ASD4haizzQduiUmdD+f6XoAPg/x85ydQ+fydhwq8sCts31d+
b3o+BCM+IvVYf/YzUeg32PUz9dHfcb+nblATOf5fCnDFb+B37GSm4G/JU4Hf0NcCnM72464Y4BYY
JX7nnM/UcXZirYPL6BU6AvwKdEyAUsMAUIEXVkMF3jz9MYptrO/57PIH/5L53DGRdYjIxVKtg5iW
5U67P6SyTG/cZtk+fbxYXmA+d7ctSOz5KQTG5+YjZjljMut63PGqdRxpf9aE9kuV2s5iOUZ1N274
/FgnzZexv7m2Pn/bpnHdF5MX6O7XRs7xdD+TsnPDICq6TaG2mSt6fL1t7LZhLnX7ps9uN9nfw/zv
z54cdO3YrfNggJf+nJ7x93ag3wjOZ4bjJ/uxu/F8erxDn4M9qMBvaK0Dtdf0D895uW200pn/ccsf
3WwR1tHEKiLtSIpUS638wegfi7uB8tz8D0z/4GV9/ia29sfuzRfZrtcjPORlt4/SYUh7vPptaJup
o0pvv1Rp7Tyut3+s72v0Oelc3GOdOt9ga3/3WPv8ZUn5TOk88nlZrE4DwnmvbZNeRvbaRmabbWv5
4ztZa5fU7ZM5g0GsQS1v9egytQ26dx+twMt+Tgfl/t4S+43k+QYEeFFU4NviHcXKH7F2eFuf0LUO
tViA6zZKh+z+gQXEAnixHZHtWgvwxyvWDuntZx2T/eEHpux2jq/X7wxS55us7+8+8c9fpsTPlLW1
N19XebrNbGEWbHc3EA/+fWxYa5e07esslhNqJ33OO7EJ79t3PqeT9c9fzvHQebf7jfT5zmP7fPCz
NKACv6FoR2F/1IE/1GFy/xj1OzM9M/Ze787ogxI72yTyx+ltp6zXv9S58oc9fy2yXWsBHv3bymm/
VCntvNK23rFOnc+xur/ZJDjtcuejzM2MyZ8pPebOfgTCNvo3IcbPwhnH17G2DUnbN/I/46FjqMsL
7kP072ZDyc+po+jf22a/0Uud7yzSlrZ+2f6ja6UCL+zaFfjybD5suszkLWWtQ03ubHPppTvtPPw/
9DMr8GiHktx+qVLb2e+wXbq907FOnW+yvr/7rIVRlozPlAWWzKstGTq29npwR91jWvr4+tbaJW37
JuPx7Ntou7Xjn41tpT+nk/XP35HjEe43ltbns+PSh20p1hbrG5WMCvyG1joK+fR0f/D+X6J9TzV1
IPqH6HeCw4c8+kHO6GzXdB3ZbPvkweI7vtB+2Hza0fSPlW6Xsy/jfsz2b7AZaEntlyq9ne2YyvKn
Wct9B5692RtWP3857NhJBz4samib4AZrW8q+PMOXum2b5LPht428a76tRY+vb61dkrdv0LfNK/n4
afvsDcPyn9NBqb83XW9Kv5E630Cfj/UVe1mAF1ogFXhh39o++2DqmWJomn0y9SaQLsSGSS8hzeeR
PxxnGXbTiN48Yo+djkDmm5bjT6t/mBFdBxDavsAHXjoxbz69ESY4m7Mv/c0y3R/m9Iekf1Tjctxp
1kGplPZLldzOInZ3rz32OrPt+XL2N5cdw9CB2GG5L/F27vYx3NkO2+S3d/hzVfT4Du0emrxjlr59
g+4YPr3ADxk+6920L8RLf05L/71Z+yX0G6nzGTtJKhe2g58OcNyY/LF4an+8pfT6Sj/eyTrrPWdv
B3Wdc3i99lrhjrikS29f6c/V1R/37HOs1X//uJT0qybbqMALu/r2Xd7wx1T7v6lSl/etf3cJX149
1/Iyr4sAPyj183KXf0/RX/nTqxf9M0dRgeN65n9EtT3OVXr9pR9fWOhS7Ly6WczzhasDa66+fSPZ
Ns/dH1eACrwwKnAAwCdQgQMAUCEq8MKowAEAn0AFDgBAhajAC6MCBwB8AhU4AAAVogIvjAocAPAJ
VOAAAFSICrwwKvD66a8lXfpXsQBAUIHfhv6U5PRrTt8IIH8QA5n0JwMrzEECHEANqMALu8L2feV3
ledDP16JbttHf5f7bIV+a/x27fI7Sv+mNupEBX5DXwvwq4bBzYLKRkkq8XvZBHjV9DfUr/qz6fgM
KvDCaqjAm6c/RrGN7TufvW3eL5nPHdfXH6i/pyHgLMuddnUuqetVMu/z4e6Ljuv7dEJpGvd7MS2C
K+MrCNlnbzxhaT9v9nGMdG3Xvlq2x7J9RXJ3/fhuS20Xt02ckb7cYy47NAzGodsUGgt6Lunzl2Fz
eYnHw06M9HmnDcbnhv0flqXHvF+vfT7H8bJ1maGdGdqyzGdAabt//EQdl0IFfkNrHby9ph2O87IO
mG+dXv+4I53xbBHWUccqtmLVXOp6tUOUTtXrLNt3ox3ufN7MbVsNSO2oZVn+q7Je6cz9jrnbPuv4
+220dpbHR8JKrW5fjpR2sbAODNOpQea817ZJTqbmJ1t6PNxtTf/8pUlfXuLxiLTJS/Zt3A1rEw1P
XYMzRKS+bgH/nH0+FAGO8qjAC7t2Ba6dSKSj1I5nq2dZ6/BTwmCvwLKzOq/MbVsLSK8jdy3W0XXY
8yaNvj/D2vZlSWyX5QlUF1ruvuk2hT8/rfOZO/j5W8hZXuLxiLTJIsCdebzPor4W26bCbL3ZbYY7
oQK/oWgHb52LVgGRye24Fpen9fVAdTtIDINNievVziu578rctl0nQIvXwvMeC3AJTrtse7yKN8nt
ovvitHcgbJNOenI+fymylpd4PCJtcsUA178V23/ZlnDL4+6owAu7dgXuVkNrdL7uuzxvKZHOzay9
lix9vV6nuSVz25LCaG6xjjMCvLO2fVky2kXX2QWFVt/LfbDXg2dU7mcu9fOXKmd53w1wa5/FScUx
VOCgAr+h1Q5eqiftfPzvmfvvjqcSSzo7v2Nrh5t/Yh1QRhjEZazXOkqZ1y1FZacau4kq8L2mdqrD
c8MyI51fdvvJA+3g/cXpviQExg6r25cjq110f6QKf4Yvdds2yb5tfQee9vnLkLy8xOMxfK7658bP
n/u5nH3WUwK8u2nw+LF3ZZ3E4paowAv71vaNZ/ihadYx6s07Xac0TBI+dkPOZLqrtpvspiC76Ucf
Ox2UzDctx5/29MfJ61XWubr7rQEy78w7y7ujZ/ub0X7aSXvtJ9vo9aNemwyddheAw/NHOt5iAS62
2sXVtVE4hIZt8o+fLm85c8rnL8fm8jKPh9cmemzlDGe4a19PUob3DMvSILXH+jmxAJ9e6xdoz5UO
WwIcVOBAZSxI95wdHWQhHVlvyZOKZBKKnqs97tnx0qsE/eNSXhLgX/gY4EKowAu7+vbhDvrLus5l
3PNpxRquvtVXAlwNoXnVf0/RXxHQq1P9M/hNVOAAosbLw840r/oW83y6LJR1eq72GDgJFXhhVOAA
gE+gAgcAoEJU4IVRgQMAPoEKHACAClGBF0YFDgD4BCpwAAAqRAVeGBU4AOATqMABAKgQFXhhVOAA
gE+gAgcAoEJU4IWdtX389jEAwEUFXhH9zWlGHwIAKCrwws7cPsb/BQAMqMArQoADAAZU4IWdXoFz
DR0AIKjAa9I278ef3sz2elOHA8BvowIvjAocAPAJVOAV4TtwAMCACryw0ytwAhwAIKjAK/KSAOcK
OgBAUYEXds72tfwSGwDAQwUOAECFqMALu/r2AQDugQocAIAKUYEXRgUOAPgEKnAAACpEBQ4AQIWo
wAEAqBAVOAAAFaICBwCgQlTgAABUiAocAIAK3b4C5zfEAQB39BMVuA7DySheAIA7+YnvwBlHGwBw
Nz9TgRPgAIA7+Z0KnGvoAIAb+YkK/N0278ef3sz2elOHAwDugAocAIAK8R04AAAV+p0KnAAHANzI
T1TgLwlwrqADAO7k5hV4yy+xAQBu6ScqcAAA7uYnvgMHAOBuqMABAKgQFTgAABWiAgcAoEIEOAAA
FSLAAQCoEAEOAECFCHAAACpEgAMAUCECHACACkUDnN8QBwDgulYrcB2Gk1G8AAC4ns0AZxxtAACu
hwAHAKBC2wHONXQAAC5nNcDfbfN+/OnNbK83dTgAANdBBQ4AQIX4DhwAgAoR4AAAVGg1wF8S4FxB
BwDgeiIB3vJLbAAAXNhqBQ4AAK6JAAcAoEIEOAAAFSLAAQCoEAEOAECFCHAAAKrzfv8fko12zrv/
734AAAAASUVORK5CYII=

--_004_B8F9A780D330094D99AF023C5877DABAAD726EECdggeml511mbschi_--


From nobody Tue Jun  2 14:26:25 2020
Return-Path: <session-request@ietf.org>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C85C3A101B; Tue,  2 Jun 2020 14:26:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool <session-request@ietf.org>
To: <session-request@ietf.org>
Cc: netconf@ietf.org, netconf-chairs@ietf.org, rwilton@cisco.com, mjethanandani@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159113318280.7933.13070681353138410478@ietfa.amsl.com>
Date: Tue, 02 Jun 2020 14:26:23 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/o9Yu_T9X-fjdlCeim9U9Ts_b54o>
Subject: [netconf] netconf - New Meeting Session Request for IETF 108
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2020 21:26:23 -0000

A new meeting session request has just been submitted by Mahesh Jethanandani, a Chair of the netconf working group.


---------------------------------------------------------
Working Group Name: Network Configuration
Area Name: Operations and Management Area
Session Requester: Mahesh Jethanandani


Number of Sessions: 1
Length of Session(s):  100 Minutes
Number of Attendees: 65
Conflicts to Avoid: 
 Chair Conflict: netmod httpbis tcpm idr
 Technology Overlap: opsarea opsawg
 Key Participant Conflict: anima rats





People who must be present:
  Mahesh Jethanandani
  Kent Watsen
  Robert Wilton

Resources Requested:

Special Requests:
  
---------------------------------------------------------



From nobody Tue Jun  2 16:48:15 2020
Return-Path: <mjethanandani@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D2E3A1126 for <netconf@ietfa.amsl.com>; Tue,  2 Jun 2020 16:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 7JLd-r1P89CX for <netconf@ietfa.amsl.com>; Tue,  2 Jun 2020 16:48:11 -0700 (PDT)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 E4BC63A1125 for <netconf@ietf.org>; Tue,  2 Jun 2020 16:48:11 -0700 (PDT)
Received: by mail-pf1-x42b.google.com with SMTP id g5so266740pfm.10 for <netconf@ietf.org>; Tue, 02 Jun 2020 16:48:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=TXFPlopV/84KD1PqBNaMFds+tcLqh1Xkc50q5W9RwN8=; b=lbMaJfdXDK5y+KsIjCjKhws2THAhKM6SlIoKZyzSK1GeBzsCno+HYYQ4bA3sw5kpKy iM2wiSyF/YU0pXq6PcxljMKZ7gP09v+EDtHWxxFO13afRqohB7jbICnGoah+TYTWqdjB vaj516FWGVrLZNNE+OV044cIchv72EPwmrmTL/55J47+WBFV0DNPXGyOlTLmix1JJyiL k/sMZg8nm3YEO96bWWeSskpYtCuJ9mZRX6F6y/K2GtyqpNORbdASb1Q5A0GFULMtt736 R8B5xsBKPkGJ2PuZLK52ePbpLa/KAE4tdCpkOo5V6y8YNC27tZh246wuQenBk6GY17za IO0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=TXFPlopV/84KD1PqBNaMFds+tcLqh1Xkc50q5W9RwN8=; b=LOQgLmzfMZp5pfpxfhbemEB8LY1DTtDp7dCqZ/y04/GL2sH2eDc8qhctlOg3NJXo1A 85OzvPnLubQzRITsfjT1KrcKQDxNsyJBWm6C/z3jJbV0xsRWjvLvExkJ6nvXiKYguhAq MQmmyzbk/IcaJarB6le4DKoaUe8OtDf6u0qM73rktn9YPwNCipy2tJb6XhuobdiPIMDH 43MVe5fnL3w+daHty3q9EkQymD2h/x6gyXf/bUHzP8xFXuWHm6NxygM8TFnkYaCkBy0s pJvkddacHKyUO86gg8lORqxjsAaF5Azz0oNDYowYMhcg2dkCmvJChkDrsJWURzx1SpvT B0kg==
X-Gm-Message-State: AOAM533TJFDPc02zJrDU4juZDjnIQYgkd0ZLxOH+g2/FTzwPhiiU2guK uw41ryFi/V4p6GaYfUlD7IJPPLNIk/0=
X-Google-Smtp-Source: ABdhPJyAW+CMmMQMSr4jSr14N13RFDbj93M6uOUY2LXezGvGePjp3JVckSV0ponMLvgCHzLSjMC0fA==
X-Received: by 2002:a63:f91b:: with SMTP id h27mr26176351pgi.276.1591141689755;  Tue, 02 Jun 2020 16:48:09 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:9463:ed44:7572:301? ([2601:647:5600:5020:9463:ed44:7572:301]) by smtp.gmail.com with ESMTPSA id j15sm173356pjj.12.2020.06.02.16.48.08 for <netconf@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 16:48:09 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Message-Id: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com>
Date: Tue, 2 Jun 2020 16:48:07 -0700
To: Netconf <netconf@ietf.org>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/oNFfTJwabuqNMHqYu3juvLlne00>
Subject: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2020 23:48:13 -0000

NETCONF WG,

The authors of

- draft-ietf-netconf-crypto-types
- draft-ietf-netconf-keystore
- draft-ietf-netconf-trust-anchors

have indicated that these drafts are ready for Last Call (LC).

This kicks of a 2 week WG LC for the three drafts. Please review and =
send any comments to the WG mailing list or by responding to this =
e-mail. Comments can be statements such as, I read/reviewed the document =
and believe it is ready for publication, or I have concerns about the =
document. For the latter, please indicate what your concerns are.=20

Any reports on implementation status or plans to implement are also very =
useful.

Thanks.

Mahesh Jethanandani (as co-chair)
mjethanandani@gmail.com




From nobody Tue Jun  2 16:59:39 2020
Return-Path: <mjethanandani@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065993A113E; Tue,  2 Jun 2020 16:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 dNmMXghZJUj8; Tue,  2 Jun 2020 16:59:33 -0700 (PDT)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 7475D3A114F; Tue,  2 Jun 2020 16:59:33 -0700 (PDT)
Received: by mail-pg1-x52d.google.com with SMTP id e9so412617pgo.9; Tue, 02 Jun 2020 16:59:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=D+ZocUjP/wMXXC9r00I03uAhdBSxkAwfV9qS9CrNLeA=; b=G8QfM8vGe0qW20mDNJDH8NC+DRULJr9wZHyLnPpMTX7wQEvCkxTvC/drUYfoMqH8Tb CVINdKcIKoiFbHnDUf5qOW0+pj8lDTJ/y2cGyVK9X9WpxfwlotrJZ9ZbvSeS6hv54Ffv MHeu/PtlH/JlN9NYPh+PAEcCxKyC4Y9kITX0tNY9Hk78MGt1RymYsLKchxbdHLd9iedq A3mkzBEZavjvBRJ6r0JxNgv1FgUy0ojWYmo0Hkh/2Mkp4RB5FseaVo2qxtM97iZL5Iu1 zV1ThESAB2+5Go8yxI3HycSeOVwgkqZLrvJc3ZjREc62PX7lBYG0tXUyHwvhJBWNEbiR Xnrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=D+ZocUjP/wMXXC9r00I03uAhdBSxkAwfV9qS9CrNLeA=; b=VvA0oytLKJbcyRf5IzXj9wNnypy4J0WnIV2ID74aj9wlqVzpDQ9/SYb0tA3K1ndUoc gyhHF1jUfY0lUI033NBEK/Zk+StBRfJbZ3xm9U4B7lKvQFeLqr3glUtCmrJylhRjqsYK axjnnvN31Ga9Vqtljii2faCAu0jnEJfR05RduT+rf0FM0C5Jj1BkpwksweLUEY3zgBqd QqaoLBnRpWL4D999vMFbagjkZTCetEGVf+9q2SXlCCvJVv1jUdoSSDIC3MswDNLayeM9 934DjMxACw4Zvf4ejpCRgvIyfCdbKGchoD2Fa62GTz33+O4wOO6nO+CKCFguWlbyWqXH ql3Q==
X-Gm-Message-State: AOAM533KAmdfEtH5M+vHjWIpisszvjYojVMROrqtAZ2zj0DezPptjRkK 0EivQbE0BCbT6Hqt74pydBi6LoD6iFQ=
X-Google-Smtp-Source: ABdhPJykMrZuw8AZ/JM4KFm0P8zFbeTkcQoJinijAv84vgauj5KYS3JUIoim08G+PTNl5oEAvs/+rQ==
X-Received: by 2002:a17:90b:3006:: with SMTP id hg6mr2077201pjb.159.1591142372561;  Tue, 02 Jun 2020 16:59:32 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:9463:ed44:7572:301? ([2601:647:5600:5020:9463:ed44:7572:301]) by smtp.gmail.com with ESMTPSA id p8sm120201pgs.29.2020.06.02.16.59.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 16:59:31 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Message-Id: <548F5F56-2EEA-433F-8DB1-A50FB59E130F@gmail.com>
Date: Tue, 2 Jun 2020 16:59:30 -0700
Cc: Netconf <netconf@ietf.org>
To: draft-ietf-netconf-crypto-types@ietf.org
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/WfolqOslIsXDMKH0vpCxudxc534>
Subject: [netconf] IPR declaration for draft-ietf-netconf-crypto-types
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2020 23:59:38 -0000

Authors, Contributors, WG,

As part of preparation for WG Adoption:

Are you aware of any IPR that applies to draft identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

Thanks.

p.s. A separate IPR declaration will be sent for the other two drafts.

Mahesh Jethanandani (as co-chair)
mjethanandani@gmail.com




From nobody Tue Jun  2 17:03:54 2020
Return-Path: <mjethanandani@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2393A1140; Tue,  2 Jun 2020 17:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 OHiiktQPdk_K; Tue,  2 Jun 2020 17:03:52 -0700 (PDT)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 861423A113D; Tue,  2 Jun 2020 17:03:49 -0700 (PDT)
Received: by mail-pf1-x42f.google.com with SMTP id v2so303211pfv.7; Tue, 02 Jun 2020 17:03:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=37M0WN9JShnSmG/rUYHFiIWhfiE/cD9OcbgS9R52768=; b=KaVZgyvTey76m60AKsSCDgh7aoN1LHRne2qqrOim3RFRFB4Gy4hy54kIZbP6+iQkp+ DuAtQD2vEy0tdQkfFRTJr3zXxD2R055S0WFX6QlSGmSsIztEa2nIbdD8IOP6s997493n ZILsat7GTHbuk0vF4/LxIISNWZg/4ziHKnTNLbpgCevKGuZogMi1mToU5/wWUXJQMJMs A/MfT9k2N5aqH3S7CWf6OeN0XAw6xLPafVbLPUDQpL2Bs1IM1IFqxfLBt69CmxhnRq6f WtK/iUVtkEm7KO7eBbtcBNPo+vtzKMvx/nvw8qUDIXVusHwBX+XexsO9cRF5vcmwKxyP hfFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=37M0WN9JShnSmG/rUYHFiIWhfiE/cD9OcbgS9R52768=; b=lUuoJqtDcmo7yuqSbvHV5a1jZzdkd04tFM/VHtGfCuz+TrrTmcHcBuYqYNoFTmDn3/ CfUHjWcvI87k4r91TwB5ARaJManRRJCob/aQ0csvx14zVqR0IBeYtb/yVzxfvxNN8jH8 pVR3uIq7RCnHejdfLHXygHvmd2XWM/Oz7AyEYWgGERrO/zgaE1ANOflCYTb4k2E+WpLv U0P12Zxi89s1c+wfAg27GGFgkAC2feVDom4SZ6sM6V3qI1Nz9V0dDfYggNHHGrqPh3Du ZoHoU59FkzgMwIJl1fbw0aTWw3aOPSWmukq3jkAHRbgYJjIcYKaNMFATxzWL1lmDFFBm bYGg==
X-Gm-Message-State: AOAM533Z2+5eszslLgn0AKCKrUNTGQ7EAyXF8mS+Rlt3jt28TMHnFUdN /qHLxb3OCIwYAiybIBdphQaflDORYZA=
X-Google-Smtp-Source: ABdhPJxaCXfjzhBsJFyZ5h958ALZW8cY962coNlpCbBI6BpnUOB80PC54+uMM39WxSPYOEvhPWgjkg==
X-Received: by 2002:a63:1615:: with SMTP id w21mr25530140pgl.217.1591142627270;  Tue, 02 Jun 2020 17:03:47 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:9463:ed44:7572:301? ([2601:647:5600:5020:9463:ed44:7572:301]) by smtp.gmail.com with ESMTPSA id h7sm110825pgn.60.2020.06.02.17.03.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 17:03:46 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Message-Id: <72C089EE-612D-4BA5-AF9D-7AB0D5ADD5C4@gmail.com>
Date: Tue, 2 Jun 2020 17:03:44 -0700
Cc: Netconf <netconf@ietf.org>
To: draft-ietf-netconf-keystore@ietf.org
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/4tJnsE9U0GxtGnZG5O4NrN6hQw4>
Subject: [netconf] IPR declaration for draft-ietf-netconf-keystore
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 00:03:54 -0000

Authors, Contributors, WG,

As part of preparation for WG Adoption:

Are you aware of any IPR that applies to draft identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

Thanks.

Mahesh Jethanandani (as co-chair)
mjethanandani@gmail.com




From nobody Tue Jun  2 17:05:30 2020
Return-Path: <mjethanandani@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386BF3A1140; Tue,  2 Jun 2020 17:05:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 TkjGGXRQ6CLh; Tue,  2 Jun 2020 17:05:28 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 0AC633A113D; Tue,  2 Jun 2020 17:05:28 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id o6so469965pgh.2; Tue, 02 Jun 2020 17:05:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:cc:to; bh=4OX74p+Dn3x6MvkQYJmaKM5MtPcMUPrujGG9Bxe8feg=; b=pNkoGpmXV66VmqAbAJ+xS+yLocPK3v7ttEQOLX1Hg0l1mbG/92gQ8Coe7yFWbXhsIH F5R2gn/cW70GRWWi+EMBFJtSGDClTP7EQFQauKDe/0ISkPni/X7hwsvbX4oIrNhkVfub kJ8HIF3j+qNmzKlMFv9xlQ42+zt/emEQH54pFCWxRoVEs1idPxrfrGj4PQDLbxmD8hkd tA6aEgqc+wVAZbZJ/qxqZudtgyfLP0zkIa17IR5ff9cfdZLpkejSb38mtszbKuyByF4Y 9E24n+BT/YyGYTylyrk1r3tZtm9lFl3S23wQBvqB4IvyDkLjDXsHKCPndSBm5YRZUwVx wcCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=4OX74p+Dn3x6MvkQYJmaKM5MtPcMUPrujGG9Bxe8feg=; b=plwg7yzse9RzAe2+71wMHS5ZtNpMuN6abplyRFBJ0/Gt5c4HsIWbqHUUmmChQ6D2VY uj7j6OnibUwlXdkiQiO+SjB0QB8Z52HGx7WUtaDkTw8FiRRB5wfM+F2IImOWsSOgVRsW mm9A1p60VUMDHbz2cJkfQPCjI8BWs4tTrOc5WDXDvUaQtmd68klYCXNPOp+iPRu9VRLz 6jbuLLs2lqOav8+Pnu3BT6zAkow758tZNp7jHqC+i9tE0d0iBCUKgYvZHCPV7EAtL4EF d6twWT8cyLia5Cgi6akuR2CFrTOwlru2yWYSwEdWcvrrfYXYIcQE67zk6+G+dw+WqvQd ZaiA==
X-Gm-Message-State: AOAM532S44ByayIOw+RffJohlaDuoXumTm+D+VHM4F0dVNihZnQQJew1 mbWlBqVfe5xbDYg2P/rLDQUUNclpwf0=
X-Google-Smtp-Source: ABdhPJzSb3Bz5bWD1jY1XovfMV+7AvDU9g48Gac+3aUxeHDH0Nqtv7Zoa03M1ZoDLquQm1IFt/pO/g==
X-Received: by 2002:a62:1917:: with SMTP id 23mr15385262pfz.272.1591142725782;  Tue, 02 Jun 2020 17:05:25 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:9463:ed44:7572:301? ([2601:647:5600:5020:9463:ed44:7572:301]) by smtp.gmail.com with ESMTPSA id g19sm216184pfo.209.2020.06.02.17.05.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 17:05:25 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1CE0B7DE-1E9F-40F1-B232-C4863111FC0F"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Message-Id: <4367651B-3A72-4294-AD9A-01BFA6FB7095@gmail.com>
Date: Tue, 2 Jun 2020 17:05:23 -0700
Cc: Netconf <netconf@ietf.org>
To: draft-ietf-netconf-trust-anchors@ietf.org
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ytZANGRX45Plz9DwYDv2_fFwZ1I>
Subject: [netconf] IPR poll for draft-ietf-netconf-trust-anchors
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 00:05:29 -0000

--Apple-Mail=_1CE0B7DE-1E9F-40F1-B232-C4863111FC0F
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Authors, Contributors, WG,

As part of preparation for WG Adoption:

Are you aware of any IPR that applies to draft identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

Also please send the response to the list above, and not unicast it.

Thanks.

Mahesh Jethanandani (as co-chair)
mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
--Apple-Mail=_1CE0B7DE-1E9F-40F1-B232-C4863111FC0F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" =
class=3D"">Authors, Contributors, WG,<br class=3D""><br class=3D"">As =
part of preparation for WG Adoption:<br class=3D""><br class=3D"">Are =
you aware of any IPR that applies to draft identified above?<br =
class=3D""><br class=3D"">Please state either:<br class=3D""><br =
class=3D"">"No, I'm not aware of any IPR that applies to this draft"<br =
class=3D"">or<br class=3D"">"Yes, I'm aware of IPR that applies to this =
draft"<br class=3D""><br class=3D"">If so, has this IPR been disclosed =
in compliance with IETF IPR rules<br class=3D"">(see RFCs 3669, 5378 and =
8179 for more details)?<br class=3D""><br class=3D"">If yes to the =
above, please state either:<br class=3D""><br class=3D"">"Yes, the IPR =
has been disclosed in compliance with IETF IPR rules"<br class=3D"">or<br =
class=3D"">"No, the IPR has not been disclosed"<br class=3D""><br =
class=3D"">If you answer no, please provide any additional details you =
think<br class=3D"">appropriate.<br class=3D""><br class=3D"">If you are =
listed as a document author or contributor please answer the<br =
class=3D"">above by responding to this email regardless of whether or =
not you are<br class=3D"">aware of any relevant IPR. This document will =
not advance to the next<br class=3D"">stage until a response has been =
received from each author.<br class=3D""><br class=3D"">Also please send =
the response to the list above, and not unicast it.<br class=3D""><br =
class=3D"">Thanks.<br class=3D""><br class=3D"">Mahesh Jethanandani (as =
co-chair)<br class=3D""><a href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a></body></html>=

--Apple-Mail=_1CE0B7DE-1E9F-40F1-B232-C4863111FC0F--


From nobody Wed Jun  3 00:04:01 2020
Return-Path: <hrogge@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E343A08B9 for <netconf@ietfa.amsl.com>; Wed,  3 Jun 2020 00:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 BQrGeh6klXWD for <netconf@ietfa.amsl.com>; Wed,  3 Jun 2020 00:03:58 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 DCEB03A08A7 for <netconf@ietf.org>; Wed,  3 Jun 2020 00:03:57 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id u16so617682lfl.8 for <netconf@ietf.org>; Wed, 03 Jun 2020 00:03:57 -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; bh=p75sxrJ+PtkdKPMHWWnOEYU1mf+ucBsQ6lF2/jBuFbE=; b=aKQhTtVAm07IH242vCo+wdcYLr6ZOtlQsn9B3vFAmaOUA3MjRCuk2AwbGeaak/J5wM lABJWB4mTjnajcqVWG5NxnDv8UTpdga2+nU6fckJ1dqU1nIQQoPJDOc64p3q144WssbN ehebayVs138ty8RiMTWos27MrvPXdh/ZCxTNILkbxKrb3xnJRnKjsuyrGDcPdY6TTNAz XhdabQ6SbIdScvjJKUBQLHYlsjMbwXw1SCcrs7+tZ7C4awYmLscQC1e3PncLTpLcJuKj vIV2fhY3fnfIsy1rspSGK7ssR+h+GqC1Jjo1CGjj9YsuqLKiOpuwGhgHNbJ5y75JTtil 0qIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=p75sxrJ+PtkdKPMHWWnOEYU1mf+ucBsQ6lF2/jBuFbE=; b=UnnDoVl8z7IbCfEOpLEbNx/uS//1ERbJKdanlXZ8GRe3jPdurPzQ0FZFOHEFT4Dd97 rzei75GLS0thPP7aGb/PhOok2QXLeUGYPkXrMX7o453HfhoaudNIXO/jBKBrdP5a3fQX Svd9RB3Sc8tULDjUttNBHoxsBrIePOZD1nfQRcPe18WhEmJoPKZmww1a/RSwf8ENrgsR UWxfefJoh53lXh0x3zmv2W3J9DuZxmfQARH/roA7SITOTGQTKS8JNwX8d2WbTfe5uRTW p2iIk+7UhW9Hx16H2ciaxAIm7FLmKQikRRHW46l81o4p9VIsRR5P8Umj2d+MJzIQVYgF oeHQ==
X-Gm-Message-State: AOAM533kwOZqCM+qokduHC2zLvODEkdEfyFs6LKGvCd2vvBfsYYIJjz7 A5FcVRRQpo+mMvCsNoE9Y+rhG1aPIBRbUQm1ZvlKN14P1kA=
X-Google-Smtp-Source: ABdhPJwLls337bCvaEwnYZw5+TboBRLSMnkgC/GevykM0Y3RCF85ENe6rdGoV0gTCwaVuFl7q+c+sgPSoRRKyZEH0gs=
X-Received: by 2002:a19:c505:: with SMTP id w5mr1648207lfe.201.1591167835496;  Wed, 03 Jun 2020 00:03:55 -0700 (PDT)
MIME-Version: 1.0
From: Henning Rogge <hrogge@gmail.com>
Date: Wed, 3 Jun 2020 09:03:29 +0200
Message-ID: <CAGnRvuo8pJp-Q3JHnPOQUf2cxoXa=3sj5n7LaK7OJ3OOFKMaig@mail.gmail.com>
To: Netconf <netconf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/9p6i7PXntoaKz1WUUEJGIKraX7c>
Subject: [netconf] Questions about RFC 8040 example B.3.9
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 07:03:59 -0000

Hi...

I am currently implementing all the "with-default" modes in my server
and stumbled over a couple of questions with example B.3.9.

First, the yang model in RFC 6243 A.1. defines the status enum with
the values "ok", "waking up", "not feeling so good", "better check it
out" and "better call for help" (with "ok" the default).

RFC 8040 B.3.9. uses the value "up"... which is undefined (and unclear
if it should be a default value or not).

Second, both results in B.3.9. have a JSON array around the value of
the "example:interface" section... I would expect the result of the
first example to be

{
    "example:interface" : {
        "name" : "eth1",
        "status" : "up"
    }
}

if "up" is a valid but non-default value for status.

Same problem with the second example.

The problem with "up" versus "ok" is also present in the RFC 6243
examples in section A.2.

Henning Rogge


From nobody Wed Jun  3 00:07:45 2020
Return-Path: <hrogge@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DA33A0C97 for <netconf@ietfa.amsl.com>; Wed,  3 Jun 2020 00:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 hLnQ9apscquG for <netconf@ietfa.amsl.com>; Wed,  3 Jun 2020 00:07:40 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 8094A3A0C99 for <netconf@ietf.org>; Wed,  3 Jun 2020 00:07:40 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id 9so1337599ljc.8 for <netconf@ietf.org>; Wed, 03 Jun 2020 00:07:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=ZPotLq05cWtYPWRlmyzMLBR5mnYtWtKB5Zwd/aqLvH8=; b=k8WYNgn6LF1Uovyq/nHtOzvn6GuiP1kFtoCDkTbTomkH4Jh041uCp/T7KPr9iOnYdX GSDUoYf/2gmSsxXYPBxH+74/Fzkv8v0G0ZYbOFd5KA7AD0oDL7sdlnGwyuJsa3RjpJK7 CBeQe29YtD5qkIoRW53SE+8/GMRulq32rfHBrkt0cQ/VmNVh8syfZmm8vopXxKnFKvMJ BB2rcgyZdRYldSDhDsyIQccf9k8F7zgr/jpFIUp/t9NeDJ8aXnIsR7dZIVp6LT+9JCXc IlrLDYvHOOUdPiSmwQVGo1Pi60TKWsqGyIsuoy8TxW8G3FwGzXfKHT6dKJYY8vxppIEe IQ4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZPotLq05cWtYPWRlmyzMLBR5mnYtWtKB5Zwd/aqLvH8=; b=DZnfbsEU2u+rzUfAdCAosuTToXYjELy2zjO1SXTLy0rmGW0u+BP86QcfOeChPALYfN kd0Z/2lqwPH8ul9AsdF1rBZujphVaKQ/ei5bmJt8CZ763Mbmu+8ZHwjaIW0gqS8Kdhp7 MNoEM+B6CJVL40DBxzif8SS9cnQBiwKGaL2T88Ehfs90TPILsgf/oEwXtNdw89uBOIlw JSn+HY8onhDFPCd4O18aHfyTkq1AcmZOEkUIF7PdgYzO4mTyb88qdbNq0WurBFMv58oY 7ON1o9RjP5I4WwFdQEg/+j8TDxNgbWR9MQ33ph2gS2DsARPepYHJivitm+4wPuVBFz0q YHiA==
X-Gm-Message-State: AOAM531h2mRF0noWzIF1LL8qb90PGYDAMiEzs3Meb4BBMzUK9W8fI2JZ MZle2WPBRrR0WOOiROpXE3fl559zcMrUWkcEbgtkbHNX
X-Google-Smtp-Source: ABdhPJzIsnTBWGDwsPIhFWKgPj8XgmSCtOUXdWbh9zJMHiCcsLJYkY8MEr0HUhCBUxvMaCWctYJ2f1sWl4FXijUtPTA=
X-Received: by 2002:a2e:2e0d:: with SMTP id u13mr1297037lju.189.1591168058134;  Wed, 03 Jun 2020 00:07:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAGnRvuo8pJp-Q3JHnPOQUf2cxoXa=3sj5n7LaK7OJ3OOFKMaig@mail.gmail.com>
In-Reply-To: <CAGnRvuo8pJp-Q3JHnPOQUf2cxoXa=3sj5n7LaK7OJ3OOFKMaig@mail.gmail.com>
From: Henning Rogge <hrogge@gmail.com>
Date: Wed, 3 Jun 2020 09:07:12 +0200
Message-ID: <CAGnRvurpJPOuTrT7ft+kVXJPSm2frXw=LY-cVj2ew7X541PFFg@mail.gmail.com>
To: Netconf <netconf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/TxucCtTZ20TOOoNkkKKjZveAAOs>
Subject: Re: [netconf] Questions about RFC 8040 example B.3.9
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 07:07:43 -0000

*sigh* pressed the send-button to early...

the "ok" vs. "up" thing is in the RFC 6243 errata.

Still, the problem with the array and the point that "up" should be
the default (and unreported by "trim") is still valid.

Henning Rogge

On Wed, Jun 3, 2020 at 9:03 AM Henning Rogge <hrogge@gmail.com> wrote:
>
> Hi...
>
> I am currently implementing all the "with-default" modes in my server
> and stumbled over a couple of questions with example B.3.9.
>
> First, the yang model in RFC 6243 A.1. defines the status enum with
> the values "ok", "waking up", "not feeling so good", "better check it
> out" and "better call for help" (with "ok" the default).
>
> RFC 8040 B.3.9. uses the value "up"... which is undefined (and unclear
> if it should be a default value or not).
>
> Second, both results in B.3.9. have a JSON array around the value of
> the "example:interface" section... I would expect the result of the
> first example to be
>
> {
>     "example:interface" : {
>         "name" : "eth1",
>         "status" : "up"
>     }
> }
>
> if "up" is a valid but non-default value for status.
>
> Same problem with the second example.
>
> The problem with "up" versus "ok" is also present in the RFC 6243
> examples in section A.2.
>
> Henning Rogge


From nobody Wed Jun  3 05:23:47 2020
Return-Path: <010001727a2322a2-a498411c-e5df-42ca-b2b1-f386aa1665dc-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E953A1088; Wed,  3 Jun 2020 05:23:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 XyJKK585VCcN; Wed,  3 Jun 2020 05:23:44 -0700 (PDT)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13103A1085; Wed,  3 Jun 2020 05:23:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1591187022; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=vRv4K0PmztHEA7BK/NCADBhUMAj9+WLen8fPDaDKbMs=; b=bFABWzrr6tevJE/BGkbqQOJYXjgHosAN6KG2y9KtKZ3rDZQcZ9f50hUALXHDEMLk i1bEGoSwZkhpNL+Eq6ZyUVRPU1exyENKws1/uMDcGWOYYLh03VLqgxinntGunxUqmod f3JklROc9C0h/1ZncHz969aMfqHvnHym9l5qM4Y8=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <010001727a2322a2-a498411c-e5df-42ca-b2b1-f386aa1665dc-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3B3F26D0-7294-4611-A5BA-F7CEF11DE9CA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 3 Jun 2020 12:23:42 +0000
In-Reply-To: <4367651B-3A72-4294-AD9A-01BFA6FB7095@gmail.com>
Cc: draft-ietf-netconf-trust-anchors@ietf.org, "netconf@ietf.org" <netconf@ietf.org>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
References: <4367651B-3A72-4294-AD9A-01BFA6FB7095@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.03-54.240.48.90
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/k7XGaUxDiV_A1RYGMrpS3QRhTIk>
Subject: Re: [netconf] IPR poll for draft-ietf-netconf-trust-anchors
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 12:23:45 -0000

--Apple-Mail=_3B3F26D0-7294-4611-A5BA-F7CEF11DE9CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

No, I'm not aware of any IPR that applies to this draft.

K.


> On Jun 2, 2020, at 8:05 PM, Mahesh Jethanandani =
<mjethanandani@gmail.com> wrote:
>=20
> Authors, Contributors, WG,
>=20
> As part of preparation for WG Adoption:
>=20
> Are you aware of any IPR that applies to draft identified above?
>=20
> Please state either:
>=20
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>=20
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>=20
> If yes to the above, please state either:
>=20
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>=20
> If you answer no, please provide any additional details you think
> appropriate.
>=20
> If you are listed as a document author or contributor please answer =
the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author.
>=20
> Also please send the response to the list above, and not unicast it.
>=20
> Thanks.
>=20
> Mahesh Jethanandani (as co-chair)
> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>

--Apple-Mail=_3B3F26D0-7294-4611-A5BA-F7CEF11DE9CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><span=
 style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=3D"">No, =
I'm not aware of any IPR that applies to this draft.</span><div =
class=3D""><font color=3D"#000000" class=3D""><span style=3D"caret-color: =
rgb(0, 0, 0);" class=3D""><br class=3D""></span></font></div><div =
class=3D""><font color=3D"#000000" class=3D""><span style=3D"caret-color: =
rgb(0, 0, 0);" class=3D"">K.</span></font></div><div class=3D""><font =
color=3D"#000000" class=3D""><span style=3D"caret-color: rgb(0, 0, 0);" =
class=3D""><br class=3D""></span></font><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Jun 2, 2020, at 8:05 PM, =
Mahesh Jethanandani &lt;<a href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><meta =
http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii" =
class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: =
space; line-break: after-white-space;" class=3D"">Authors, Contributors, =
WG,<br class=3D""><br class=3D"">As part of preparation for WG =
Adoption:<br class=3D""><br class=3D"">Are you aware of any IPR that =
applies to draft identified above?<br class=3D""><br class=3D"">Please =
state either:<br class=3D""><br class=3D"">"No, I'm not aware of any IPR =
that applies to this draft"<br class=3D"">or<br class=3D"">"Yes, I'm =
aware of IPR that applies to this draft"<br class=3D""><br class=3D"">If =
so, has this IPR been disclosed in compliance with IETF IPR rules<br =
class=3D"">(see RFCs 3669, 5378 and 8179 for more details)?<br =
class=3D""><br class=3D"">If yes to the above, please state either:<br =
class=3D""><br class=3D"">"Yes, the IPR has been disclosed in compliance =
with IETF IPR rules"<br class=3D"">or<br class=3D"">"No, the IPR has not =
been disclosed"<br class=3D""><br class=3D"">If you answer no, please =
provide any additional details you think<br class=3D"">appropriate.<br =
class=3D""><br class=3D"">If you are listed as a document author or =
contributor please answer the<br class=3D"">above by responding to this =
email regardless of whether or not you are<br class=3D"">aware of any =
relevant IPR. This document will not advance to the next<br =
class=3D"">stage until a response has been received from each author.<br =
class=3D""><br class=3D"">Also please send the response to the list =
above, and not unicast it.<br class=3D""><br class=3D"">Thanks.<br =
class=3D""><br class=3D"">Mahesh Jethanandani (as co-chair)<br =
class=3D""><a href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a></div></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_3B3F26D0-7294-4611-A5BA-F7CEF11DE9CA--


From nobody Wed Jun  3 05:24:06 2020
Return-Path: <010001727a236fb9-aa0ecebc-2880-4bc8-ad43-59f7a12e9e8f-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39B43A1088; Wed,  3 Jun 2020 05:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 wMBOsQbVl2kC; Wed,  3 Jun 2020 05:24:03 -0700 (PDT)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD8F3A1085; Wed,  3 Jun 2020 05:24:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1591187042; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=H5zzIRLVSIOFtZJGugeIAxl94q0w1gJf7kqT8o8W44g=; b=A2Cw1kvazJ02xgSpox0jKlbj6RCQ+kUvwbOc1AVwfP0+/zGRQZbKFSFNXaxW5J1H gjtiIGBh+U/IgEKwXUEhBlxLC1NiTZDYyV11vdk99KW+0wPJ5PQW8HtJ0tXpmTWFHdV /mXXZTJinpYPqPY2O3aX9zgyHmJCgEAuLdruuUzM=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <010001727a236fb9-aa0ecebc-2880-4bc8-ad43-59f7a12e9e8f-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_56D80A14-0937-4CFF-B8B5-5F5C8C196436"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 3 Jun 2020 12:24:02 +0000
In-Reply-To: <548F5F56-2EEA-433F-8DB1-A50FB59E130F@gmail.com>
Cc: draft-ietf-netconf-crypto-types@ietf.org, "netconf@ietf.org" <netconf@ietf.org>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
References: <548F5F56-2EEA-433F-8DB1-A50FB59E130F@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.03-54.240.48.90
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ravH6wTrunIEv_qqEwyGGFYz6sk>
Subject: Re: [netconf] IPR declaration for draft-ietf-netconf-crypto-types
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 12:24:05 -0000

--Apple-Mail=_56D80A14-0937-4CFF-B8B5-5F5C8C196436
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

No, I'm not aware of any IPR that applies to this draft.

K.


> On Jun 2, 2020, at 7:59 PM, Mahesh Jethanandani =
<mjethanandani@gmail.com> wrote:
>=20
>=20
> Authors, Contributors, WG,
>=20
> As part of preparation for WG Adoption:
>=20
> Are you aware of any IPR that applies to draft identified above?
>=20
> Please state either:
>=20
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>=20
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>=20
> If yes to the above, please state either:
>=20
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>=20
> If you answer no, please provide any additional details you think
> appropriate.
>=20
> If you are listed as a document author or contributor please answer =
the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author.
>=20
> Also please send the response to the list above, and not unicast it.
>=20
> Thanks.
>=20
> p.s. A separate IPR declaration will be sent for the other two drafts.
>=20
> Mahesh Jethanandani (as co-chair)
> mjethanandani@gmail.com
>=20
>=20
>=20


--Apple-Mail=_56D80A14-0937-4CFF-B8B5-5F5C8C196436
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><span=
 style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=3D"">No, =
I'm not aware of any IPR that applies to this draft.</span><div =
class=3D""><font color=3D"#000000" class=3D""><br =
class=3D""></font></div><div class=3D""><font color=3D"#000000" =
class=3D"">K.</font></div><div class=3D""><font color=3D"#000000" =
class=3D""><br class=3D""></font></div><div style=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Jun =
2, 2020, at 7:59 PM, Mahesh Jethanandani &lt;<a =
href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D""><br =
class=3D"">Authors, Contributors, WG,<br class=3D""><br class=3D"">As =
part of preparation for WG Adoption:<br class=3D""><br class=3D"">Are =
you aware of any IPR that applies to draft identified above?<br =
class=3D""><br class=3D"">Please state either:<br class=3D""><br =
class=3D"">"No, I'm not aware of any IPR that applies to this draft"<br =
class=3D"">or<br class=3D"">"Yes, I'm aware of IPR that applies to this =
draft"<br class=3D""><br class=3D"">If so, has this IPR been disclosed =
in compliance with IETF IPR rules<br class=3D"">(see RFCs 3669, 5378 and =
8179 for more details)?<br class=3D""><br class=3D"">If yes to the =
above, please state either:<br class=3D""><br class=3D"">"Yes, the IPR =
has been disclosed in compliance with IETF IPR rules"<br class=3D"">or<br =
class=3D"">"No, the IPR has not been disclosed"<br class=3D""><br =
class=3D"">If you answer no, please provide any additional details you =
think<br class=3D"">appropriate.<br class=3D""><br class=3D"">If you are =
listed as a document author or contributor please answer the<br =
class=3D"">above by responding to this email regardless of whether or =
not you are<br class=3D"">aware of any relevant IPR. This document will =
not advance to the next<br class=3D"">stage until a response has been =
received from each author.<br class=3D""><br class=3D"">Also please send =
the response to the list above, and not unicast it.<br class=3D""><br =
class=3D"">Thanks.<br class=3D""><br class=3D"">p.s. A separate IPR =
declaration will be sent for the other two drafts.<br class=3D""><br =
class=3D"">Mahesh Jethanandani (as co-chair)<br class=3D""><a =
href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a><br class=3D""><br class=3D""><br =
class=3D""><br class=3D""></div></div></blockquote></div><br =
class=3D""></body></html>=

--Apple-Mail=_56D80A14-0937-4CFF-B8B5-5F5C8C196436--


From nobody Wed Jun  3 05:30:38 2020
Return-Path: <010001727a296206-a31c527a-31eb-4b4e-aa3c-9a510e20684e-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8C93A109B; Wed,  3 Jun 2020 05:30:34 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 z02xFtSVvkRd; Wed,  3 Jun 2020 05:30:33 -0700 (PDT)
Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA933A1092; Wed,  3 Jun 2020 05:30:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1591187432; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Zmw6eMZqwoH+knWqi1xXEt6Uim8RQQgNscCELL12vDU=; b=BQEGJIYekZi9xEGKVdlYj/VyxWoCUG+zsXjGmbh/TfjvmmJjaL96YIM5R9gXyO/7 WrPhhbl+tXrPYfbrkL4lNVCE3fvu6CQUQSkjfb+3TS6Q0P9jBN0OlQknuD5bXZWGLwn 0hugSFFTO8lO4grFy9vAqJbWM5goTgiuWDjUCIhk=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <010001727a296206-a31c527a-31eb-4b4e-aa3c-9a510e20684e-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FDA393C5-A2CE-47AD-8384-5CD461288C48"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 3 Jun 2020 12:30:32 +0000
In-Reply-To: <72C089EE-612D-4BA5-AF9D-7AB0D5ADD5C4@gmail.com>
Cc: draft-ietf-netconf-keystore@ietf.org, "netconf@ietf.org" <netconf@ietf.org>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
References: <72C089EE-612D-4BA5-AF9D-7AB0D5ADD5C4@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.03-54.240.48.110
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/31l9RngIfzy7IOt6fsxG6fxFLLo>
Subject: Re: [netconf] IPR declaration for draft-ietf-netconf-keystore
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 12:30:37 -0000

--Apple-Mail=_FDA393C5-A2CE-47AD-8384-5CD461288C48
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

No, I'm not aware of any IPR that applies to this draft.

K.


> On Jun 2, 2020, at 8:03 PM, Mahesh Jethanandani =
<mjethanandani@gmail.com> wrote:
>=20
> Authors, Contributors, WG,
>=20
> As part of preparation for WG Adoption:
>=20
> Are you aware of any IPR that applies to draft identified above?
>=20
> Please state either:
>=20
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>=20
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>=20
> If yes to the above, please state either:
>=20
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>=20
> If you answer no, please provide any additional details you think
> appropriate.
>=20
> If you are listed as a document author or contributor please answer =
the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author.
>=20
> Also please send the response to the list above, and not unicast it.
>=20
> Thanks.
>=20
> Mahesh Jethanandani (as co-chair)
> mjethanandani@gmail.com
>=20
>=20
>=20


--Apple-Mail=_FDA393C5-A2CE-47AD-8384-5CD461288C48
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><span=
 style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=3D"">No, =
I'm not aware of any IPR that applies to this draft.</span><div =
class=3D""><font color=3D"#000000" class=3D""><br =
class=3D""></font></div><div class=3D""><font color=3D"#000000" =
class=3D"">K.</font></div><div class=3D""><font color=3D"#000000" =
class=3D""><br class=3D""></font></div><div style=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Jun =
2, 2020, at 8:03 PM, Mahesh Jethanandani &lt;<a =
href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D"">Authors, Contributors, WG,<br class=3D""><br class=3D"">As =
part of preparation for WG Adoption:<br class=3D""><br class=3D"">Are =
you aware of any IPR that applies to draft identified above?<br =
class=3D""><br class=3D"">Please state either:<br class=3D""><br =
class=3D"">"No, I'm not aware of any IPR that applies to this draft"<br =
class=3D"">or<br class=3D"">"Yes, I'm aware of IPR that applies to this =
draft"<br class=3D""><br class=3D"">If so, has this IPR been disclosed =
in compliance with IETF IPR rules<br class=3D"">(see RFCs 3669, 5378 and =
8179 for more details)?<br class=3D""><br class=3D"">If yes to the =
above, please state either:<br class=3D""><br class=3D"">"Yes, the IPR =
has been disclosed in compliance with IETF IPR rules"<br class=3D"">or<br =
class=3D"">"No, the IPR has not been disclosed"<br class=3D""><br =
class=3D"">If you answer no, please provide any additional details you =
think<br class=3D"">appropriate.<br class=3D""><br class=3D"">If you are =
listed as a document author or contributor please answer the<br =
class=3D"">above by responding to this email regardless of whether or =
not you are<br class=3D"">aware of any relevant IPR. This document will =
not advance to the next<br class=3D"">stage until a response has been =
received from each author.<br class=3D""><br class=3D"">Also please send =
the response to the list above, and not unicast it.<br class=3D""><br =
class=3D"">Thanks.<br class=3D""><br class=3D"">Mahesh Jethanandani (as =
co-chair)<br class=3D""><a href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a><br class=3D""><br class=3D""><br =
class=3D""><br class=3D""></div></div></blockquote></div><br =
class=3D""></body></html>=

--Apple-Mail=_FDA393C5-A2CE-47AD-8384-5CD461288C48--


From nobody Thu Jun  4 09:00:28 2020
Return-Path: <antons@sedonasys.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AD43A0959 for <netconf@ietfa.amsl.com>; Thu,  4 Jun 2020 09:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_IMAGE_RATIO_04=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sedonasys.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 Uyj6fO1_moW4 for <netconf@ietfa.amsl.com>; Thu,  4 Jun 2020 09:00:24 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150101.outbound.protection.outlook.com [40.107.15.101]) (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 110863A0B15 for <netconf@ietf.org>; Thu,  4 Jun 2020 09:00:16 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IyzgGmNHnpLqsqSY6wGjySy5iZ2mdBO2IOM22Pz5EjCzeFi1+tWZL/SbcWFIiCTXUUIP9tcThvk0s0vdmYwi9OGyG/qtWVgEibetz0edQHDfvPRX3F9OOA3l4p07GBUf3u1Zz0qaF1El6+bfjViCOQDtQCHH0qYh4y46dPgz4gPYlyA7ectDJGeuTEma2akL1pdqJAiwf0iDk6chewdnAhJDvfPXRqUUxLEguqq0Y1zvzZKlok5OTq8Mxy08t3TYgTzOMkazHgtEN5MPhi0TuwOX+Qd7aN/rQbPWbwUut5QB5DFPPYHPzzzFrZyz1pjv9wps5PQ6qbkhF5D33a4ptg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yo6HKk8kVhdKi0sBTlVE02E6eX8z1XX2P6O4bHd/Jms=; b=ToBucDwTOyYKkz3APzgHvGog1joZq/n4mlFhSe18sy7xOGFMukKOAqbOY2Sye6dlVUjq6MGEYQEd00D83nToXtCmYg5wyAANJZ9X8iqnaUZHnRdzF338DugDgSRI/pxzTvHP+WqEhFjDC92Z9q4yUA2iGVV8y3D8UFPvCFve3pEVnqVJxpShKvbgcN+DR72Kk4vONhxNPbxWZQh62ywLPmB3ds04sibagVWCnA73pvFJfwN9UPPHpSjq5jrEhZqLzeM5VoF4OFwpvPA35b3uM5FQr9mapW9PF15H1jyGde+B3QtNpJTAnlhfCJ4jrrCJdeqC98KwaYVSejsAE2oXyg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sedonasys.com; dmarc=pass action=none header.from=sedonasys.com; dkim=pass header.d=sedonasys.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sedonasys.onmicrosoft.com; s=selector2-sedonasys-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Yo6HKk8kVhdKi0sBTlVE02E6eX8z1XX2P6O4bHd/Jms=; b=IBJhNq5oHOLQ5M+5TbTP7zRGXXpe7+pDIY6PQOrxxxz5KkNj2qGcv+sxKqwAhX3hfKSjWbYGIQLPfPi9lxuXX3gJf0jSJ/7XEQdVRe/9ya3b0A2m3/aweVq3IZL7S3Vt6xA19hjTxqbEKINCccys+Ifbt9YjQ2v5ar0lb9MBME0=
Received: from AM7PR10MB3956.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:17e::10) by AM7PR10MB3844.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:179::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 4 Jun 2020 16:00:14 +0000
Received: from AM7PR10MB3956.EURPRD10.PROD.OUTLOOK.COM ([fe80::78c4:678d:4faf:d146]) by AM7PR10MB3956.EURPRD10.PROD.OUTLOOK.COM ([fe80::78c4:678d:4faf:d146%3]) with mapi id 15.20.3066.018; Thu, 4 Jun 2020 16:00:14 +0000
From: Anton Snitser <antons@sedonasys.com>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: RESTCONF PUT method on list URI/Resources
Thread-Index: AQHWOok7N72gDjlyR0S72FPPE5cQKA==
Date: Thu, 4 Jun 2020 16:00:14 +0000
Message-ID: <0E0AE22C-4A71-48B9-9DF4-E716884FE130@sedonasys.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.6.190114
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=sedonasys.com;
x-originating-ip: [80.230.230.43]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: be65fb2a-9143-4bbc-5ac3-08d808a05e5c
x-ms-traffictypediagnostic: AM7PR10MB3844:
x-microsoft-antispam-prvs: <AM7PR10MB38448FCD495305F20F801C75D7890@AM7PR10MB3844.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 04244E0DC5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5nhUhVVm5LTqyxBqR/1mKSaO+BDS7QZsCYU/q2AlUYdd6zQecGytSrXIywdLFmm7L0aPQHmm5mvorWR1HxDKtma07Sg+sT5OEiIk6QZqWkhNIs/AO7myWxlX3svirovlmGkuty3rUBk+LMOSyorTDCA8ypwc2V0pldurSiNqr1AKse0HWXtXna1ZIALBcvSR44FjNHphklKb8QvRsVHnU54jx90ERdNB6zJ9NFtA9deYcSnAXUhZRCU4BH4LJnhjQAy9QCrigWjcvdPuRbX2hN3obgVVDh8AVHKe2zbRsircDEXpYM1qy8V/EnODgoBQE/ZIQ5dsGFtyfpTdujINmbWKpNuUJVtZyq5VmAqu3+bihknXhgqSLemd+9JNd8OhoW09KJnYK8TTGgd9rF4DsA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:AM7PR10MB3956.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFTY:; SFS:(346002)(366004)(39840400004)(136003)(396003)(376002)(6916009)(6486002)(99936003)(33656002)(166002)(36756003)(5660300002)(7066003)(8936002)(508600001)(4744005)(2906002)(8676002)(71200400001)(2616005)(6506007)(76116006)(26005)(91956017)(6512007)(66476007)(64756008)(66576008)(66946007)(66556008)(86362001)(45080400002)(186003)(316002)(66446008); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: skDUPBVOLtc1ceoqlZxc8SgnkJnKiqXuWxgjISleQD1xuVcOJPz8Az0hRsvnrs4CBWy1JbID9ENZJE7nAAelrVJKqrdWrUE2nsQvktfcvCsLI+Jgg3IBw7R9hLe6tilb6rsR6pogPi0t2yTTejv8bBGnDqxfoT69wDo05KdEyZBV6ZSg6lGT9nZ5u+vspvzgRAlCzy02pLgOem22Rok3YtuK9xuPP755+YApBqmQdLGbK7bkDubiJ4rGWVg7X/tDu+feYDmPkfVXHoZN/DWKnmg/JEhGqr10odafS/LFCep0LDse/A7CW1B31SUhNopnFi1mS18FLziYGcYoygztQxnuwjEzNM1+wM/LTvN2kGDNMtsEwKdscYMBHZ0+lctKmhg0WBn/v/QmMyvjozpCXZDLggtGCfgLivQSMH+jFQZw5RlqjeIr2xU5RBPGSKrlukUIjyI+Zs2R3iy9S4un8Y9GsvSmHEZTCWlqrMjb1oNlD/Cf5cmtsq/qz4bcSgjR
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_006_0E0AE22C4A7148B99DF4E716884FE130sedonasyscom_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: sedonasys.com
X-MS-Exchange-CrossTenant-Network-Message-Id: be65fb2a-9143-4bbc-5ac3-08d808a05e5c
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2020 16:00:14.2790 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d7c5624d-c76e-473e-9a79-91d374431ce8
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NlKixQ/yW6zZMvE02sMjiQPWWCoLwKVtGCf5/n0csGhx9Espv9ewgOBbkrAC5NlMo8aUdYXNLZXY9+sX6O2odw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR10MB3844
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/M9wGeZPc0dk8vCmQj1foEZPQj5s>
Subject: [netconf] RESTCONF PUT method on list URI/Resources
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2020 16:00:26 -0000

--_006_0E0AE22C4A7148B99DF4E716884FE130sedonasyscom_
Content-Type: multipart/alternative;
 boundary="_000_0E0AE22C4A7148B99DF4E716884FE130sedonasyscom_"

--_000_0E0AE22C4A7148B99DF4E716884FE130sedonasyscom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGVsbG8gZXZlcnlvbmUsDQoNCkkgYW0gaW5xdWlyaW5nIGFib3V0IHRoZSB2YWxpZGl0eSBvZiB0
aGUgUFVUIG1ldGhvZCBvbiBhIGxpc3QgcmVzb3VyY2UNCg0KQXMgcGVyIFJGQyA4MDQwDQoNCg0K
ICAqICAgTGlzdCBlbnRyaWVzIGFyZSBkYXRhIHJlc291cmNlcyBidXQgbm90IGxpc3QgdGhlbXNl
bHZlcyDigJMgbm90IHN1cmUgYXMgbm90IGV4cGxpY2l0bHkgbWVudGlvbmVkLg0KWy92YXIvZm9s
ZGVycy9uei8yMmJ3YnpibjJycWN6ZGR5OTYyOWN6c2MwMDAwZ24vVC9jb20ubWljcm9zb2Z0Lk91
dGxvb2svV2ViQXJjaGl2ZUNvcHlQYXN0ZVRlbXBGaWxlcy9jaWRpbWFnZTAwMS5wbmdAMDFENjNB
OTEuQjY1NzFFODBdDQoNCiAgKiAgIFBVVCBpcyB1c2VkIHRvIGNyZWF0ZS9yZXBsYWNlIHRoZSB0
YXJnZXQg4oCcZGF0YSByZXNvdXJjZeKAnQ0KWy92YXIvZm9sZGVycy9uei8yMmJ3YnpibjJycWN6
ZGR5OTYyOWN6c2MwMDAwZ24vVC9jb20ubWljcm9zb2Z0Lk91dGxvb2svV2ViQXJjaGl2ZUNvcHlQ
YXN0ZVRlbXBGaWxlcy9jaWRpbWFnZTAwMi5wbmdAMDFENjNBOTEuQjY1NzFFODBdDQoNClNvIHdv
dWxkIGl0IGJlIGEgdmFsaWQgaW1wbGVtZW50YXRpb24gdG8gYWxsb3cgUFVUIG1ldGhvZCBvbiBh
IGxpc3QgcmVzb3VyY2U/IC9yZXN0Y29uZi9kYXRhL21vZHVsZTp0b3AtbGV2ZWwtY29udC9saXN0
DQoNCkFsc28sIGdlbmVyYWxseSBzcGVha2luZyBpcyBpdCBmYWlyIHRvIGFzc3VtZSBpZiBub3Qg
ZXhwbGljaXRseSBkZW5pZWQvbWFuZGF0ZWQgaXQgaXMgdXAgdG8gdGhlIGltcGxlbWVudGF0aW9u
Pw0KDQpUaGFua3MsDQpCZXN0IHJlZ2FyZHMNCg0KDQpbaWQ6aW1hZ2UwMDEucG5nQDAxRDNENEVD
LkFGRDgxMjYwXQ0KQW50b24gU25pemFyIHwgU3lzdGVtcyBFbmdpbmVlcuKAqA0KbTogKzk3Mi01
MDQwNDI3NDQNCmU6IGFudG9uc0BzZWRvbmFzeXMuY29tPG1haWx0bzphbnRvbnNAc2Vkb25hc3lz
LmNvbT4NCnc6IHNlZG9uYXN5cy5jb208aHR0cHM6Ly9zZWRvbmFzeXMuY29tLz4NCmw6IExpbmtl
ZGluPGh0dHA6Ly9saW5rZWRpbi5jb20vaW4vYW50b24tc25pemFyLTRhYTU3NjQ2Lz4NCg0K

--_000_0E0AE22C4A7148B99DF4E716884FE130sedonasyscom_
Content-Type: text/html; charset="utf-8"
Content-ID: <79A963E66E0550489608F3C61748CF8C@EURPRD10.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC
My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv
ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S
RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj
b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFt
c29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhh
dmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1M
KTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5k
aWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5
IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7
DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUg
OCAzIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt
YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz
cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdy
YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5
bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt
YXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt
c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t
cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0
ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz
aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0
O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp
bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTQzNTQ0NTA2MjsNCgltc28tbGlz
dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk2NDA3Njg2IC0xNTg4NDQz
NTQwIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz
IDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6
MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo1NC4wcHQ7
DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDo5MC4wcHQ7DQoJdGV4
dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTI2
LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTYyLjBwdDsN
Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjE5OC4wcHQ7DQoJdGV4
dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6
bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjM0
LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjcwLjBwdDsN
Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjMwNi4wcHQ7DQoJdGV4
dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE1MzE2NTAyODY7DQoJ
bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03NzQyMTc5NiA2
NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5
ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl
ZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N
CkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTQuMHB0Ow0KCXRleHQtaW5kZW50Oi0x
OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJbWFyZ2luLWxlZnQ6OTAuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p
bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMjYuMHB0
Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx
OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTYyLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K
CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdp
bi1sZWZ0OjE5OC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5n
ZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzNC4wcHQ7DQoJdGV4
dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgltYXJnaW4tbGVmdDoyNzAuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6
MzA2LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9
DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQot
LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4
dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl
eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+
DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRG
NzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IZWxsbyBldmVyeW9uZSw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgYW0gaW5xdWlyaW5nIGFib3V0IHRoZSB2
YWxpZGl0eSBvZiB0aGUgUFVUIG1ldGhvZCBvbiBhIGxpc3QgcmVzb3VyY2U8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFzIHBlciBSRkMgODA0MDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10
b3A6MGNtIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9
ImNvbG9yOmJsYWNrO21hcmdpbi1sZWZ0Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkxpc3QgZW50cmllcyBhcmUgZGF0YSBy
ZXNvdXJjZXMgYnV0IG5vdCBsaXN0IHRoZW1zZWx2ZXMg4oCTIG5vdCBzdXJlIGFzIG5vdCBleHBs
aWNpdGx5IG1lbnRpb25lZC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+PGlt
ZyB3aWR0aD0iNjMyIiBoZWlnaHQ9IjEyOSIgc3R5bGU9IndpZHRoOjYuNTgzM2luO2hlaWdodDox
LjM0MzdpbiIgaWQ9IlBpY3R1cmVfeDAwMjBfMyIgc3JjPSJjaWQ6aW1hZ2UwMDEucG5nQDAxRDYz
QUEyLjYwNTFCOUQwIiBhbHQ9Ii92YXIvZm9sZGVycy9uei8yMmJ3YnpibjJycWN6ZGR5OTYyOWN6
c2MwMDAwZ24vVC9jb20ubWljcm9zb2Z0Lk91dGxvb2svV2ViQXJjaGl2ZUNvcHlQYXN0ZVRlbXBG
aWxlcy9jaWRpbWFnZTAwMS5wbmdAMDFENjNBOTEuQjY1NzFFODAiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNz
PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6YmxhY2s7bWFyZ2luLWxlZnQ6LTE4LjBw
dDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+UFVUIGlzIHVzZWQgdG8gY3JlYXRlL3JlcGxhY2UgdGhlIHRhcmdldCDigJxkYXRhIHJlc291
cmNl4oCdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+PGltZyB3aWR0aD0i
NjIxIiBoZWlnaHQ9IjEzOSIgc3R5bGU9IndpZHRoOjYuNDY4N2luO2hlaWdodDoxLjQ0NzlpbiIg
aWQ9IlBpY3R1cmVfeDAwMjBfMiIgc3JjPSJjaWQ6aW1hZ2UwMDIucG5nQDAxRDYzQUEyLjYwNTFC
OUQwIiBhbHQ9Ii92YXIvZm9sZGVycy9uei8yMmJ3YnpibjJycWN6ZGR5OTYyOWN6c2MwMDAwZ24v
VC9jb20ubWljcm9zb2Z0Lk91dGxvb2svV2ViQXJjaGl2ZUNvcHlQYXN0ZVRlbXBGaWxlcy9jaWRp
bWFnZTAwMi5wbmdAMDFENjNBOTEuQjY1NzFFODAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJs
YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+U28gd291bGQgaXQgYmUg
YSB2YWxpZCBpbXBsZW1lbnRhdGlvbiB0byBhbGxvdyBQVVQgbWV0aG9kIG9uIGEgbGlzdCByZXNv
dXJjZT8gL3Jlc3Rjb25mL2RhdGEvbW9kdWxlOnRvcC1sZXZlbC1jb250L2xpc3Q8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2si
PkFsc28sIGdlbmVyYWxseSBzcGVha2luZyBpcyBpdCBmYWlyIHRvIGFzc3VtZSBpZiBub3QgZXhw
bGljaXRseSBkZW5pZWQvbWFuZGF0ZWQgaXQgaXMgdXAgdG8gdGhlIGltcGxlbWVudGF0aW9uPzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv
cjpibGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5CZXN0IHJlZ2Fy
ZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj48aW1nIHdpZHRoPSIxMzIiIGhlaWdodD0iNTAiIHN0
eWxlPSJ3aWR0aDoxLjM3NWluO2hlaWdodDouNTIwOGluIiBpZD0iUGljdHVyZV94MDAyMF8xIiBz
cmM9ImNpZDppbWFnZTAwMy5wbmdAMDFENjNBQTIuNjA1MUI5RDAiIGFsdD0iaWQ6aW1hZ2UwMDEu
cG5nQDAxRDNENEVDLkFGRDgxMjYwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+
QW50b24gU25pemFyIDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj
b2xvcjpibGFjayI+fDxiPiBTeXN0ZW1zIEVuZ2luZWVyPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDs7Y29sb3I6
YmxhY2siPuKAqDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFj
ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPm06ICYjNDM7OTcyLTUwNDA0Mjc0NDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5lOiA8YSBocmVmPSJtYWlsdG86YW50b25zQHNl
ZG9uYXN5cy5jb20iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwNTYzQzEiPmFudG9uc0BzZWRvbmFz
eXMuY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+dzogPGEgaHJl
Zj0iaHR0cHM6Ly9zZWRvbmFzeXMuY29tLyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+
c2Vkb25hc3lzLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPmw6
IDxhIGhyZWY9Imh0dHA6Ly9saW5rZWRpbi5jb20vaW4vYW50b24tc25pemFyLTRhYTU3NjQ2LyI+
DQo8c3BhbiBzdHlsZT0iY29sb3I6IzA1NjNDMSI+TGlua2VkaW48L3NwYW4+PC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_0E0AE22C4A7148B99DF4E716884FE130sedonasyscom_--

--_006_0E0AE22C4A7148B99DF4E716884FE130sedonasyscom_
Content-Type: image/png; name="image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename="image001.png"; size=21748;
 creation-date="Thu, 04 Jun 2020 16:00:14 GMT";
 modification-date="Thu, 04 Jun 2020 16:00:14 GMT"
Content-ID: <image001.png@01D63AA2.6051B9D0>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAngAAACBCAYAAABTlcfCAAABQGlDQ1BJQ0MgUHJvZmlsZQAAKJFj
YGASSCwoyGFhYGDIzSspCnJ3UoiIjFJgf8LAxsDCwMfAzaCXmFxc4BgQ4ANUwgCjUcG3awyMIPqy
Lsgsr5/Vd2O5+ar/p3A4sfNovcRUjwK4UlKLk4H0HyBOSi4oKmFgYEwAspXLSwpA7BYgW6QI6Cgg
ewaInQ5hrwGxkyDsA2A1IUHOQPYVIFsgOSMxBch+AmTrJCGJpyOxofaCAIezkbmbsaUBAaeSDkpS
K0pAtHN+QWVRZnpGiYIjMIRSFTzzkvV0FIwMjIBWgsIbovrzDXA4MopxIMRSdzAwmDQDBW8ixLLf
MTDsWcTAwPcOIaaqD+TfZmA4lFaQWJQIdwDjN5biNGMjCJt7OwMD67T//z+HMzCwazIw/L3+///v
7f///13GwMB8i4HhwDcA2DJeV/AOC+kAAABWZVhJZk1NACoAAAAIAAGHaQAEAAAAAQAAABoAAAAA
AAOShgAHAAAAEgAAAESgAgAEAAAAAQAAAnigAwAEAAAAAQAAAIEAAAAAQVNDSUkAAABTY3JlZW5z
aG905iWfjAAAAdZpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1sbnM6eD0i
YWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1s
bnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAg
ICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZXhpZj0i
aHR0cDovL25zLmFkb2JlLmNvbS9leGlmLzEuMC8iPgogICAgICAgICA8ZXhpZjpQaXhlbFhEaW1l
bnNpb24+NjMyPC9leGlmOlBpeGVsWERpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6VXNlckNvbW1l
bnQ+U2NyZWVuc2hvdDwvZXhpZjpVc2VyQ29tbWVudD4KICAgICAgICAgPGV4aWY6UGl4ZWxZRGlt
ZW5zaW9uPjEyOTwvZXhpZjpQaXhlbFlEaW1lbnNpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9u
PgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgr6tACbAABAAElEQVR4Ae1dCfxN1fZfJVOGEIkS
UqEU0kAhkSYqEZUieUKTFxFNmjUp1UuJf71Ek9fTqHqlAekpiZAxIVGEMpPh/td3/d4+nXt/9+y9
f797r99g7c/n3rPP2XuvvdZ3D2edPa39YuxInSKgCCgCioAioAgoAopAoUFg/0IjiQqiCCgCioAi
oAgoAoqAIiAIqIKnFUERUAQUAUVAEVAEFIFChoAqeIWsQFUcRUARUAQUAUVAEVAEVMHTOqAIKAKK
gCKgCCgCikAhQ0AVvEJWoCqOIqAIKAKKgCKgCCgCquBpHVAEFAFFQBFQBBQBRaCQIaAKXiErUBVH
EVAEFAFFQBFQBBQBVfC0DigCioAioAgoAoqAIlDIEFAFr5AVqIqjCCgCioAioAgoAorAAZmGYNq0
afTll1/Shg0b6KKLLqITTzzRO8vZs2fTzJkz4+IfeuihdM4558Q9y883mzdvpj179lDZsmXzM5vK
myKgCCgCioAioAgUIgT2y6SpstGjR1O3bt3i4Bo3bhx17Ngx7lnUTe/evem5556LCz7kkENo9erV
cc8ycTN58mTq0aMH/fnnn1SkSBEqU6YMHXfccXT77bfTscce651lgwYNJO6sWbO80/hEnD9/PnXo
0IG2bt0aRK9evTpdddVV1L179+CZehQBRUARUAQUAUVg30MgoyN4jRo1EgXt4osvJozGnXXWWfT8
8897K3jGTO6YMWOoWrVqUjqVK1feK6VUoUIF2r17Ny1fvpzq169P3333nfwmTpxIGJWsWbOm8LF2
7VpauHAh/fLLL6IA1q1bN46/P/74I+4+8caVPjG+uS9durQonuDvtNNOowMOOICglOLXtGlTOuaY
YyTqzp07ae7cuaIU165dO+Db0NmxY4fIs337dsLo6MaNG6lZs2YmmLZt2ybpIQfSH3HEERKGslm8
eDHt2rWL6tSpI9clS5ZQsaLFqNZRtSQOaP30008EXmvUqCH+OXPm0KmnnkoVK1aUOMgfo7Rrf1tL
J9Q/gX777TcpayjycC7+JZL+KQKKgCKgCCgCikA8AhjBy7TjEbfYoEGDYpxzrG/fvt7Z9ezZU9Lw
iFSsV69esY8//jjG053e6VONeMMNN0j+yJeVlVibNm3k/vrrrxfSTzzxhNxDLvMbOnSohM2bNy/W
uHHj4HnDhg1j+D3++OMBW7b0QSSL57777hP6H374ocRq166d3D/77LNyz6OGsSOPPDLgATx26dIl
xkqZhP/rX/+KC0M44hv3ySefxKpWrRoX59JLL42xUhZ79dVXg+eQtU+fPnJ/0EEHmeQxVjzlGStr
sZtvvjmIX69ePYkzffr0bPyBh/79+0u4i/8gI/UoAoqAIqAIKAKKQBwCFHeXoZuTTjopeNH/+uuv
3rkYpcEoT7jeeOON3ulTjRhW8EDLKEQnn3yykIbiN3jw4BgUlaVLl8ag3PBon4T9sPiHGI+kBUoN
lD38jPKFSLb0QsTxZxS85s2bx3h0NMgLvMCdffbZ8oynxYXHtm3byv2wYcMk3PD3wgsvxHgkMHbn
nXfGLrvsMgmDIs2jkRK/X79+MR55jUExQxnceuutsfXr1wd5fv/997FFixbFeIpYwoUA/02aNCl2
9NFHyzMoeQ899FDsiiuuiN11110xnvoOlEconW+99ZYon6BvFGgX/yYfvSoCioAioAgoAopAPAJ7
RcH79ttvY7fddpu86KGI+DooHRidwogR/Hj5Q1GAcrA3XKKC99577wkPGImDgwLTvn174Qm8mV+Y
Nyg9+CVzPumTpTPPjIIHxdLkDSUUjqdCg2dQsPEzo3m8dk/iQOEy6XCFAjpixAgJmzBhgoThmXEo
C8Qz8ht8oODB4TnCw65ly5byDKN8YQelGHExQshT4UHQ/fffH+NpZi/+g0TqUQQUAUVAEVAEFIE4
BDK6Bo9f4OL4xS/r2IYMGUJYw5boPv30U2IlgS6//PJgbRbiYL2XWfOFKytKsiZuxYoVxMpKQCYq
fRAhDR7shH3llVeE0umnny7r87AJA+vQXnzxRVmfds0118h6tcTswuvwsKasaNGiOUqfSC/x/umn
n6YFCxbQAw88QA8//DBhzSM2hsBhLdu1114bJMGmkSZNmsg9diNj8wgr4PTNN9/IWjysL+SRsyA9
dj8bZ+QoX768PCpWrJhcsY4Q6xVXrlxpoma7hssLgaVKlZI4W7ZskY0sJUqUkHueiifQNbRs/EsC
/VMEFAFFQBFQBBSB7AjEqXtpvsFIEUaA7rnnnhjW0XHuMawTCzt+kctzhJmpOROOdXudO3eOsdIS
w9ovxMG6rrCzpQ/Hy6l/2bJlMt2KPDEKhZFD+DFaxpsCYqzsBHzzTl+R0Yykvfbaa0F2mLJFOsiB
KVLEwWimb/qAUIKHNyPEMDUL2sB006ZNwZQqcGclOOAf065Y79e1a1fJH7jCIT3kYsU1hhE2M5WO
kUWsOTTr784777zYwIEDAwwwtQyHqV/kDzoYyYQfPzOKeO+99wY0sJ4SI34YiYXDqJ3BBnWEldMY
+EZ64BMOj+JfCOmfIqAIKAKKgCKgCGRDIH4+LVtwag/wgjcvfVwxPZs4VYfpVrO2C+u8ws688A0N
TDF+/fXX4SgyXRuVPi5iDm/MFKXJG4oZFKBw/nfffbcoTIgDRYlHxEReKDvGQQkyih+uLVq0iPGO
XAn2SW/oJF5nzJgRYAu6WNsI3owi+vnnn8egpIbX5iEelFXe9SvkwIuRz8iAdY/GYZODUfpMPKw5
NA7r8IySiXzNmj0oZChXw4tJi6vZEAIayfiDsgrlNCo8zL9E0j9FQBFQBBQBRUARyIZARs/B4xe6
HHPBSp1Mr5YrVw6Pkjocx1GyZMlsYTziQ5gCrFSpEh1++OG0//7JjW9Epc9GMM0PcMwHzuXDMS77
7bdfUuqY3oUMOBokkX+f9EmJ5uAhDltG/pjiDvO4Zs0aOvDAA+VoFEyVHnXUUXHhJgtM0+IXhT/k
R/kkymbSu67gb926dTIdH+bPpIvi34TrVRFQBBQBRUARUATiEci4ghefnd4pAoqAIqAIKAKKgCKg
CGQageTDYZnOVekrAoqAIqAIKAKKgCKgCGQMAVXwMgatElYEFAFFQBFQBBQBRSBvEFAFL29w11wV
AUVAEVAEFAFFQBHIGAKq4GUMWiWsCCgCioAioAgoAopA3iCgCl7e4K65KgKKgCKgCCgCioAikDEE
VMHLGLRKWBFQBBQBRUARUAQUgbxBQBW8vMFdc1UEFAFFQBFQBBQBRSBjCKiClzFolbAioAgoAoqA
IqAIKAJ5g4AqeHmDu+aqCCgCioAioAgoAopAxhBQBS9j0CphRUARUAQUAUVAEVAE8gYBVfDyBnfN
VRFQBBQBRUARUAQUgYwhoApexqBVwoqAIqAIKAKKgCKgCOQNAqrg5Q3umqsioAgoAoqAIqAIKAIZ
Q0AVvIxBq4QVAUVAEVAEFAFFQBHIGwRUwcsb3DVXRUARUAQUAUVAEVAEMoaAKngZg1YJKwKKgCKg
CCgCioAikDcIqIKXN7hrroqAIqAIKAKKgCKgCGQMAVXwMgatElYEFAFFQBFQBBQBRSBvEFAFL29w
11wVAUVAEVAE9hICv//++17KSbNRBPIPAqrg/a8sFi9eTJdccon8Nm/e7F1CsVjMO65GVATSjYDW
vyxE//jjD0oFi8Le/nMrn6u+RmG+du1a6tSpE910000uEtbwKPrWRAmBY8aMoQoVKtDOnTsTQvLP
babKZ29JmCn+01H+6cAgU/KlgzcbjQKt4I0ePZpq1apFNWrUoGOOOYZWrVplk9UaVqlSJWrevDn9
+9//ppwoeDfeeCM98sgjVtoaqAhkCoH8Wv+mTp0q7RJts1evXrR79246/vjj5VnXrl0FDlv7HTp0
qMRt0qQJbd26laZPnx609XPPPVfS44U9cOBAKleuHJUvX15+lStXpmnTpuUY7sLe/nMrnwvIqPpX
tmxZqlKlCr377rsuEtbwKPrWRAmBhx12GLVt25YOOOCAhJD8c5up8tlbEmaK/3SUfzowyJR86eDN
RqNAK3jt2rWjESNG0PLly2nLli303HPP2WSNDPvpp5/k665Hjx7Z4mzcuFFeLh9//DHt2LEjafi6
deuyPTcPXOlNvGTXX3/9lebOnUu4wi1btoz+85//0KZNm4Lo4AkvtLfffpt+/PHH4Lnx4CWIcPC/
YMECmjdvngmSK9J/88039NFHH9HPP/8chCEd4pq8McUBXlasWBHE8eFv+/bt9OWXX9IHH3xAq1ev
JnwJhb+kXfwHmSXx+OQfRf/PP/8U+cDTnj17aMkPS+JwRXap0Dfs+uAfVX6LFi2SMt+wYYOUD0ZF
Eh3ql63+ufJPpJd4n9v626hRI7ruuuukbULBK1KkCLVq1YoOPPBAuv/++yUbW/tFW2zZsqXU3Qcf
fJAaNGhAL7/8MmGkrl+/fpK+T58+9Prrr9OHH34oSuA999xDa9asobW/ZccpUa7wfX5t/z7lH9V+
feWLah/h9DZ/VP0rVqwYnXfeeZIUZYb+Jdk0qat+RdG38RQOW7p0KR1yyCH05JNP0n777RcOEn9e
tY8wI7b65yofF/+p9L8+9Q9y2Pi3la8P/VTK34d+XrefcD3IiJ+HQAu0e/7552ONGzeOjRw5Mla1
atXYrl27vOX57rvvYnXr1sUcq/z4hSLXX375RWhwBZH7gw46KFa9evUYrp9//rmEzZ8/X/LFM+5A
Yg0bNpTfnXfeGeRvSx9Esng6dOggeZ5zzjmxSy+9NODz6quvllSzZs2KHXnkkfLcyHHDDTcEFMEr
+OORSeENcsJvHCteIheeAztce/fuHWOFJ/bJJ59IWv7ylej8UpX7evXqmeQxF38zZswI6IMPg/OU
KVOEhov/IKMIjyt/G/0JEyaIPMDNyA7+gC0rf5JjKvRBwIW/jb/ffvtN6hV4Qv0y+L089mXhzaf+
ufIXQpa/VOsv6tFJJ50U69mzZ4xf7iIHf6DE5Whrv7feemusRYsWIjt/xEk64ADZcQ9sHn/88Th6
w4YNi/GHTtyzqJv83P5d5Q+ZbO0X4S75bPUP6W3Op/7xR52UUbj+/utf/wrI2uqXD/2AUISHR42l
f0SdwS/R5XX7SLV8XPyn0v/61D8X/7byddFPtfxd9FEX8rL9JNbFTN1j3UqBdk2bNo0NHz48xqNa
0ojffeddL3nwEodydNZZZ8W+//772Jw5c2KJCh5r97H//ve/8sJHhbniiitEAUAG/GUU41ExSd+x
Y8cYf6HK74fFPwT529IHkRyexx57TDrJzp07x3ikJsYjaPJyQzIoJ+B527ZtQsV0qKYT7d69e6xN
mzZBDjzCGevSpYvcQ34oNlAeIRtexsAOL00eFZU4Dz/8cIy/woP0CD/66KODe3ii+AM94HvaaafJ
Cxn3zz77rNCfOHGi0HDxH5dRxE1U/ojuon/XXXcJPzxCFFu5cmWMpwzl/oEHHghyS4W+DX8f/qBk
ozxeeukl4QdKNhQeOJ/658pfCFn+0lF/0X4gA+qR+VgIZ2lrv1Dw+vbtKwoir4+VZEbBM3XVV5kL
5wl/QWj/tvJ3tV8f+VztIxGz8L1P/TP90bhx46R/uf7662Nnn312QMZWv3zoB4QcHtTBZApeXraP
dJSPjf909L+u+pfK+xNFZqOfjvK30c/r9uOosmkLLtAKnvlC+Pvf/x7j6RlRPsIKjQ0lKHR48ZjR
JMSFH8/MCN7MmTNFQTJfgAg7+eST48hCYbrlllvinpkbn/QmbtQVCgaUJDTYsINCAn7QSUNJNT88
69+/v0Q1L1coZaBx2WWXxXhtlIR9++23kh5fgWGHEb727dvLI18FLxl/pmzee++9MPnY+PHjYzxl
IwqVi/+4hBE3qeADBS88IoksoEhDHuNSoW/D36f80EFh9MM4fFCE7/HcVv9s+Ruatms66q/hEWW9
ZMmSuOxMHYlqv0bBwwcI2qAZscDXPZQG0Fy4cKHQ5Glfqbeou3jxuVxBaP+28ne1X5d8PvXPhSHC
bfUPCh4+Io1DX1CdZ0KM86lfNvqGjusapeDlZftIR/nY+DdtK5X+11b/XPyjTFzla6NvyjSV8rfR
zy/tx8iZqWv+XXXKvbfLvfjii8RTo1S8eHFZg8dfh8SjebJOrFq1atbkPJUr4Vj8bRzW8YVdt27d
qGbNmsQvEcLibWymeOONN8JRZF1H1KYMn/RxxCJuKlasmG39SNGiRSU2K7SytskkZWVT1ivhnl+K
xKOT9MUXXxDWb3GFJ1ZgiF+0VKpUKUmC9TFhh/Ve3CnLI6xZCWOybn3ytYbJ+CtZsqTQCK8XxIOL
LrqI9t9/f+IvKAm38S8RPP6S5e+DD0hjAT83rgBf3LMyHZdrbunb8PflL7ww3KQJM4cyiqp/tvyx
Js7l0lV/edSRZs+eTfzFH5elb/sF/qyMEyuCQXpWzMXPo9V0++23SxvARiv4WckL4kV5Ckr7jyp/
V/t1yWfqUqrtz1b/gH2JEiWCIsC6vLDzqV8u+mF6OfXnZftIR/nY+E9X/xtV/1z8oyx8yjeKvinL
VMs/in5+aT9GzkxdC+wmCx7eJ7wgeM0ZYRE2jzYRr8chHtEingqUl7YNtGOPPZb4a5IGDBhAn376
qSwC5hEDScLDw3KF8nf44YeLn0eeiEdzhK4JRwB272HHIBZ38xcL8fQeYVs+nE96iRjxB+UICgdk
Xb9+vSwwN1Gxq4fXN9GkSZNE+TzzzDNFacOuNShycIMHDyae4pIX3m233UZ/6/43WfSORflHHXUU
1a9fXxa885egLICGAsvrKoinnCX9KaecQpMnT5ZNGNhgweubRCYs7IWz8QfceG2k4IENHpDjhRde
kJ112NThw79kYvmz5e9LHxtTsBkAZYjF/2+99RZdfPHFkmuq9G34+/CHckdHavDGPZxv/bPlL4Qc
f6nWX5BHuUMBBS0ssjfKs0/7hdz4wEB6tHN8FOADBA7tHJs0nnnmGdkEhbqGRf342IOi53IFof3b
yt/Vfl3y+dQ/F4YIt/V/4B/lburtju07pC6b+utTv2z0XfyhvqDfxEJ9OPjxQ75wedk+0lE+Nv7T
0f/a6p+Lf+DrKl8bfaSHS6X8bfTzS/vJkjKD/5kaGsw0XUyjMSzyw0JtOFZYgmd83ImTBQxxY8rA
0DEbGcw0GNaywY9wXLGGBP7wNC3WAGGa1NAAX2ba0yd9FJOYxjQ0w9fwInWs98MGk3A4v/RkzRvo
Ys0gf+VJOK6YLgkvSseUGaZkTXrECYezciFT1CYc62fgB04+/PHuqmBdI9IBJ0z7mulmF/9R2OC5
T/4u+piiRXkZuVDGgwYNko066aDvwt/GH6YlDe4XXnhhjF9MwT2m442z1T9X/oZG1DWV+guarIwF
PBtZ+CNCsnO13yFDhgRpUS6oM6j7oGOmZbFxAzLimanniMsfPVEixT3Pz+3fp/xd7dcln63+xQFl
uYmqf2YKGGWDaXP+AA7K06zr9alfUfQtLAVBWLdp6l34avq4vG4fqZaPi/9U+l+f+ufi31a+PvRR
kLktfx/6+aH9BJU1Q579QJcr/z7rID53RoRpoPB0ggEEXyEIP+KII8yjpFd8GWJY3AyNm0i+6U38
3FwxMoLRJpw7ZaZeQAfPMC2CL1nEiZIBX7gYGcF5UZg+TXQIg1yJUyyJ8aLukR6jMcA4mYviP1nc
3DyLon/33XfL9Purr76aG7JBmij6vvhHpQ8y8PAkq3+++dvI7436a8s/MQxLDRLrEW8ykmUHrORF
1uFEOua+MLR/W/t1yQccMlX/DMa2q2/9Sla/bXR9wvJD+0ilfHz5z2T/6+Lft3xd5ZWJ8jd55of2
Y3hJ93WfV/DSDajSKxgI4Ny7nr16ytQ6LJjwqCydf/75BYN55VIRUAQUAUVAEXAgUKA3WThk02BF
IBKBLVu3yDpErMWABRQe0o+MqwGKgCKgCCgCikBBQ0BH8ApaiSm/ioAioAgoAoqAIqAIOBDIvuDK
kUCDFQFFQBFQBBQBRUARUATyNwKq4OXv8lHuFAFFQBGQjRAKgyKwryKAjUDqco7APqHgwWj8HXfc
QZ06daIrr7xSDkLOOVSppVi8eDFhMT9+UQfTJssBu5Qy6TJNP5O8K+38iwB2u6K93XTTTfmXyRBn
fCyO8+zMUPRs3ty2bxBy9U84V7NChQrBeYjZMk/Dg1T4R/a5TV9Q+p/cypeGoskICZxFyra2xTBA
RjJII9G9Uf+TsTtv3jx5XwOnPn36JIuS75/tEwoerDuwyRaqU6eOdJTYXr63HQ4W5TPniM/ny5GC
d+ONN4oFjUzxm2n6meJb6aaGAJuRoho1aiT9mYOyU8mhbNmycmwPDt7OjcPB04a/Xr16yaGpxx9/
vDzr2rWrkGTbwVSrVi15hsONsVnGuKFDh8rzJk2ayGHL06dPD+Kee+65Eg1H9wwcOJDKlSsnB6ri
UFVYrJk2bZoh433NbftGBq7+CccXsR1fCp/K782YZ8RU+EcWuU1fUPqf3MrnCf9ej4Y6hYOAYeUo
v7u9Uf+TYcBnalLr1q3FstM777yTLEr+f8ZfUAXa8anoMe685RDUFStWZJMF4VwKcvipOWA3WyTL
Az5DKPb111/HPvroIzHwbokaGbR8+XI56JNP5RdejK1bJHDRd9nic6XnM/BiOJAS/MOGJ5sui+PT
Rd+GL+SATUIjz9KlS2MffvhhjM8VCvJAeuTPFiKy2SINIkV40kHfJX+UfEgHrIxsfA6TyIrDQ43z
4Y/PaBP7v++//36MR2pisBEJ2salgo+hkZsrf+TE2BKM1EeUj/nh4Gw8N85Vv2zywRYpDJLz9Iq0
T2Do60AXh2Kj7c6YMUOSwWYtDstGe4LDYdSo14iDQ7z5ZH95jj/kefXVV0sYj94L5pARByKbw8J7
9+4dq84HneM5W9yIPfHEExL/3XfeDej4eGzt21W+CLf1TzjoFW0Mh7ImOhz4jDYHHCATDndNdK78
Ed/GfyK9ZPe29K764+p/XOmT8WOe+eJje3+Alk0+H3wNP8mutvaD+Db5feRLlqd5hoPeYZ8c70XU
I/QJiS638vn0nz782+o/eDW8o2+Bn0fdpLx88kd6H/nQx6CfCDuUG9olfuhr4JYtW5btHRFOkxd+
TEsUWPfll18K8KaDxxWdtlHkYKwcz8I/nHTv64zBZrwUUMC4GisVPjTY7FeclYuWLVsKL0ZpsNGH
MoaXLfIEz2xzV3533nlnkLUtPSKBV6SHtQqkBw7ww/nQd+HLQ9dC/5xzzhHrFgZnvFjhZs2aJS94
PDfWPtjklIT5/KVK3yY/8rfJB0PVwI5HToTVfv36yT3bQA1Yd/EHxQT1BvKDlsFnypQpQiNVfAJG
cunBiw08wUExhxLes2fPGJRROFf9cskHBQ/0UX+N/Djd3tehHbM5PuEJnSjoGOXM0IAVG7STkSNH
ipIH6yvGof2zHVzJGy9pOPCBuo978GasGpg0bI5PTs8397arq327ytfVP/EhsdJ+wDN+YQdlDngk
4vvy2JeDaK78XfwHhCI8rvS2+uPT/9jSR7AUPPbBx9b+QcglnwvfgJkIj6v92OT3kS8i2+AxFDz0
y/g4Qj3Cr3v37sEHaCryufpPH/5t9R9C8Ch/0L+Cd1j4wRXvOFf+SO8rXzIFjw/HDzBj+9cgF7zj
0B/lF1dgFTxo6KiYUC5QWfAywJc3CnjEiBGCL+Jg1ATP8LKBH19Evo6HsOXrHnSQB0zDGOXFRQNp
MHqBSoeRIGj6iQqejT6+LNiGq6Rn27AyUoGKBvNCxtnSIw4aKxsTN9Fjzz33XAxfzHAu+j74gg7b
5xV8O3fuHGMbtzGMopqXKToPyIyvHTjzws/JSz4V+jb5feTDCJIxqwT+Ub+OPvpoeAMXxR/qI8of
JrnwMsM920gWrCZOnCjp04FPwEguPEbBgxIEXtlecRwVW/3ykc+U97hx40R+mPqDWbicOIyuof2i
HIyyHU7ftGnT2PDhw2X0AUpQePQNChTbYhYFEWar4IyCZ/oKjBDkxvm0b1f5goZP/2RGHhP5xEsM
2Lz00ksShI8QlKVxtvx9+Dd0kl190tvqj6v/QZ629Ml4Snxmwwf8294fPvLZ8E3kJfHep/245LfJ
l5hfsnsoeKg/6MPQd6Nfxj3b5JboqcgHAq7+05f/ZPUfo434wMH7H4o4lD2YEAX/5n3jyt9XvmQK
HuRDv4P+xMxMGNNsyUZCET8vXIFV8L799lspzMQRNWjvsH0Ydih0vMxy6mbOnCkKEgoRP9AJ26G1
0YNCh/hmtAZx4cczM4LnQ982heFKb16OUEqgaGA4Hg0h7KLo++KLzgG00WGFnbFFiUYEJdf8IH//
/v3DUa3+VOjb5PeRz9VBgPEo/szXN6/9jJNv/PjxMqWWLnziiOfwxih4vOA6BuWATbfFUbDVL5d8
IAQFDy9R44AFRjRz6lBHUW8SpykND5i6veeee0T5Dn/QGAUPH2dov2ZEFwo3lE7QxDQRHF5q6Dfw
w4cBHD7oMIKY+Js8ebJ8sCF9VPvOSfmCjq1/SvaCA394QeIlZxw+CM29K3+f/snQTXb1SW+rP4Zm
VP+DcJ/0hk6yqw0fV/t3yefCNxk/4Wem7kb1D4jrkt8mXzivKD8UvPCMBOJdddVVMiKeqnyg5eo/
fflPVv9hbxrtBuVk3IQJE+SZj4KXE/miFDx8BKA/w6wa3n/AEjLnJ1dgLVmUKlWKy5cIu9/Cjkfo
ZFFk+Flu/d26daOaNWuKvVIsvmZD6fTGG294keOpIokHW3zG8Ro845WrD/399tsvclOGKz2/1IhH
D2UhLXY1coMiHmkTu51FihQRHqLo5wRf2AYFnbAzNnH5hUutWrUKgrCgvEGDBsG9jye39G3y+8gH
mcJltm79uqTsJuPP2CTmr7m4NBdddJHY++XOQZ774IMdfAsXLKTWZ7em4sWLx9FLx02jRo2odu3a
xJ0U8RQ6XXDBBcRfxmSrXy75DF9h+865tWXMo1I0e/Zs4lFGQ1auvFaQeOmBYIJy4tFB2RXIo8hU
rVq1IC7Kh19mxIpg8Iw7Y/HzVzfxFIvUUWzUgJ+VPAnDvWknQUL2YDOGq32ns/6H8070hzdemDwR
x/ij6he/4ISUrX9KzCt875IfcW31x9CK6n980xs6UdcofFzt3yWfC98ofsxzn/bjg1+UfCYf15XX
nsZFQTsCzVTlA1Gf/jO3/Jv3DStzAf+Jp1PY8k+HfKDByh3dfPPNxIqemL1E/5mvXH7SNnPCC+bn
69evL1/XWEuBYVJozwxujHeqCilo2GvWrJFnGE2AH4upfR00cqwZwzQKaOLrGF/z5gvBRgfD69Du
MeKHLxWsHTLr4JbyglY4H/oYnYCcq1evjuGrEyMNZkrGlR7TUpgSwwgGHNbnAB/QMi6Kvg++2Exx
3333yTA5hvjNYlNDG1hBfvCNKRmMfPCuuRjWL/i4VOnb5PeRDyM+wAujK/hSRDlgKhP1Cs7FH9Zi
oIzwBcgdZwzrxVCHzGiNDz6or2b0GFin0xn5UHbmh5FWs8nCVb9c8mFNH9oAyh4O06IY0fNpP0ZO
4Pbkk08KjmjjKDc40AQtYGqeoc1hxBgjd/iixkgx1hRiygRlhjCUJ0bw4Nq1ayc0sIkKDvEgM2i6
nE/7dpWvq39CHigX9B2oA6aMWPkQ9rBWEvXJ1EfEw73B15a/D/82DHzSu+oP6Ef1PwjzSY94Uc6G
j6v9+8hnwzeKp/BzV/txyW+TL5xPlB/tBO2BjwCRPgmzEbjHZiO4VOUz/UtU/+ni31b/0S+g/eP9
glkRvNswUwX+Tf135e+SD+0MbQ7vfuRl2l94tgptD+8E5Av88psrsFO0ABJTNpiSBbj4oRMML5o2
FdiE44pC9XVmTh3p0HFiDRH8vtO0GFrGC87kf+mll4oftOB86GONkHkxgQ6mQ1FxfdJjiskoB7ii
kobxAQ0bfRu+2Lln5Apfw4vgsV4QnVg4HC9V84IVISL+0kHfJb9NPrCFBo4pP8M/lGX4UY4+/GHH
rVl3iXQoR3yEmA7CBx/ENR8Gr7zySgRaOX+MumfkSryiw4Rz1U+bfGYKBLQx7Wk+tHAfXtdo4xzr
ZRN541F0SYJ2YMKMQgYF3DwbMmRI4Ed7A46omwg307L4IEEdwTPTThAX0z8+ztW+XeXr6p/wgWLk
CV/RhvHRZp5deOGF8oFr7qGkw7nyd/HvwsCV3lV/QN/W//ikj+LRBx9X+3fJ58I3ijfz3NZ+EMcm
v498Jp9kV7MGFUpR+P3CMyzBB1Oq8tn6Tx/+bfUfMmHtHdbgot7jPYvBA/iNgmfLH+ld8gEL06bC
VzOABBpwWNqCfsPkm/U0f/zvBzaY+QLteCSFMDWL83L23z+9R/vxlx5hOuOII47IFUaAF+kxTRSe
rjLEfOnz6AVhWN8M7fukx/QgpsX4K0NOwrfJEEUf+aSKL79ICbxUqVIlGPo3/KfjGkXfV36XfKhb
wD23U4xIjzPXUAeSuSj+w3G588hW9uHwTPl96qdLvkzxlhu6WKqQWA7All/2xEpejvsQV/sGjz7l
mxtZfNPY8vfh35aPK71P/QH9qP7HN72NR1eYrf275ANtG76uvBFuaz97Q37wgHaBpQfJliSkQ75U
+k/w5+N+/vlnWZqB9hx+17r671TkQ/mwgkw8+BO3BMSH370Rp1AoeHsDKM1DEVAEFAFFQBFQBPIX
Alh799RTT8lHAk+TEp+iQTgcPZOOl23RqFGjiJdb0T//+U9Z+3vddddlMstc0S6wmyxyJa0mUgQU
AUVAEVAEFIFCgwBPxRJPd2O5GfGaW+JTKjIuG0YJMWKIjRbIk9e1ZzzP3GSgI3i5QU3TKAKKgCKg
CORbBF6dk3WKQb5lUBkr0AhcfnzBGBtL74K1Al1kyrwioAgoAoqAIqAIKAKFAwFV8ApHOaoUioAV
ASwkVqcIKAL5E4EtG7R95s+SKdhcFXgFD/Pu+dmliz8cdsvbxuWXeKBjMvnZOgGxrVRZ/JksPF3P
ouTDrqxOnTrRTTfdlK6sCiWdKPx8hGXD2lIfUM58llVkkjFjxlCFChVkJ29kpDwMwILlO+64Q+rL
lVdeSTioWN3eQSCq/qW7/ea0/0q39Du2xh8yny76UfjlhP4X771M1zQ7hHbvLFzTyiuXzKOnbr6U
f51ozEN9cwJJjuJuWPsrvfH0YHp6QGcacdtVtG71zzlKX5gjF3gFj8++EQsT+bWQ0sVfpUqViM/8
Iz6DJ9KyRRgDHBnDB0WKFYvw83T7o+QrW7asHIvy7rvvpjvLQkUvCj8fIfnsJWrdurVYbnnnnXci
k6AusB1XOaE+MlIeBsC6CZtsojp16ogiiuNt8tpByaxVqxbVqFFDrHrwGXrB/cCBAwlKqQlHnPAP
1jBc4XwWZFx60IKi7mspJ134RNW/dLffnPZf6ZCPzz6kd194hPq0rk5XNy5H1zStKP7ZU/+TDvJC
Y8yDN9GEF4emRK/CIVWpUYs2tP8BWdaFUiKWjxIfVKEy1WvcispVrErfTsrce+C1J26lmZMnUJWa
x1CpshVo++aN+QiFvGWlwCt4OMOIT5iORBHhfJI2sZ1GUXjCEdEJz507VzpjPF+2bBmhI098wWC3
DOLizBt0zKtWrQrIQImaNm0avf3228SHdgbPjcfFnys96GCHEM5R69GjhyHrvOLMOT7UWeLhKxOy
hUf+2BKAyA75jbm35cuXy7OcjKBEyYcz4/hAW8kf9Nmag5wXlci4j/yJacy9T/m56BtsMIUJP8rX
4I0RMuQBh3BglYiNiz7KDfUD9W/BggUEmmEXhV84TpQf57nhOAA+6DYqimzjhyLI1iCymZNje5hS
L3BOFMoHozaJziVfYvzEe6THaDLoox0lOoRjhBHHHLA9Wbkee+yxidEi723t20e+KMJQivlAazrw
wAPl2IVmzZrJOVeoy3379hWzROh3XnvttaBdwg9TdChnPthZ+qWo8KOOOopef/11QpsbNGiQjLRD
SezYsSO9+eabUWwFz7FTEHUJfQ7b4CSYnGKLPlJ/g0jscZVfVP3LSfu1lS94Me0pJ/1XWIbc+sc/
czd9OPZJ6nX/P+mf0/6gzjc9SGtXr6LwdOhOrn8/fv8NzfnyY/p9dZb5NpPfL8sX028rl9HWzRsk
fPPv2d8z27ZupE1/ZH9uaGxjZePHudNp7n8nEvJKdGt+XkplyleiLgMez9Y+ffIHzR9mf0Xffv4O
rVkR//7ByNaKxXMJVzjIMvvLj2j7ls0BGxg1RHrwt2rpQsKoW7pc6fIHU8uOPenEFm0jSdr4RyIX
fkg/6Z2x1OWWJ6j9tXdRl0HD6LBaf/UfmZQvUqj8FMAvtQLp+EUsVhJwAj1OkcZp//jB8K9xxqAz
4uCka1yNFQjE4S9mecZ2N8U6AZeLnFx99dVXCwlW5OIsMcB0DOLAugHcrFmzAjMl5jRwmDaD8+HP
lh40cFK3oYt8jVUE7twR7HQwJo30sGBhZIMhdZhXgbkw84xHHISWyQvWJ1zORz6Yh0MeKB9gDz9O
ZzfOJb+JF3V1lZ+L/tSpU6VeGBxgAQB+WEeBeTnwzCNfkn2/fv3kHnXAOBd91DXQAD1jjQJ+OB/8
TD6uKytPIkdiPP4gkfoJHvALO5wkj3JJLB+Y/DHOJZ+JF3WFCUG0O+Rh6mDv3r0DSx7JLDmAJ19n
a98+8rny4fO0xHKMiQecDX8wb2b8rKhJO0O8Z599Vkz3ucINTZTLF198YW6FDsx3uRysV5h6i6vB
GX5WmCW5rfx86p+r/brKN9X+y4WBLXzUlCwTlR163x57ZfbO4NeszeWxW4a/I/f3jp0Sq3xYVv2s
WDmrjzy7U6/Yy9/9GRs56ddY+YpZ7QPXUmWz+q8bHnxJ0g59e26sdv3G8hzhRx7bUH7h/B5/b76U
EdIiH1zvfP6TgJexs3bEqlQ7Up4jLMynK3/EfehfMyQ9yrxarTqS17mXXx/Qady6vdBu2PSc2Onn
dQrqS8uLu0kc8IJ8jzu5ufAOOvCH+UiH/7bnPhD5E2m5+Hfh165HdksTKAuTTybls9W9/BRWYE2V
wRYlj4rE8FLmr16x94kOGOZHjOOv1xjMzUChQYcPs0RGeTNxjP29zp07i605HqGJ8Ve1BEOBwIt5
xowZMf4ql7zQCIyDQgSli8/EkUemQ4QS48OfLb2xcQf5vv/+e7GFmhsFD/xCRtjRA1+4hz1buOHD
h8uLHzY+4YxpHB7BlHvbn498Bo9x48bJSx2m3mDuyzib/CaO62orPxt9yIgXNJR7vIig7MEEHfAx
5QmzYmGzWjDvA9M+xtnoIw6UafMxgPvnnnsu1qVLF3i96odE9PiLUvBMUrSBRAUPYVBiIa+xbQwl
tkWLFiaZKBtR9TuIFOFB/YVSB3zR9mAqzJhHguIEhzg8Qio8oK7Az6OJERSzP3a1b5d82SnGPwGf
wA39AH4wi2SUOvQTvG5QEoQVPPQVPBoZc4WbnIyCByzwQYDyeOGFF0yw9Yq0wJSntyUdyhllaPo4
W/1Mtf26yhfhsNGZSv9lFd4ROPiFTwWTB177Knjhmxc/rmNmbItBqYPyA2UKSt2Af7wlaXrcOVzS
3PF/H8n9dUNelPu2XW+K1TvlDPGPnr45dvvID2P1m7SKnXZOxxiUGPyGvbcgyO+lb7bE7h37heSF
PJq37RwzylWYF8RJVPAQbssf4VDqTjj1zNjo6Zskz0HPZtWDmx5/LeChy4BHRQYotiMnr44N/3hZ
7Kn//CjhZ7a/OnbSGecHca8Z/EzsjAuvDO7DPKbij1LwXPy78EMZjvjsZ5EPssP//JfrAv4zKZ+j
+uWb4IJxmAv3eomuePHixJ0H8ctJ1nphLVKiwxQGKzPBOjRMRfFLPDEasV1LGjt2rAyRYzG6cVOm
TJH1fSeeeKI84tFBmjhxovgxTctfweK/4IILTBK5fvXVV7L43cafKz3WI2H6ZfTo0WSmrDCF9emn
n8bl5brhESfiTl+iYZPGVVddJeudsE7ommuuEfmGDRsm02Ogf/PNN1Pp0qVdZMkHfxDhl7xMO8GP
KVustYJzyQ9efV2y8nPR5xe1TKMNHTqUgBEc2xQkVsi8snXRB//At0mTJnTMMccQ1iDBVBzWPMH5
4IcNB2w3NRs/bIuUMGWYDgccWOkUUigftAM4H/kkYsQfprNBg+3nBqbB2l7QVtaRskIqU8s4JLRy
5cpCAdPNxh9BMttjn/YdJV82YhEPDj744KBOID9M+8IdfvjhdN9992VLhb7C9BeucJMYdQ59E9vS
JaxH7NatmwlyXqtU/cv836mnnkroewz2qfRPJuOo9mvyiCrf008/PS39l+Ejp9fdu3dKklhsT9Kk
K36YK9O11w4ZQ5hKhGt4RhviESyaO22iTC3iGY8IUdO2V8BL9ZueS1Pff0X8Rfn9cxyvL/vivbF0
UMVDqV6Ts+R5+G/lj/PpnVFDaP7MqfJ4y8YNdPQJ2d8/4TSJ/qj8169ZRSuWLJDoj/dpF5dsyeyv
6ZSzOgTP6jRsQr2HjM42BXxm+7/R4Cub0oCLjqUy5SrSwYceQWd3vj5Il0mPD/8u/IoUPYDKHpzV
f5Qud3DgN3znpXyGh7y+FlgFzwC33377xa0tM89xRUdZs2ZNeUni5cGGypMuYsbLBXQSXYMGDeLW
TKGDNw4vJzh0zq1atTKPpYNGOuOi+HOlh/1aOKz7M27LlpzvBMPanLADjQMOyCp28AClFUodT/GI
wsNTzOHoTn+UfCZh2CZg2JarS36T3uearPxc9LFOCg4nkhsXXqOIZ5AtjPm69X+ttXHRR3oeYSEe
fZUPDKxv4xEl4pFisXtqbD7a8INiaOKBnnGwGZkuZ+oC6BmZwn5X/Y7io1SpUhJk1neaeFBkoDSk
w/m07yj5fPM/9NBDiUfEJDrWUeKDMt2OR+zkYxUbG1JxqEtGXlOWrvKz1T/wEtV+XeUL6wJwPv0X
dtguXLCQWp/dWj58JGGKf9WOOk4ozPj0bTryuKy1yGGSxQ/Mqp/btvwRfkxbN/3BmwKqBM+KFPnr
Fbl/kaw+PwhkD/CL2qE7cnB3qnRYTXrs7e9F+cBmjK8njg8nd/qj8i96QDFJ26DZ+XTcqS0DOm26
9afqtf96/yAAyhv4THQlS5elR9/8jhaxAop1hPO++pSeGdSFhr67kIqENnzI2rwf51GlqjWpRt14
2ok0fe99+E8Vv7yUzxeHTMfbP9MZZJo+XnY8vSbKycyZM+mBBx6QRdvIF50LvrThxo8fT7BTx2On
xNMT8gybKaAAYSEyjF0nvozMCJcZ+br22mslHf4wIoNNDJMmTZKRhzPPPJPQ6WHXKF7kxkXx50qP
UTsoXQMGDJBRO4x68JolIWv4N3lEXXmaRL6ieU2PLHTHyA926YVHx7p27UoYpcACaOwOxKLynLgo
+UADuKIMcJX77Ttkswj4d8kvCRx/tvJz0W/UqJEoGjASjUXtr7z8ihzVEc7ylFNOocmTJwt2GLHA
SCfkwcYJF33QGTx4sCzIb9++Pd122230t+5/k0X14U1BNvyQHiO4iT8z4gheUG+BA3iCHz/UcTiU
P+6xkB7OhCMdHMoFL2KkNfe4pqN8sIkAI1IYQeepQ9mkgg8sng4PRnSRL0/fSt5QgOEPK9wSYPmD
HLb2bZPPQjYIQnpgaHgyHwAGL0QE9ngOHLERJxzmCjf9DZQoU2ZB5g6PycfwhOimnYFntOlU+idD
DxgbujtC7ddVvr79F7DFrMoFF15Ajz76qENq/2CM7PAUHX3+5gs0a8oH9Of2bbyZYBo93Otcmvj6
s1S5Wi2qWecEemvkEHmOjRdQwJYumE2nnJ01+rXzT/Rfu4LjS3btzOrHdu7Ien+AmwPLlKdFs6bS
hvW/0bL5s+jtUQ/yqN7Lwuie3XuowiFZ75/pn7xJ7780jHitAm+2yEq/i8tp8x/rZSMBEsCP3+5d
We3Tln+ZChXpqHqNaMG3U6gs71ate1ILKl6iFM2cNIHmfpX1/sFmih3bt9KunVn5bN0Yr8y++ey9
NHZofzq5VXu6sMcgat7ualq9cjlt3rhe+Dd/Yx7pS8P6duLNIl+bR15XyCHybd3EMu0M5ENd9+Hf
hR82UGxav1Z42cwKKvwoZ+MyLZ/JJ19fGewC7XgaU9YKMcgyF8/TdcFGCrOmDGFYO4M1YPBjrRV3
ruI36cyVd9HG4YEFy1h/gzV6rCBJGhMB6/2wIcGkxbVdu3aygN7EsfHnSo81NazkBfR5V5/4IYvL
mfVOWDOGtTiGR54CinGnHZecpyYFH+5s45773ETJxyOQQZ6s4MR4V2Fwb9a1ueS35e9Tfi76WHuH
dVXABjjz9Kn4DQ780pY1dAY7rB+EH+UA56KPNZ9YJ4U0uGJNGupQ2EXhF44T5UdZGt7CVz5KR5Kw
Ip80HDxgXZxJgwX7rPwF91g3BeeSTyJZ/pYsWSIbTEw+wCAsf7JNFqyUWCjGB9nat4988dTi77AO
1/DNimqwfhXPsFEEDusFTRxz5Y+kgJAtHBsgTBpzZcPlQVqXB2slTbo5c+aIH2uRedeu+LG+1qf8
ouqfT/t1la9P/4W1mWYDEk/3usT2DseasX9+tSHWskP3ACfghTVmWA+H8CcmLJRNBQZHrIPrestQ
CUMc8/zkMy+ImU0beIZ1d2ZN2hPvLwo2OCCMp0ODjRRYC4dF/3iO67mXXSd+nqaV9Kedk7x9ggef
/LHeDxs9DJ+4ntLqohg2gPzfl2vjnps4t454P+AdawIhM8JwxZpEI7+RD+vcTBjWxJnnPtcLu/dP
ykPfYeOEjo1/0Hfhl2yTBSu9AY+ZlM+7IuZxxEJjixajEyVLlpQfV9jA4QsU051Y/5Sq45cT8cL7
bIaF8eWOL3kcTWKmRhLziuIP8WzpuX4I/5iGDE+XJNJ33WOEBKNFiVN+wIcVQMJIFkb6cuts8rlo
2uR3pfUJ96WPYzyqVasmIzZhrDGtiLoVnmIO5xtFH3UCaTCigji2OpgKfmFeMuGPks83L4wgAkMc
PbL//umdNEhn+/aVp6DF8ym/VOqfrXx9+y+M5KGNpcuFbdFixGzNyqVUkdeYmanZcD44imPrlo1U
vlLVXNdPjFQVK8F9BP/CDqNYv/+2iipWqRZ+nFY/Rh+3bd3M6wWrENal+TqM8BU5oGjW6NrG35Py
uPi7/9JdXZrzMS6P0nldbvIlnaN4Nv5TwS+T8hUUW7T+tSFHRbb3I4c3R4Rzh0Jje7GG4ybzY/oO
v9WrV8tZXsnWqEFxws/movhDGlt6rJ0w01A2+q4wKIhhh/PdRo0aJeekYQ1MlGIaTmPz2+SzpUOY
TX5XWp9wF31Mc+EcNrzk4DAlivPljMNaOpuLol+mTBlJhg0Vxh9FJxX8omim63mUfL70sbYs1fVl
UXml2r6j6Bam5z7ll0r9s5Wvb/+VTuUuseyKFi9Bhx1ZN/FxcI+1Wvil4kqX+2tzXpgO1rJlUrlD
XqUOKi+/cL4+/hKlsjbTYcOI8SemW7V0gWw0aXlJz8SgtN3b+E8FPyNTXsuXNqByQajQKHi5kN0r
CU/dyXorjOxcd911cpCpV8J8HglfzBixgmLXs2fPbKOS+Zz9tLKH9VM4jBWjDcACh8iqUwQUAUVg
X0fgDF6X1/icS6l4yZytzS4ouBV2+TI2RRseIi8oha18KgKKgCKgCCgCioAikAoC+WUKN70LYlJB
RNMqAoqAIqAIKAKKgCKgCKQFAVXw0gJj6kTC9hFTp1bwKBR0+Qs6/6nWmH1d/lTx0/SKgCKgCKQb
gQKt4MEw8lM3X8q/TjTmob7pxiagB2PNbzw9mJ4e0JlG3HYVrVv9cxBm8/jyh3OTrml2SHDeko1m
YhjWjeWlS0f+qcifSdm1/PzQza/l58d9emL9+tMP/+uLLo08+DZZTuloP8nopvtZbuVLNx+ZolcY
5fPtvzKFaZhuYcQ3LF9+9RdoBe8gPuCxHpuLKVexKn076d2MYfzaE7fSzMkTqErNY6hU2Qq0nbfV
+zhf/iocUpUatWhD+4dOD/ehjzhjHrxJDuj0jZ/ueOnIPxX50y1PmJ6WXxiNaH9+Lb9ojtMfUpat
BdRp1IymfTyetvPBrr4uHe3HN69U4uVWvlTy3JtpC6N8vv3X3sC5MOK7N3BLNY8CvYsWNgRbduxJ
c/87kRWwLBuniYDs5NPoly+cRRvXr6bDa9WjQ6odGRcFZyD9smwhm6jZQLVPbEbYUh12SD/pnbHE
xqupdqOmSU2+hOOH/T78rfl5KZUpX4nPGXo8KW2c1r10/gzavmUTVTi0Gp+EvpsOq3VskM22rRvF
zEzwIIceGz6/LF/Mpo+KyhZ82DesWffEwG6jycaWP0Y+N/6+lsqWryj2Gn9buYx+Wb6Ijql/WrAt
3yW/jT/w4MLH8Jmbq5ZfwS4/lLmtfdvqN85Ow6gD3MGVD6cDy5ajtat+om18Xhr8eGbc2l9WsImt
knTGxd3pxYSZBFv+SG9rPxLu6J8MD8muNvlMfLSvFT/MIUyxH879SvnKh5mg4GqTLy/bJxi04esj
P2jY5EO4zeU2f5/6tWbFj2KJ4qAKldjywyFSH3exdY1yBx9Ku9jW7lY+u65osRKEo0zqntyCflr0
HVvWKBccCePTf9lk88Evv9cfW/n4vJ9c9duGX34IK9AKngvAnxbOpif7daRfuKFUq1VHjDOfe/n1
1PXWJyQpOvB+bevyqNxBVJobxma2Q9hv2HhuLM0lfNxTt9Nb//eI+O/t3lKuMP48/NMsO7HyIIU/
PsVdTOds3JBl43TUF1lmVwzJ+dMn0+N921ON2vX5xbKJfpw3U4xh3/78J9yoF9KowT3o56Xz+TDd
4mwgO8s8TcPm51OH6+42JKxXGz6bf19H91/dgn5fu0bOQfqTOxYYy77hwZfotDaXe+U/+sG/0xw2
m3PMCY254zmIpn4wTvhpeXE36nHPKHLJb+MPhGz4WAVPU6CLfxt/Wn6ZLz9b+3bV72/Yhuk/Bl4p
NaV9z1vpkhvupUevbyN9CFsPoLvGTKEVi+bQ0wM7B0bfTzj1zLiaZcvfp/xt6eMySnLjkg9JYLpr
OMsI81RsxYDWrl5FZ3fqRVfd/g/52HTJl9ft04aPj/wu+ZLAGvcolfxd9evmp96i2y8/Rfpctk5B
nW9+lG6+IOvDnq1zsFmu32j6Z3/NWlU+rLqUIxi8/sHRdHqbznG85vTGB7/8Xn9s5QM8XO8nV/3O
KaZ5Eb9AT9G6ABs+6Ao2kFydRk/fRA+/OYcGPfseffjqcDb4/G9JipPN7x37BY347Fe675WvqFHz
NjT1vTEB2Q7X3sNhWevtkBb+oe/MD8JT9eBU/8cmLKSBz0xISuqLCWOpbsPTCQrd/a99TdcMfoYP
zcyyyFGpag265Pq76Sg2pF230Rl02d+HyK9p2y5JaSV7aMMHX3/XPzRWkl3e7xGC8tm2601s2/F5
eeaTf5/HXqf2ve6gmV/8h0+IL0IjJ6+m4R8vo3a9BwsNl/w2/kDAho9kkOE/F/82/nzwc7Fvw0fL
j8RyQVT7duHT5LxLqfvtT8nH33ldstb3duD2hg+8Qc99KCPHT/S9hG2NHiYG2x/+98xsxWXrX3zK
35Y+W2YJD1zyYeQb65er1qxDbBaLnvxoGQ34x1v00bjn6LM3RnnJZ6t/YMdW/xPYzdWtDR8f+V3l
52Iqlfxd9Qv8P/3Rcqp3yhk8+7RGZqBQ9/7+6CvU467nqO+T46VuosxuefptUe5Q19FHz//6Mxfr
znAf/PJ7/bGVDwBwvZ9c9dsJYj6IUGhH8NavWRV8WT/ep10c1JhuPOWsDrTyx/n0zqghNH/mVAnH
CBXbCQziwuwLgwMSiQAAER5JREFUjFbDlS53cOA3EbDhYhVP7ya6K24eKtO5ic9zen9m+7/R4Cub
0oCLjqUyvMbnYFZIz+58vZDBVPJxvP7wi/fGyvRnvSZn5Yi8Dz4giE6ladsrhHb9pufS1PdfEX9O
8mf7jNR7yOikU9BCLMmfD382fJKQ3OuPbPzlBL9kjPvgg3T7cvm52rcNH4Sd2f4aXt/6GH348pPU
/tq76M1n76fzu/YVc1crFs+VmYGe978QLJm4+Lq7aPZXf71cbfn7lL8tPfjzcVHlv+KHuTJid+2Q
McGyi4ZntJEZgrnTJtLRDU6zyudT/2z134d3VxwffKLkX7VsgVU+V94ITyV/pLfVL4TDrNqA4e/R
I9e14fdAM7qaZ55OPacjggJXrlIVWUaDB7WOP4V+nPs1zZzyfRCeqicKv4JQf3zKB/gkez/51O9U
sd0b6Qutglf0gGKCX4Nm59Nxp2ZNr+JBm279qXrtBhI2cnB3qnRYTXrs7e9FeZvw4lAe3RsvYT5/
lasfTfuzKbREhzU66XAwn/Pom9/RIlZAN/2xjuZ99Sk9M6gLDX13IdsQzMoXpoB2bN2S4+x88AHR
IkX+qiL7FymaLR+f/KGcIl5OnA9/PvggT0yHrfxxHo/m1qQadbPKPie85DauD38++CXL3wcfpNuX
y8+nfdvwwQfeRT1vo5cfu4UO5pHzjb+vobMuvU6KYw/bcIbbw7ZGjduxLb4d+uRvK3+f9CbvqGuU
fMYm67Ytf8Ql3crLVMqxTVOXfD71z6f+I/Pctk8ffKLkd8kXB0rETSr5g6Stfpks169eSat5KVH1
o+vxiOjLdPoFV9KBpZObTkRdwkxJOl0Ufvmp/kTJ61M+SJvs/eRTv6PyzU/PC/QULQwRw8jzNt61
tnvXTvHjHkcPlKlQkY6q14gWfDuFyvJu27ontaDiJUrRzEkTaC6vC4Pbs3sPT7FkLZae/smb9P5L
w3gTwx7CAlg4TGNsWp+1Lm4zK1jw/7l9m4Th72Kefux53wvZftW4McLZ+EP4LjZCL/z/b1cu/Pgh
Hdybz95LY4f2p5NbtacLewyi5mw2ButlNm/MspmKOAeWKU+LZk2lDbwmY9n8WfT2qAd5VO9lBFmd
Dz47ed3d7t27BAcQ27Vzh9A0+ODGlj+MPe/YvpXTZcm5dWP8y8Qmvw9/PviAxzGP9KVhfTvJ1y3u
fZ2WX8EuP1f79qnfzdp2pbIHHUwj7+pFba8eEJhsgm1TrHt67clBNI+nxOZ8+TGNe+oOqVp//q//
cOWPyLb245PeVpdt8lWuVotq1jmB3ho5RNbiYZMFPnCXLphNp5zdQRbq2+TLD+3ThY9Nfp/ys2GL
sFTyN7Sj6hfCscnh3m7NqTWvG7/v1a/owFJl6aGe5xDWx+HdBIc+1jhsCIDbzf0t1ge7+i+TLupq
wy8/1Z8o/l3lY3s/+dTvqHzz0/MCbaoMx5e888LQbHj2HTaOlaKL+ctnCY24vRst/G5aEAcLVjv1
eYDXntSWtXijh/QJNhKcetYl9OFrz8g07T1jv+QO+69NFoYAlMZ7X/mLnnme7Ori7+kBl9OX/3kj
W9Kutwylc6/8u5y5N4OPZ8HUMTaClCxZis6/qp+EmUTYhfrYjRcG09EYbu54w/3BRhETL9nVhg+2
tfc841BJdvKZF1DPe5+Xs/rwoH6TVjSQ1yHBReVfvW596nFaRYkT/rt1xPt0/Gmt5ZFLfht/KD9M
kbvwQUfY+8xDBbvHJ/Cu4GJZI7thnqL8Wn4Fu/yw1jaqfQ/4x7te9Rt1Y/yI++iTcSPoiQ+W8C77
EkF1+WH2V7xJ4Ypgcfvp53WSjUSY1sJGLFv+6F/gotoPNnr5pA+YSfBACXC1X+zSHHX3NfQ9b+aC
Qx/TofedQf/iki+v26cNH5/ydcmXAGm221TzNwST1a8f506nOzqfJlEat25P1z04hq5tWVXeBXgH
lTiwNM39epKEY/3nwA4N6TSevj2pVTt66pYrZP3o2l9+sr4fTf7JrgWl/iTj3Tyzlc/AER8430+u
+m3ySXbNL6bKCrSClwzYZM/wdbpt62Zej1RFhsXDcfCV8/tvq3jzQrXw43zhxxdGET6mREYneUu8
jUeM/BUrUVJ+OWXeho8vrVTyd+URxZ8PPou/+y/d1aU5H0PzKJ3X5SZXVmkN9+HPZJgKflH4GNo+
11Tyd9GP4s8Hn1TLL9X2jfSDOhxPrS+9lte/3phNVMwW/MHrfbFGN6z8mYi++Ufh75ve5JebK46S
2MrHv5SvVJWn+OIndVzyIb+CXL4+8tkwTbV8XPXLlnd+CcvL+uPCINXyAf2o+m3LO78oeH8tsLJx
W8DDSh1UXs5ySyYG1rLZFKdkafbWsxKlSktWWJBt/FF5ly5XISrI+dyGjzPx/yKkkr8rjyj+DCY2
fHBGFEZUWl7S05VN2sN9+DOZpoJfFD6Gts81lfxd9KP488En1fLLbfvGGVmfjX+e1q5cRiuXLua1
tsm7Sqx7SnZ2nMHEN/8o/H3Tm/xyc8VaOfySOZd8SFMQy9fI6iOfiZvsmtvy8a1fyfLMb8/ysv64
sMht+YTpRtXvcJz86t8nRvDyK/jK195BYMe2rcHaqb2To+aSTgTyovwwdfrePx8NxCjHu+nb8y5Z
delHIC/KN/1S5Iyi1q+c4VXQYueXETxV8ApazdlH+M0vDWQfgVvFVAQUAUVAEShkCMQvuChkwqk4
ioAioAgoAoqAIqAI7IsIqIK3L5a6yqwIKAKKgCKgCCgChRqBQqPgwe4cTKfgl5ODf7GLSp0ioAgo
AoqAIqAIKAKFCYFCo+Dh3LY6jZrRtI/H03Y++NjXjXnwJjng0ze+xlMEFAFFQBFQBBQBRSC/I5B8
739+5zqBv7W/rKDixUvSGRd3pxcfyjIMbqLgjJ5f2F7s1k0bqPaJzfisquImSK7btm4UM2BxD0M3
rvShqNm82Aq/8fe1VLZ8RbEX+9vKZXw6+SI6pv5pwbEnOH18+cJZYkz68Fr16JBqR8bRwUG9S+fP
4BPLN1GFQ6uxpY3dge1LRET6FT/MkbN6Dq91bHBkA9L9+tMiKn1QBckbZ/msX7OSYEbt4MpZ1jv8
+NtOyxbMFPxq1m3I52VtokpVagTnCabKf5yweqMIKAKKgCKgCCgCaUGgQCt4KxbNoacHdg6sOJxw
6plxoGDatl/bunJCe+ky5Wgz21nsN2y8WHmA/cNRg3vQz0vnU7FixWnutCzzZQ2bn08drrtb6NjS
x2UUcTP6wb/THDaLdswJjdkk0UFyyj2itry4G/W4ZxT9tHA2Pdmvoxi9rlarjshxLpul6cpGpeHm
8wnzj/dtTzVq16dtrFj9OG+mGAO//fksXn+YPY1P0r9STtKvWLmqGA8/u1Mvuur2f9DCmVNoGNOu
c2JTuvmpt9iE2RD67K1/UsXK1ehBPvkczsXfsvkzhT+YR8Mp97CoAXfX6M+pdsPTU+ZfiOmfIqAI
KAKKgCKgCKQdgQKr4GGE6om+l9Ahh9ekPkNfF9t7Lz/SLw6gioceQfeO/YJq1m1E2zZvoLGP9qOp
740RBa9S1Rp0yfV3y1lXpcpWoBbtu0vaSofVDGjY0geRLJ4+j71OH4x5gsY8OoCatbmcRk5ezSNu
22g32wmEGz7oCqpUtTo9NP47OQV/9tT/0EPXtqU6JzejU87qwMalx1JdVqT6/eNtif/ZG6PY7myW
iSPIj/WG1Y4+nu575SsqxQcdz5r8Pj16Yzs6ovYJ1LJjT2rH9mvnT88yZ9O5/6Msdwt65fEBQgt/
Nv6wNvEf/S+j8odUpQHPTKAqNY6hz94YSf933w1sQzfL5mEq/AdMqEcRUAQUAUVAEVAE0o5AgVXw
Vi1bICNfPe9/IZiyvJgPIp391WcBSCt/nE/v8MjV/JlT5RlGoI4+4WTxY6r2uMat6Iv3xsoUZr0m
ZwXpjMeW3sTxucI+bO8howmnphu3ns0brViyQG4f79POPJbrktlfi4J3Zvu/0eArm9KAi46lMrzG
8GBWWM/ufL3EWfHDXBmxu3bIGCpd/mB51vCMNjLCN3faRFHw4ohabpLxh9HLX9hWZZeBw8RuL5K3
7NiLyvKBrzWPa8TTvanxb2FHgxQBRUARUAQUAUUgRQQKrIK3Z/duEX0P24o0bse2LcYr15GDuxNG
5B57+3tRTCa8OJQNeI+PiwOlK2rXrU/6OGIRN1DOwsodohU9IMvofYNm59Nxp7YMUrbp1p+q124g
9zAB8+ib39EiVlA3/bGO5n31KT0zqAsNfXchFT+wlMTZtuWPIC08W3kauhzb3M1yLNv2rf/zE23e
sC7whz3J+MOaRjhMDYfdiS0uFHuVu//cKY9zyz9MyBgnyiRPmddrfFa2NZImjl4VAUVAEVAEFAFF
wB+B/f2j5q+Yhx1ZlyofVp1ee3IQzfv6M5rz5cc07qk7hMk/d2yX657de6jCIVkbCqZ/8ia9/9Iw
3qSwh6dJs8IR6cAy5XnacyptWP8bLZs/i9eqPcijei97p5eIEX8wpg4Fa9fOPwnGxLdu/EsZK1Oh
Ih1VrxEt+HYKla1Qmeqe1IKKlyhFMydNoLm8bg/uzWfvpbFD+9PJrdrThTzd2rzd1bLebvPG9VS5
Wi2qWecEemvkEMJaPGyigAK7dMFsOuXsDpL+yONOpu95Hd+P339DKxbPpQ/HPklQiDG9C2fjD/Y1
a9dvTO/830M0978TCeaEJvEavhvPqib0UuVfGOC/P7dvozs7N5ap5QkvPWYe61URUAQUAUVAEVAE
UkCgQJsq+2H2V7zJ4ApReoDB6ed1ko0MMC4//NOVPFr3bxo9pA/9vnaNGJw/9axL6MPXnpFp2nvG
Zq1lg03Ax268MJguxXRlxxvul3V6PumjsN/Ka/56nFYxW/CtI96n409rLc9X/7SERtzejRZ+Ny2I
d0qri6hTnwdkWnTEbVfRjMkTZHMDNjmULFmKzr+qH5175d8l/hqeQh119zWixOEB4nTofWcQvpuV
uSd5k8Y3k96X+PVPb03fTf1YcLr6zmec/K1b/TONuqN7MO2NjSDNL7qKebhZRiRT5R9MYa3fnZef
KhtIbnxoDDU5/zLhVU2VCQz6pwgoAoqAIqAI5AqBAq3gQWIoCH/werDS5Q6WjQqJKEDJ+f23VVSx
SrXEoLh7jLAVK1FSfuEA3/ThNDn1Y/Rt29bNrIRWCY4fAQ2MsBU5oCjt3rWTNm/8PVIGHOWydctG
Kl+pqkyfJuYPZbNYsZJ0QLGsaeHEcNc90u/hUT+z1i8xfqr8gx5G8oC/cargGST0qggoAoqAIqAI
5ByBAq/g5VxkTVEQEFAFryCUkvKoCCgCioAikF8RKLBr8PIroMqXIqAIKAKKgCKgCCgCeY1Axkbw
8lowzV8RUAQUAUVAEVAEFIF9FQEdwdtXS17lVgQUAUVAEVAEFIFCi4AqeIW2aFUwRUARUAQUAUVA
EdhXEVAFb18teZVbEVAEFAFFQBFQBAotAqrgFdqiVcEUAUVAEVAEFAFFYF9FQBW8fbXkVW5FQBFQ
BBQBRUARKLQIqIJXaItWBVMEFAFFQBFQBBSBfRUBVfD21ZJXuRUBRUARUAQUAUWg0CKgCl6hLVoV
TBFQBBQBRUARUAT2VQRUwdtXS17lVgQUAUVAEVAEFIFCi4AqeIW2aFUwRUARUAQUAUVAEdhXEVAF
b18teZVbEVAEFAFFQBFQBAotAqrgFdqiVcEUAUVAEVAEFAFFYF9FQBW8fbXkVW5FQBFQBBQBRUAR
KLQIqIJXaItWBVMEFAFFQBFQBBSBfRUBVfD21ZJXuRUBRUARUAQUAUWg0CKgCl6hLVoVTBFQBBQB
RUARUAT2VQT+H5yJWLDP93AtAAAAAElFTkSuQmCCAA==

--_006_0E0AE22C4A7148B99DF4E716884FE130sedonasyscom_
Content-Type: image/png; name="image002.png"
Content-Description: image002.png
Content-Disposition: inline; filename="image002.png"; size=23573;
 creation-date="Thu, 04 Jun 2020 16:00:14 GMT";
 modification-date="Thu, 04 Jun 2020 16:00:14 GMT"
Content-ID: <image002.png@01D63AA2.6051B9D0>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAm0AAACLCAYAAAAzia4IAAABQGlDQ1BJQ0MgUHJvZmlsZQAAKJFj
YGASSCwoyGFhYGDIzSspCnJ3UoiIjFJgf8LAxsDCwMfAzaCXmFxc4BgQ4ANUwgCjUcG3awyMIPqy
Lsgsr5/Vd2O5+ar/p3A4sfNovcRUjwK4UlKLk4H0HyBOSi4oKmFgYEwAspXLSwpA7BYgW6QI6Cgg
ewaInQ5hrwGxkyDsA2A1IUHOQPYVIFsgOSMxBch+AmTrJCGJpyOxofaCAIezkbmbsaUBAaeSDkpS
K0pAtHN+QWVRZnpGiYIjMIRSFTzzkvV0FIwMjIBWgsIbovrzDXA4MopxIMRSdzAwmDQDBW8ixLLf
MTDsWcTAwPcOIaaqD+TfZmA4lFaQWJQIdwDjN5biNGMjCJt7OwMD67T//z+HMzCwazIw/L3+///v
7f///13GwMB8i4HhwDcA2DJeV/AOC+kAAABWZVhJZk1NACoAAAAIAAGHaQAEAAAAAQAAABoAAAAA
AAOShgAHAAAAEgAAAESgAgAEAAAAAQAAAm2gAwAEAAAAAQAAAIsAAAAAQVNDSUkAAABTY3JlZW5z
aG90A/QPYgAAAdZpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1sbnM6eD0i
YWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1s
bnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAg
ICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZXhpZj0i
aHR0cDovL25zLmFkb2JlLmNvbS9leGlmLzEuMC8iPgogICAgICAgICA8ZXhpZjpQaXhlbFhEaW1l
bnNpb24+NjIxPC9leGlmOlBpeGVsWERpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6VXNlckNvbW1l
bnQ+U2NyZWVuc2hvdDwvZXhpZjpVc2VyQ29tbWVudD4KICAgICAgICAgPGV4aWY6UGl4ZWxZRGlt
ZW5zaW9uPjEzOTwvZXhpZjpQaXhlbFlEaW1lbnNpb24+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9u
PgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgp2RF8GAABAAElEQVR4Ae1dCbxN1fdfQohkHpKM
JaVBIoUi0YASpZEiqZ9mpfQvDb8GiqJUNP1KoXlQaFKaSKWkFK8SEmUeMobuf33Xax/n3nfP3vu9
ey/veWt9Pveec/aw9trfPZx19l577yIxJlJSBBQBRUARUAQUAUVAEcjXCOyRr6VT4RQBRUARUAQU
AUVAEVAEBAFV2rQiKAKKgCKgCCgCioAiUAAQUKWtABSSiqgIKAKKgCKgCCgCioAqbVoHFAFFQBFQ
BBQBRUARKAAIqNJWAApJRVQEFAFFQBFQBBQBRUCVNq0DioAioAgoAoqAIqAIFAAEVGkrAIWkIioC
ioAioAgoAoqAIqBKm9YBRUARUAQUAUVAEVAECgACqrQVgEJSERUBRUARUAQUAUVAEVClTeuAIqAI
KAKKgCKgCCgCBQABVdoKQCGpiIqAIqAIKAKKgCKgCKjSpnVAEVAEFAFFQBFQBBSBAoCAKm0FoJBU
REVAEVAEFAFFQBFQBFRp0zqgCCgCioAioAgoAopAAUBAlbYCUEgqoiKgCCgCioAioAgoAqq0aR1Q
BBQBRUARUAQUAUWgACCgSlsBKCQVURFQBBQBRUARUAQUAVXatA4oAoqAIqAIKAKKgCJQABBQpa0A
FJKKqAgoAoqAIqAIKAKKgCptWgcUAUVAEVAEFAFFQBEoAAio0lYACklFVAQUAUVAEVAEFAFFQJU2
rQOKgCKgCCgCioAioAgUAARUaSsAhaQiKgKKgCKgCCgCioAioEqb1gFFQBFQBBQBRUARUAQKAAKq
tBWAQlIRFQFFQBFQBBQBRUARUKVN64AioAgoAoqAIqAIKAIFAAFV2gpAIamIioAioAgoAoqAIqAI
FMtXEAxpkVlx+k/NLH/lrggoAoqAIqAIKAKKQIYQ0JG2DAGrbBUBRUARUAQUAUVAEUgnAqq0pRNN
5aUIKAKKgCKgCCgCikCGEMhf06PhTG7/h/475Q+quc+e1LNJJaI9ioR9I++z/txIXy/ZGOdffe/i
1OaAfeLc9EERUAQUAUVAEVAEFIGChEC+VdpGfL6MbntvoWB53qHlqURJP1Efmr6cHp22OK4MqrDi
t/Tmo+LcMvGwZcsWatmyJS1fvjxgX6dOHTrzzDOpT58+NGzYMHr00UfF75RTTqEBAwYQrhs3bqS9
9tpL/C+99FLaunVrEN/cHHvssfTyyy+bR70qAoqAIqAIKAKKQCFDwE8T2smgrFu/lW6dvJDK7VWU
1mzcnqvUY7GYhH/x3AOpZrkScl+tzM7JZrFixahcuXI0Y8YMOuCAA2ifffahjz76SH5Lly4Vt4UL
sxXRunXrUunSpalkyZI0Z84catq0Kc2fP5/g37p1a/rxxx9p2bJlBGVtwYIF9NVXX+UKBw2sCCgC
ioAioAgoArsXAvnSpu26d3+nimVK0n+a18gz2pPnr6cxs1bR1u0xqlOpZJ755CZi0aJF6ZprrpEo
GDGDooXRNdDHH39M3bt3F8UNz/3796dKlSpRjx498EjXXH0Nbd+eraCOGzeOWrVqJe5PPvkknXzy
ybRp0yZ51j9FQBFQBBQBRUARKJwI7JwhqFxgO+v39fTkF3/QWxc2zGGb5sOmZPFsPfSJ6UskOKZK
r2m1Hw3rtL9P9LSF+eKLL2jo0KE0evRo4Xn44Yc7eTdq1IiaN29OFStWjAvbokULWrduXZybPigC
ioAioAgoAopA4UIg3420Xf/uYpkWXfLXVvpy8QYpjYteX0hYYOBDA1pWpQ8vOYRig5rT0v9rIlHG
fbeMiBc27EyC/RlG02bPnk3t27enW2+91Zn88ccfT59//jntueeecWF79eql9mxxiOiDIqAIKAKK
gCJQ+BDId0rbxq3ZytWN78ynST+ukBJ5J2sFbfsn21bNFNHUX9fRqM+X0vqN8Ub7VdiOTVaKFt2D
cF+7UilatvZvWrw2PtyHH35II0aMoBUrstMwfNN17du3ryhgWJzw7rvvylQoeJcpU0aSWLRokVx/
/fVXuZYtW1au+qcIKAKKgCKgCCgCikAyBPLd9OjUyxpSbOt2emn2ahr7/Wp6a/ZyGnpKHTqkcqlA
/pXr/qaWo2bL85zlm+nB02oFfgPZHm7hmr+pcfW9aAZv/bFgxSZqWa8C1aiQvSgBAZcsWUJt27aV
OFlZWfTwww8H8VO5wSKIF198UVjAnu2QQw6R6c4wT0yBzpw5kzB6hqlQE/6QRodIMIy0Pfvss7KY
AQ633XYb1a9fn+65554wG71XBBQBRUARUAQUgUKGQL5T2oD/3BWb6ZznfwqKoverv1DLWmWoQbW9
xK1i6WJ0aI2y9P3idXRUjWw3Ezhr5RZ6+dul9Ny/DvWqlKaHO+xnvOVauXJlgvKEqcsjjzwyzi+V
h82bN9Obb74pLKC0FS9enDDiFqbbb7+dMMo2efJk+cHvjjvuIGwNApo2bRqNGjVK7vGHadYqVaqI
8laixA7FMwigN4qAIqAIKAKKgCJQKBAowqND8fOOuzLbuTx7FCNyRYoXzSHxn2u20IoN26gKK3dV
yrJ9mNmYN+HsUazILFVqxwheDkYZdPjtt99kcUHt2rWDKdMMJqesFQFFQBFQBBQBRaCAI5AvR9p8
MU2msCFuNbZlw89Fu0phg1z777+/Szz1VwQUAUVAEVAEFAFFIEAg3y1ECCTTG0VAEVAEFAFFQBFQ
BBSBAIH8NT0aiKU3ioAioAgoAoqAIqAIKAJhBHSkLYyG3isCioAioAgoAoqAIpBPEVClLZ8WjIql
CCgCioAioAgoAopAGAFV2sJo6L0ioAgoAoqAIqAIKAL5FAFV2vJpwahYioAioAgoAoqAIqAIhBFQ
pS2Mht4rAoqAIqAIKAKKgCKQTxFQpS2fFoyKpQgoAoqAIqAIKAKKQBgBVdrCaOi9IqAIKAKKgCKg
CCgC+RQBVdryacGoWIqAIqAIKAKKgCKgCIQRUKUtjIbeKwKKgCKgCCgCioAikE8RUKUtnxaMiqUI
KAKKgCKgCCgCikAYAVXawmjovSKgCCgCioAioAgoAvkUAVXa8mnBqFiKgCKgCCgCioAioAiEEVCl
LYyG3isCioAioAgoAoqAIpBPEVClLZ8WjIqlCCgCioAioAgoAopAGIFi4Qe9VwQUAUVAEVAEFIGc
CDz//bacjuqiCHgicO6h6VG3dKTNE3ANpggoAoqAIqAIKAKKwK5EQJW2XYm+pq0IKAKKgCKgCCgC
+Q6BDWtX5zuZIJAqbaFiWbFiBXXr1o2uueaakGv+vV29OrtSbd26NU9Crl+/PjJeLBYjm39kRPXY
aQikWv47TdCdnBDqbioUFb+g9Q+pYJBK3J2F388//0xnnnmm/PJDX7V+9Up6uP95NOa+61KBb7eP
G1U/0o3fn7/9Qg9dd7b8tmzckCtcP5swli5pVYW2b81/U+KFSmn7888/qV69elS7du0cv5tvvpnK
li1L1atXp7feeitXBewb+JVXXolL9+CDD6aTTjqJvvrqK2Hx9ttvx/mH5fzggw8kzPbt2+mGG26Q
cBUqVKCqVavSfvvtJ36u/CHQP//8Q4MHD6YaNWrQ3nvvTeXKlZP7d955R3hs3ryZLr30Uipfvrz4
Q8bPPvtM/IYOHSrpHnPMMbRx40aR2+B58sknEzpR8xyWHff33Xef8CjMf6b827RpQ6bjeu211wSz
Vq1a0euvvy74Aq9bbrmFlixZQgceeKC4tW3bVqBLtfwLA/5XXnllSvUtKn6m+4c5c+bEtR+0pa5d
uxLqDchVP3za/84o/52FX+XKlem4446jV199dad8YK5d8Sdd16EBXXtK/Ry/l0cMpJKluT+tVI1m
fjwhIzAv/nVOXPqQ5aHrutGXk1+V9GZ8+EYg1ysP30qrli2h/qcfLG6DL2lPLvkzInQSps8NuoYm
PjM0h0+68StbrhId1KQVTX//Ndq88a8c6dkcKlTZl5q07kB7FCtqC7ZL/AqV0rZs2TJauXIlvfDC
C9S7d28BHPenn346zZ07l/bcc0865ZRTxH3NmjX03nvvkRnNCJfOli1baPr06TR+/Hj69ddfw17W
+44dO9JNN91EGBmDgjZixAhJE+54GePFfccdd9DChQtFRsiGHxTJ33//XXg/8sgjNHbsWHrzzTcJ
CtZFF11EyBfiu/IHBrfeeisNGzaMnn32Wfrrr7/k5QblwOTzsssuo8mTJ8sPWJ1xxhkiF/IJzE44
4QTJ+6BBg+iII44QWYBVv379qG7duvTMM8+I/Pfee2+QByim8+bNs2IT9gQ+wPf999+Xcvnxxx/D
3mTDHy+u2bNnE66gBQsW0Lvvvit5RX7hhx++zIEZXpR4DpdjXvnHCZnkoUOHDqIgf/TRR4EijDqA
tK+//npq164dNWjQgI466igZ7d13330FQ9QHKOqgVMs/iVg5nKLwhzvKwmCLOgPsFi1aJDz+/vtv
8V+6dKl8HMz7ZZ7gbhJw+ZtwwH/GjBnS/ky9N3628jVh1q1bJ+3cPOf2GhU/0/1D/fr16cUXX5T2
M2DAAClrKPBnnXWWKGyu+uHT/m1Y/PHHH1J+qI8TJ06UD7Np06ZJGwnHs7UPhEsHflHlb+T47bff
pB81/bhxz+R13arltG7tSrr83rF0fJdekhTum7Q+jf5YkEXF+P1xWMuTxH3jujX0/bT3KdkU21au
37989wV989GbtGyR//ujWs0D6PL7xtLSxQupU6/+dOH/PUSVqtei4f3OIShshzZvR9VqH0h1Dm5C
J59/NUHxuHxwdvhTe15PLvld2K1e/gctnvejyPztJ5Noy6aN9POszwnKZJhc+du0cR39tWZlOIrc
5wa/X3+YIfiuXro4Bx84rPhjEW3fto2OPyO7nJIGinBc9vt82rt8Zere/wEqUqRIjlAYfUP5zf58
Mi2ZnyWY5AiUSQf+4i809OWXX8aqVKki+eXOMdawYUO5HzlyZIwVC7lnZQpzKxJun332kfuXX345
wOjbb7+NsXIi7oiPsFdccUXg77qZMGFCrFatWkEwVkyEB3dC4sajbvKMBx79ir3xxhuxPn36xCZN
miT+F154YYxf/nKPv23btsUee+wxeXblb9WqVcJ74MCBQXzcnHfeeTHupGP88hX/hx56KPDnkTnB
AjKAWOmMtW7dOgZsWJkQN9yz8iP3rBgJj19+/iWWlZUVGz58eOzJJ5+MJaYpgZP8sUIjvPkLOta4
cWPhhXtDLvx5ZELiozzPPvtsiY8y6tmzZ+yBBx4IniEXeKE+wB9lykqcuNnK18bfyGi7tmzZMta0
adMYj2bG+CUpdYGVsxiPpEq0c845J0d9gnwG31TK3yaX8bPhDxlR1vyRIcFZUZfnRo0ayTPqEPzR
LpAnyG2wZ4VN6pjNH0xYSRBMEM/w4A+JGOohyIY/MGrevLnIgHJF/cHPt+75xM90/4A8AiMe3cat
EPC8+uqr5d5WP1zt/192kZfTTjstKDPgj37KlOFzzz0n8WztLx34ucp/1qxZUr+MXPwRKTKiLWWa
7ho3LVa+UpXYuO+2xq4eMi5Ws95Bct974MOxxi1PkvsBIyeIPAhXumz2++OaB14QP8Qb/PLXseo1
s98fiI98nHzu5YE/wrh+4Hv7sx8H4cDn1AuukucWp5ydgx/SGDp+dsxHflvaTdt0CuoDeFatsaN+
XD5otKRvyx9kaHB4c8EF+NQ9uLH8ul52c5AXF37/HfNpkG6lqtl9TPtul8bGzvpbeNz7yjdSLqZ+
HHZ0G5F55IeLgjRseRzz7RYpH2CMX2LYgU99IO6HND1OZEc6uE8Ml+w5XfUzPWtQWfKCQBixYuUj
h6jNmjWTr7awx8MPPyy2Ehjqf+KJJ+Qe/ueee65MV/3www9UsmRJwrQiRueOP/74IEyYT7L7TZs2
0ejRo2nx4sX0/PPPy8hKzZo144JiCg1fk9xJEytlgd8ll1xC/OKXUS6MzGF6gBUS8Xfl7/vvv5dw
GFkME0buQBiRArVv316u+MOXBvL23XffBW78IpRpu+uuu45YoQ3cwzfnnncuIZ8YOTLTO2H/qHuM
ACJ/rNxKkMcffzwYlYKDC3+kxcoZQTZWRmXEBVO5mBbef//9BXOMUvJLUPgPGTJERj8x0rrHHnuk
xF8YOv4wOorywojqAQccINNfrJjL6KEjqninUv4+/G34Y5T1//7v/4gVO2F1//33U5vWbajfdf3k
+dRTT5URQuQNI7E9evSQEVtWNAmjSIgLe9Eo//79+0sbOvTQQ2WkrWLFijRxwkTqdFonqe+YtreV
L0wF7rzzTsIoL6b3gRWobp26cnX91alTxzt+JvsHIydGNs1IF7Bxkav9u+Jj5gDmEmOeG0NF9ihC
mAH4/PPPpY1/+OGHdMEFF1jbR6dOnVLCD/mFjVpU+ffq1UtG/jGij3qANm3asStv6fAvX3lfOqFr
9gxNmF/dRs1kVCfs1mPAg9SsXVfCVOCUV5+iZid2Fe9HBpxPlfetRYNfm0XFS5Sk76a+S4P/05EO
atoqCBPmY7vHiM9P306jRfPmUscLr7MFFb/cyJ+M2bUPvkaXtKxEfe8eLe+F+644nf475jP68r1X
aM6XU6hFh/PIlr/GrTrSmZffThOeHkKly1ag1v+OVlauUSdHcsnwQ34fYhu1mgccSneO+4JKl6tA
GPEbcmVn2r/BYXR85140/Nozqcp+deiqoS9K/Rh7X3bflCOBCAe8A+6fmCUjaff27ZAj1GcTx1DD
xi2o34jx4jfllSekDHIEzKBDoVLaYPuFTj2RjjzySMLPEKalMCUBgkJmFAhMI/LXpLijgwrTF198
4a20YRoDL+opU6ZIJ4kOMZFgPzZu3DiZPg37tWjRgn766ScaM2aMTGXgxXTbbbcRlEhX/oxdHGv8
YZbBPaYLQVBGw4Rn42fc7777bnkRf/zxx8Yp7oppYEy3mBd8nKflAfmBzRxsuWCzAkULijMoN/gf
e+yxghGUTtj+GbrqqqsIygYwhxICBe/aa6+l4sWLp4W/SSfqCqUNecOLB1OisGfEVDkUXB9Kpfx9
+Nvw94mPMDzyRpjeA0Fxw8cAptugtIGi/NHWUMao95UqVZKwHTt1lA8TmCpAaTMUVb4nnniiTP1D
gcF0Ym6oRIkS5BM/0/0DZMZU+tq1a+nwww+XqXGYQbjI1f5d8Y1/9X2rS3vA89FHH03o2zAN7tP+
UsHPpBFV/qj7mLrFBy9sbUH4AEjWf4pnmv/KV61BXS+/IwfX2g0bE36GeASIjm5/pjxiunTmoIly
DxszKFigB67qLFfzN++7L3OltA254jTasG4t1TnoMDqt1/XU8vQLDavIq6/8kQz+9ShXuToVK1Zc
nuod2ox+nf0lzfz0B7Ghc+XvkOZt6bMJY2gftv1rdMyJSZOKwm/RL7NpxdIl9J97nqMy5StK3MbH
dyAe6aLZ0yfTAUccS3/wdHOfu/5HNepl148z+t5G330xJWk6eXFs0+ViuvWClmIruDfbzFWstj+1
P+/yvLDKc5xCpbT5ohRWWmDHYggvdhA6VGMYjmfYG8G+y5d42kFsVPAVi5cPT30SRiPC1KRJExml
wtckT78SlETYhkGBwcsenRUI9kPVqlWjTz/9VF5uYR6J93hZgmDQDLupRDIdIV6y4RFJKHvojMOE
lyqUxagv3cMOPUy+1PHlnBviqSFRQLH4Aav1kDZGzGATlxv8IV8yewQogRi9HDVqlIgFmzejDKSD
vyuvsAdCncJCA4z4oRzwDHcQlA2UqSGeYpZbs9gklfI3PG1XG/5FixYVTDds2LESa+WqnLYpGNnE
h4HB34x0mnSj/EuXLi1BYCMZJigvUJTCFFW+CIN0U1lN6Iqf6f4Befjf//4nbQ6LH8Lkqh/hsOm4
BxbFimW/JnzbR17xc5U/m4JIlsIfkOG6GM4vFkVlzc2idu3bEZTxnUnF99zx0VuseOj9USz7/ohW
p9IhR58QiNThouupVgP/9wci9rnjCWp0dFsqVSa+fmAhxLpVywLefyz4Se4rVs1erBZ4pOkGZb3H
HkWFW3HP/CGObTVnFH4l9sruHzZtiO8fNv61hheAVKd//h10+Gdb9uADhNqyaUdflY4sA+8hr8+i
n2ZOFbu8H7/4kB4d0J2GvpVFRXfSooU90pGRgsYDBuno1NEJwJgaw/KG8PJEp2Beols2bxF/jJBg
5AcvWYwuYSoGU5joaLDa1IxiGT7JrniRIW2kh/QxooRVq1B8oDyATCfE9mcEw23IiBe3Mf5GWpgm
MCMzU6dOlXg19q0hV/xF5Q8yIy7bmImiCB5QHDEi8eijj1Lt2rVlug73GCWDvLjHFzZGo0CQHTJC
fiiTkBEvVUNIG7R6zWpZKMG2RcbL64qFEkirS5cuMjJzca+LxTAbiyJ88Ef6UApQfsAwUQGAEJhq
wrQuRoNgyIxVtKB08RdmSf4MdsAPij+mvU3dMwtBMP2LUSm2HRKMEQYKc5kyZYRjKuWfRKQcTjb8
ERimBJ988olMX2JkBIta0F5MPhAGoyF9+/Yl1M277rpLRpWxoMVQlD+mUDGyhDiol8AEq47ZjikY
+fYpX0yNIm2MaM+cOZMwKsw2WSZ559UWP5P9AwQz9RWKYbIRcVf9AI+o9g8/G5kyDCu8ph9EO8d0
tU//l1f8XOWPj0p88KL9YnQNo68Y0QehfzaEfo3tRmVaHeYP6abNG9bT5k3refptuyw0CG8LsW3r
FnGHMT5o69/8Ptm2lbZu2Ux7V6hE9Rs1obnffEplK1Slhke1phIlS/Nq04k0+4sPvMTEAgcQFJuY
mIzGRzvmlLPpm08n0cK5s0Qx+vDlx+nwY9qSUXgQ2iZ/PLf4J5NPxDdk8rl9698yXemTv732Ls9T
ilNpLS/sWDDnWxr/xCAefRsrLG34Va1ZT0YW33j8Hp6+nC7YYxXq/LnfUbP2XalG3YbEdnb0woMD
6EeersVCkJceukX4/s34+9A2rufr16yiTevXSXDc47f9X0Xw9ZH/pTFDr6embbvQab0H0HGde8rC
kPXrVvmwT08Y7hgKFbGCgbnBuN+NN94oGLCNWeDOSkOMO/3gmaduJAwM7GHsHObRuXPnwFDcBiav
rAzimQUR3CmKYT/4PfXUU4F/mD/ueWsIYW2M8+EGHjAWfvDBB4NkbflDIFYYYhdffHFcOt27d48t
X75ceGCxAgzNTfowin7ppZfEj1+EgTvShnE4j8qJGxYd8MrCwB/xERcLJXJD559/vsQz8WGMjgUE
hmz48wsvLn2TB8iYSKwISVizAMT4p4u/4Re+ok4ZmXiFrnhhYYJxY5tDcWOlNcAAixb4gyBgk2r5
B4wiblz4ozyxEMbIzPaPco9FHyAefY3x6HHMuKOesHIc1AOXP4+oxrDwxPBHHTLl71u+rBTGGatD
Hp6mj8hxTueo+JnuH2Dkb/JtrvPnz88hoK1+uNp/DmYhBywwMumiLuKezURivIJd7nnlcszWPgyr
VPCzlT/4szIvfZ6R0yw2Mv0pwqBfMu2Ep1rhlBaCcflT01YGGBkZTr+4vxiiPzx5YeDXvN0Zscc+
+iN4PrLVyRJm2IS5Yoxv4uLarO3pslAgmfF62A1G/uF4uH/w7Z9zGMF36H51sAjigMOaxm558r0g
jE3+cFrJ7hs1Oz5I/95XZ8r9sSedFbvqvrFy3+vmh2I++Rs+6ae4xQIHNT4mBgN/H/yGT8wSw3+D
AxYL9LhhaJA/trELFiogTItTuolsZgFJsnyF3Y496cwgjyYNXE0ax3U8L8AWaWMxhPEL80l2n5ZK
yEyKgBELpZRLBDAKgC9aTFeYaYNcsshTcNjUYTp01UoeieOvG15Zlic++DLlFwJhAYQZxQkzQv4w
UgFjeRhn2gjTmMYGyRbOxw+YYroQX/aQAdOZyShV/BEfGNarXy8Ze0l7V5SvEQYjHBjtxOhnmNJV
/mGe4Xtf/DG6WqpUqRw2l7fffruMDGOBTTJy+Zs42DYCaWA/QVf9M3ESrxhphYz45YVSiZ9q/XTJ
G1U/XPHS5e+Tv1Tws5U/XllYxIU+JzxVnZg3jLjltewTeeE5nWePYiuQTRvXU3me1itaPP1WShgB
W7PiD6pco3ayrGTczSd/GMHasyT3IfzLLWEkbOOGdYTFFYn9A+rHGrYfLFOuoiz2yC1vW3iMMhZl
ez6Mnq5ft5q3XIlfQGiLm66zR1Vps6GsfoqAIuCNAPZl63NpH1H2YcuIKSqsKDXk8jfh9KoI5EcE
0qm05cf8qUyZRSBdSlv6VfzM5lu5KwKKQD5FYAMfFQO7JPxgB8lT7nGSuvzjAuuDIqAIKAKKQA4E
8tVIm37J5CgfdVAEFAFFQBFQBBSBXYxAukbKUs2G3VgpVe4aXxFQBBQBRUARUAQUAUUgLQio0pYW
GJXJrkAg2bl+u0IOTVMRUAQUAUVAEdgZCKjSlgGU87ogF4fgPnRdN5r8wqMZkGoHyyj51q9eSQ/3
P4/G3Oc+EmUHt/Te4UBiHFUCHJ4bnL03XLIUsK/PJa2qkNk7KFmYvLpF4ePLL9X4vunsqnC7e/5S
wdW3/qaSRqpxo8pvZ7X/qPRTzVe64qdLvj9/++Xfvuxs62ayiXKnK/1Evvq8eyCgSlsGyhHnzWHT
v9xS+So1aBtvxpg1c1puo+YqfJR8JUvvzTtLV+PNHifkil86A+/Dm0424qNOylXal775+K1I1hWq
7EtNWnegPTKwC3UUPpHCJHikGj+BXb573N3zlwrgvvU3lTRSjRtVfjur/Ueln2q+0hU/XfKV5WOO
DmrSiqa//xpt3pi96biPjOlK3yctDZNeBHDEWr169WSrJhxXiAVZ6aZCqbRhdOaX7/g8vc8n05L5
WYSv4zBhjxv4f/PRm7SMzzIL0x8Lf6blixfQxvVrZcdlfJ0m0qaN6+SIi0R313N5PtOtzsFNJBi+
tpBO+LgP7Kq96OfZ8jM7Y69Y8ps8r1z6u4t94B8lXzHeHw1n5YHAHztKJ5uCtOETJGK5QT5+nvU5
zfrsHVq3cinhi9SMmOFMuRPO6kNHtu4YyWHZ7/Np7/KVqXv/B4KjksKBbfJlsvyMDFH4Gn/Ih1FV
4Lt66WLj7H214bd2xZ9SH3AFoQ59N+092QXdJGDDB2GwB9Kvs7+S9oGwieSTv6j2k8gr2bMNH5/8
JeNp3HziR+GD3dLRV6DO4ni5pb/Ni8MVafjUXxe+tvJFGlHywc+HospvZ7X/qPSN7DZ8fMoPfNCu
EBY72S/+dY6ci2n4u/BzyWf42K4r/ljEaW+j48/olSOYLX8I7ErfFT9HgiEHH/xc+Pi8P5P1b4iH
9gMZQHi34H0Wfnf5yRf9/gBfl/wIkynijfbliMSFCxfKyUE40SbdVOi2/Jjz1Sf0wLVdqHaDw2nT
hr/o1x9nyoGzNz+VfYzIb1nf0YP9zpKDZ2vWO0gO+D353Mupx03DCQraXT1b0+oVy3hTxCq8AewW
ObT3ikHP0rEdzhUF8Ilbe9Pv8+fwpqMl+BDbbJ6NjzuVuva93bvsfvtpFl3dvrYcjotIbbr0pF43
P0ozPhxPI268QPh06XMTnXnFf2nI5R1ExgaHN6fbnvvUmgYUVB/5cOhu/86HBPm75oEXgsOMbfhY
E//Xc8GcmYLv0sULiXeUFvzgddvoj6hB4xZOFnhZ3nvpybRubbay/MRnK+Li2OTLdPn54IvjVx7h
MkT+cTAyDkBu3+1SuvDmEUkV0LjM8YMLv9GDrqbv+UicAw9rTnvtvQ9NffslYXHCGRdRbz6v0IYP
AkKB7texoZRNmb3L0Xo+16/fsNeoIR/K7JM/F38RxvLnwseVPwtr8XLFt8mPo4Yeuak7VeCPK7w4
UXYgYNvzlpFem6Ta8AUvV/na5EN8G/mUH+Jnqv37pO/Cx1V+q5f/QQ/160ZZs6YLFLUOaEQLWTE4
6vhTqd+I8db67yOfDV/4Lfrpe3r4xvOCg+EPO7pNXBRb/nzSt8WPSyjiwYWfq3653p+29ps181Ma
xu/Wg45sSdc99AYfX3UPTXnjae4Ha9KgV2eKxC75Mtk+IiDLlTPObl60aBHxqUlyZCQ2E8fRgDi3
OV1U6JS2zyaOoYasHKABg6a88gSfg7ZjOvKRAedT5X1r0eDXZsluyt9NfZcG/6cjHdS0lSgulw8e
Q3f1bk/n9ruPWnY8n8YN7U8fvf6UKG2V961NZ15+O014egi/9CpQ6y7ZX1mVa9TJVXktmjeXR5GG
UKtOPejHGVNoeL9zqArzOP2Sm1jJWUUvjhhIp3TPtvfqyumNvucqGvDYO840ciNfjwEPUrN2XQlD
9VNefSpQ2lz42ITA6OGI68+h8jy12f/RiVS99oGM/+P05J1XyLSwLa7xw+7X90/MkpHQe/t2MM7B
1SVfJsvPhS++NGGvV/OAQ+nOcV/IWX3ffjKJhlzZmfZvcJiMMAYZSXLjg99V979Ibz83nJ4b0p9a
8YfE458s5S/PTbSdlV2QC59K1fYnPgqG6jRsworJWhozpB9NnfCcKG2u/PnwFyEi/nzwceUvgnXg
7IrvwufU86+il0feSedecze16HgByYHRN/ekKnwuIs4idJENX5/ydclnS9+n/Ez8TLR/n/Rt+EA2
V/k9N/gaPgd3C93z4pdUolRpenbQVaK0mf7ehl/jVh1T6r9Rf4dfeyZV2a8OXTX0RRmNHXtfPwOp
XG35Swc+cYkleXDhZ8On2Yldyfb+9Gm/nbmNzPnqY5HsvOuHcL/SmsY90D+Q1CZfpttHIESKN08/
/TTx0ZCEc4JxTu7bk96mjp2iZ45ym1yhU9radLmYbr2gJfU//WDam20OKvJLqv15lwtuq/joCyhM
oAeu6ixX8zfvuy8DxQWjbFDYQIe3PJmmThon98VLlKBD2B7rswljaB+2DWt0zInints/fB2e0v0a
iYaG0vr0HoSXO5S2Nl0uYXu5++mdsQ9Sl//cRq+PvItO7XFt3IHAUen5yocRoKPbnylsMF06c9BE
uffFJyr9pYvmyVd89xuH0b51GkiwE866lMpWrEp1DsmeFo6K6+PuK1+mys+F76JfZsvozH/ueU6m
0ZCnxsd3kJHe2dMnO5W23ODH5/nRZfeMjhu988EHU0lv8hfwnJlTBfIN69YSn18o9678+fAXRhF/
ucEnWf4i2CZ1ThbfV360z069bhC+LTtdwNPc79G3fEi3j9Jmw9dVvr7yJc0wO7rKz8TLVPv3Sd+G
j5EP12TlB/esmZ/ROdcMotoNG+OR+8ybadbn2TMePvil0n8vWTBX+rc+d/2PatQ7WNI/o+9t9N0X
U+Qef7b8pROfIMGIm2T4+eBje3/mpv1GiBU4J5MPo4wYBY56f/jIHySQoZuff/6ZPvvsM2rSpAnx
mcnEZ+LSqMdGqdKWCt6lypSlIa/Pop/4pfTXmpXZX8oDutPQt7KoeLE9hfURrU6lQ44+IUimw0XX
U60GRwTPRYvu0HX3KFo8cDc3RYoUibNFM+6+1783b4wLiueixbLTxDl1p/f5Pxp7/w1Usfr+tG71
Mjrx7L5x4V0PLvmK71kyYFGseDYmcPDFJ4iccFOiRPYZc5iWDtORrU/LcX5c2N/33le+TJdfFL4l
9iotWdm0YU1cljbyFGQ5PoPQRbnBDx8kkCNMPvg8fmsvPq+wDt0//gdRprGg5svJr4XZCN+wraXx
9OFvwia75gafZPlLxjPKLVl8X/nRHvHVb/Ddgud//I5wtuHrKt/tf2+V7Lj6p6g8G/eo+mn8M9X+
DX9b+jZ8THxck5Uf3PdnsxcoRoaWzN9hr+xbvjb5DN9k13+2bxfnf9iOztCWTRvMrVx98mdL3yd+
XIIRD8nw88HH9v70a7/8bgy939b/a+aSKGYy+dLZPkQBZHOhRs1PlI+ZxPTz+vzMM89Q48aNqQQP
4GzYsIHat29PjzzyiEyZ4pzvdNAe6WBSkHi8PvK/NGbo9dS0bRf5Mj6uc0+xL1rP0457V6hE9Rs1
obnffEpleRVjw6NaU4mSpXk15USCPQtoK9uxbd++LTCc38ZD8eLOxvWG9tq7PE+5TqW1q5azjcq3
PHc/iEffxhpv6xVD+/iaGHNvPzFWx1TXtHdf4anKLkG8Vh17UNl9KtLjt11KHXv252mAvQI/nxub
fMjPP/9sF2NO8JL88uG4MI72wceWfvmqNQi2d28+OViM3Lds2kgfs03DlSfWlLwiLgyHcZDwJl5t
JYfy8j2e8ZIEwRhc/NmmCIR7/BDPR75Mlx9kisK3Kk+h1TnoMHrj8Xt4ene6GOJCKZo/9ztq1r4r
olrJBz8caIxOcdvWbJzMghUw9sHnn+3/UIUq+4kcX33wOk16dhgrJP9I+RvhovLnw9/wSHb1wceW
v2Q8E91s8X3lR/scffeVYlbxBo9KfvnBeDqq7emSlKv+2vB1la+vfIl5TnyOKj+Ey2T7N3LY0rfh
g/i28oN/m64X05v/GypmCI8P7CWmF3AH+eJnky+bU/L/GnUbUtUateiFBwfQj19OkYVGLz10iwT+
+9/3gyt/CGxL3yd+cumyXW34+eBje3/6tN+6hzSlH9iuHAsVsAjhnTEPEpRcTK2CbPKlq338vXkT
DTyvuZilTHz2/mxg0vC/hRdtQWm74ooraNCgQXTvvffKaFvDhg1p5MiRwTss1aQK3TFWo/7vQvr6
k4liAA9D+FJs93Dqhf3o5AuuFiyxImzUzRcFhqxwbMYdcrer7iYs4e5zfDUJ17RNJ+rz36dkrzA4
HH5MW7rxX7syrG68/8rTgqlWDPWedcVdYhckkSP+oBzCvqlGnQN45KloEP+0XtdL+rDnMvTaqDvp
g5dG0fC354ntnXH3uUbJV7VWfbrixFrConm7M6jnzY/Spa2zR4CObHUyXf/IW7JiLgofM+VpkwEr
hZ64pVcwZYDFHsedfiGXwXUycvHC8Juk003kce2wl1jRPoP3kTtXlNhE/x43DJUy3JXlZ2SKwhfG
/FiN/MTtl0jHhfCog10vGxjUP8Mj6mrDb9OGddT72Eo5ot40ahIdemw7cbfhg/L7cvKrYiNpFtsc
feKZ9A7vG4gp0jvGZNt+2vLn4p9DuAQHGz5Yse3KXwK7uEef+C758dL6nqeyS+xVhmZNfV8WJB3P
9bfr5XfyaHhRctVfF7628sUIjEu+uAxHPESV385o/xApKn20Dxs+N45626v8p04cR1/zoq3ivBgM
ZhfP3nc9jfsue5TSBz+bfBGQBs5YNf3IjefLQAAcW5zSTRYDwSTjkQ8XW/Pn075s+Jj4gTAJN+mo
/673p639Qhx81DzICwFnfDxJpDu8RTtpR8Cp58BHneWbjvaBAYCB5x4tixCvHPwcHXPqOQlIJX90
HWPVokULmjYtu4986qmnZCHCEUccQbNmzRKGr776KnXpsmPwJXkqbtdCp7RBky9arHj2KM661VSp
evIhSyxH3rRxPXfK1b1WhSWDGiNAe5YsJb9k/i43rHYsxSv48DIIEyr+gK6HUruz/8P2eFeGvXJ1
n4p8qeKDDuQf/rrCFgmZoFTlg0yp4OOKj9WHG1nJKl953zxNDaeKnw0f1K/Vy5dEtg1TXjZ8bPxN
fNs1VXxsvH38ouSH0rZkwU90+b1jfNgkDeODr6t8o+RLmmCEo638IqIEzplM3wefQBDHDWYqsDAM
ClOYfOTPKz5QCtawfXSZchWTflD75i8qfd/44fzm9j4KH9/3p6v9on7vuWcpwjYzeaF0tA+MuOH9
7Esupc2XT6rhCp3SlipguzI+9rCZ8tpTtGLxAvrw9Wd4G5CH2J7tP7tSJE1bESg0CGCU5uk7/yNm
D03ZXKHuIUfREa1OKTT5LygZnfHhGzLStob308NoqNmyqaDIr3LmTwTyi9K2w6I+f+KkUoUQ2MJf
Bqt408g9eKTwxLMu4U0+l4V89VYRUAQyiQAWIFTZv7781vB+YH+tXp7J5JR3HhGoVL2WLFSoUHU/
no24jDfqPi2PnDSaIpD/EMhXI235Dx6VSBFQBBQBRUARUAQUgfyBwA7L9vwhj0qhCCgCioAioAgo
AoqAIpAEAVXakoCiToqAIqAIKAIFG4HVq1cX7Ayo9IpAEgRUaUsCSn53MnuW5Xc585t8M2bMoK5d
u8pmh+mQDbtfn3nmmfJbv359OlimlYd5aW3dmr3dQarM041fqvLk1/jaPjNbMj74Pvfcc1ShQgU+
0io9dT83OYqSb8WKFdStWze65prs025yw7Mghs1r/xiFX0HEIBMyq9KWCVQzzPPKK6+k++67L8Op
7H7sa9SoQdgAEceMpIMqV65Mxx13HGH/nXQoba+88grVrl2b2rRpE2zE+Nprr1G9evWoVatW9Prr
r4s/wtxyyy20ZMkSOvDAA8Wtbdu2kqXtvCv7DTfcIG54aVWtWpX22y97s9w///xTeCF+4u/mm292
QpJu/JwJFtAA2j4zW3A++KKuduzYkYr9e5JMZiWK5x4lX9myZal69er01ltvxUfYTZ/y2j9G4beb
wpTrbBU6pQ0vrtmzZxOuoAULFtC7775Lf/2142glvNinT59O48ePp19//TUHqPgSQDyMZOB+zpw5
9Ntvv8lX3Y8//hjwhj/SWrRoURwPF398HSL9999/n+bOnUvgGaZ169bRypUrw05e93/88YfwQp4m
TpxIGzdulM0AIX+YUpXPR/6vvvpK8oe0ktHvv/8uOEIJgXxQUAy55DPhEq/oMI866ihxNmWYTNkC
f4wqvffeewQ5kpEp7969ewfemzdvlvJGma9Zk31U1cKFC5PWgSBS6KZDhw6El81HH30UKJYjRoyQ
Onj99ddTu3btqEGDBpIHfK3vu+++9MILLxDSgKIGwpEpY8eOpTfffJMgz0UXXUTLli3jUzy2yxX1
BnGM3Lg//fTTpZ6FREl6mxv8bO0nKXN2/JtPu0BdX7p0qRy2Pe+XeXHtEvHS0X5d9dNWv3766Sdp
+2vXrpX6gdGTRMpr+0zkk+w5lfwXFnznz58vZz4++OCDwVFjBkuf8kNYW/9jeEVdo8p/T96T7JRT
sreIQf+A/sWMhod52epfOFyye5/8RfFHn4a+C+3OEPpHuOGH+uNLyfpHExf42Pr/KPx845twu+2V
X16Finh6LLbPPvvETjrppNjZZ5+Ns5Hk17NnT8Hh22+/jdWtW1fc+PgJufKxFAFGU6dOjdWqVSuI
d+KJJ8o9j7jEPvjgA+HNX3gSvl+/fvLcqFGjIL6LP7+wJQ748RlmAW8wYOUl1rx5c/Hng2jFH2EG
DhwY8LfdnHbaaYHcyHc4HzydIFFTkQ8MbPLDnzsVkQFlgPRxRRxDrJxJHk25ADvcs0IjQVzyGT5R
19tuuy2GcmWFJ8CiV69eMe6QJArvaB3gYsJcdtllfJLTP+LPu1tLfCPfCSecIHxYIY49//zzAU8e
uZLwpg6h3HyoZcuWsaZNm8YuvfTSGHgCI8iBugU655xzYuH6CDfIgroBuvDCCwOs8Lxt27bYY489
htvYl19+GUO9Ab344ouSD9zzESvSHnDvIhd+qZQPf0hIfUgsH7RNUz6ptl9X/bTJv3z5csEPeANH
1F3cjx0zVmBLtX26sId/KvkvDPjyx4n03ygb/MLkKj+EdfU/YX6J9z7l//bbb0udCdefl19+OWBl
q39BoIgbn/zZ+B9wwAEiG95/wBGEvsH0dZMnT45IeYezrX9EKFv/74OfLf4OKXbvO4wUFTq6//77
pSKed955MR55iPFIWIxHKwQHvDDwIt60aZM8m0aGhsWjcdJZQ+FD5YQChxcsKrUJz+eNxfhrKsD0
rTffiqExGLLxRxgoEEZBwTNeuN27d8dtjEdOYjz6FoOieNZZZ8X4S01+v/z8i/j7/KEjg0wTJkwQ
uT///PMYlEujtKYiH9K3yQ9//sqLIU28hNHJnH/++UHa8MdLCYro119/HeNRRskr8DXkks+Ei7pC
6QA/1AGUPcoVz3fddZfIBAUJ5QvZoKgBK/iPGjVK/NGhAf8ffvgh9v3330tdgT8ULBCPdMnLYtWq
VfIM/uigUXd8iEcChQfiDB06VMoGaU6aNEmiu5Q2nvoVeQ8//HBR7l566aVA4UE952lV4RNW2oD1
Qw895CNezIYfGKSrfPjsvtjixYtjo0ePlvzcfffdgXx5bb9g4KqfLvmhPKO8n332WZEHbad169Zy
n472KYwcf6nk35Tf7o4v+phEpQ2w2soP/q7+B2GiyKf8zfsE7RL9y+WXXx7jQ8UDlq76FwSMuHHl
z8afR7+kbvMMTGzmzJnSJyIZHsWP66MjkvbqH239vw9+tvhRcu1u7jvehrtbziz5Qad37LHHBqMn
JiheEuiQUbHxYjY/uPH0VOzjjz8Wf7ysDeHrFf4+SpuLP3iiswE/KHqQES9pKIdhghKHhpQXQkfG
U3+idCIddBzDhw+XjiMd8rnkR2cApRRy4AcZoPgagrLCh+6axwBzOPjIByUQik/i75NPPhGeeGmF
Rz7hiNEpjIR98803Ik945A/+GPXkM+NESYO8n376KZyFcA83o7RBGcXoGEY/gS3SgiLvSwgPxRzy
gC86UtRHtpsTFi6lDYHwNXrrrbfGeJGEYIz4kCVMYaUt7O66t+HnUz554Y+PK7QFQ3ltv4hvq58+
8uOliDpqCGUVfoZ7Ku3T8LVdU8l/svLbHfG1KW3h8kosP1v/YyuTsJ+t/KG04cPQED6e0V+AfOqf
BLT82eqnD3/IApkuvvhi6X94mjOGD0DT/1iS9uofXf0/+Nvw84lvk3F38Cu0JyJUqlQph71D8eLF
+T1JBNsiY9iNZ9gL4eBX2JeBWEGTK/4SbaJwqPOGDRsC/5WrdtieufgjEisyxKM4YtMEexluhMSd
Ks2bN4+KFs0+gxRpJKYbJJjLG/AyxrrpkM8lP2ys6tSpQ1lZWWIkjwUVMMA3BJzDNnzhex/5YJhv
cDI8cS1fvnzwCFu+MKG8gEHp0qXF2dijmTCwX+KOlniqUZxgH2YoXNZwg4yssNF1111H3AGKHRlP
Z5rgzivsTWD7goUGsEuDDR6e4Q6CXRlsvgwBR5BZbAAjXti/3XHHHeKOsNWqVSNWLmXRhDim+BeF
n0/5+CQN/ty5Bu0Tz6x0xkXNS/sFA1v99JXftBfwM3Fwb8infRpbVbQFHlk2Ub2vec0/EigM+NqA
tJWfrf+x8Qz7ucq/ZMmSQXC0bUOmLkW9f0w41zUqfz78O3XqRKy0ESuXxDMOhIPPceA5jwa6kvXq
H139PxKx4ecT3yloAQ9Q6JQ2LDhAp4WXIE9hyWHd5cqVk2LEahe8JHlETRSlgw8+mNgOiHiKSwz/
2SZMXt48pE033XQTHyi/iW6/4/a4KtCsWTNR8mDIjsY5bNgwMQKH8bOLP4+iEI+QEAwxYUyOjrl2
rdp0/gXnS/r8FShpQQH5iI3VYWDOX0/EU2e0//77E3+hxMmS+AAZQFD4jBJjlAEeIaKKFSta8+8j
n0t+KDxGwcDKSB41ENl5aFzwuuSSS4infkVJhRLF01BBNnzxCyIkuUE+sRDj6quvFrx4BE6URh5t
pPr16xN/VRJPlYoh80EHHURPPPGEdFrIF+oDFLH+/fvT4MGDpZNCPQBBfkM9evSge+65R4z9kb+9
9trLeFmvKB8ogfih48bPlJkxWD733HNlQQLbpoi8PH1OPCJMZcqUEd5YmQZFFx1vqVKliEdpxb3G
vjWCtNEGUAeghIIv4poOPQgUcWPDz6d8ItjGOaN8+vbtSxdccAFNmTKF3njjDeLRSgmTSvv1qb+2
9o/4aC/ADeUCzEz7MfUXQvq0T9Q/GKLztHuulLZU8w/5dmd8UT9Rt9GHgtDHg6Cs42POVX62/kcY
efzZyh/pow/EtUSJErRl8xapS6g/6Wg/tvz58D/jjDNkwALtoEf3HvLugfJm+hdb9n36R1f/D/42
/Hzi22TcLfx2h+FC3zzwCIoM+XLBxV159WjAAvZhZmrKhOvcuXNg6A1bNhiLww9DyTyyIfdmehSG
3/yyDfjDXgFhsegB5OKP6T3uYCQOrhhKf+CBBwL5cMOdrkyZGfkwdcRKXFyYZA+wvTFxMMWLe9jG
8QpCuYc9VqryueQ3Nl5IG1MRsOnAfXiKFIsiYFuCaRvkHf6GXPKZcMmuxj4NU8+YMgRf/DDVzJ2B
ROERTZkONX4ogzD+mHZBuRt/s5glPOUCRrfffrvkz9SLZPIkumEK1vA1Rr+mrsHdTMtfe+21QR0B
bpgSMWQWryA8ZIKsvIrOeMd41DBIw6R14403Bv62Gx/8UikfpI3pO9Rn026QhwEDBsiCinS0X1f9
tMkPO0eDGRb1wG7RPMOUwpCrfbJiIeWHts0vWRPNeU1H/nd3fGESYMokfEUb9i0/W//jLCQOEFX+
ZnoScqGt80d3IKuxg7bVP1faPvlz8UfdRJvjj1Gx+YWseC/4kqt/9On/o/CDDD7xfWUtqOF2vA0L
ag4yJDc6ZCxOQCW2EYy7UbETX87oYG0dchR//kKUBQe4msURUenDkJ5HDaO8U3LPq3w+8kOxdeXN
CA/7nUSFCH5R8pl4Pld0cpAlGUG5gT2HUebCYWAfhnJPLHMTBjyhGMJWMFPEX+ax+fPn52DPo2yC
DTpn3GeSbPjltXygVPCIVspiR6XvUz+ReFT83AgW1T5ho4o+A3U7UxQlf2HAN52YRvU/PmlElb9P
3Kjy84nrE8bGH/0Kj+gKGywGc70DE9Pz6R99+v8o/HLz/kiUbXd41gPjuffMC2EInlfcyfA7psAw
zcHbNOSFlcZJQACbyOIHeyxMIcEmDPuV5XfCHlqYTuVOj55++mnZMw3TfEp+CGB/qD6X9pFpf5w0
waOIdOqpp/pFLkCh/ve//4l5BeqJ79R5OrJXWPBNFauC2v+kmm+NXzAQKHQ2bekqFtb2ZUNd1typ
T58+xKsH08W60PPhKT2x76hZs6bYNmHz14JAPPImm3LC1gl1IrxgoCDIv6tl3LBxg9jpwbYQmynz
SN6uFikj6fO2IwT7uJ2psCEjhQXfVAutoPY/qeZb4xcMBHSkrWCUk0qpCCgCioAioAgoAoUcgUJ3
jFUhL2/NviKgCCgCioAioAgUUARUaSugBadiKwKKQOFEANs6mL3WeMFT4QShEOdayz89hW+2UUoP
t53HRZW2nYe1puSJAOwEkxE2G+7WrRvhsHSlXY+A6fTMXnK7XqJsCaLqT36RL1U5sHky9s7CxtvY
08qUQyJfbIyKBTGJhPLC/n58Pi5hv79Ecvknhs/U888//0xYkIIfFn4VFnLVX9/yzytervRdfFON
7+Jv88celagvvGUUXXXVVZFBeVsXqlChQrAPZmTAfOihSls+LJTCLhJ29cdJCYlUtmxZOREAG8gq
5R4BnDxRu3ZtatOmjZw4AA7Y4LhevXrUqlUrWbELf/xwIgMWA+CECTybE0KwuSVOCIEbOr2qVasG
myVj9Sx4wS/xBwVhZ1FU/dlZ6Wc6HShq2BAcVxA2jk2k2bNny+bOQ4YMSfQibP6M9gWlCKcxJCpu
Lv8cDP91wCkP4fLHPTbKxgbWeSFsBstHyBEfoeSltJn6beoeNnuFcstHweUl+V0Wx1V/fco/FeFd
6bt4pxrfxd/mz9tDyebjOMEGJ8pEUY0aNahjx47BaUBR4fKje6FT2vBiQYeGK2jBggXEm+sSdho3
hOHn6dOn0/jx42X3cONurvgShT+fWydHW0G7DxPi40QEbFfx+++/B16Ih7AmbXwhQxbe8ysI4yMf
ds+eNm2aHDWCFYrofMHbkEt+Ey6v16j8gZ+P/K50eS8tOQEiMRyOfOFNKMUZ00LAN9koQ6r59ynf
qPphyz/qGMobP4wcQAGaM2eOPPOGkkF2bfLb+AcMIm5wwgI6K5ymwQfLSyhspYK08fXerl07atCg
gZyKgdFMdHy8bRW01AAAGD9JREFU8TLxnkqiqCECb7Qpp3WgQ0Q9xLEyOJkDecGV91aSOL179xb+
iI/Vv+YIOHG0/Pnkz4YPWEfVn3S0Pz7XVfoMHG2G+ofR39wS5IMigf4DecktQVGGQoMfXlJ77JGz
G8epLVihmkjoK1AmUIT40HJ5cQ0dOjQI5vIPAia5gZLGGzVLfUEa2AYJRypBCQz3Tz755z0SJY6p
R0mSy+GElzBOKEFaOIYJdRt9BtxRPw256g9GivBeQN+Ce7RRI4+r/0YaLv6u/iWq/hr5fcrfhE12
TTV9V/lFyY90ffBzyZcsT8YNpwhh6y2cXhRF2GoH7YY3HQ+OyjNhfdq3q3wNr4xduVIWKsJO+9jl
nr/A5JQCBlY2uuzZs6fgwF+dsbp164qb2TWf9wkLMOIXnsTHIeJm93ncG2JlKsZLxiU+djwH/8su
u0wO7MbO9UibOxEJ3q9fP3kOH2Duku/rr78O+IOXkd8cYu6S38iZ16stf+Dpkt+WLneOchoF8oUN
dYEvfjh83RAOXEae4W/yj12yDaWaf1f5uvjb8m9Od4D82HgXvJAPPKPO8YtF3Gz1z8bfYGC74oQF
nKLAHZscco+6inpqTlXAxrbh+g5ekA9lA7rwwgvlxA954D9sdMlTbfLIR74FGyGHD6QfOXKktDcT
x3Z15c+Gv6v+pNr+sJmwKa9w/Rs7ZqwtS3F+/FIQPFF3gT2uqHO5Ieykj82TsYkpdqBPJFaYYnwM
kRz8jT4sTM8884ykj7oG4iPbRA4TxuVvwkVd+QhAyZPxh3yoP+Y0D1f+ceKM6XcR74QTTpD4vKWS
YWm9hg9gR0AcCA8+2CgbZKs/8MfGxygXxMEPJ13gij7ep/64+Nv6F1f9hXwgV/lnh0r+n2r6tvJz
ye+Dn02+5DlK7sofVHH12oRCvUf/inaHX5h82rerfMP8MnVfKE9EwC7XaIg4Jgm7LmN3e7NDMzoM
dBRmt3ujJBjFgPdYintp4YXFZ35K+WDnaLwAoRCiAqBTNUf/8FenhOEzFGPmyBI4wB+754cpSj7w
Q4XDMT9oIHjGCxF5McceueQPp5Pbe5/8gWeU/K70sMs/Oll0lDheCw0PP7ygDJny4FECyT+OwcKR
R4ZSzb+tfJGGD39b/vkg+bjyHj16tNQZs+t4qvwNDlFXvMxxLA2UDh5hieHDAXWKz6+VKC6ljUfo
pL7xGa2i3KEcjOxoRzytKnzCShs+NHgj6iiRcrjb8LPh41N/Uml/EBQvHrQ3PhNX5AZ+OB7Ol/gr
XRQtYIY+AsdqmQ9GXx62cHxurdQnvPxQpsArTIMGDYqh7AzxiJvkxzy7/E24qCuUNuDDI7fSL0IB
Qp2Dcg+y5R+YoC6i/f/www+i6OVFaUPdhvJ59913x/BBjPQN2eoPTgFAXPTfUB6hwOEDB/kx7wNX
/bHxhwy2/sWn/pp85PWaavq28vOR34WfTb7c5DlKaTM88DGRqLTBz9W+XeVr+GfyWmg312XFh8aM
GSPDo7DNAcGGh5Uhue/UqZNczd8XX3whBo44UPiYY44RWx9MT+CgdszhgzDtBR7jxo2Tw97h1rFT
R7HL4EqUqxMTksmHqQtMZeEkBhxmDuJRPLEr4o7JS36JlMe/3OQvmfyuZHGAMnfYckh89erVZbou
WRxM28FWBoTpUhyODvIpPwlo+bOVb274R+UfxrGslNCHH35I/EIiHn0jPktUDh9PB39L1sSLO1ap
u/xylClRTNNhKgkbA/tQixYtCFMIaDuY6gBefDQS8UtWbNvuvPPOHGyOPPJIwi83lAw/H3x86o+P
HMnSN/H4xU78oSaPqH/AwpeAGY9uBdPTmGbFyQ/pItQnTIFjCo0VKJmqM3UNaZQsWZLCK04xZc8v
ryB5l38Q0HFTp04dmb7lD8tgOh2Hkdvyn5WVJf0bf8gQ7NFAd9xxh7QVR3Jx3pimf+ONN2jKlCli
+4f8g1z1B+WKuJguZmVP4vAZwgSzAh9y8YeBvK1/8e3/fGSJCpNq+rbyS4f8NvmQpwsuuIBQTxIJ
9R52uemgqPbtU77pSN/Fo9AqbZj7LlKkSBw+2MkehEZqDK/xDMPrI444ArfSweEFBZsg2LOwZk48
Ykd80DiVLl1awoQ7RTigY4aiAUKa/DUs9/hbuWplcB++SSZfqVKlJEjY/g4OsBmCXQt/qYq/TX4J
wH+wMUIDROcKY2Qf8smf4ZNMfuPnugIj22oxvFgMwWbFkE/5mbBRV7zAoso3N/yj8g8lH7ZGsPcB
wXbGHH+WDv5R+TLusMcAZlhoALs0KPt4hjsIynL4JAfTQe63337ijw8U2L/hZQpC2GrVqhFPz8vH
iTim4S8Zfr742OpPKu3PZAt2WoaMTObZdYUNINoccIVihQUBMKBPF0GhhiLOIwIBSywC4ZEFeUb9
g40itgzBiQyo67V54Yghl78JZ7uiDYWPb+MRRfkQg9Jmyz9OmQGF7c/CfaUtzbAfj+7JohrkGco3
jzgST+vLhxHCRfWPxu4y/AGT2A/Z6o+pC1H8kbatfylatCiCyDsiMV3xSMNfqunbys+Il0r7c8mH
hVEGJ5MermZRTtgtr/dR7dunfE2aGGDJmptF7dq3IyizaaVMDuPlR95sJBnj0QAZAsfUKBubxomJ
oXQMiX/zzTdycDuvfIrxiyr2/PPPSzj+WpLpOExtgGDPwgUS45eX2CRh6gE8YPuFQ3kxHAx/TEOA
MG2BZ+5YZfgf4TElYKaYXPI1b95chvwx/IupEF7WL0P64AdyyS+B+A9TipDDTNsad9sV9gCu/Lnk
t/E3fldffbWkA0xRDrC7MdNR/AUttgoYigdhehlT0mb6wjf/Jq3Eq618EdbF3yf/mC4E9qhnmC4N
Uzr4h/mF71HHgJWZCoUf3FCmmDIFwS6NO87YzJkz5dBoHgWU6Srx5D9+IYr5AL/0xclMr4WnsIEB
6iWm/dEGTN02PGxXF34ufMDbVn9SbX/ADlNoJk+8iEmeTf2z5Q1+mK6DzSAvuJA+AbyQJ9/4Lv7G
H9ORsG1D32LaCvwwBYjy5fNPpf/AdA+PJploTv8gYMTNO++8I/zRt87ng8fRXpFe//79JYYt/5h6
Q/1Cu8A0FbA1dsPg5SKYi6CfRh1HPkGssEr6Jr6t/pipZaTPq6qlb0cdRls15eOqPzb+kMfVvyCM
rf7CPxVKNX1b+Rm5bPK78PORz6ST7Ip6j7qHfgn1APf4oW6AUMfwjLqFemn8zfS9q327yhdpoG8E
b9Qb6BrppkJl08YjYAIkwAz/UICG8PKBYhT279y5c2CIDRsUUyC4omLAwNwQj7iJ0aqJjzBhf1QO
/hIL+Bvl6eyzz475yAeDWmPngTTQ6UIxNJXSJT/kxAvHyI5KnBuy5c9Hfp+0eAo4zhiZv5ZF2V28
eHGAW5cuXcQg1+Bs7AR98m+TwVW+Nv65yT/sdiC7MZA2MqWLv+EXvgIzg5exgcTCBONmjMWhqJk6
bl6gho95iSIOFA68ZHkVlvGO8ahywM/w5RWFgb/txgc/Gz6Gd1T9gX8q7Q8faiZPvDpNFFLzjPL0
IdjGAjeDH2wycQ+c00k8ghfIiv4mTLxHVeCHvg6Kcphc/uGw4Xuz6MBggivqEexTjRLlyj94oE4Z
HugXcQ/MXGQWUYTDo3+DzSHcjAG/rX+HLZtpE5ADH+yIa5Q2W/2BfK766epfwMNWf+GfCqWavqv8
IJtNfhd+PvLZ8s+zYkHdQbmZnxk0gVJo3MJXvKN92rerfCEb3sWmn2RTKZu4efLTs0e55JIRlntj
GhLTRWZYFOHghukkVnxkSTimE5IRd4QyLQr7kmRL8jFliunO8PReMj5RboiPpdGYRkpGUfIjLLYL
gW0SbKvYkDpZdKebK39OBh4BeJRGMDLTwh5RgiC2/AeBktz4lm9e+ZskEX/VylVUr3494xR3TZV/
HLM8PPDLjnjFXtzUGdjA5hPToZD9761/x03D5SGZPEfxwcdWf1Jtf3kWnCNi+o8/QMQeNhU+qcRF
+8X2KphuSkYu/2RxfN1c+ec3meCDvi1sCuHL3yecT/0BH2zZVLNmTbH5DMviqj9R/H37F6Rtq7/w
zwulI31X+Rm5bPJH4Zcb+Uw6u+IaVb5hWVjRl/dX2C0d96q0pQPFAsaDp0ZkPyOeMhC7lgImvoqr
CCgCikBGEYBNGRZ8QfHAxy1sUI3taUYTVuaKgAMBVdocAO2u3sYQeXfNn+ZLEVAEFIG8IsBT9TRg
wACYDwkLzLhgJamSIrCrEVClbVeXgKavCCgCioAioAgoAoqABwI5zz/xiKRBFAFFQBFQBBQBRUAR
UAR2LgKqtO1cvDU1RUD2RMP0NKZeMA0TRTB2zc+U3+XLFHZYpOFTfq70Cyt+Bpf8nv/8Lp/BUa+F
CwFV2kLljc1yu3XrRjgsWykaAWPnER0i//pgQ2Fe9k18xiXhdIJdQdiclo/KkY2ZsSlkspcDb7tA
OKkDK4R3Jvni4yMfNpgE1vhlarPQRGx85U+Ml5tnn/Jz8fPBz8VjV/unUr6ZzH9U/5Sb/j2T8u3q
ctP0CzYChUppwxL3evXqyTYG2AU8/MOu4WXLlpUtPt56662CXaoZlh674mMn94JIvN+THI/F++vJ
iQC7Ig9Q1MqVKxfs4s17WeUQA1vFdOzYkcK7c+cIlAEHX3x85MMxb3zQNvEeSTtNafOVPxXofMrP
xd8HPxePXe2fSvlmMv9R/VNu+vdMyrery03TL9gIFCqlDefK8Q7IxDuFU+/evaXkcI9joHCECfZM
w1mCIExb4bzQZKMgmB6ZPn06jR8/Xs7Kkwi5+LPFh2KJMz5xBeGYI978V/aHw7PLH2HAf8aMGSI/
9hkKk0/8cPhk99jDCThGEfxxlA4f/h4cj5QYFnJBFuz5g72/cK6bi7CHD7DBDyM3Ji6eeUPHILot
fez9hKX7vDlqEN7cYFQLIzUGe5Q9ePNB6CaIXG3lFxcw4gHHF+GFhx+UjMR9/LAVC9x509ocR63h
mCLUCexzhPqJ0QNDmcbHpGOTz4ThTYNllNC0M+Nuu2Za/nSVr6v8bHmEnws/yIn+Be3HHDfn4gl/
3/y5+PvU77yUr8mDLf+2+m3iu65R/ZNv/26TD2m78HPJh/N/sVcmzvzFMXAYsQRPQ7b+C2Fc6fuU
n0lLrwUQAR5KLjSEI3r4ZSj5ffHFF2XXfTyMHDlSjrXCPTck2TEZ4cyu8NgF2tC3334rR8NwUQe7
9uNYGl9yxedpO0mXp89iZjdwpNWzZ09JwuWP47PMjuI4rQFx+VD54MQEV3xbPli5ktMigAvwwa7P
+A0cODCIxp2upIkwkANXHF1iiJWzuBMncCwKZEzctd2ED1+xazXC4jd8+PAYsIQceMZxPazExVzp
G344BgzyhQlH50BeHuESZ954WJ4hoyFX+ZlwtqvZmR07Z2MH+DAhD8gL5MAvTNix2+Q3XD9xlBoo
0/ggDZt88MeO8jilw5STOb2DN+qFt5UyLX+6ytdWftYMsqcLP7QVlDuPUAa7quPeh3zy5+Lvqt+p
lC/yYMu/q367MPDpn1z9u00+pO/CzyUjjrBDv4P2gXI27YTP7pWorv7Llb6r/FzyqX/+R6BQHWPF
IyYxPihbSiWstKEh8UaK4m4a9UsvvSSKDo6ZwVFThvBCwovIHGtiwocVOxM22dUnPm/mKI2ZD6KX
s9EgNx/yHLCL8sfxVFDUoPChA4RSgLM50TGEzxiNih8kEHGDMwz561/OosTRNFB88MPRHob4K08U
EcgCGXAsiVE4EQZKIxQ9YM6jCMIL8vkSzurEeYCGRo8eLXlGeiBX+iZeMqUNfjgSzByJhWfgF07P
p/wQL1WCMpeotIEnXszAy5zFCsUSx/QYyjQ+Jp1k8qEMoHDiSCc+iFzO1s2N0gbemZY/v5dvr169
4j5gHnvssVj37t0N7M6rK38u/rb6nY7yNRlIVn/g56rfJn6yq0//ZPrrqP7d8I2Sz4WfiZ/siv4Y
7QPH8kHBxDMGDNCezbFyrv7Llb6t/JLJpG4FDwH/t2XBy5tV4rDSFg6IRg3Fx9CECRPkywjP5uxL
NAy8mMwPjY6Nk02UyKtvfChVaNho1Mkoyh+Hq0MWfI2FCV/qOHfSUFR8+EPJwqG4ib9PPvnERJeX
CM54S0Y4aByjZlA4zJdk+FxFjBDhjEBDH3/8schsnl1XKK/IIzp3EA47HzJkSBDNlb4JmBelzbf8
TBqpXKNeGsg3MDQEJTr8nGl8TLrJ5MPZpSgbM2qAsLiHmxlpc9WvTMtvU2ryQ/kCV+CFDwX0Aeec
c05s6tSpBnbn1ZY/RLbxd+Xfp3ydAv4bIFn9gZerfvvwh5Ib1T/Z+vcw7yj5bPiF4ye7N6NoeKeE
CYfT49xdkKv/sqXvKr9wmnpfcBEoxh2EUgIC4TPmwmeDmjNIWSmhtm3bBrG4g6AjjjgieI66yU18
2F4VKVIkipWcOZroX7p0aQmfuI0E7J9geB+mKP44i7Bo0aLhoHIP42tDSDdqNeBFF11EderUoays
LILtDxYsvPLKKyaq4AS7MUPhe+Nmu+KsV36RybEyCAf7rvDxMq70bbzhh7xt2LAhCLZy1Q7bvdyU
X8AgAzfhxQlGJpNMpvEx6SS78mHQ4sxTTIF3GEs4uupXpuXP7+XLHzrEo5T02Wefib0iKzHEI+40
b968pO0yAPrfG1v+EMTG39SlqP6NlQJJxVa+/4qR0sVWv30Y2/onxI/q33142/BL1m+GeZozlGG7
GSbYVBu7Vlf/ZUvfVX7hNGFHlzU3i9q1b0clSpQIe+l9PkegUCptaDRQOvCSgbF5mTJlgkPhYcSJ
TglXVOYtm7eI4SeMR2E4ziNQxKND0pEefPDBxHZyxFOjYpgPZcJGPvEhG/aAQvo49w6NGSsNDdn8
69evTzzyRHfddZcYsh900EH0xBNPENuh0K233iosbPERwIQz6SW7QoHj0TzCwg505JMmTZLDr/kL
V7Dbb7/9JBp/Qcq5fXgRAz90lpdccgnx1Kq8hKBk8jRfsiSsbv3796cmTZqIwgZD97333jsIj7Kz
pQ9/KLHAAQa9wBiEPKGzb9asGUEJx0IOyDts2DDJE8L6lF8gSB5veApK6iaMkUFGPnTWeCmgXqDe
Qh500ngGGXxxn0l8bPKhPbC9jqQ/ePBgkfOmm26CSCIfrj71K5Py5/fyBT4o+7Fjx8qHWe1aten8
C86X/oVHVAGhlWz5Q31x8bf1bzxa7yxfq3Dsaas/vvXblYatf0J7ierf0d5d8rnws8mGfql58+Z0
9913U8WKFalFixayKA5tZOLEifJucfVfrvRt5WfeTzjInGc/pB+88847iU2GbGKrX35DoOAOEuZN
cn5hy/QDl0NwvfHGG4WZGV6GH6YTYXBswhk7J9hvccML3OHfuXNnsVHwkcgWH0PkJr3wlVePCmuX
PwLxF7kYMZv4/LIXA3X4+cRHOBfxSs04Y3NM45gpWdj2YboO6eMKm0Dch6dIeQ8ksW2DzZ4xPnel
meiPqWnw5VVscV6u9DFtYrAJX3lbCuHDCpFM7xo/2DPiHotCQLbykwAp/vGeZknlA06wETRy8erX
GCt0wTPwCFOm8LHJh/QxfcOKWyCXWUwTnsINyxl1nyn583P5AgtMH6PNopxxhakGyt6XXPlz8XfV
71TL11Z/clO/bXhE9U8+/btNPqTpws8mF/zQXxk7T5QxTG0wpW1MYVz9lyt9V/lBBqQFu2KkP27c
ODgpFSAE9OxRrrl5IYzQYbQGBwmbYenc8Ek1vistfK1jRAn7DZmhd1ec3PpjFAhD/mbY38TH1yJG
4DDC5iJ+IRF3WrL03RU27A/8Vq1cRfXq1ws7y31u0s8R+V8HYId8hafHw2EzXX7htPJyn2l8bDJx
/yfljyn48FSULU6iX6blz6/liz4FdQ4jPsDApw0lYofnqPz58rfV73SUbzKZ0+0W1T+lko4vfq40
UD4YLUcbSSRb/+Wbvq38THoYcUvsu42fXvMvAqq05d+y2W0le/311wk/7FHECwKIt0yhESNG7Lb5
1YwpAoqAIqAIKALpQKBQ2rSlAzjlkXcEYPcE+7CaNWtS3759ZXPjvHPTmIqAIqAIKAKKQOFAQEfa
Ckc5ay4VAUVAEVAEFAFFoIAjUKiOsSrgZaXiKwKKgCKgCCgCikAhRkCVtkJc+Jp1RUARUAQUAUVA
ESg4CKjSVnDKSiVVBBQBRUARUAQUgUKMgCpthbjwNeuKgCKgCCgCioAiUHAQUKWt4JSVSqoIKAKK
gCKgCCgChRiB/wc5SV+kjq53+QAAAABJRU5ErkJgggA=

--_006_0E0AE22C4A7148B99DF4E716884FE130sedonasyscom_
Content-Type: image/png; name="image003.png"
Content-Description: image003.png
Content-Disposition: inline; filename="image003.png"; size=9344;
 creation-date="Thu, 04 Jun 2020 16:00:14 GMT";
 modification-date="Thu, 04 Jun 2020 16:00:14 GMT"
Content-ID: <image003.png@01D63AA2.6051B9D0>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAIQAAAAyCAYAAACd13PPAAAEDWlDQ1BJQ0MgUHJvZmlsZQAAOI2N
VV1oHFUUPrtzZyMkzlNsNIV0qD8NJQ2TVjShtLp/3d02bpZJNtoi6GT27s6Yyc44M7v9oU9FUHwx
6psUxL+3gCAo9Q/bPrQvlQol2tQgKD60+INQ6Ium65k7M5lpurHeZe58853vnnvuuWfvBei5qliW
kRQBFpquLRcy4nOHj4g9K5CEh6AXBqFXUR0rXalMAjZPC3e1W99Dwntf2dXd/p+tt0YdFSBxH2Kz
5qgLiI8B8KdVy3YBevqRHz/qWh72Yui3MUDEL3q44WPXw3M+fo1pZuQs4tOIBVVTaoiXEI/MxfhG
DPsxsNZfoE1q66ro5aJim3XdoLFw72H+n23BaIXzbcOnz5mfPoTvYVz7KzUl5+FRxEuqkp9G/Aji
a219thzg25abkRE/BpDc3pqvphHvRFys2weqvp+krbWKIX7nhDbzLOItiM8358pTwdirqpPFnMF2
xLc1WvLyOwTAibpbmvHHcvttU57y5+XqNZrLe3lE/Pq8eUj2fXKfOe3pfOjzhJYtB/yll5SDFcSD
iH+hRkH25+L+sdxKEAMZahrlSX8ukqMOWy/jXW2m6M9LDBc31B9LFuv6gVKg/0Szi3KAr1kGq1GM
jU/aLbnq6/lRxc4XfJ98hTargX++DbMJBSiYMIe9Ck1YAxFkKEAG3xbYaKmDDgYyFK0UGYpfoWYX
G+fAPPI6tJnNwb7ClP7IyF+D+bjOtCpkhz6CFrIa/I6sFtNl8auFXGMTP34sNwI/JhkgEtmDz14y
SfaRcTIBInmKPE32kxyyE2Tv+thKbEVePDfW/byMM1Kmm0XdObS7oGD/MypMXFPXrCwOtoYjyyn7
BV29/MZfsVzpLDdRtuIZnbpXzvlf+ev8MvYr/Gqk4H/kV/G3csdazLuyTMPsbFhzd1UabQbjFvDR
mcWJxR3zcfHkVw9GfpbJmeev9F08WW8uDkaslwX6avlWGU6NRKz0g/SHtCy9J30o/ca9zX3Kfc19
zn3BXQKRO8ud477hLnAfc1/G9mrzGlrfexZ5GLdn6ZZrrEohI2wVHhZywjbhUWEy8icMCGNCUdiB
lq3r+xafL549HQ5jH+an+1y+LlYBifuxAvRN/lVVVOlwlCkdVm9NOL5BE4wkQ2SMlDZU97hX86Ei
lU/lUmkQUztTE6mx1EEPh7OmdqBtAvv8HdWpbrJS6tJj3n0CWdM6busNzRV3S9KTYhqvNiqWmuro
iKgYhshMjmhTh9ptWhsF7970j/SbMrsPE1suR5z7DMC+P/Hs+y7ijrQAlhyAgccjbhjPygfeBTjz
hNqy28EdkUh8C+DU9+z2v/oyeH791OncxHOs5y2AtTc7nb/f73TWPkD/qwBnjX8BoJ98VVBg/m8A
ACAqSURBVHgB7ZxpkF5llcfPu/eaXpJ00lk7G1kZlrCHHWFYRAdGGHREv2Hph7EsP/jFKqusYcqx
9JtIiSVVOoCMrKKjWIIo5cAAAZJAErKvnU6nO71v7z7/37nvE96EhCGJJGbME27f7bnPcs7//M95
zr0vsbKKHVcpqXZOW/VjMZ0nrGRxK/oW87vUDLUSOqYWheuhhOsJVYzrYowH2Pwk1Dq7P1USSB5/
R5Hy31d1aIHrQAJtAo7YIQCgW65Tg7vvQ8NPonqVm2XtYxyfLadFArHjZwjUHimXEUdcEJl1OVyX
VsvSaqR8gQEthxNXvP+JcFFRPgAKYGEfmOO0SOVvuNPjBgTKCq6gossKu+tOuai77JFoqMmhiKgU
yIinCwKD6uIfaAQK0Z+SYFDwvVlS+2TEHdw8W06RBIKWPnJ36C8AITwUxQS4CFSIkmEQACE7J0SJ
aY/SueQHtMAJT2pzP+E3dU6JHE90fPbvqZTAcQOCwWHLUYkUxxncUHKkRJCJ/qquDriPurkGLhLl
lDDDmZjCn9ROd2ICUNxr8Jf7Z8uplsAxXUZYfMSOjPBwCyWtMuJ4eaCRtIJ0l9cZimf9kdXBhA4m
JvJWKJZc5YVyyWpqMtZcH7cm1a9RPdAY0136KhXLlkxEK5WS0JMQck4nJBjTB+au8R6tlEqKqlQ/
ofGf6eVDGYKJVpd4HLutUL120qEVJYOsKvWr6o7OUdvbO2w9A+PWNzRhg0OjlssXLVabsnJNwtKi
i5a6pLVNStnc5kab0dykrdaaMyhfjYk14oQWaiuWVqOnERFHAgJZABA27rEhD8pHBY5X/iv/c0yG
COMuFnEG4gLA4MLAogsWiycFhIQNFsq2df+4vb2107bu7bOugyPWN5qzcjxtsVRCahYHpAScVN6K
2ayVJiYslp2wyZmUzWyeZEtntdvVFyy0xTPqLa2ukmAQILhvoefTX1B+AEQAQWCFAAbOYYhwfvpH
fWIjOCYgmCAlCIBjBJMTn5fE52My6B0HRm31xl22VmDY0zdh+USt3EdGC4oaS2VqLJ6UOxGgiqUJ
uZERGx9XnfGsZUdH8SfWIHZpKOTsinMX2z/fcoUtac9Ymm6hHgCRPI0UwYRVAhtwHGQRwBHuA4Iz
HQjMhXJMl8GkgwBgCSbMeSkRsy7FB6u399nqdVts855uGy4kLDmpzXIKFstxtqSNFgoKNSYkURaT
OctPjFt/b69lc2VLpWutYVKTZWrSNty7z97YtM0uv2CpzWufbmnccJFgU6Aw/MbpKYEV6D3MnWOu
UwIAwjky+n8dQyRl3dUlLkCUNOl9AxP2izVd9saWLusfGbdE3TQrp+vkOnRfy8tESv6hVFSAWbZ0
JmkpPZcbHLbhzr0WL8StobbJYplGgSdhA+NFS6YaLBsbtaKQQCxSo5VHKkVoenj/1WM5FccoPCi9
2jCycnujYrhcLmf19fXW3NzswwkGFJ45FWP8OPpIuiHS8pHsrDiBQgxQ0ooir/u7ekftTxs6bfXm
PjuQlb/MtFgpVWdZ+X7iCYVZltCx7lgmmbBMrGATwwM22LPfiuM5ywg4GbmbslYW+VLenyASWbJg
js2f3SLwiBx0N+UJLtU7YkxHnLq1HlUBWLEUeqhg1JxGxv3BuVYqBmsPbQYgcDswxs6dO+273/2u
ZTIZO//88+2Tn/ykzZ49W91FAeaRbVSa/sCOeqEfNX5ovNXXq48/0MDHdCGpaEmDqUymIkNBQCkC
0b0uy15tXMHSrnGzJ9/cb6+9t9+yqWYxAdyueCKf18TEDHInDh61FysVdK6cY2HEin1dlh/uV7Ky
1nKFotUUxgWUcWvU0rU2UbLzl82zW6690OY0kZs09SaGUVtFtVOWu0HQJe0pycoxgkrouCDXEtee
lBhCjQE2LXOx1mRarkvxDkJ3OqdNMZwuOLXDdnGWuapLO+l02vKaCyUc4wLcTVJHLpDru3btsid+
8QstkZPW13vQ7rn7n7xPF530mhODeHCpsZQ0Fp6HXRkHeCyrLa7lcllLJlNet5AnSI+Cdp6vqatF
tJabyHqfjNnBozkyXgr1acuf03VeFcRI+pxkiXhZnZfRBiMObeIyPOOYsmHJ8X82dtvaPQM2kmjU
BOXbva5u6AAosOUk2JSei8vCi9kRi5fGrDw2aBP9B9xNpBR/JPNiCk1g4ex2u/T8JbZyyWybO63R
6tRSUULPyd0kNZaEhAUi6QaBoHZEAUAQLcFqKiGl80/tAYwAAMDgD1YJkDYSBLnqg344ByBF9YcC
QwwQjnGZtItrSMkNAgbOKc2Tmv0aynFFqa2y2irpfqamRvVKAoZyMIW8lFt36DlXop6nzUw642NB
kQ4ajQEw0A8AoW1kyTgBL3vqwZrRXAUsPcOYitoA3V+iRIBQW7xWeJ+i1bF8vKYr/x63zbv77OXX
1ln3gOKClpkSHg9wN3oGZtADVl9XY6PDQ1avVhvE/50bN9tI1w6b1tpk09oabXJLsy2cP8cWz59t
58xpselNtVYn5Y/LnXT29dj4UL8VsmOyvpg1T26zhqZWq62pleKjYbpCEIy2hCyQkpfQEVBcdbAQ
hJnTCqa2ttYZo4T1VQmLMXMel0sbHRn1Z4KyUQLK8vsSPsWtXfUBDGBqaWmxCS2b05ko4AU4tIly
XCk6AbRxjQUgJehbY81lc554C0ygSs5iALcEQCU/2sqr/7RAxXmsAtSkxprXPKJ5CwRivshQKnN5
X3E+5pP5E0n6iBboTHZjRU2sW/Tw1qZd1j2oALJ+mjKSGhAC9Wd8WH4UB6WyjKRijySIzo9ag7JM
y/9uiV1x4TJbunC+dcxstjoJMpOOm0hRLqRsnZ37rKe7y0b6eySYnBQqhWi6NT191tQ61ebMmWNT
W6dIPlgCKxYpXYqDslFSSkyCzHds226vv/GGde7d60qdPHmy+/aZM2fa8nNXuMUhUFzR2jVrbPXq
1UaAmFV/8+fPt+XLl9vixYsjpbgblGWq7vr16+3111/3/gHHjh07rE5WDzhQIHVgq2QqaRNj47Zm
7VrbuHGj9R444H0RX5x77rm2fMUKBw3CgkmefuopGxkZsSuuuMLaZ8ywP770ku3V2A/ouZmzZtl1
115rHR0dPhfT6m2gv982bdpkvVqpTQjwAwMDHscsXLjQVqj9ltYW18PJ/qkAAsW6J46YVmdFWQhR
/+bOXlu/Y59WAQ0Wr2m0US0bM7JgzSl6Al+Da5Gwx0aGrV4Kj4/3WzI3Yrdev8puumSJzW+vdwAo
6aFn5P/Vbk6I79y9y/bu3ilBjqhDqFtjgAYl5D5NeGh0wi0UlqiHemUZMj0HQ0lUPzY2Zo2NjbZ1
yxa7/1/vt5dfftn6JTgsnnuwxE033WTf+ta3bOE5i6xrX5c99KMf2W9/+1vbtm2bK5W4g/pXXnml
ffnLX7brrrvOFT00NGSPPfaYb9SFOXICT0tTs1LwNcZ9CkAFDMQTP/3pT+0pKfqdd97xNrlP3XPO
Oce++tWv2m0KQGGOzVLst7/9bdu9e7fde++91tbWZg8++KCYcjxyGQLbrbfeat///vdtSttU2751
m/3gBz+wP/7pT7ZbMQxgnDRpkgMawDPHr3/96zZ1WhtdnlQR38m8IgKqNBT5atYYg3LaG5Rn6Owf
t9jkaUouyX/LIsu+ChDSefRQkfXGpXAFiymxxKI5M+yGy8+1xW1pS0mRabkY6BDKxNI6d223vTt3
2cjoiPISKbUlWpVwE7L8strJ6BOqCQmos7PTWppbrE7KTfL+RHVgCuDrFqrzl176oz333HNuuQgK
q8SC9u3b53uuYVXP/fKXDoicGABFzZBl5uRy6OOFF16whoYGmzdvns2dO9fPf/zjHzsjABiWlwSf
uNasgj365joMwZiefvppVxr90h+uBQZgibpGjPS9733PpkyZYldcucpjGQJY2mDcyAMlNzU1OcA4
fkmMwZjuuvsunxdtwDyNGmPr5FYPqmE4D3KfeMKuuuoqu+W2Wz3OOKSSEzgQQ1S0KiFHwFB0LOUQ
Lm7ZPWCb9vRZWbmDXEwZAthACKcqYEA40ePYvaJzchC5Mb3NLNoCAWJGa9pTS0k9oDWB1SpdTRC3
e88u27Jls43r5Vc8mXb3VBIw5UG8D9rKKIedVC4bt9B9oNumTW2zOikxLwW4X8aPShEwAbTOMYr4
9Kc/bfd+4Qt+vnXrVgdS2/Rp9uYbq92CR1V/0aJF9gXVueGGG+xgf5/9qMIaMMzbb79tra2t9tBD
D9mePXucZS677DK3cBQG1T/8k4c1QslAYwEUuwTsxx9/3NkJINxxxx121113Oas88MADzlybN292
9jj/ggsUF9U4GAAEwFghd/KNb3zDAfSTn/zE/vCHPzgAcVW33XabTZ/R7kzCOG6++WYHDmzCGAEN
IKTuTTf//ckDwhWryUW8EFE6awbgcWBwzAbGxBVyF3lVLAsMJSkbhbEFLHFIQUBJoQTqr0vLgmTQ
vlbgbZVXjlv/QJ91dnXLMqVYpbfLWrL6RzECYVn0TbxKdFsoR8EdQmPyWCcFdwJ4CDSxcqi8qWmS
+9ODBw86K/Rpf+HKlbZs+TLFJUDbbK18OxSNpcMEt3/qU84ko2OjtmDBAr/O81h0T0+P9fX1udKm
TZtm99xzj1199dXeTpdY58EfPuj3ACGAgGGILchNAKbPfe5zduFFK70+MQGABVzU6VXbxBAU5AXl
33333Xbl1VdZPqvgWm298sor7g5QdJ2SX8yBOjzF8h5GgeWIfQApYwZY1cGzd3ACf/xdEj7dC6Yv
xaCTUfU+MJ630XzZsuIRPnoiBhCbq0QT8mcAj5OMAKP7ZSmTASelXOEiwoyql5TOnsjlbde+/ba/
r1+Ao47YQQ+jYDbWvkAyesgbdYZgOQZTUGib4JC+WIYh1EXy0QwJ5fz+97+3NxRcXnrppXbLLbfY
qlWrbMasma5g2ATaJrn0b/ffHwlSQAMAtM9Gm4ODgzY8POz329vbbaXARaHPGsUz1AOM9M01gMQz
xCzTp0+3jo4OuRWtRLS0JHkFawBGQEFfzTpHebRDDLRkyRJvn1hk6tSp3iZtcx+3WS8AMx7Yi/hk
i2Im7tMmdXAxbHrQ2zmZP8mIIaREUbDUpi1SxLASUf3DORunMykXgZNscn15XeorUYJy/Ej3dZMW
CuJ+No2Vi5q84gLV6xsatgM9B/U+Q+5Dwiti9WII1iwATU8IdOpLR8Klj4SJYw0wAf1EeQiC0mgZ
R8QP9d/3pfvsySefdIFjWb/61a/s1VdftS9+8Yv2LwroAIuv96VwWOfXv/61K4XlJ0qloEzYA3bA
4hgjCuNZCkrUfw5KjvHhPj6NjTapRxuUdEpve8Wo9MkYYQ8seVxAaa70F5TOnkJ8BRtGrCc3rXZZ
3hIL/ft3vmO/+c1vfJXBeAE2YGBjeQszxYmxTrIcetscNYVgovzCRLZgIxp8njWuBhpnJVFxF5Gq
pLZKEOGgUL24lMtn+Fm5gwkpHdD6kkKCgR16e/skFGUqFZimRfkjE6OK0HEqgDACog68xIKQJHgy
fggHqkUh7FlukvihEHR+7Wtf82j7d7/7nftT4ofu7m575pln7AL5bWcWzQOWuOiiiwSgL7kg4wI7
CkHBKPW8886zt956y+8BCsCFIkNh2Up9lAIAaBe2YI8Vd3V1+VhZvVAcBLg8CYOAkODYpVzpkzZQ
aEiqARw2+qZNDIC45dFHHzWW0p/4xCc8npghV/Os5vaEAkqCV545QoRhyMe1T0a2EZ7hLLoC8pg4
CZeYUodFmTBLPdwGC0en9vAYIwEMcjkkoPlWwtEaEYvXyunN5/DooFyEomuBoVTUXo95+gtFh4EQ
b+A6ULyexMIQPmMhhS1oOh3XiI4RJIXMYI3ikVVXXWkrL77INq7fYPfLJRBwsQxFqbO0toe6Wcej
pIvkBljShUIfgIISrB2FQPEEhOQoAOXWLVu9X+RDPepA87RNXwDivffe80Awq9f969atc6AwflYv
xCSwBOc8G+ZGz6zCKLQNgHh5tkdugfY4ByTXXnut3X777a6llxR8Updxc9/1JXmdTJGqUS3a0JCU
AHEVuTII7HRdQPA+BAbohBRtUUtCViIlBRbsy9p7Ll33GA5Lxpp0TF9I0SrWpDeeGnBuAspgwrBQ
XoKN0sNcczx48KkT7X1EdKzJBrAAxqTYpiBqLCrQiqsDKBbF4wKuu+Zat/CgdFLVtXovAHUvW7bM
SOLAGgR33xEFf0qBJRE8fvnFF1/0eIOAEOWjYOri98kv4D6IFX72Hz/zcRfUPwpASW1SMoEpLmp/
93574Ic/dHfCUpdVw/79+125CxYttCkCD74fJbppaYxkW1m9peQeQiod5qLtRq2cAEaUEi97DgUg
de3vsl9qGY17m8RylX/o6ySLFn0aDO2U5DQABLiQHsqy4qyjTi9ryvKV2ZhN0vITV5CMyaeLBcqK
DQgOWSloNP6JXKqQtfpEwVobpQy1wwIWsOTlRrICDHXJNZB/92yC7nnxXSVPxnCKyvfXKBCVleFe
uE24y6Q5P5THV5svvPiCPfLYo/Kx/yVfOtkDPNrM6gUS1Eomb9Hic+zmW2+xt9eu8dzDz//zcXvy
6aec9hE8qwGYg0CUlQhxCb4bq3/zzTftvvvucwDQf73iCuoPKRHXN9Bvc+bOsX+48w7bsm2rg+aV
V1+xt95+65Clk+sgML1RCaSMvit1AEjhLIHHxpVAU4wRCi6J+jEttzCLZqX7l61Y7noZV8p8zbq1
9u6G9W4IBLwtyklgAAMKagEo5WjACOwX+jnWXqxdhSo3y6hqnbTZUAdjaFEoS40JyeN5lnxKxui1
9qGVgWrEcBUlUVxKk+kfsOlzm23+9CYlo2gLBoJNIgRrF/WI5Tu7VPVPdYqec7CICVhmATZ/L1AJ
mjybSUNUVTvLtI5fefHFtmnDRqds4gSSTp/5zGc8H9DR0eF1Q26A4IzUNc/ie8lf3Hjjje6fg7v4
kmIMgsFHHnnEmQJ2mDdvnn3+8593wDz88MO+h7KRz2c/+1kHF4EtbZPJREEsC1nxfPOb3/QUNtRO
HzOkTF6y0SbBKQVFwkSsOgAnsQn1GdtXvvIVe/bZZ51tuE5+4s4777Tnn3/er3sDf4E/Ma33lRiU
ckgAKBMJdeVkqPsEtp+/tN6ef3ODJZpnK4tYr/cMKbfMYkwBHjGFqCSul2CAKqXP5OrLE5YaO2C3
Xb7C/nGV1shqMqPMJZ5/X/+QrZfCWJ4F33lM1DIUWUltXdqyej8AI1x2yaXWNnmKbkTxBMLDJUCV
WOpmBZG9+7s9I4nFQ7MkoKBy+kGwBHAIeqeWnbgNFEFcwMoCl0KGkzrBFzNWcgiwBG0CkAsvvNDH
j18HCJyHWIY6tEtAS9wCWGgTBRNnhDHgSrZv3+6yYJzEFrASc8La6ZPrgInxc52xEsvgxuiP4JeV
Bf0BVurj6pDt0coxZX1E5Viu7PlHfdhSMV1RekEJhAOq+Oyrm+yZ/15nOX0VlUtOFUNkLKFgriDF
x/TLK15zJ8QO6bKEVRwzG+6xxWKGu2+8xC6YWRd9aq860GDP8JiobqMLCkEGejvqQCuASCuzRQ6i
qb7RLhUDNDdOsqLegQAELxJUXktXBMRn/kATYYfonzoIE8VQ2MMIwarDdYTIOKiL0gJgw542sdxQ
qEd9ng/jZ07Uo32uBVDxDPXDfDmnLiU8G8YYxse90AcgY0z0DyhCIBsYhLqMkzq0G9rkenU51vXq
OhzHPQaQBUuW2hCc0smyaX430Tap1lpqM1bWoMqi97zAklfskI9LAdC9Jp4UGDLFCaspjlh7Q9JW
Lp5jHVPrpJxKkzpK6rsFBMIkw6bbxy7CpgdVmiT1QybSl2YaqH8foOuavbdRUMDr7YotAAOT5zwo
PAAwCCUomnPcC0KnPmNE4KEeQuY6ygj32cMqtE07tM01ClRO4T7g4DobyqNN2g/HMAgKpo/QFsCm
Dhtt8CzX6J8xhnoBINwP7VaP2wdxgn/IB3nxnALhvF5Zx/RyCnton1Rv0+r1PUJegaViBFwDS0uJ
Tp5FCZFSVi5B1qMvqtPjfXaxwLDqvLnWojyOLwjVXF6/y6APfp/BJJkMEw6TiXo/8m8kCNLUlCbR
aaZC5awYeJZkFe0gMDk8jYeonDFG96kTgMAxAmNDsEHoXCd+AETVBSGj7FCohzJCe4GBUC4rCPIA
rHbYAAJjwr1wn3Pq40Y45zpLUbKOPBf6gvbZACj9ICfu4ULoI/TNCiWAjfvEKlwjB8I4T7YoT4cl
658EGjGEh3NSaMlmtTbb4pnTbeeB7aLqMWuqq7f+sSG9pBLaJ4atIRO3VHbY0rkhW6XvHq6/eKFN
rxMjVEZF6lovHfQlVdHf9eOLgxUxQbaA+iB0Jsm0mBvHLLua9crZFc1Y9QyBJokr/yCFazyjvlA4
bVaXcO511Giw6nCdfrnHVg0C2qA9CnXCvfAcCvjzn//sCgbofE+BYoj8iQl4J8FKhGQS8QJKJKdB
HoJ7LGeJXfhWgtUMbzKJAwDr5Zdf7nELL6yCEQEywAuzwBgXy4Vy/O677/r4eIVODIHLCmNk7Mzr
eIqLj0dYC4geKs+ScCjbZCn3kqUL7Nw57ZYaPWixkW5rTer3FIUhq5sYsFJfp7UqnX3leUvs5quW
W7t+hUULsAN7vqHsHRi0t9a8Yxs2bjhkpQyYgWIFYfCBNRzlAgM5fNgAgWJVFL4lCMWfq0zWFarx
h7ZCHfZ+r6rekXU+isCObIMxAgiUjIJRIEEhDMFHLswlMAesQLKK4HDp0qWH5kN98iKwBErlRRV1
AAcfwmA8WD/XCUhhD9LoJNgILLnPq2/cDkAggIaJmF/1eF2e1QL5P46T/J9bKMQDrAZkJ9pkEZp0
neS/bFadjV20VK5ii23TSiEnFxFTrmF6m97L1zfbivnT7eIls2yK3CfES+LqoALIQQ14ryxh8+Yt
tnPPbv94gzd7TCAMMgwcluA4WCTHuey4XIV+6qflI+leirOYH53+P1g342VFwL6jo8MV/tprrzkz
ME8sHsUDaBgBy2Y+MAiWzzlswWomuAwSYhgKhedRNOACBKxYkB3nKJ8xACA22IP6yO5kCpklSfp9
QMjbChLyvwogFbpbvazysgWN1j7tfNvaM2q9eiXeIEczVd9DtrXU2NTGhDNCb69+wnfwgD4d6/LP
x4aGokkeONCjlYl+ticwUFA+k0FgIeJnkggVdCMojUbJn3qbOWOmTVGiKcpjEP4GBvOmTssfrJ84
BAXwlRVugCUo82F5yZzIQwQGoN7111/vVs9rbRJUtMF8UR6uADcK0wAGXBPXYBruIxv21GcLYIFZ
YBye4+0nWdJrrrnGwYccq43ueASllKGqV+InGAJ8wBM4ZU8ZC6xKGNqCxri1ibLypUar1W3iAx4b
1Y9ttu/eY7vEAj093TY0PKicvKJnRf4TyiU06vebUB6TJmACDAEQCLaawjknM8kXVLNmzfA3hwkB
k8kRYOIy+He6C4qBzgE3Lg1XEYI6QEEqnTowA0Eh46ceMQYFQFAfMAEgQIBrIf6gXSydtinskQsb
oKMuAKENQME5bz5pizpc5/6JlkrUFD2O9wigCK7E70yIMXShoUYWqvcMCd4jCMXD+kXW1s1bbdPW
bdanr63Tmlxa3wskpPSRkSHlCKL3/ZOnTHXLZ7AAAN+LFTBZcvdByZyTkgZAc+fM1dvBRnEFbKUa
CMIXHR5tnuh8T/q5AGBAgGUCctigo6PDQcDYOSfIoy6KJnkE83GN+zyLLAgk+V6CpBhJJ5RKHViF
eAEgASyOYVgMiTYBAKDBDe1Uko1j3AkuiPuBWU5ksrFyXr1Kz7y/wHMBCh1aku/ZOHG20AFJbt0g
gxjXZHho86bN9va6d/QaO6cXTSSHtByUgqG1wZFBTyrxccpM+U2CxJQmxAphXEKsE3D4HgJ3EH1p
LfrUK21yDgvmL5CL4k0kY1A8oxUQY3Ia1KXDLKBiDAz1xO1CDx9HYRzMEb+P1WLZWCqFQI+gkK+p
yTSifKweRcEGKBcwEDfQBucokiCRtmDSEAsAJtqgP46pRz8YVOiPMSAPspYYWXVxeenCYfKqrnCU
Y71AVG+VEg4OE+zRJK1r/QcH7bXX3nBX0TCpUS+u9HpWE8zptfaohED2AaRPnjpFk8zIfeiLGxVP
LqlLXlelhf6SXnrx66+6mjoBp93mzJ5jTXouLCkrQzsjdiwD+RgWS+abC/awXlDemTCJkDLwsR4G
hDD6o12sXIPqmTDpZX76jxLDz9caGxv8UzG+W4i+oxDzuBGJaQQCCs8WBIapLa02v2OetbdNcyEG
FxKGcKbsiRmIIQBCsNYqezsjpnEYQ3yUETPBQk5Rcipuu3d26nXyWqdOGIGPcJWH9J+pNeuHI2l9
iwC9ZfVxjPDiluI+Tt9DuBsQjc6ZqSWrVhJtCrr47Awv4eVoQPwoAzyNdYLyqyka0HPOvM+EcoKA
UNpaX1UX9Dq8W8vKLq2Lew722rC+YPZfV0n7/L6SxFL45CyutyZ8PYxwGhQEzdC3h5ObW22ywFCj
D2U8x1ASGvBgCO8MBET1KgDln0muIoD1uAHhD0pnsAQvoPSuS9Rf1v9PSvl8fcCRVTQ9oqBxWD/A
IabAMuJ6Y5IQOJqUSCGuqK9vsHoFlcQQhwrM4FslMaL6ZxooAkOEfTVTVB8fmvNf4cEJAULvt9yS
mWRBYPCPXvleToWVhscGokr/VbJXZaWgIFJRMP+nOYz/kNA4gxV8q4BAdb0SFc+gwuqBEtzDmeYu
GPsJAYIHQ0GPXo5QXjB4LoetUjPaheeqL1ZfO+pD1ZXPHn8cEqji7BNrHmMO5Uh9cr3qdqgmNnj/
8LCjUPlY9w+rfPbk45DASQOielBBn+HaYecfpuRQkTrhOOxDY2f3p0QCf1FAHNPymcqHKDhgBbZx
THxI3VMilb/hTk774jiAAR2E47D/G9bLaZv6/wKfbJa0ghDEsgAAAABJRU5ErkJgggAAAAA=

--_006_0E0AE22C4A7148B99DF4E716884FE130sedonasyscom_--


From nobody Sat Jun  6 12:03:31 2020
Return-Path: <010001728b042c6f-26b300e2-e7d9-47c3-9963-8603b17f9b2e-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137C23A0A6E for <netconf@ietfa.amsl.com>; Sat,  6 Jun 2020 12:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 sXVWgLd5a-PN for <netconf@ietfa.amsl.com>; Sat,  6 Jun 2020 12:03:27 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750403A0A52 for <netconf@ietf.org>; Sat,  6 Jun 2020 12:03:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1591470206; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=DOWWSwqxCxESEGBTretsaRVcn2oOpYuyIrXCFju/HZA=; b=HfaoVFvcmOzr49bpona6OtOgNZcVqcgjO3d3i3xnjU3WRrHu+i9gDCDQS0yPatcE peZ5hL1J0VnUmGs1ejoXh2lA/CAwQ2ljVdvlTyfDCEG+pOteMi6Z4QHjSVu+LeswpBV uzJdazNY+Yw4CGchNXIxGTTbk2UqTYtOf1G7zn4w=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <010001728b042c6f-26b300e2-e7d9-47c3-9963-8603b17f9b2e-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AE44527C-B7A8-4D99-9A58-B5E70F2C28A7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sat, 6 Jun 2020 19:03:26 +0000
In-Reply-To: <0E0AE22C-4A71-48B9-9DF4-E716884FE130@sedonasys.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: Anton Snitser <antons@sedonasys.com>
References: <0E0AE22C-4A71-48B9-9DF4-E716884FE130@sedonasys.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.06-54.240.8.88
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/-tSTCFv8_JtAGtOmI95qWe2CFss>
Subject: Re: [netconf] RESTCONF PUT method on list URI/Resources
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jun 2020 19:03:29 -0000

--Apple-Mail=_AE44527C-B7A8-4D99-9A58-B5E70F2C28A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



Hi Anton,

> On Jun 4, 2020, at 12:00 PM, Anton Snitser <antons@sedonasys.com> =
wrote:
>=20
> Hello everyone,
> =20
> I am inquiring about the validity of the PUT method on a list resource

Currently, a list is not itself a data resource.  It=E2=80=99s tempting, =
I know, but it=E2=80=99s per RFC 8040...


> As per RFC 8040
> =20
> List entries are data resources but not list themselves =E2=80=93 not =
sure as not explicitly mentioned.
> <image001.png>
> PUT is used to create/replace the target =E2=80=9Cdata resource=E2=80=9D=

> <image002.png>
> =20
> So would it be a valid implementation to allow PUT method on a list =
resource? /restconf/data/module:top-level-cont/list

No, that would be invalid API.


> Also, generally speaking is it fair to assume if not explicitly =
denied/mandated it is up to the implementation?

RFCs intend to be fully-specified, so as to ensure interoperability.   =
If you find something unclear, it is best to ping the list here; not =
only will you get clarification, but we may find the need to file an =
errata if warranted.

K.

> =20
> Thanks,
> Best regards
> =20
> =20
> <image003.png>
> Anton Snizar | Systems Engineer=E2=80=A8>=20
> m: +972-504042744
> e: antons@sedonasys.com <mailto:antons@sedonasys.com>
> w: sedonasys.com <https://sedonasys.com/>
> l: Linkedin <http://linkedin.com/in/anton-snizar-4aa57646/>
> =20
> _______________________________________________
> netconf mailing list
> netconf@ietf.org <mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf =
<https://www.ietf.org/mailman/listinfo/netconf>

--Apple-Mail=_AE44527C-B7A8-4D99-9A58-B5E70F2C28A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""></div><div>Hi Anton,</div><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Jun =
4, 2020, at 12:00 PM, Anton Snitser &lt;<a =
href=3D"mailto:antons@sedonasys.com" =
class=3D"">antons@sedonasys.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D"WordSection1" style=3D"page: WordSection1; caret-color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;"><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 11pt;" class=3D"">Hello everyone,<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 11pt;" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 11pt;" class=3D"">I am inquiring =
about the validity of the PUT method on a list =
resource</span></div></div></div></blockquote><div><br =
class=3D""></div>Currently, a list is not itself a data resource. =
&nbsp;It=E2=80=99s tempting, I know, but it=E2=80=99s per RFC =
8040...</div><div><br class=3D""></div><div><span style=3D"font-family: =
Calibri, sans-serif; font-size: 11pt;" class=3D""><br =
class=3D""></span></div><div><blockquote type=3D"cite" class=3D""><div =
class=3D"WordSection1" style=3D"page: WordSection1; caret-color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none;"><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 11pt;" class=3D"">As per RFC 8040<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 11pt;" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><ul type=3D"disc" =
style=3D"margin-bottom: 0cm; margin-top: 0cm;" class=3D""><li =
class=3D"MsoListParagraph" style=3D"margin: 0cm 0cm 0.0001pt -18pt; =
font-size: 12pt; font-family: Calibri, sans-serif;"><span =
style=3D"font-size: 11pt;" class=3D"">List entries are data resources =
but not list themselves =E2=80=93 not sure as not explicitly =
mentioned.<o:p class=3D""></o:p></span></li></ul><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 11pt;" class=3D""><span =
id=3D"cid:image001.png@01D63AA2.6051B9D0">&lt;image001.png&gt;</span><o:p =
class=3D""></o:p></span></div><ul type=3D"disc" style=3D"margin-bottom: =
0cm; margin-top: 0cm;" class=3D""><li class=3D"MsoListParagraph" =
style=3D"margin: 0cm 0cm 0.0001pt -18pt; font-size: 12pt; font-family: =
Calibri, sans-serif;"><span style=3D"font-size: 11pt;" class=3D"">PUT is =
used to create/replace the target =E2=80=9Cdata resource=E2=80=9D<o:p =
class=3D""></o:p></span></li></ul><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 11pt;" class=3D""><span =
id=3D"cid:image002.png@01D63AA2.6051B9D0">&lt;image002.png&gt;</span><o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 11pt;" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 11pt;" class=3D"">So would it be a =
valid implementation to allow PUT method on a list resource? =
/restconf/data/module:top-level-cont/list</span></div></div></blockquote><=
div><br class=3D""></div><div>No, that would be invalid =
API.</div><div><br class=3D""></div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"WordSection1" style=3D"page: =
WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 14px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: =
none;"><div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; =
font-family: Calibri, sans-serif;" class=3D""><span style=3D"font-size: =
11pt;" class=3D""><o:p class=3D""></o:p></span></div><div style=3D"margin:=
 0cm 0cm 0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 11pt;" class=3D"">Also, generally =
speaking is it fair to assume if not explicitly denied/mandated it is up =
to the implementation?</span></div></div></blockquote><div><br =
class=3D""></div><div>RFCs intend to be fully-specified, so as to ensure =
interoperability. &nbsp; If you find something unclear, it is best to =
ping the list here; not only will you get clarification, but we may find =
the need to file an errata if warranted.</div><div><br =
class=3D""></div><div>K.</div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D"WordSection1" style=3D"page: WordSection1; =
caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;"><div =
style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: =
Calibri, sans-serif;" class=3D""><span style=3D"font-size: 11pt;" =
class=3D""><o:p class=3D""></o:p></span></div><div style=3D"margin: 0cm =
0cm 0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 11pt;" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 11pt;" class=3D"">Thanks,<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 11pt;" class=3D"">Best regards<o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 11pt;" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 11pt;" class=3D""><o:p =
class=3D"">&nbsp;</o:p></span></div><div style=3D"margin: 0cm 0cm =
0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 11pt;" class=3D""><span =
id=3D"cid:image003.png@01D63AA2.6051B9D0">&lt;image003.png&gt;</span><o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: Calibri, sans-serif;" class=3D""><b =
class=3D""><span style=3D"font-size: 11pt;" class=3D"">Anton Snizar<span =
class=3D"Apple-converted-space">&nbsp;</span></span></b><span =
style=3D"font-size: 11pt;" class=3D"">|<b class=3D""><span =
class=3D"Apple-converted-space">&nbsp;</span>Systems =
Engineer</b></span><span style=3D"font-size: 11pt; font-family: &quot;MS =
Mincho&quot;;" class=3D"">=E2=80=A8</span><span style=3D"font-size: =
11pt;" class=3D""><o:p class=3D""></o:p></span></div><div style=3D"margin:=
 0cm 0cm 0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 11pt;" class=3D"">m: =
+972-504042744<o:p class=3D""></o:p></span></div><div style=3D"margin: =
0cm 0cm 0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" =
class=3D""><span style=3D"font-size: 11pt;" class=3D"">e:<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:antons@sedonasys.com" style=3D"color: rgb(149, 79, 114); =
text-decoration: underline;" class=3D""><span style=3D"color: rgb(5, 99, =
193);" class=3D"">antons@sedonasys.com</span></a><o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 11pt;" class=3D"">w:<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"https://sedonasys.com/" style=3D"color: rgb(149, 79, 114); =
text-decoration: underline;" class=3D""><span style=3D"color: rgb(5, 99, =
193);" class=3D"">sedonasys.com</span></a><o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: Calibri, sans-serif;" class=3D""><span =
style=3D"font-size: 11pt;" class=3D"">l:<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"http://linkedin.com/in/anton-snizar-4aa57646/" style=3D"color: =
rgb(149, 79, 114); text-decoration: underline;" class=3D""><span =
style=3D"color: rgb(5, 99, 193);" class=3D"">Linkedin</span></a><o:p =
class=3D""></o:p></span></div><div style=3D"margin: 0cm 0cm 0.0001pt; =
font-size: 12pt; font-family: Calibri, sans-serif;" class=3D""><o:p =
class=3D"">&nbsp;</o:p></div></div><span style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 14px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
text-decoration: none; float: none; display: inline !important;" =
class=3D"">_______________________________________________</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
14px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
14px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">netconf mailing list</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
14px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><a =
href=3D"mailto:netconf@ietf.org" style=3D"color: rgb(149, 79, 114); =
text-decoration: underline; font-family: Helvetica; font-size: 14px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;" class=3D"">netconf@ietf.org</a><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
14px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><a =
href=3D"https://www.ietf.org/mailman/listinfo/netconf" style=3D"color: =
rgb(149, 79, 114); text-decoration: underline; font-family: Helvetica; =
font-size: 14px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;" =
class=3D"">https://www.ietf.org/mailman/listinfo/netconf</a></blockquote><=
/div><br class=3D""></body></html>=

--Apple-Mail=_AE44527C-B7A8-4D99-9A58-B5E70F2C28A7--


From nobody Mon Jun  8 08:39:13 2020
Return-Path: <jladouce@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A973A0909 for <netconf@ietfa.amsl.com>; Mon,  8 Jun 2020 08:39:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level: 
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JvtogEyX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Iz0Wx+wR
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1BHg9ZfISfA for <netconf@ietfa.amsl.com>; Mon,  8 Jun 2020 08:39:08 -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 3E7BC3A07B0 for <netconf@ietf.org>; Mon,  8 Jun 2020 08:39:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4258; q=dns/txt; s=iport; t=1591630748; x=1592840348; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=BnjzKsXZdfyMfs0lE4//ds3zuLj2eFvOoMXEC9OvGHY=; b=JvtogEyXciK1XeFfWnfR17XZjfTvUjuYSj1XDMuzoLtsSZp8z8ujNjtO WD4gVIJbrCALlnfsZzpPcjeGFjPLj6WsXYzMxBjlqJADPcE17k/dMU+2u AHDog9fNQZOskqTlIn/Zo+NxaBAKUfC2OQ5StiDUXKt0Wkfti51c9Ow8A g=;
IronPort-PHdr: =?us-ascii?q?9a23=3AXwAeExRL2+MB/SducWptmHYyodpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9mJ5/dNkeGQsq38VyoH+5nS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh4TsbAB?= =?us-ascii?q?65NAdpKKLyAIGBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR?= =?us-ascii?q?6cqXpTcOMQzmRtdl8=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWCQA1Wt5e/4QNJK1mHgEBCxIMQIM?= =?us-ascii?q?cUgdvWC8sCoQag0YDphGCUgNVCwEBAQwBARgLCgIEAQGDf0UZgh0CJDgTAgM?= =?us-ascii?q?BAQsBAQUBAQECAQYEbYVbDIVzAgEDAQEQEREMAQEsDBEBCBoCJgIEJQsVEgQ?= =?us-ascii?q?BEiKDBAGCSwMuAQMLpSQCgTmIYXaBMoMBAQEFhVUYgg4DBoEOKoJkglEPhw0?= =?us-ascii?q?agUE/gTgcgk0+gQSBYwEBAgGBSi+CfTOCLY8GBIMDhlSKcZA4CoJZh0B3kE8?= =?us-ascii?q?DHZ5Ki3KFEYoAj3eEGQIEAgQFAg4BAQWBaiKBVnAVOyoBgj5QFwINkEAYg1q?= =?us-ascii?q?FFIVCdAI1AgYBBwEBAwl8jgUBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.73,487,1583193600"; d="scan'208";a="689767072"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jun 2020 15:39:06 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 058Fd489004313 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jun 2020 15:39:04 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 10:39:04 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 11:39:02 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 8 Jun 2020 10:39:02 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XGUQqGz8kxlU+bGpuld+ik9eMe9wBcMYt4H0OmVLbxAu+KMJ/pqnJxl2ec4s8Ow4LUBw4Z7SODv21I3sFyJQk4vwAAF8TkMO6nsFcbmry08tEsaxddOm/ZWJipEObyc2IpgjVRxPpXHSTV4r8RdtsUyRnbR2+OI6gyNXVBIJoK1NThnKwjfQIclax8Q87+lqTVCj7FyfXO+2uO4K+vSeBcTCmB8gze4F42Fx/f9/NmPpRTdNnVkhv9Sgp4hB4YaXm1+1p1egN3bc76y4RmuVawJCCQyyGq3nPKxChCsn33IpxrLklSTrRfJYBhw2f1XRhe1an8Z1jwQHr1oPE/IyUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BnjzKsXZdfyMfs0lE4//ds3zuLj2eFvOoMXEC9OvGHY=; b=EPPHfO1g931iZ1/WA6KwHCwD0/zk7WkImNusM3SyVPT4OhIrj5gc65u8xKlIIpLmdDgiUHY48JiSyaLFIiTUgPFHrV1aa0t5ylzeoaRmzU+KkhEBG7+h9/aepv8fa29W7Ub1KX/50bnXw92AoJASmSeKoKxIgWtao3nNsaPVcEtzcy+iYgAeRC49xOAnR4okNRd5QYIAZ0XwV1VlYWLbOdfmuO7cvtwP/2o8hON5iSKZS+rMis8XYlcAqPjW9IouvpEKLfFkqNqZHyF1coXPo4B5V519QAaPZXJZynTnTJSok+WZG0jYdBgWj8TLpvlBZqRjZp5NVxrewFWZLASEKg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BnjzKsXZdfyMfs0lE4//ds3zuLj2eFvOoMXEC9OvGHY=; b=Iz0Wx+wRxvSXTc88NjqAcwMkuHlRJOghwiucL3AFJTvlDynWtAcrNBpA+TDltpA+xrVJy2b1BYcLZMOU1r/pHXl3NJ0ZBr1eHifAIjPb2AOwxjx83th1FJQcppQH0H7fhqZyVpOg9+JP6+MKovGQcWKrxp9X1raAoCR18zscRhI=
Received: from SN6PR11MB2622.namprd11.prod.outlook.com (2603:10b6:805:57::31) by SN6PR11MB3375.namprd11.prod.outlook.com (2603:10b6:805:c0::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Mon, 8 Jun 2020 15:39:01 +0000
Received: from SN6PR11MB2622.namprd11.prod.outlook.com ([fe80::ec4f:5d21:5d27:7c2a]) by SN6PR11MB2622.namprd11.prod.outlook.com ([fe80::ec4f:5d21:5d27:7c2a%7]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 15:39:01 +0000
From: "Jeffrey Ladouceur (jladouce)" <jladouce@cisco.com>
To: "Jeffrey Ladouceur (jladouce)" <jladouce=40cisco.com@dmarc.ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] Question about RFC 6242 : netconf over ssh
Thread-Index: AQHWParuaFqwbmDVr0iRhc3EpC4jhQ==
Date: Mon, 8 Jun 2020 15:39:01 +0000
Message-ID: <529EE682-F67A-4A04-A869-65882A895528@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.37.20051002
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [87.101.49.80]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5075512c-789d-4057-8c7a-08d80bc21180
x-ms-traffictypediagnostic: SN6PR11MB3375:
x-microsoft-antispam-prvs: <SN6PR11MB33758BC0936972DA377B0BAFDF850@SN6PR11MB3375.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 042857DBB5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6ujMr8rdg0S7wjQF7YUElxqOJC5TWfY9HZGgDbaL9Rsc++YVVe7rW2fkH2acIOZyz1xEjaQluk5Y1SEUkZHsj1xnjwyUUNj4K2svZhiB8sRx60mmL4VsDX8ch3fL8oYYK93c8Tj7nFmM7ifNUYqfZhhnSV5unTPsdmp72Gu8oQ3Q8QDBK/jbFMXlO3b7uPng1eoscAvfR1Iql0VfB0fD3yLVE6f0j6QlmN+53e+rIB75p+9tNYpielzp3dc9P/SiJ+C8Q5TeHTd7z/Z540BWvHT0eXpTLgkIH/P4Tx2YCtvdV2E6d1Og1ex2BE7KYAVjF5+Hl/mPrmzPL0/HRPkBtuvDa0Lfr9OP6i4oH7CEYupr2YxFz96Zgv4jou13NAtQB8ez/Mwi/NMOSfmU5SJvZQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:SN6PR11MB2622.namprd11.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(366004)(376002)(136003)(39860400002)(396003)(346002)(26005)(2616005)(6512007)(6486002)(86362001)(8676002)(36756003)(478600001)(186003)(316002)(76116006)(83380400001)(966005)(66946007)(91956017)(5660300002)(8936002)(66446008)(2906002)(110136005)(33656002)(71200400001)(6506007)(66476007)(64756008)(66556008); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: TxPrkKo2Q+f+jgxa8WLAMZM7VG9bSvu2+//3Gd/XrQYMr1Nfk1LiThgI08uXkDFFMJuGEHv1db9iWSFMOyqzSeZrkkuB7k9I0gwFfpemnszOreMcjrhwKq25mnRvOXxD6NS8p00RLtyP94E/MnSMgc7t+3TbeQ/Pgd2DD4ezVMv0lrd8QmUL2eXTuFaNX2SgcAydGglk27AO2c7O3CMRB95+zTbi3SFLzB2N2Oo0BtZlTz/Z+xAtDr6x40fEn74cCjVDi0QfaZIedNE1O71Kk0wO+fMxbxdFedVzm8qE4WHWYdy9m5kLOW4PHghMgzHvIvdKPQhgBZgBln9U3Tk+Somx7/vN3otjTfDiU5tJt1n4ZnSiThEyToKmIlmiot/xJtaON2B9iAwhO5EmeV2t96hxySTXz/xtaDezwhe6ozBdWRRiVNfU8DMEMzyaHHzb6cHcnLLEo0yPC3REzymtHPn13nutVWf8TrUU07QjviU=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <CE038335A1DF1344AF24B13CB6FD5328@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5075512c-789d-4057-8c7a-08d80bc21180
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 15:39:01.7233 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: k1Mkun+yeasOTj4cRtfJApTKPshtMVV9pq06m4u98kfCuf1Qj2Ppg8GaXM02ae6OzhX7TgSdVquaeF08sH9C5g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3375
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/KImZJ8VThcmMIxDTP4E5SSqNDbg>
Subject: Re: [netconf] Question about RFC 6242 : netconf over ssh
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jun 2020 15:39:11 -0000

SGVsbG8sDQoNCkl0J3MgbXkgdW5kZXJzdGFuZGluZyB0aGF0IHJ1bm5pbmcgbmV0Y29uZiBvdmVy
IGEgcHNldWRvIHRlcm1pbmFsIHZpYSBzc2ggKGkuZS4gcHR5LXJlcSkgaXMgbW9zdCBsaWtlbHkg
bm90IGEgd2lkZWx5IHN1cHBvcnRlZCB1c2UtY2FzZSBhcyBJIGRvbid0IHNlZSBhbnkgcmVmZW5j
ZSB0byBzdWNoIHVzZS1jYXNlLg0KDQpUaGUgcHNldWRvIHRlcm1pbmFsIGlzIHR5cGljYWxseSB1
c2VkIGJ5IGFuIHNzaCBjbGllbnQgd2hlbiB0aGUgcHJvZ3JhbSBvbiB0aGUgc2VydmVyIHNpZGUg
ZXhwZWN0IHRvIGludGVycmVhY3Qgd2l0aCBhIHRlcm1pbmFsLiBUbyB0aGUgYmVzdCBvZiBteSBr
bm93bGVkZ2UsIGEgbmV0Y29uZiBzZXJ2ZXIgaGFzIG5vIGV4cGVjdGF0aW9uLCBhbmQgaW4tZmFj
dCBtYXkgZXhwZWN0IHRvIGJlIGRpcmVjdGx5IGNvbm5lY3RlZCB0byB0aGUgc3NoIHNlcnZlciBp
bnN0YW5jZSBhbmQgbm90IHRvIGEgcHR5IGRldmljZS4NCg0KV291bGQgaXQgYmUgcmVhc29uYWJs
ZSBmb3IgYSBuZXRjb25mIHN1YnN5dGVtIHRvIHNhbml0aXplIGl0cyBTVERJTi9TVERPVVQvU1RE
RVJSIGFuZCBpZiB0aGV5IHdlcmUgYXR0YWNoZWQgdG8gYSB0dHkgdG8gZXhpdCBhbmQgZHJvcCB0
aGUgY29ubmVjdGlvbiA/DQoNClJlZ2FyZHMsDQpKZWZmcmV5IExhZG91Y2V1ciANCg0K77u/T24g
MjAyMC0wNS0wNywgNDo1OSBQTSwgIm5ldGNvbmYgb24gYmVoYWxmIG9mIEplZmZyZXkgTGFkb3Vj
ZXVyIChqbGFkb3VjZSkiIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGps
YWRvdWNlPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCg0KICAgIEhlbGxvLA0K
DQogICAgSSB3b3VsZCBsaWtlIHNvbWUgaW5wdXQgb24gYSB0aGUgZm9sbG93aW5nIHVzZS1jYXNl
IGFuZCBwb3NzaWJsZSBhY2NlcHRhYmxlIG91dGNvbWVzLiANCg0KICAgIFN1bW1hcnk6DQoNCiAg
ICBSRkMgNjI0MiBkb2Vzbid0IGV4cGxpY2l0bHkgaW5kaWNhdGUgYW55IGxvd2VyIGxldmVsIG1l
c3NhZ2luZyBpbiBSRkMgNDI1NCB3aGljaCBjb3VsZCAiYnJlYWsiIHRoZSBuZXRjb25mIG1lc3Nh
Z2luZyBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLg0KICAgIFNwZWNpZmljYWxseSwgdGhlIGNs
aWVudCBjYW4gc2VuZCBhIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MjU0I3NlY3Rp
b24tNi4gInB0eS1yZXEiIGp1c3QgcHJpb3IgdG8gaW52b2tpbmcgdGhlICJuZXRjb25mIiBzc2gg
c3Vic3lzdGVtLg0KICAgIEhhdmluZyBhIHBzZXVkby10ZXJtaW5hbCBkZXZpY2UgaW4gYmV0d2Vl
biB0aGUgY2xpZW50LXNlcnZlciBjb3VsZCByZXN1bHQgaW4gdGhlIGJyZWFrYWdlIG9mIHRoZSBt
ZXNzYWdpbmcgYmVpbmcgY2xpZW50L3NlcnZlci4gDQoNCiAgICBSRkMgNjI0MiBzdGF0ZXM6DQog
ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYyNDIjc2VjdGlvbi0zIChTdGFydGlu
ZyBORUNPTkYgb3ZlciBTU0gpDQoNCiAgICAxLiBPbmNlIHRoZSB1c2VyIGhhcyBiZWVuIHN1Y2Nl
c3NmdWxseSBhdXRoZW50aWNhdGVkLCB0aGUgU1NIIGNsaWVudCB3aWxsIGludm9rZSB0aGUgInNz
aC1jb25uZWN0aW9uIiBzZXJ2aWNlLCBhbHNvIGtub3duIGFzIHRoZSBTU0ggY29ubmVjdGlvbiBw
cm90b2NvbC4NCiAgICAyLiBBZnRlciB0aGUgc3NoLWNvbm5lY3Rpb24gc2VydmljZSBpcyBlc3Rh
Ymxpc2hlZCwgdGhlIFNTSCBjbGllbnQgd2lsbCBvcGVuIGEgY2hhbm5lbCBvZiB0eXBlICJzZXNz
aW9uIiwgd2hpY2ggd2lsbCByZXN1bHQgaW4gYW4gU1NIIHNlc3Npb24uDQogICAgMy4gT25jZSB0
aGUgU1NIIHNlc3Npb24gaGFzIGJlZW4gZXN0YWJsaXNoZWQsIHRoZSBORVRDT05GIGNsaWVudCB3
aWxsIGludm9rZSBORVRDT05GIGFzIGFuIFNTSCBzdWJzeXN0ZW0gY2FsbGVkICJuZXRjb25mIi4N
CiAgICA0LiBSdW5uaW5nIE5FVENPTkYgYXMgYW4gU1NIIHN1YnN5c3RlbSBhdm9pZHMgdGhlIG5l
ZWQgZm9yIHRoZSBzY3JpcHQgdG8gcmVjb2duaXplIHNoZWxsIHByb21wdHMgb3Igc2tpcCBvdmVy
IGV4dHJhbmVvdXMgaW5mb3JtYXRpb24sIHN1Y2ggYXMgYSBzeXN0ZW0gbWVzc2FnZSB0aGF0IGlz
IHNlbnQgYXQgc2hlbGwgc3RhcnQtdXAuDQoNCiAgICBJZiBJIHdlcmUgdG8gdHJhbnNsYXRlIHRo
ZXNlIHN0ZXBzIGludG8gdGhlIGNvcnJlc3BvbmRpbmcgUkZDIDQyNTQgbWVzc2FnZXMuDQoNCiAg
ICBTdGVwICgyKSB0cmFuc2xhdGVzIHRvOg0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9yZmM0MjU0I3NlY3Rpb24tNi4xIChPcGVuaW5nIGEgU2Vzc2lvbikgLCB1cG9uIHdoaWNoIGEg
c2Vzc2lvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZA0KDQogICAgU3RlcCAoMyksIHRoaXMgdHJhbnNs
YXRlcyB0byBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDI1NCNzZWN0aW9uLTYuNSAo
U3RhcnRpbmcgYSBTaGVsbCBvciBhIENvbW1hbmQpLCBidXQgc3BlY2lmaWNhbGx5IHRoZSAic3Vi
c3lzdGVtIiB2YXJpYW50Lg0KICAgIFdpdGggYSBzdHJpbmcgb2Yg4oCcc3Vic3lzdGVt4oCdIGFu
ZCDigJxzdWJzeXN0ZW0gbmFtZeKAnSBzZXQgdG8gbmV0Y29uZi4NCg0KICAgIFF1ZXN0aW9uOg0K
ICAgIDEtIERvZXMgIFJGQyA2MjQyIGltcGx5IHRoYXQgaXQgZXhwZWN0cyBkaXJlY3QgY2xpZW50
L3NlcnZlciBjb25uZWN0aW9uIHdpdGhvdXQgYW55IGludGVyZmVyZW5jZSBmcm9tIGEgcHR5IGRl
dmljZSA/IFRoZSB0ZXh0IGluIGl0ZW0gKDQpIGFwcGVhcnMgdG8gbWUgdG8gaW1wbHkgdGhpcy4N
Cg0KICAgIEZyb20gd2hhdCBJIGNhbiB0ZWxsLCB0aGUgdXNhZ2Ugb2YgdGhpcyBwdHkgcGF0dGVy
biBpcyB3aGVuIGEgY2xpZW50IHdhbnRzIG5ldGNvbmYgb3ZlciB0dHkuDQoNCiAgICBUaGFuayB5
b3UgZm9yIGFueSBmZWVkYmFjay4NCg0KICAgIFJlZ2FyZHMsDQogICAgSmVmZg0KDQogICAgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBuZXRjb25m
IG1haWxpbmcgbGlzdA0KICAgIG5ldGNvbmZAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0K


From nobody Tue Jun  9 11:17:25 2020
Return-Path: <010001729a4cffe4-c72daa30-98ec-4371-913c-05cb546b1d0a-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806303A0CC0; Tue,  9 Jun 2020 11:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 hGqztRpTvsPE; Tue,  9 Jun 2020 11:17:21 -0700 (PDT)
Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789733A0CBC; Tue,  9 Jun 2020 11:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1591726637; h=From:Content-Type:Mime-Version:Subject:Date:References:Cc:To:Message-Id:Feedback-ID; bh=bDO+JPtQMM/KH2FydIb33lkv2Lv7P1ELYySLzwtlvh8=; b=V7DO/xrEtIlgVi9Y2eBi5DmP3l8Q+vlFHa+64gGY+gbREqxvD5uSdLa4h4xWvr/i iqMRbs2LWXMiVHpaDXr7z+E2mojcp+2kUY989XzlGr0UJev3xraf77e7ZYtLZguTREm nFZz38DOLJBYc63w7QgQQr4B6Y0wFbZbR4t9kJS8=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1D54D608-E36E-401D-995C-7D5725C79696"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 9 Jun 2020 18:17:17 +0000
References: <159172475503.26176.3191268380192615720@ietfa.amsl.com>
Cc: draft-kwatsen-netconf-sztp-csr@ietf.org
To: "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <010001729a4cffe4-c72daa30-98ec-4371-913c-05cb546b1d0a-000000@email.amazonses.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.09-54.240.48.92
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/oIKeL2vPIfG5UvgdULPuSiqaX7o>
Subject: [netconf] New Version Notification for draft-kwatsen-netconf-sztp-csr-00.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2020 18:17:24 -0000

--Apple-Mail=_1D54D608-E36E-401D-995C-7D5725C79696
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Dear NETCONF WG,

Based on popular demand, I collaborated with Security gurus Russ Housley =
and Sean Turner on this I-D.  I think everyone knows Russ and Sean but, =
just in case:

    - https://datatracker.ietf.org/person/Russ%20Housley =
<https://datatracker.ietf.org/person/Russ%20Housley>
    - https://datatracker.ietf.org/person/Sean%20Turner =
<https://datatracker.ietf.org/person/Sean%20Turner>

This draft has a very narrow scope (and hence a relatively short length) =
to patch in something that ostensibly should=E2=80=99ve been in RFC 8572 =
(SZTP).  The Abstract below has the details.  Please review and provide =
comments.   The authors believe that this I-D is, for all intents and =
purposes, done.   We do not foresee any scope extensions.

FWIW, I was surprised by the interest/demand to be able to set an LDevID =
as part of the bootstrapping process.  I had always assumed that it =
could be something the NMS/Controller app could do after establishing a =
connection with the bootstrapping device.  It turns out that the Mobile =
and IoT folks need to have in set inline so as to support routing path =
decisions and peer-to-peer associations before or, in some cases, in =
order to, connect to the NMS/Controller app (if there even is one).

K.




> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-kwatsen-netconf-sztp-csr-00.txt
> Date: June 9, 2020 at 1:45:55 PM EDT
> To: "Kent Watsen" <kent+ietf@watsen.net>, "Russ Housley" =
<housley@vigilsec.com>, "Sean Turner" <sean@sn3rd.com>
>=20
>=20
> A new version of I-D, draft-kwatsen-netconf-sztp-csr-00.txt
> has been successfully submitted by Kent Watsen and posted to the
> IETF repository.
>=20
> Name:		draft-kwatsen-netconf-sztp-csr
> Revision:	00
> Title:		Conveying a Certificate Signing Request (CSR) in =
a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request
> Document date:	2020-06-09
> Group:		Individual Submission
> Pages:		29
> URL:            =
https://www.ietf.org/internet-drafts/draft-kwatsen-netconf-sztp-csr-00.txt=

> Status:         =
https://datatracker.ietf.org/doc/draft-kwatsen-netconf-sztp-csr/
> Htmlized:       =
https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr-00
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-kwatsen-netconf-sztp-csr
>=20
>=20
> Abstract:
>   This draft extends the "get-bootstrapping-data" RPC defined in RFC
>   8572 to include an optional certificate signing request (CSR),
>   enabling a bootstrapping device to additionally obtain an identity
>   certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the
>   "onboarding information" response provided in the RPC-reply.
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> The IETF Secretariat
>=20
>=20


--Apple-Mail=_1D54D608-E36E-401D-995C-7D5725C79696
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Dear =
NETCONF WG,<br class=3D""><div class=3D""><br class=3D""></div><div =
class=3D"">Based on popular demand, I collaborated with Security gurus =
Russ&nbsp;Housley and Sean Turner on this I-D. &nbsp;I think everyone =
knows Russ and Sean but, just in case:</div><div class=3D""><br =
class=3D""></div><div class=3D"">&nbsp; &nbsp; -&nbsp;<a =
href=3D"https://datatracker.ietf.org/person/Russ Housley" =
class=3D"">https://datatracker.ietf.org/person/Russ%20Housley</a></div><di=
v class=3D"">&nbsp; &nbsp; -&nbsp;<a =
href=3D"https://datatracker.ietf.org/person/Sean Turner" =
class=3D"">https://datatracker.ietf.org/person/Sean%20Turner</a></div><div=
 class=3D""><br class=3D""></div><div class=3D"">This draft has a very =
narrow scope (and hence a relatively short length) to patch in something =
that ostensibly should=E2=80=99ve been in RFC 8572 (SZTP). &nbsp;The =
Abstract below has the details. &nbsp;<span style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0);" class=3D"">Please review and provide =
comments. &nbsp; T</span>he authors believe that this I-D is, for all =
intents and purposes, done. &nbsp; We do not foresee any scope =
extensions.</div><div class=3D""><br class=3D""></div><div =
class=3D"">FWIW, I was surprised by the interest/demand to be able to =
set an LDevID as part of the bootstrapping process. &nbsp;I had always =
assumed that it could be something the&nbsp;<span style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0);" class=3D"">NMS/Controller =
app</span>&nbsp;could do after establishing a connection with the =
bootstrapping device. &nbsp;It turns out that the Mobile and IoT folks =
need to have in set inline so as to support routing path decisions and =
peer-to-peer associations before or, in some cases, in order to, connect =
to the&nbsp;<span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, =
0);" class=3D"">NMS/Controller app (if there even is =
one).</span></div><div class=3D""><br class=3D""></div><div =
class=3D"">K.</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D""><br class=3D""><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">Begin =
forwarded message:</div><br class=3D"Apple-interchange-newline"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;" class=3D""><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif; =
color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">From: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D""><a =
href=3D"mailto:internet-drafts@ietf.org" =
class=3D"">internet-drafts@ietf.org</a><br class=3D""></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;" class=3D""><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif; =
color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">Subject: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D""><b class=3D"">New Version =
Notification for draft-kwatsen-netconf-sztp-csr-00.txt</b><br =
class=3D""></span></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px;" class=3D""><span =
style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">Date: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D"">June 9, 2020 at 1:45:55 PM =
EDT<br class=3D""></span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=3D""><span=
 style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">To: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D"">"Kent Watsen" &lt;<a =
href=3D"mailto:kent+ietf@watsen.net" =
class=3D"">kent+ietf@watsen.net</a>&gt;, "Russ Housley" &lt;<a =
href=3D"mailto:housley@vigilsec.com" =
class=3D"">housley@vigilsec.com</a>&gt;, "Sean Turner" &lt;<a =
href=3D"mailto:sean@sn3rd.com" class=3D"">sean@sn3rd.com</a>&gt;<br =
class=3D""></span></div><br class=3D""><div class=3D""><div class=3D""><br=
 class=3D"">A new version of I-D, =
draft-kwatsen-netconf-sztp-csr-00.txt<br class=3D"">has been =
successfully submitted by Kent Watsen and posted to the<br class=3D"">IETF=
 repository.<br class=3D""><br class=3D"">Name:<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>draft-kwatsen-netconf-sztp-csr<br class=3D"">Revision:<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>00<br =
class=3D"">Title:<span class=3D"Apple-tab-span" style=3D"white-space:pre">=
	</span><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>Conveying a Certificate Signing Request (CSR) in a Secure Zero =
Touch Provisioning (SZTP) Bootstrapping Request<br class=3D"">Document =
date:<span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>2020-06-09<br class=3D"">Group:<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Individual Submission<br =
class=3D"">Pages:<span class=3D"Apple-tab-span" style=3D"white-space:pre">=
	</span><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>29<br class=3D"">URL: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"https://www.ietf.org/internet-drafts/draft-kwatsen-netconf-sztp-cs=
r-00.txt" =
class=3D"">https://www.ietf.org/internet-drafts/draft-kwatsen-netconf-sztp=
-csr-00.txt</a><br class=3D"">Status: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"https://datatracker.ietf.org/doc/draft-kwatsen-netconf-sztp-csr/" =
class=3D"">https://datatracker.ietf.org/doc/draft-kwatsen-netconf-sztp-csr=
/</a><br class=3D"">Htmlized: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr-00" =
class=3D"">https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr-00</=
a><br class=3D"">Htmlized: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"https://datatracker.ietf.org/doc/html/draft-kwatsen-netconf-sztp-c=
sr" =
class=3D"">https://datatracker.ietf.org/doc/html/draft-kwatsen-netconf-szt=
p-csr</a><br class=3D""><br class=3D""><br class=3D"">Abstract:<br =
class=3D""> &nbsp;&nbsp;This draft extends the "get-bootstrapping-data" =
RPC defined in RFC<br class=3D""> &nbsp;&nbsp;8572 to include an =
optional certificate signing request (CSR),<br class=3D""> =
&nbsp;&nbsp;enabling a bootstrapping device to additionally obtain an =
identity<br class=3D""> &nbsp;&nbsp;certificate (e.g., an LDevID, from =
IEEE 802.1AR) as part of the<br class=3D""> &nbsp;&nbsp;"onboarding =
information" response provided in the RPC-reply.<br class=3D""><br =
class=3D""><br class=3D""><br class=3D""><br class=3D"">Please note that =
it may take a couple of minutes from the time of submission<br =
class=3D"">until the htmlized version and diff are available at <a =
href=3D"http://tools.ietf.org" class=3D"">tools.ietf.org</a>.<br =
class=3D""><br class=3D"">The IETF Secretariat<br class=3D""><br =
class=3D""><br class=3D""></div></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_1D54D608-E36E-401D-995C-7D5725C79696--


From nobody Fri Jun 12 09:30:59 2020
Return-Path: <ietfc@btconnect.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144293A07BA for <netconf@ietfa.amsl.com>; Fri, 12 Jun 2020 09:30:58 -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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 AY_2TRLxrfpR for <netconf@ietfa.amsl.com>; Fri, 12 Jun 2020 09:30:56 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70092.outbound.protection.outlook.com [40.107.7.92]) (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 863533A089B for <netconf@ietf.org>; Fri, 12 Jun 2020 09:30:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OnLJCabkB+V80LAqX35YG6eDHa2hKPKLs9PA6sRsGvuDmFF1rdQHKo6xxMJAZqwKt9vEzXA/pFUh0XqGT+/KE2qe/yl8ZvSVdymuPeelCn2ZyC/I9PvOkyy0oQkOysxp/S1t78GcEmQFoeUzmY9Be07NKcSxehxFB8TnSrhDV9xKXw2PxKNhmjnaJzqH1Gf8khZF7OV+y0jzhjzy+V7HCiIxwpICYmkD1R2zU+v60eOonTGJ05sHKKVuckWUcFDdiOZ9behxcFVH1VxfwVk6tmrZumzP/10YDjaH5wc6DiVdeZLie8p9/KK9e4o3Ikew+kDlWCGxKIBsncAtLgh2Gw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pc6zIcB3NfTim/ysSSD/DQiu5tiECdBr1xfd2QjvFJ4=; b=Hxzbnb2lmE6aZSZUkFs8fbkUlDGQ1lzsoOffnDZlJfK6vQ+0SszwWxysNMqVPs3hyiAudGPUfzoDwJn1aA3Sc1QdyLI0uTcznpSpwWs05hldQKZgunbJwcLmMsz17tb2Zy01XkaA+PA/mwyWoIzzrPO+E+3tt7sJdqKIzALWLx1G0CuUBKQYcRHAfqwCkA+ZujiSeI5LqdMqKnd9q4sJmFfzgYPdq/Z8R6QtGx3dHQEFkwY+f9pSz2+XjvUWUCLD91KB3e4mvBLV8Q46Zctn5Aanu0ULqbbinU9X94Ih2H0nIVzgBu/irGsgjmngsNvAq/D/eIb3Wwr86oPGQl9cxw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pc6zIcB3NfTim/ysSSD/DQiu5tiECdBr1xfd2QjvFJ4=; b=LkUegswr+kuGk0tgrNtIIZfZJHpmvebv+MQk5M1tkcLe+OwiA/seAXp2ggLbfCM/z8v4oIcWtITH84R01k0gVpJxNKAGNMe/pnVB0yoMVoXiYLpvpk1BUSac7OjQ9wl0jOLzYQoHhZwbAcd0y7JLctZckleZksm2+N4QJfxoaak=
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com (2603:10a6:10:198::14) by DB6PR07MB3301.eurprd07.prod.outlook.com (2603:10a6:6:22::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.7; Fri, 12 Jun 2020 16:30:52 +0000
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65]) by DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65%7]) with mapi id 15.20.3109.012; Fri, 12 Jun 2020 16:30:52 +0000
From: tom petch <ietfc@btconnect.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Last Call  on Re: [netconf] Today's update to client-server drafts
Thread-Index: AQHWLu3jaU/uAQvClUC0xIr2aQT0pKizkcMAgCG8O+M=
Date: Fri, 12 Jun 2020 16:30:52 +0000
Message-ID: <DBAPR07MB701671D1E66A7C53FB559072A0810@DBAPR07MB7016.eurprd07.prod.outlook.com>
References: <0100017233fe7ff7-8e22b4b1-aa03-4c8e-bf9d-fdbc7d3e41fd-000000@email.amazonses.com>, <85A8ECA9-8875-45FA-839B-50CE35F6C8BA@gmail.com>
In-Reply-To: <85A8ECA9-8875-45FA-839B-50CE35F6C8BA@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
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=btconnect.com;
x-originating-ip: [86.139.211.47]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c038dfe5-fd3f-4d73-088a-08d80eedf95e
x-ms-traffictypediagnostic: DB6PR07MB3301:
x-microsoft-antispam-prvs: <DB6PR07MB3301E3100E4ECC2964C4813AA0810@DB6PR07MB3301.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0432A04947
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6T4mVPU0Ahs/j8QuVfrAYkUMAUA3P6bsxfr+jchYJ+TiyIrrS+3Kye9ptNUhNX5uqxi/ZT1OMEmVQ6xYwBuFWGYSLD1ZTNHORWscdx71mbrq00WIMvycCgFQPESUNEoJ2uUiOLASmNmjx+PWjjR1WeWNErhY9KJLQNbbfIW9k8LAl+sF2AndAnlfD49dajJsVeGhcDC6jgLQOWtuUTr8kyR3vYWOM16IjeJUh49R2IRlzUeJNhDFBWboNbuYptcIL++FmOA0jyMxrghDZCmWpXadchclh6mIELrh8+ZJdIbOMXfOCbgwfEL9ELEMmH1NpFAUd+4NDqDBqj07JKAxvrJ7m2Hmx3/gvyswiQ4wN10Sbl3Lbp+op9Pw7zDfRkdxLQdQZC8oK0xKHV49Y3ZOTQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DBAPR07MB7016.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(376002)(366004)(346002)(136003)(39860400002)(396003)(86362001)(55016002)(33656002)(52536014)(8936002)(8676002)(9686003)(478600001)(83380400001)(966005)(5660300002)(15650500001)(186003)(4326008)(66446008)(66476007)(26005)(2906002)(6506007)(7696005)(316002)(91956017)(64756008)(66556008)(66946007)(76116006)(110136005)(53546011)(71200400001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: FLrYRovVxEAaMzmTLiDxnbMEHDOOIYPRHmjNbxgwFCBu93EfBSVvxo+eYM+e+dJfsNE20VMhaRC2Wl1IuRuxnkEM+4MpT0+Xz2wfjmmzKhg/Njkum+vesP/f9uUQpMJCz/xbHu1Brs3tumHLxXNoYqeiZ1NUgwhb6Td/bGjpK8cNmTbQcM7inQKlQmkIwiYUBVEVHWLH0bHB/sQRssmJufbTc4n2Ld7AVrrxl4BmCFXAw707TdOhY4HfuXjNViyrMI60uPLCxqdSDVsSBGpPYFg4cNmqqi6Xm1jF/xE/AjGG3AvgrK9pNoWKUdcLHc15R6OUbfoYX+o3glMpshwkAM9uO3c9Je52VojK9SH4JYfbc8iqy91HcU0ZtAPSsje810IMBCOXATLaDRw9f8R91t0vrr8GalrGHh8qmSq9SzkXDSclJbGOEEJlr8iJsffIBO05U3d9xhnAWCzX6TMWqG6b76nJLISuGWE9T2pxdSI=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c038dfe5-fd3f-4d73-088a-08d80eedf95e
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 16:30:52.5144 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cS6XpVK8QMiD6aAvdqVrQxbuiizLnQDCNQ5RoAkPri4DnUhm3rUAqTy33J/HQ9sbKSAXYd4AUi7kpxUjL7idmg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3301
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/sR5u1WZ6oCNm7y_sPhKToMH1mpQ>
Subject: [netconf] Last Call on Re: Today's update to client-server drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2020 16:30:58 -0000

From: netconf <netconf-bounces@ietf.org> on behalf of Mahesh Jethanandani <=
mjethanandani@gmail.com>=0A=
Sent: 22 May 2020 06:14=0A=
=0A=
<tp>=0A=
I am sure I saw a Last Call but cannot now find it.=0A=
=0A=
I wonder if there is anyone in the IETF who is familiar with this work and =
with RFC8635;  would these I-D meet the needs of RFC8635 which I have alway=
s seen as one of the two use cases for this work?=0A=
=0A=
In passing, trust anchors registers prefix ta; logical except that the I-D =
uses ts=0A=
=0A=
Tom Petch=0A=
=0A=
What would it take to get the remaining drafts into WGLC?=0A=
=0A=
> On May 20, 2020, at 2:30 PM, Kent Watsen <kent+ietf@watsen.net> wrote:=0A=
>=0A=
>=0A=
> The entire suite of drafts were updated today.=0A=
> The first three drafts are ready for WGLC.=0A=
> All of the other drafts are almost ready for WGLC.=0A=
> Below is the Change Log entry for each draft.=0A=
>=0A=
> K.=0A=
>=0A=
>=0A=
> For all drafts:=0A=
>=0A=
>   o  Added a "Note to Reviewers" note to first page.=0A=
>=0A=
>=0A=
> For crypto-types:=0A=
>=0A=
>   o  Removed the IANA-maintained registries for symmetric, asymmetric,=0A=
>       and hash algorithms.=0A=
>=0A=
>   o  Removed the "generate-symmetric-key" and "generate-asymmetric-key"=
=0A=
>       RPCs.=0A=
>=0A=
>   o  Removed the "algorithm" node in the various symmetric and=0A=
>       asymmetric key groupings.=0A=
>=0A=
>   o  Added 'typedef csr' and 'feature certificate-signing-request-=0A=
>      generation'.=0A=
>=0A=
>   o  Refined a usage of "end-entity-cert-grouping" to make the "cert"=0A=
>       node mandatory true.=0A=
>=0A=
>=0A=
> For trust-anchors:=0A=
>=0A=
>   o  Removed "algorithm" node from examples.=0A=
>=0A=
>   o  Removed the no longer used statements supporting the old "ssh-=0A=
>       public-key" and "raw-public-key" nodes.=0A=
>=0A=
>=0A=
> For keystore:=0A=
>=0A=
>   o  Removed augments to the "generate-symmetric-key" and "generate-=0A=
>       asymmetric-key" groupings.=0A=
>=0A=
>   o  Removed "generate-symmetric-key" and "generate-asymmetric-key"=0A=
>       examples.=0A=
>=0A=
>   o  Removed the "algorithm" nodes from remaining examples.=0A=
>=0A=
>   o  Renamed/updated the "Support for Built-in Keys" section.=0A=
>=0A=
>   o  Added new section "Encrypting Keys in Configuration".=0A=
>=0A=
>=0A=
> For tcp-client-server:=0A=
>=0A=
>   o  Removed commented out "grouping tcp-system-grouping" statement=0A=
>       kept for reviewers.=0A=
>=0A=
>=0A=
> For ssh-client-server:=0A=
>=0A=
>   o  Updated the "keepalives" containers to address Michal Vasko's=0A=
>       request to align with RFC 8071=0A=
>=0A=
>   o  Removed algorithm-mapping tables from the "SSH Common Model"=0A=
>       section=0A=
>=0A=
>   o  Removed 'algorithm' node from examples.=0A=
>=0A=
>   o  Added feature "client-identity-publickey"=0A=
>=0A=
>   o  Removed "choice auth-type", as auth-types aren't exclusive.=0A=
>=0A=
>   o  Renamed both "client-certs" and "server-certs" to "ee-certs"=0A=
>=0A=
>   o  Switch "must" to assert the public-key-format is "subject-public-=0A=
>       key-info-format" when certificates are used.=0A=
>=0A=
>=0A=
> For tls-client-server:=0A=
>=0A=
>   o  Updated the "keepalives" containers in part to address Michal=0A=
>       Vasko's request to align with RFC 8071 and in part to better align =
to RFC 6520=0A=
>=0A=
>   o  Removed algorithm-mapping tables from the "TLS Common Model"=0A=
>       section=0A=
>=0A=
>   o  Removed the 'algorithm' node from the examples.=0A=
>=0A=
>   o  Renamed both "client-certs" and "server-certs" to "ee-certs"=0A=
>=0A=
>=0A=
> For http-client-server:=0A=
>=0A=
>   o  Removed "protocol-versions" from ietf-http-server based on HTTP WG=
=0A=
>       feedback.=0A=
>=0A=
>   o  Slightly restructured the "proxy-server" definition in ietf-http-=0A=
>       client.=0A=
>=0A=
>   o  Added http-client example show proxy server use.=0A=
>=0A=
>=0A=
> For netconf-client-server:=0A=
>=0A=
>   o  Updated examples to remove the 'algorithm' nodes.=0A=
>=0A=
>   o  Updated examples to reflect the new TLS keepalives structure.=0A=
>=0A=
>   o  Added keepalives to the tcp-client-parameters section in the=0A=
>       netconf-server SSH-based call-home example.=0A=
>=0A=
>   o  Added a TLS-based call-home example to the netconf-client example.=
=0A=
>=0A=
>=0A=
> For restonf-client-server:=0A=
>=0A=
>   o  Updated examples to remove the 'algorithm' nodes.=0A=
>=0A=
>   o  Updated examples to reflect the new TLS keepalives structure.=0A=
>=0A=
>   o  Removed the 'protocol-versions' node from the restconf-server=0A=
>       examples.=0A=
>=0A=
>=0A=
>=0A=
>=0A=
> _______________________________________________=0A=
> netconf mailing list=0A=
> netconf@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/netconf=0A=
=0A=
Mahesh Jethanandani (as co-chair)=0A=
mjethanandani@gmail.com=0A=
=0A=
=0A=
=0A=
_______________________________________________=0A=
netconf mailing list=0A=
netconf@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netconf=0A=


From nobody Fri Jun 12 10:42:14 2020
Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46943A1159 for <netconf@ietfa.amsl.com>; Fri, 12 Jun 2020 10:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level: 
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 header.b=FZr7q10z; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=S6P6Kunh
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WMYNBvvF8gv for <netconf@ietfa.amsl.com>; Fri, 12 Jun 2020 10:42:09 -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 4D9F73A0FB5 for <netconf@ietf.org>; Fri, 12 Jun 2020 10:42:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8096; q=dns/txt; s=iport; t=1591983729; x=1593193329; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N9nZYfWEgKUCYy2kTwY+Y2QxP4clCosniEIkJhzZJA0=; b=FZr7q10zPPMSXjTZue2dKK3mayI658lI6AzQrYAFT7qWYUCP5jXqtiFF sO2XQEHW2jPWj51db56Dc93OP8twP+XRsOcgbqsra50s35XuMHL9PLfEk KIFWb1q10CkzQ1dXPOqp0rdCV9Tfei6HGiMeSLaaPWnHay3DqeA2f/ltV k=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3AGksqpRBCmDbhyTqkEYvqUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw00g3WVJnA5vQCjefK4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS9n3e0bfpDu04CJBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAgCuveNe/5BdJa1dCRwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIE5BAEBCwGBUVIHbystLywKh2ADjTyJf4ldghCCZoJSA1U?= =?us-ascii?q?EBwEBAQkDAQEYDQgCBAEBg39FAoIrAiQ3Bg4CAwEBCwEBBQEBAQIBBgRthVs?= =?us-ascii?q?MhXIBAQEBAwEBEC4BASwLAQsEAgEIEQQBAS8CHwYLHQgCBA4FCAYUgwU4gUZ?= =?us-ascii?q?NAx8PAQ6odAKBOYhhdIE0gwEBAQWBM1EDgyENC4IHBwMGgTgBgVKBEYRLg1i?= =?us-ascii?q?BRBqBQT+BVIJNPoF5JUkBAYE5LoNFgi2RZogqmWVMCoJZhCaCU4QiiRmFB4J?= =?us-ascii?q?wiRqFGossgheddJFQAgQCBAUCDgEBBYFpI4FWcBU7gmlQFwINjh6DcYUUhUJ?= =?us-ascii?q?0AhIjAgYIAQEDCXyOIQGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.73,504,1583193600";  d="p7s'?scan'208";a="510028612"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jun 2020 17:42:08 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 05CHg8C9015754 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Jun 2020 17:42:08 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Jun 2020 12:42:08 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Jun 2020 12:42:06 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 12 Jun 2020 12:42:07 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dRcOsoLXPL33BgVzKmzIIxMx0T+CJ0KiEY9OUrYCXXlGPpiyGuM6DAXvXqao8c3h/sC9j+05OEuxWYSPNIUcIKLeqvyTGGb8bntTbsK7cOdICSe/aiYRkAHMDZoYJZZjmEA2lxjRQDbIlPpRHi3Ns8yZgeex+tZV1TKTk3JwofaHkm5yRAZDz7JIr3EXKifGOdbYcVq6isT6tU/npUh/AWMzhlQLzfLHsIHph+CKwuv7H14o85ZPC1XgyvI+Knm7pRVcjB57mAtPaWQCzytwb7WiC6JTCUy7rkLMMxDjyB6RymlTQ+I5BszxmcE3M/Ndfi8Ppe/izKcPY1WucN6nrA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hF3X1M1zPDBMVU/KF5z74AsUFlEU2xam8RvfUgaUSCQ=; b=R91NPoJiVJlLNIkaEZEkxAH5OLlwJXYyQmqgafG8Pc2edGBasXB1thGtULh+otJt4WEMe53ytJQekb9lpdjs7w60eDtdgkDzt92K/BpGOr4G/MzKzOPtzvQ9hr3w6rm20TyiG07UFSPnT24uIHTfFawSuea9XQBb2r87N9uCsB1C7RLzJ6GGchfXxfUE1d7WJGXH0yUyVJu6gL+1wilOJlPs/cIiFW+TVkQAPyjkPPRD+WKT3ipk7jinROTF4kBomqjqDrHdeic3z55Rw6k/gkROZzLN3j3EZF1Yd8QX5zBeg46kPZ7vB9bdSYzOKrN1m2EkFAJZfc5X6M37nxPgig==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hF3X1M1zPDBMVU/KF5z74AsUFlEU2xam8RvfUgaUSCQ=; b=S6P6KunhmWUn8XBu1JwVzGPqaInzF/DKsnt1aHz6e6Wli8xVsH6O2j7PL+HzLiFKN+Gp6HUCjn76zHU0cEod+MehICnhnU09mvNNvvRf5Nj6H35S2QLy70f3M3ZF8nfyjTf6Qa2AUJaYXAwa3mBw4zZmET56mhktGv9gN7ISrpM=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4616.namprd11.prod.outlook.com (2603:10b6:208:26f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.24; Fri, 12 Jun 2020 17:42:06 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290%7]) with mapi id 15.20.3088.025; Fri, 12 Jun 2020 17:42:06 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: Netconf <netconf@ietf.org>, Mahesh Jethanandani <mjethanandani@gmail.com>
Thread-Topic: [netconf] WG LC for three drafts
Thread-Index: AQHWOThTTo+30icCv0mQD3Parb0A+ajVR//Q
Date: Fri, 12 Jun 2020 17:42:06 +0000
Message-ID: <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com>
In-Reply-To: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8bd64b40-7cce-473d-b29d-08d80ef7ecb1
x-ms-traffictypediagnostic: MN2PR11MB4616:
x-microsoft-antispam-prvs: <MN2PR11MB46165188CB0C69B1BD7E45FCA1810@MN2PR11MB4616.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0432A04947
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: PcY7f/flX7kFJKo9eFYy1+UJ5NwYT6fIfFUWmBl7WFwFFADG5u287o3jv2WI6Q6PG8pVK9ycyUqSZIyKwLwHQNxDaZjpmYXlIcU1v4pYpvMZvxk1wGzqTpRnQR8bQ3NuJikTsQ/dIY2DOSyjO/n18+yzAJ6VE1T68nDU3B0FXcBBMGT0zBdTmBBXUZeRuQGU90NjOWjS/oY4ZeGymqYgaU727CU2kfuGFc5uYwGgk/0vsZblIGLGCz4GdhsXuNNBdTZ3cwUzNwCmpedhZf6EMifWOglOknAfVu4GKTf9aDn7gvcunYcS7fb+JZfvLVSgd50UwtWUnubHXd16PFgeC0MMWWphK8aJoWRxma58ezeUE8Q0jETBr86E+nQmhLrTrhUcQHrJstg5quSJTfqXfTzOVnDr9gg4y8Fjb55ThQxd7Q7FDAe1JH4D0w3H341k8uv9q8cvE3Hoj36ioTC6WoRsTciboVWzRYsUOD/0o9g=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(136003)(376002)(346002)(396003)(39860400002)(366004)(8936002)(76116006)(66946007)(66446008)(64756008)(66556008)(66616009)(66476007)(6506007)(26005)(9686003)(7696005)(52536014)(5660300002)(55016002)(71200400001)(8676002)(53546011)(2906002)(186003)(316002)(54906003)(99936003)(966005)(33656002)(83380400001)(4326008)(86362001)(478600001)(15398625002)(43620500001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: ztyt0ExqxzVup8OCCYfD5UlRCII0p52p+I4LWDhq/ThtYbASriM+Lt7KfqsMX3r0/fosDywbJIy1hLPwxiCRVRWQIQp6IVDjRP8V61+8YkhiNZxHsAo4XfEqckaLchIjShI0Swy2nhEG9P2XQWzxVIN+U+k9aFhr5T69wEbJ2TIgoCgA97D59PkGOb1ZLbP8PvEAgQyY6CxCSzAG9EUNTabxkP4SSpCKJ2QBOsI5vSJ9oSwS4MEjhHsQ0T9Rcavax39/ifsukMbfhSwITIfKOEA5VruiyKje9I8Tlo9S6thrlqJ/MitZj4bogov4YoUNzKMSnLkOhxhkW+LOHHvnuSdlBxjEUeQOkE8RwsJPGta5XVehJESxw7yJc693ApriRTMPhYurzwKe6OSksaIefd2W+KhCJ0cewZAXfduvdWiJX21Bkb1962fxa4ag+1nvKtPje4Ara6KD8f950AoXDW0RBJwl7wuAiuZrELhZGEpnFk2qcEjCizjSGxRBA5yf
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_070D_01D640BF.41120700"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8bd64b40-7cce-473d-b29d-08d80ef7ecb1
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 17:42:06.2511 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: STjPrfM116SelhxilR9ljNKVFe5BWrMZswVbuEeT9yCvQdsacly3arYd01+ahUBs
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4616
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/T5CEKdxVZSZkh3OJqDKcco9eBOU>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2020 17:42:12 -0000

------=_NextPart_000_070D_01D640BF.41120700
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Kent,

I have been reading draft-ietf-netconf-crypto-types, and the thread: Virtual
"hum" for the "key generation" issue discussed at virtual meeting.

I have a couple questions on the previous "asymmetric-algorithm-type"  and
what is now in "asymmetric-key-pair-grouping".  My reading is that instead
of the previous ENUMs of -v14, other applications/WGs will now need to
create identities for the various algorithm types.  And this is fine.

If I have this correct, then each of the TCG Algorithm Registry ID values of
TPM2 specifications in Table 9
https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2-
Structures-01.38.pdf 
could have its own identity.   And there would be no barrier to each of
these identities also having another base identity that might be
"tpm2-algorithm".  In this correct?

If this is correct, my second question is whether there will be an attempt
to ask other YANG models to import these application identities elsewhere?
As you and Rob note in the thread, trying to predict the desired identity
inheritance hierarchy is non-trivial.

Thanks,
Eric

> -----Original Message-----
> From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh
> Jethanandani
> Sent: Tuesday, June 2, 2020 7:48 PM
> To: Netconf <netconf@ietf.org>
> Subject: [netconf] WG LC for three drafts
> 
> NETCONF WG,
> 
> The authors of
> 
> - draft-ietf-netconf-crypto-types
> - draft-ietf-netconf-keystore
> - draft-ietf-netconf-trust-anchors
> 
> have indicated that these drafts are ready for Last Call (LC).
> 
> This kicks of a 2 week WG LC for the three drafts. Please review and send
any
> comments to the WG mailing list or by responding to this e-mail. Comments
> can be statements such as, I read/reviewed the document and believe it is
> ready for publication, or I have concerns about the document. For the
latter,
> please indicate what your concerns are.
> 
> Any reports on implementation status or plans to implement are also very
> useful.
> 
> Thanks.
> 
> Mahesh Jethanandani (as co-chair)
> mjethanandani@gmail.com
> 
> 
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

------=_NextPart_000_070D_01D640BF.41120700
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw
ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz
Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX
DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g
Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2
tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI
zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl
zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS
qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk
UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD
VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB
BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO
VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup
SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p
+slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg
lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA
AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD
aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD
VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz
guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I
4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG
VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+
FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ
BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC
NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j
BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j
aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG
CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw
NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3
LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF
AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo
0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp
9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt
U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ
MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04
96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv
eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg
Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw
EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM
D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE
S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO
yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M
mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v
Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp
W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB
Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v
c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp
c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E
MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV
HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G
A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr
+GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ
KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0
JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f
1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG
+gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG
A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjEyMTc0MjAyWjAjBgkqhkiG
9w0BCQQxFgQU7o0wspUU56zQxTRNMUImAO3SNkwwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK
EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN
AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK
AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw
CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH
BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B
AQEFAASCAQAScLEp61H2HGRB8W+Y2L9GDzMB5v3ruLHvVWFlFcmOE+BFLGjFN+Y92VHXY/d6LtuC
I7BwW3t0SwRZLNAcLfazHONyTORiKwsIsgbA9NZKG2LgaGN58WsadlWGTUFC8pEe6FCdkKURueQc
fdXf3P3d6VRYVcdfhLANi6EFVFi8l4ukpE7eMejAS9VoE1LzMAK4NNsNEffd6JpLjZSxMbMHWycE
RGczeM+d2cyq8yX44INHgQvM1B+RaUeQmXk23PxlfZkOgyEulQ5UAgcU8uN/PcJTf4IjdEeBwKS3
DENvroCfIi4Yn4LJcpSs/CdZ6s2L0vpBfYOILXTmOS3FSFSrAAAAAAAA

------=_NextPart_000_070D_01D640BF.41120700--


From nobody Fri Jun 12 13:03:57 2020
Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316813A0DF6 for <netconf@ietfa.amsl.com>; Fri, 12 Jun 2020 13:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.598
X-Spam-Level: 
X-Spam-Status: No, score=-14.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 header.b=by4/rIeR; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=kF21/3v7
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibcpoJaA5vLC for <netconf@ietfa.amsl.com>; Fri, 12 Jun 2020 13:03:53 -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 BF3063A0CCB for <netconf@ietf.org>; Fri, 12 Jun 2020 13:03:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19756; q=dns/txt; s=iport; t=1591992197; x=1593201797; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RMUldaKNcHzorQvV9sZaKxCLg7mLt+yiSZNnwu06Q5Q=; b=by4/rIeRHcyJmBv04hS86Mt7e18d+bvTSmZQGi6WRKVOf9zyzHKsQ5/Q GSjp3SFQesjVK32d6nC/yP1OeNiio7j2JCsGjSqVFgo2RNRT5b/M3h47i FjylxQ4omJqhp8cVD+FFmbW3AorvHTC5K1qWvkI0KkCzaQ+ixgZWuUDPa g=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3A8q2fUxbkuTxoo/IgCilAgjT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD5rS9+lJjazQvryzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsuteFTOuXC0qzgfBk?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAQCU3uNe/4oNJK1dCRoBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAUCBSoEjL1IHbystLywKh2ADjTyHVYIqiV0?= =?us-ascii?q?OggKCZoFCgRADVQQHAQEBCQMBARgBCgoCBAEBg39FAoIrAiQ4EwIDAQELAQE?= =?us-ascii?q?FAQEBAgEGBG2FWwyFcgEBAQECAQEBEBsTAQEsCwEEBwQCAQgRBAEBLwIfBgs?= =?us-ascii?q?dCAIEDgUIBhSDBTiBRk0DDhEPAQ6ofQKBOYhhdIE0gwEBAQWBM1EDgx4NC4I?= =?us-ascii?q?HBwMGgTiBU4ERhEuDWIFEGoFBP4FUgk0+gXklSQEBgTkSHINFgi2aEIk7kCp?= =?us-ascii?q?MCoJZhCaCU4QiiRmFB4JwiRqFGoJeiE6CF510kVACBAIEBQIOAQEFgWoigVZ?= =?us-ascii?q?wFTuCaVAXAg2OHgsYg06FFIVCdAISIwIGCAEBAwl8ji8BgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.73,504,1583193600";  d="p7s'?scan'208,217";a="512384115"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jun 2020 20:03:16 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 05CK3FhE031006 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Jun 2020 20:03:15 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Jun 2020 15:03:15 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Jun 2020 15:03:15 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 12 Jun 2020 15:03:15 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T/CQ9cHxFXN5V2IGDu5oeja0llVx4xgzMPKJ/dVuQ22g8wS+Q7V1U9fuY0j6/ofr+l87ZhKV5imnl+3wr7tJ5n7y0EuHYZP/F267iLeDmx5WMFXVKlTACB2MwdncXT0GKCl/4HKXPh4DDLMBBv1qDoW9Q6VD/HsrFIDP/urQNyTQmxMKTVmYsQAibfuzXDPvSSFy1v/W7iZcLyYR776aMyIgcxMC7W8nB8oBRhDRhmVMBHNJtqzC9aHHYaZpH1lplDTHJGdBZgUuKmDlZCq04wEC8CzjnLWCWRNee38sBfYvV99XTN4QCpcda+kocZJwHWOoHw+wE9SMtiAXdWYjJQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WqHcO1npSzBjBt3HApnJD9U+rDHxFpbswtA2dZWqz8U=; b=R7ihA6pUPSkodr8MSzEOnzwGY+TNm6LkuTecGw7yyTdmvrw/i6W506/yIfdF9izipZLBfeM1925a6gITPELQmwOKbr9D04qMxtND4yKUQdmPbD0T8k7ibkgP1r0hDo3TYmZeE6vc23Ke7gBy8mb9tsHQvaMcD/ybuQMjuD120gt9W3NtLkNh4hUQH8JAWlnMPa9/NSCIsYrctcq1iZNeaB/6fmqZEBJXheS2LsUktz5cXl1MOP8oAl8fpAtf/kwSslRQn6bOO4MmTd0Sib6Z6GZsRFSx3pHFjpBKPdqKAJOnkqDbheYbK8sJU0iRLeft/0LKAyZWUWypWuT3o4kudA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WqHcO1npSzBjBt3HApnJD9U+rDHxFpbswtA2dZWqz8U=; b=kF21/3v7lHG5l13DLOyuUHpiXNXYECBDdAecIW8esq2kbh0hYdyWe3IrAJ9joNvuc0yBvXQzFgL0xNoFv8tI5Qal4KiM+xSbShsFqgM+WuM/bC6tNslrAH9GtnryEzY/vouEz4/nAIwH7rcmAoXma0X6oXF6y/oFFdI7mRCYhys=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4319.namprd11.prod.outlook.com (2603:10b6:208:193::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Fri, 12 Jun 2020 20:03:13 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290%7]) with mapi id 15.20.3088.025; Fri, 12 Jun 2020 20:03:13 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: Netconf <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts
Thread-Index: AQHWOThTTo+30icCv0mQD3Parb0A+ajVR//QgAApLlA=
Date: Fri, 12 Jun 2020 20:03:13 +0000
Message-ID: <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com>
In-Reply-To: <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3e37d452-bcc6-44d2-3200-08d80f0ba39d
x-ms-traffictypediagnostic: MN2PR11MB4319:
x-microsoft-antispam-prvs: <MN2PR11MB4319CA3F5B0DF77C990E8AB7A1810@MN2PR11MB4319.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0432A04947
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: g7eueksiydMoUtSFn8QLWDLQ2xO1czkoAi6fqqcyKluMIsxr2nGvX24csvDoBfzNUVh1vP/dIP1jWs72IyQ1E5WcCZmGLQsoNneaCP2vh0nYB00S3KxTVi9chxFz/RbePy5irNO+GWJJknuAHbE/B/knIYb6bM7kx87ntdWhDSu/9kVNZ21jWOp0vJWH/2aLL0E0d+nz7elUOQhJEqfFSYu7kskQY1J74gtArwIfpky7plAM1vl5HMsdF8oSW6xWjXrG5a9GbKmHmSoEUEqE9f1XgidtFhYm7aoq1quucXKgtCeZWadTNoRs/XxwSYWTzcrRNqvUfPHGFYB4/jDkeb3Zvai2OROwoS4SYrCw1u8uILQESnbvZA3YUTuMtHOYH+/ob3sUw4Hf5oVGapti44Vj/ocey3pH9/FNszwSPJXIMv2URm0xUIccq8Durz/WBulxTE1q2fR+A1yie0tzViOXKU9PhO2uV6rmDjLgJ6U=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(376002)(346002)(366004)(136003)(396003)(39860400002)(186003)(9686003)(2906002)(86362001)(33656002)(99936003)(55016002)(966005)(4326008)(478600001)(8676002)(26005)(64756008)(5660300002)(8936002)(316002)(53546011)(66446008)(76116006)(6506007)(52536014)(2940100002)(7696005)(66616009)(66476007)(83380400001)(9326002)(66556008)(71200400001)(66946007)(43620500001)(15398625002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: iX7EyDMKYe2aqob1kkS7dbvODKAvlBYZcRVAn3VtZA/7xdIVZHqenCquJZM3ryxBPObaz1CaBFRwHHgAA+okQQnuUj8/iOETAVlModPQQFX2neMzbcaZ5QHvOH6nNTkLMq8gTfWrtruimYKJl/juAqB+qMlHceYhvq1L69aEa5jd47DK4HLSCzPGBVdt4dk/ISBbBNEm7kGrILpD7RMI4civ8ZXD7AHyOM17Q5KjzKaivKpnOcDYf6UIAXfePOUeA0339+MQjJrQJF1mo8gphXSDc3tKsxOhI91yF8xfdvmGWSE5UpKygEZwbEKnbyfatF4gYoRioI0vXQKvfHhfIL+A6sCmDnnk6AvFEiwvTX1B0gQYeyoDoVQd9682vANaU5Gkh3eQlOtSvimNQIpoCMHE6zkcZc1Os0QJ1R0BaJ7bqDFmG+7LAB4J0Cgaog5yDhNFMVYB9yCVYNqDzyHCYkBTUPkEprWcZmHg/QioPjiEMSPep47ewkR4LSL03BNW
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_073E_01D640D2.F54DE140"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e37d452-bcc6-44d2-3200-08d80f0ba39d
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 20:03:13.5253 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wonG2kKox3bGFL0SMAeApPU2jWmYPwtcLwKYz8ET3S2qxZAnSlKnU7jmcHgtce7g
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4319
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/W8JbJj3Ef2DJerro_l-ZhgXSZXY>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2020 20:03:56 -0000

------=_NextPart_000_073E_01D640D2.F54DE140
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_073F_01D640D2.F54DE140"


------=_NextPart_001_073F_01D640D2.F54DE140
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Kent,

 

I have been reading farther, and I see that the full
iana-hash-algs@2020-03-08.yang has been removed from -v15.  That is where
the TCG identity algorithms might have been merged in my thread below.

 

A few thought based on that:

 

(1) In the draft-ietf-netconf-crypto-types, in the YANG model you should
likely remove the description text which claims support for "algorithm" in
three of the grouping statements.

 

(2) Are there plans to evolve iana-hash-algo.yang anywhere?  In your May
14th message, you  say :  "Assuming a future effort mimicked Option #2, then
"yes", as I'd expect an "ietf-ssh-common:generate-asymmetric-key" RPC to
contain an "input" node that is an identityref to the
"ssh-asymmetric-algorithm" identity.".   I would be willing to help on that
work.

 

 

Thanks,

Eric

 

 

 

> -----Original Message-----

> From: netconf <netconf-bounces@ietf.org> On Behalf Of Eric Voit (evoit)

> Sent: Friday, June 12, 2020 1:42 PM

> To: Kent Watsen <kent+ietf@watsen.net>

> Cc: Netconf <netconf@ietf.org>

> Subject: Re: [netconf] WG LC for three drafts

> 

> Hi Kent,

> 

> I have been reading draft-ietf-netconf-crypto-types, and the thread:

Virtual

> "hum" for the "key generation" issue discussed at virtual meeting.

> 

> I have a couple questions on the previous "asymmetric-algorithm-type"  and

> what is now in "asymmetric-key-pair-grouping".  My reading is that instead

> of the previous ENUMs of -v14, other applications/WGs will now need to

> create identities for the various algorithm types.  And this is fine.

> 

> If I have this correct, then each of the TCG Algorithm Registry ID values

of

> TPM2 specifications in Table 9

> https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-

> Part-2-

> Structures-01.38.pdf

> could have its own identity.   And there would be no barrier to each of

> these identities also having another base identity that might be "tpm2-

> algorithm".  In this correct?

> 

> If this is correct, my second question is whether there will be an attempt

to

> ask other YANG models to import these application identities elsewhere?

> As you and Rob note in the thread, trying to predict the desired identity

> inheritance hierarchy is non-trivial.

> 

> Thanks,

> Eric

> 

> > -----Original Message-----

> > From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh

> > Jethanandani

> > Sent: Tuesday, June 2, 2020 7:48 PM

> > To: Netconf <netconf@ietf.org>

> > Subject: [netconf] WG LC for three drafts

> >

> > NETCONF WG,

> >

> > The authors of

> >

> > - draft-ietf-netconf-crypto-types

> > - draft-ietf-netconf-keystore

> > - draft-ietf-netconf-trust-anchors

> >

> > have indicated that these drafts are ready for Last Call (LC).

> >

> > This kicks of a 2 week WG LC for the three drafts. Please review and

> > send

> any

> > comments to the WG mailing list or by responding to this e-mail.

> > Comments can be statements such as, I read/reviewed the document and

> > believe it is ready for publication, or I have concerns about the

> > document. For the

> latter,

> > please indicate what your concerns are.

> >

> > Any reports on implementation status or plans to implement are also

> > very useful.

> >

> > Thanks.

> >

> > Mahesh Jethanandani (as co-chair)

> > mjethanandani@gmail.com

> >

> >

> >

> > _______________________________________________

> > netconf mailing list

> > netconf@ietf.org

> > https://www.ietf.org/mailman/listinfo/netconf


------=_NextPart_001_073F_01D640D2.F54DE140
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 15 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri",sans-serif;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US =
link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1><p =
class=3DMsoPlainText>Hi Kent,<o:p></o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>I have =
been reading farther, and I see that the full =
iana-hash-algs@2020-03-08.yang has been removed from -v15.&nbsp; That is =
where the TCG identity algorithms might have been merged in my thread =
below.<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText>A few thought based on that:<o:p></o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>(1) In =
the draft-ietf-netconf-crypto-types, in the YANG model you should likely =
remove the description text which claims support for =
&quot;algorithm&quot; in three of the grouping =
statements.<o:p></o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>(2) =
Are there plans to evolve iana-hash-algo.yang anywhere?&nbsp; In your =
May 14th message, you &nbsp;say :&nbsp; &quot;<span =
style=3D'color:#70AD47'>Assuming a future effort mimicked Option #2, =
then &quot;yes&#8221;, as I&#8217;d expect an =
&quot;ietf-ssh-common:generate-asymmetric-key&#8221; RPC to contain an =
&#8220;input&#8221; node that is an identityref to the =
&#8220;ssh-asymmetric-algorithm&#8221; =
identity.&quot;</span>.&nbsp;&nbsp; I would be willing to help on that =
work.<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText>Thanks,<o:p></o:p></p><p =
class=3DMsoPlainText>Eric<o:p></o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>&gt; =
-----Original Message-----<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
From: netconf &lt;netconf-bounces@ietf.org&gt; On Behalf Of Eric Voit =
(evoit)<o:p></o:p></p><p class=3DMsoPlainText>&gt; Sent: Friday, June =
12, 2020 1:42 PM<o:p></o:p></p><p class=3DMsoPlainText>&gt; To: Kent =
Watsen &lt;kent+ietf@watsen.net&gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; Cc: Netconf =
&lt;netconf@ietf.org&gt;<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
Subject: Re: [netconf] WG LC for three drafts<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; <o:p></o:p></p><p class=3DMsoPlainText>&gt; Hi =
Kent,<o:p></o:p></p><p class=3DMsoPlainText>&gt; <o:p></o:p></p><p =
class=3DMsoPlainText>&gt; I have been reading =
draft-ietf-netconf-crypto-types, and the thread:<o:p></o:p></p><p =
class=3DMsoPlainText>Virtual<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&quot;hum&quot; for the &quot;key generation&quot; issue discussed at =
virtual meeting.<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
<o:p></o:p></p><p class=3DMsoPlainText>&gt; I have a couple questions on =
the previous &quot;asymmetric-algorithm-type&quot;&nbsp; =
and<o:p></o:p></p><p class=3DMsoPlainText>&gt; what is now in =
&quot;asymmetric-key-pair-grouping&quot;.&nbsp; My reading is that =
instead<o:p></o:p></p><p class=3DMsoPlainText>&gt; of the previous ENUMs =
of -v14, other applications/WGs will now need to<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; create identities for the various algorithm =
types.&nbsp; And this is fine.<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; <o:p></o:p></p><p class=3DMsoPlainText>&gt; If =
I have this correct, then each of the TCG Algorithm Registry ID =
values<o:p></o:p></p><p class=3DMsoPlainText>of<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; TPM2 specifications in Table =
9<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-<o:p=
></o:p></p><p class=3DMsoPlainText>&gt; Part-2-<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; Structures-01.38.pdf<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; could have its own identity.&nbsp;&nbsp; And =
there would be no barrier to each of<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; these identities also having another base =
identity that might be &quot;tpm2-<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; algorithm&quot;.&nbsp; In this =
correct?<o:p></o:p></p><p class=3DMsoPlainText>&gt; <o:p></o:p></p><p =
class=3DMsoPlainText>&gt; If this is correct, my second question is =
whether there will be an attempt<o:p></o:p></p><p =
class=3DMsoPlainText>to<o:p></o:p></p><p class=3DMsoPlainText>&gt; ask =
other YANG models to import these application identities =
elsewhere?<o:p></o:p></p><p class=3DMsoPlainText>&gt; As you and Rob =
note in the thread, trying to predict the desired =
identity<o:p></o:p></p><p class=3DMsoPlainText>&gt; inheritance =
hierarchy is non-trivial.<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
<o:p></o:p></p><p class=3DMsoPlainText>&gt; Thanks,<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; Eric<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; <o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&gt; -----Original Message-----<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; From: netconf =
&lt;netconf-bounces@ietf.org&gt; On Behalf Of Mahesh<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; Jethanandani<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; Sent: Tuesday, June 2, 2020 7:48 =
PM<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; To: Netconf =
&lt;netconf@ietf.org&gt;<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; =
Subject: [netconf] WG LC for three drafts<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; NETCONF WG,<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; The authors of<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; - =
draft-ietf-netconf-crypto-types<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; - =
draft-ietf-netconf-keystore<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&gt; - draft-ietf-netconf-trust-anchors<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; have indicated that these drafts are =
ready for Last Call (LC).<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&gt;<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; This kicks of a 2 =
week WG LC for the three drafts. Please review and<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; send<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; any<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&gt; comments to the WG mailing list or by responding to this =
e-mail.<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; Comments can be =
statements such as, I read/reviewed the document and<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; believe it is ready for publication, or I =
have concerns about the<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; =
document. For the<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
latter,<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; please indicate =
what your concerns are.<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&gt;<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; Any reports on =
implementation status or plans to implement are also<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; very useful.<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; Thanks.<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; Mahesh Jethanandani (as =
co-chair)<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; =
mjethanandani@gmail.com<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&gt;<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; =
_______________________________________________<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; netconf mailing list<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; netconf@ietf.org<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; =
https://www.ietf.org/mailman/listinfo/netconf<o:p></o:p></p></div></body>=
</html>
------=_NextPart_001_073F_01D640D2.F54DE140--

------=_NextPart_000_073E_01D640D2.F54DE140
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw
ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz
Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX
DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g
Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2
tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI
zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl
zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS
qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk
UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD
VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB
BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO
VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup
SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p
+slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg
lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA
AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD
aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD
VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz
guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I
4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG
VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+
FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ
BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC
NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j
BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j
aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG
CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw
NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3
LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF
AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo
0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp
9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt
U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ
MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04
96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv
eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg
Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw
EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM
D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE
S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO
yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M
mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v
Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp
W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB
Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v
c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp
c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E
MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV
HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G
A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr
+GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ
KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0
JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f
1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG
+gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG
A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjEyMjAwMzA1WjAjBgkqhkiG
9w0BCQQxFgQUyyWPWPmm+hXcUbTOCw097nBuYDAwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK
EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN
AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK
AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw
CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH
BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B
AQEFAASCAQBdpPL6IlU2wIEd3ZejtRwPaVW2AKWm5TkR7hZO5COOONF5/6hcYOQKvkVWDRtpsBeB
evECls4ZO0aEdCo/2iK1YbXD1o5VyN0y2clRGGZKHlah9EpAXB5nkE20f6+M4dMR9FnioWlhbl0n
OAZIwRH8YTYDZ4WHmxA3d53tvHp3raafTzmt8SJ8r3Ob8fuRCxFg+ymrxXbBE17wHvSg1qtZhtyu
h/9g9anBujoDVlNTIK592h9p2fDvD3g8NyIh7wHpHPz0q9m1Z+BzILt4z/XJymX+IfhxfOE29+Uk
zyzSR/GytQipHIu+4RFj7HH4dYHdKXU2x5L/oFWIChsnJLkQAAAAAAAA

------=_NextPart_000_073E_01D640D2.F54DE140--


From nobody Sat Jun 13 04:29:55 2020
Return-Path: <ietfc@btconnect.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADF93A07E9 for <netconf@ietfa.amsl.com>; Sat, 13 Jun 2020 04:29:53 -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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Xa-c71_9zX7t for <netconf@ietfa.amsl.com>; Sat, 13 Jun 2020 04:29:51 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50111.outbound.protection.outlook.com [40.107.5.111]) (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 7E5BB3A07EC for <netconf@ietf.org>; Sat, 13 Jun 2020 04:29:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HK3DF7XZfbuQt8dqrXo756IU7Mpt61ZOzVCtHTkKkk+3LtqDgTzYd9mpmPCqV9pTrFjB06fhLIG+uz704cOHAs1w3NlxL3HblBS3tlPgxlGaq7mMMMOEu0lQrtPz+x8z3M/Mo97pJHZ/l7DCykYMz8771dVDHIPintDuBJxU+p0nRTyMUBGyyal48FU2bkdi/gPWF8cKSCqjJNANSf93ed4YEc3LmpdKuCc+cz8KOkoTetAbTNQZ1407e03fYYEszfXHsWfmxCIYaTBjrdRpRlR/wj9+yxa4yprqR3sJkQIr11BSC8yUHxwBkGkikRXMyPypwE/vM1AsCOq3QbgmTA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tfXkYhfy3S3kQGrGCXUV5iGOjEIQChHg3hcED1eMiXc=; b=SO1as+kpSFyI1XvAAkRuCbnQNzCWLpfp+/519zFfouKzmoCKcm6BUKLpiOIFhf8Zb3418dHzibnkH/6ymm6++cCwJ/VOgK+dRFRqkuX/97QIQCbxXdygSUp9gFFnujY6eftVqLQiZkP9aDQrLLVvyFtBciLxCODrOoHw9OQqniwTEZLoIzzvU09XLUISJcQSiFUG9Xf/kHPOHM9hELJblVnrYKBa1FEvurubJr6MZfs2bWFBUqKREZxP6h3yejf6frKdAycaW5j0yWsBnWMgd7IZnqAhAVqOGPyom4mM2SryUQst+sR82xI25HdSCaTWjCE+RA8rdCKXLVfjhEMtew==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tfXkYhfy3S3kQGrGCXUV5iGOjEIQChHg3hcED1eMiXc=; b=JDOuaCUSzwO2Wu1TlCownkj/LE24N6fYmiYF0QnI03MLKcu3vn/aKMbzzfGmOSZwxEcxWer7vWsd7XeIqj3W0BBh226rTb5GCBOuQGsYWPcvxUEskO95hkY4DIFh8Dr3r+w63ez8Tb/oZxFHBmX+Ux3rneEXTDCRlc5qm0wDMZs=
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com (2603:10a6:10:198::14) by DB7PR07MB4602.eurprd07.prod.outlook.com (2603:10a6:5:33::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.13; Sat, 13 Jun 2020 11:29:48 +0000
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65]) by DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65%7]) with mapi id 15.20.3109.012; Sat, 13 Jun 2020 11:29:48 +0000
From: tom petch <ietfc@btconnect.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: Netconf <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts or two of them
Thread-Index: AQHWQXXxqA+PBQ9xTESoskd/uJ8I1Q==
Date: Sat, 13 Jun 2020 11:29:47 +0000
Message-ID: <DBAPR07MB7016F753766FCE8AD12A2F5DA09E0@DBAPR07MB7016.eurprd07.prod.outlook.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com>, <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com>
In-Reply-To: <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.139.211.47]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d712a1d0-f7e9-4131-45ec-08d80f8d1472
x-ms-traffictypediagnostic: DB7PR07MB4602:
x-microsoft-antispam-prvs: <DB7PR07MB4602A12A5CB3F54E93D4D734A09E0@DB7PR07MB4602.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0433DB2766
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: BHXzNIL7Mrxyd04PMXCdscHIq3j2HJttc9Zl0VVwhRztuSA4705c4Vhn8b93JKv42S1el0rxDX4p0P+oPXafbYNas0SQCFxj/Uc54JcNHt123lXH99EqnW6INYJ7AvC2XqCroJY8c9NR5o0+0T5pi96vmsY1vuaCWTNjB0cBozoNNfbOe/fHOaBSC8HZMY2ZCprvaRKb1JODB6MDmwdcVwFIM4rBRplPmb/YXr8tChPNdVBtiO7Maxbjo74WZ9sWQeabO3zuysucLIlfTLS80sUv4IRm9T6FB/unztIa8TUxDY4v5Pa2jwu2ibzOA0SFt2tu+OvzD1dHZ5Ayj9zCMoEfbFObjqeUvZl02CTI2i6xBgw6OzcMTiP1C5zp0hLKYp4RbVr/oEJDU+BPXufZrw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DBAPR07MB7016.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(39860400002)(346002)(136003)(366004)(376002)(396003)(8936002)(76116006)(71200400001)(91956017)(33656002)(966005)(66446008)(26005)(66946007)(55016002)(64756008)(66476007)(66556008)(6506007)(52536014)(53546011)(478600001)(86362001)(8676002)(83380400001)(186003)(2906002)(9686003)(5660300002)(316002)(7696005)(4326008); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: V73h7YgS6IaR+DYT7M7/Fj1HNaJngZ8Rmk9D56l5kysMR84oBFUudDzTQiTtTkvgfMuF8/equL7md2J1JsPV0uCYV/wDrplGYcgM9cIIAexvBTbF+rNIuFv0AjNwwO5Rd25Cdn66P3FUBTx8J9KWUPHcfYEaHwSdTyxpE/6fFLNT3x2OSStcR0nRxUSUYGV3dMVMgxnQjFCiKQeptJ91QcH6MAZvEmpO11r3cLDhtNIJRqfXy/5rZAOFOfDuad/iCLcm3+pw1FgOygxvvulbDuAQchGadXet+jfxJ6FaOfxpJDSbKSjUL0T+QwXmG1PElSDDUm+YxQvZVTAQQMLKV3O+Eiv5RRD44ftf1XjKj86VI/Hyduq8/koDIilq9FcQFCiMeX2ouhwQMy8IrnPWly+bBwqnFOY2qsTbheBpzEF7rzU1zkwc9sc1lw6luSmhGu72jDhPZOuJy84BrxJ4pT3e6LEbNMC+JiyUZV4UpfA=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d712a1d0-f7e9-4131-45ec-08d80f8d1472
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2020 11:29:47.7971 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jvY0DOeTnfJRgOq4J8gic1iCJCQAfssoSzoym2fMSarqG9fq2g+uHdCNKPydtUhUVbM09Sa3xY5fddXx8c7zUw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4602
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/37PkqqyWah2Rk2lGXd8bRC6wJtk>
Subject: Re: [netconf] WG LC for three drafts or two of them
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jun 2020 11:29:54 -0000

I have concerns about trust-anchors and crypto-types.  They are both more o=
r less non-existent when it comes to text.  I do not want to have to revers=
e engineer the YANG or XML to find out what RPC or action there are, what t=
ypes of cipher suites and such like are supported - and perhaps those that =
are not such as raw keys.  I would expect there to be five or ten pages of =
such in each.  Look for example at layer0-types or layer1-types for modules=
 with what I would regard as adequate text.=0A=
=0A=
Tom Petch=0A=
=0A=
From: netconf <netconf-bounces@ietf.org> on behalf of Eric Voit (evoit) <ev=
oit=3D40cisco.com@dmarc.ietf.org>=0A=
Sent: 12 June 2020 21:03=0A=
=0A=
> > -----Original Message-----=0A=
=0A=
> > From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh=0A=
=0A=
> > Jethanandani=0A=
=0A=
> > Sent: Tuesday, June 2, 2020 7:48 PM=0A=
=0A=
> > To: Netconf <netconf@ietf.org>=0A=
=0A=
> > Subject: [netconf] WG LC for three drafts=0A=
=0A=
> >=0A=
=0A=
> > NETCONF WG,=0A=
=0A=
> >=0A=
=0A=
> > The authors of=0A=
=0A=
> >=0A=
=0A=
> > - draft-ietf-netconf-crypto-types=0A=
=0A=
> > - draft-ietf-netconf-keystore=0A=
=0A=
> > - draft-ietf-netconf-trust-anchors=0A=
=0A=
> >=0A=
=0A=
> > have indicated that these drafts are ready for Last Call (LC).=0A=
=0A=
> >=0A=
=0A=
> > This kicks of a 2 week WG LC for the three drafts. Please review and=0A=
=0A=
> > send=0A=
=0A=
> any=0A=
=0A=
> > comments to the WG mailing list or by responding to this e-mail.=0A=
=0A=
> > Comments can be statements such as, I read/reviewed the document and=0A=
=0A=
> > believe it is ready for publication, or I have concerns about the=0A=
=0A=
> > document. For the=0A=
=0A=
> latter,=0A=
=0A=
> > please indicate what your concerns are.=0A=
=0A=
> >=0A=
=0A=
> > Any reports on implementation status or plans to implement are also=0A=
=0A=
> > very useful.=0A=
=0A=
> >=0A=
=0A=
> > Thanks.=0A=
=0A=
> >=0A=
=0A=
> > Mahesh Jethanandani (as co-chair)=0A=
=0A=
> > mjethanandani@gmail.com=0A=
=0A=
> >=0A=
=0A=
> >=0A=
=0A=
> >=0A=
=0A=
> > _______________________________________________=0A=
=0A=
> > netconf mailing list=0A=
=0A=
> > netconf@ietf.org=0A=
=0A=
> > https://www.ietf.org/mailman/listinfo/netconf=0A=


From nobody Mon Jun 15 07:35:33 2020
Return-Path: <01000172b867d075-422297fc-0982-4464-91f3-edd5c9bce6fb-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E8A3A0E26 for <netconf@ietfa.amsl.com>; Mon, 15 Jun 2020 07:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 ulJYfphcDvrZ for <netconf@ietfa.amsl.com>; Mon, 15 Jun 2020 07:35:24 -0700 (PDT)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A49D3A0DF0 for <netconf@ietf.org>; Mon, 15 Jun 2020 07:35:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1592231711; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=oUV0B7OApnDGyeXl371NSyVJA+PwrVrLtoEH5KvAaTw=; b=TQasTFZiMo3oh9LIbCoKM4K5PEaxEq8M/e508Dst34fe6Zf40BM4rjK/Jgy7Jl0M 8xhZItbBSz6jAeH/CuYexm6hhc9mrg+oG4LzSCa+tiU4v2eN5yTwcFAvTe7VbtN+ORo ZKtNfS7J0lD9Bpd/6pZtSGt5QRDY/3+4shCcFhko=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000172b867d075-422297fc-0982-4464-91f3-edd5c9bce6fb-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_904B8E49-53BB-4EB5-BA38-46B0A2878A52"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 15 Jun 2020 14:35:10 +0000
In-Reply-To: <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: "Eric Voit (evoit)" <evoit@cisco.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.15-54.240.48.90
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Dl4TxZsaaYAPnJz4B4WtAtxtwxQ>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2020 14:35:32 -0000

--Apple-Mail=_904B8E49-53BB-4EB5-BA38-46B0A2878A52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Eric,

Thank you for your review.  This message addresses both your prior =
messages=E2=80=A6



> On Jun 12, 2020, at 4:03 PM, Eric Voit (evoit) <evoit@cisco.com> =
wrote:
>=20
> Hi Kent,
> =20
> I have been reading farther, and I see that the full =
iana-hash-algs@2020-03-08.yang has been removed from -v15.  That is =
where the TCG identity algorithms might have been merged in my thread =
below.
> =20
> A few thought based on that:
> =20
> (1) In the draft-ietf-netconf-crypto-types, in the YANG model you =
should likely remove the description text which claims support for =
"algorithm" in three of the grouping statements.

Good catch!  Fixed here:

=
https://github.com/netconf-wg/crypto-types/commit/690c016b201241e13a1e324b=
49ba5e9db0d6c417 =
<https://github.com/netconf-wg/crypto-types/commit/690c016b201241e13a1e324=
b49ba5e9db0d6c417>


>  (2) Are there plans to evolve iana-hash-algo.yang anywhere?  In your =
May 14th message, you  say :  "Assuming a future effort mimicked Option =
#2, then "yes=E2=80=9D, as I=E2=80=99d expect an =
"ietf-ssh-common:generate-asymmetric-key=E2=80=9D RPC to contain an =
=E2=80=9Cinput=E2=80=9D node that is an identityref to the =
=E2=80=9Cssh-asymmetric-algorithm=E2=80=9D identity.".   I would be =
willing to help on that work.

I have no plans to work on the "algorithms=E2=80=9D problem again.  Not =
that I wouldn=E2=80=99t like to, but I need to scale back how much =
unsupported time I volunteer for.  Generally speaking, I=E2=80=99m =
gracefully winding down my work in progress, while being hyper-cautious =
about signing up for new work.  This is why, e.g., I=E2=80=99m not =
pushing "YANG-next=E2=80=9D or =E2=80=9Crestconf-collections=E2=80=9D =
anymore, though both are really important to me.  That said, I=E2=80=99m =
open to contract-work, if that makes sense at all...

More below.

> =20
> Thanks,
> Eric
> =20
> =20
> =20
> > -----Original Message-----
> > From: netconf <netconf-bounces@ietf.org> On Behalf Of Eric Voit =
(evoit)
> > Sent: Friday, June 12, 2020 1:42 PM
> > To: Kent Watsen <kent+ietf@watsen.net>
> > Cc: Netconf <netconf@ietf.org>
> > Subject: Re: [netconf] WG LC for three drafts
> >
> > Hi Kent,
> >
> > I have been reading draft-ietf-netconf-crypto-types, and the thread:
> Virtual
> > "hum" for the "key generation" issue discussed at virtual meeting.
> >
> > I have a couple questions on the previous =
"asymmetric-algorithm-type"  and
> > what is now in "asymmetric-key-pair-grouping".  My reading is that =
instead
> > of the previous ENUMs of -v14, other applications/WGs will now need =
to
> > create identities for the various algorithm types.  And this is =
fine.


That was the idea at the time but, as you noticed, we since ditched the =
=E2=80=9Calgorithms=E2=80=9D node altogether  :sigh:


> > If I have this correct, then each of the TCGAlgorithm Registry ID =
values
> of
> > TPM2 specifications in Table 9
> > =
https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-
> > Part-2-
> > Structures-01.38.pdf
> > could have its own identity.   And there would be no barrier to each =
of
> > these identities also having another base identity that might be =
"tpm2-
> > algorithm".  In this correct?

I believe so.  I haven=E2=80=99t looked at the TCG Algorithm Registry, =
but certainly, "identity-stmt=E2=80=9D allows multiple "base-stmt".   =
Some might be concerned for interoperability, but a solution might =
support polymorphic definitions.  Regardless, the original plan was (and =
I assume would be again, if/when the work is picked up) to enable the =
server to specify (e.g., via a =E2=80=9Cconfig false=E2=80=9D list) =
which algorithms it supports.


> > If this is correct, my second question is whether there will be an =
attempt
> to
> > ask other YANG models to import these application identities =
elsewhere?
> > As you and Rob note in the thread, trying to predict the desired =
identity
> > inheritance hierarchy is non-trivial.

I=E2=80=99m unsure about this, but I think polymorphism would go a long =
way to alleviate the issue...


Kent // as a contributor


> >
> > Thanks,
> > Eric
> >
> > > -----Original Message-----
> > > From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh
> > > Jethanandani
> > > Sent: Tuesday, June 2, 2020 7:48 PM
> > > To: Netconf <netconf@ietf.org>
> > > Subject: [netconf] WG LC for three drafts
> > >
> > > NETCONF WG,
> > >
> > > The authors of
> > >
> > > - draft-ietf-netconf-crypto-types
> > > - draft-ietf-netconf-keystore
> > > - draft-ietf-netconf-trust-anchors
> > >
> > > have indicated that these drafts are ready for Last Call (LC).
> > >
> > > This kicks of a 2 week WG LC for the three drafts. Please review =
and
> > > send
> > any
> > > comments to the WG mailing list or by responding to this e-mail.
> > > Comments can be statements such as, I read/reviewed the document =
and
> > > believe it is ready for publication, or I have concerns about the
> > > document. For the
> > latter,
> > > please indicate what your concerns are.
> > >
> > > Any reports on implementation status or plans to implement are =
also
> > > very useful.
> > >
> > > Thanks.
> > >
> > > Mahesh Jethanandani (as co-chair)
> > > mjethanandani@gmail.com
> > >
> > >
> > >
> > > _______________________________________________
> > > netconf mailing list
> > > netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf


--Apple-Mail=_904B8E49-53BB-4EB5-BA38-46B0A2878A52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Hi =
Eric,<div class=3D""><br class=3D""></div><div class=3D"">Thank you for =
your review. &nbsp;This message addresses both your prior =
messages=E2=80=A6</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""><div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D"">On Jun 12, 2020, at 4:03 PM, Eric Voit =
(evoit) &lt;<a href=3D"mailto:evoit@cisco.com" =
class=3D"">evoit@cisco.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><meta =
http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii" =
class=3D""><meta name=3D"Generator" content=3D"Microsoft Word 15 =
(filtered medium)" class=3D""><style class=3D""><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri",sans-serif;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--><div lang=3D"EN-US" link=3D"#0563C1" =
vlink=3D"#954F72" class=3D""><div class=3D"WordSection1"><p =
class=3D"MsoPlainText">Hi Kent,<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText"><o:p class=3D"">&nbsp;</o:p></p><p =
class=3D"MsoPlainText">I have been reading farther, and I see that the =
full <a href=3D"mailto:iana-hash-algs@2020-03-08.yang" =
class=3D"">iana-hash-algs@2020-03-08.yang</a> has been removed from =
-v15.&nbsp; That is where the TCG identity algorithms might have been =
merged in my thread below.<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText"><o:p class=3D"">&nbsp;</o:p></p><p =
class=3D"MsoPlainText">A few thought based on that:<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText"><o:p =
class=3D"">&nbsp;</o:p></p><p class=3D"MsoPlainText">(1) In the =
draft-ietf-netconf-crypto-types, in the YANG model you should likely =
remove the description text which claims support for "algorithm" in =
three of the grouping =
statements.</p></div></div></div></blockquote><div><br =
class=3D""></div><div>Good catch! &nbsp;Fixed here:</div><div><br =
class=3D""></div><div><a =
href=3D"https://github.com/netconf-wg/crypto-types/commit/690c016b201241e1=
3a1e324b49ba5e9db0d6c417" =
class=3D"">https://github.com/netconf-wg/crypto-types/commit/690c016b20124=
1e13a1e324b49ba5e9db0d6c417</a></div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div lang=3D"EN-US" =
link=3D"#0563C1" vlink=3D"#954F72" class=3D""><div =
class=3D"WordSection1"><p class=3D"MsoPlainText"><o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText"><o:p =
class=3D"">&nbsp;</o:p><span style=3D"font-size: 11pt;" class=3D"">(2) =
Are there plans to evolve iana-hash-algo.yang anywhere?&nbsp; In your =
May 14th message, you &nbsp;say :&nbsp; "</span><span class=3D"" =
style=3D"font-size: 11pt; color: rgb(142, 218, 91);">Assuming a future =
effort mimicked Option #2, then "yes=E2=80=9D, as I=E2=80=99d expect an =
"ietf-ssh-common:generate-asymmetric-key=E2=80=9D RPC to contain an =
=E2=80=9Cinput=E2=80=9D node that is an identityref to the =
=E2=80=9Cssh-asymmetric-algorithm=E2=80=9D identity."</span><span =
style=3D"font-size: 11pt;" class=3D"">.&nbsp;&nbsp; I would be willing =
to help on that work.</span></p></div></div></blockquote><div><br =
class=3D""></div><div>I have no plans to work on the "algorithms=E2=80=9D =
problem again. &nbsp;Not that I wouldn=E2=80=99t like to, but I need to =
scale back how much unsupported time I<font color=3D"#000000" =
class=3D"">&nbsp;volunteer for. &nbsp;Generally speaking, =
I=E2=80=99m&nbsp;gracefully winding down my work in progress, while =
being hyper-cautious about signing up for new work. &nbsp;This is why, =
e.g., I=E2=80=99m not pushing "YANG-next<span style=3D"caret-color: =
rgb(0, 0, 0);" =
class=3D"">=E2=80=9D</span>&nbsp;or&nbsp;=E2=80=9Crestconf-collections=E2=80=
=9D anymore, though both are really important to me. &nbsp;That said, =
I=E2=80=99m open to contract-work, if that makes sense at =
all...</font></div><div><br class=3D""></div><div>More below.</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div lang=3D"EN-US" =
link=3D"#0563C1" vlink=3D"#954F72" class=3D""><div =
class=3D"WordSection1"><p class=3D"MsoPlainText"><o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText"><o:p =
class=3D"">&nbsp;</o:p></p><p class=3D"MsoPlainText">Thanks,<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">Eric<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText"><o:p =
class=3D"">&nbsp;</o:p></p><p class=3D"MsoPlainText"><o:p =
class=3D"">&nbsp;</o:p></p><p class=3D"MsoPlainText"><o:p =
class=3D"">&nbsp;</o:p></p><p class=3D"MsoPlainText">&gt; -----Original =
Message-----<o:p class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; =
From: netconf &lt;<a href=3D"mailto:netconf-bounces@ietf.org" =
class=3D"">netconf-bounces@ietf.org</a>&gt; On Behalf Of Eric Voit =
(evoit)<o:p class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; Sent: =
Friday, June 12, 2020 1:42 PM<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; To: Kent Watsen &lt;<a =
href=3D"mailto:kent+ietf@watsen.net" =
class=3D"">kent+ietf@watsen.net</a>&gt;<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; Cc: Netconf &lt;<a =
href=3D"mailto:netconf@ietf.org" class=3D"">netconf@ietf.org</a>&gt;<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; Subject: Re: =
[netconf] WG LC for three drafts<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; <o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; Hi Kent,<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; <o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; I have been reading =
draft-ietf-netconf-crypto-types, and the thread:<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">Virtual<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; "hum" for the "key =
generation" issue discussed at virtual meeting.<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; <o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; I have a couple =
questions on the previous "asymmetric-algorithm-type"&nbsp; and<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; what is now in =
"asymmetric-key-pair-grouping".&nbsp; My reading is that instead<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; of the previous =
ENUMs of -v14, other applications/WGs will now need to<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; create identities =
for the various algorithm types.&nbsp; And this is =
fine.</p></div></div></blockquote><div><br class=3D""></div><div><br =
class=3D""></div>That was the idea at the time but, as you noticed, we =
since ditched the =E2=80=9Calgorithms=E2=80=9D node altogether =
&nbsp;:sigh:</div><div><br class=3D""></div><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div lang=3D"EN-US" =
link=3D"#0563C1" vlink=3D"#954F72" class=3D""><div =
class=3D"WordSection1"><p class=3D"MsoPlainText"><o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; If I have this =
correct, then each of the TCG<span style=3D"font-size: 11pt;" =
class=3D"">Algorithm Registry</span><span style=3D"font-size: 11pt;" =
class=3D"">&nbsp;ID =
values</span></p></div></div></blockquote><blockquote type=3D"cite" =
class=3D""><div lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72" =
class=3D""><div class=3D"WordSection1"><p class=3D"MsoPlainText"><o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">of<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; TPM2 specifications =
in Table 9<o:p class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; <a =
href=3D"https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2=
.0-" =
class=3D"">https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Re=
v-2.0-</a><o:p class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; =
Part-2-<o:p class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; =
Structures-01.38.pdf<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; could have its own identity.&nbsp;&nbsp; And =
there would be no barrier to each of<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; these identities also having another base =
identity that might be "tpm2-<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; algorithm".&nbsp; In this =
correct?</p></div></div></blockquote><div><br class=3D""></div><div>I =
believe so. &nbsp;I haven=E2=80=99t looked at the TCG Algorithm =
Registry, but certainly, "identity-stmt=E2=80=9D allows multiple =
"base-stmt". &nbsp; Some might be concerned for interoperability, but a =
solution might support polymorphic definitions. &nbsp;Regardless, the =
original plan was (and I assume would be again, if/when the work is =
picked up) to enable the server to specify (e.g., via a =E2=80=9Cconfig =
false=E2=80=9D list) which algorithms it supports.</div><div><br =
class=3D""></div><div><br class=3D""></div><blockquote type=3D"cite" =
class=3D""><div lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72" =
class=3D""><div class=3D"WordSection1"><p class=3D"MsoPlainText"><o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; If this is correct, =
my second question is whether there will be an attempt<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">to<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; ask other YANG =
models to import these application identities elsewhere?<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; As you and Rob note =
in the thread, trying to predict the desired identity<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; inheritance =
hierarchy is non-trivial.</p></div></div></blockquote><div><br =
class=3D""></div>I=E2=80=99m unsure about this, but I think polymorphism =
would go a long way to alleviate the issue...</div><div><br =
class=3D""></div><div><br class=3D""></div><div>Kent // as a =
contributor</div><div><br class=3D""></div><div><br class=3D""><blockquote=
 type=3D"cite" class=3D""><div lang=3D"EN-US" link=3D"#0563C1" =
vlink=3D"#954F72" class=3D""><div class=3D"WordSection1"><p =
class=3D"MsoPlainText"><o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; <o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; Thanks,<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; Eric<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; <o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; -----Original Message-----<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; &gt; From: netconf =
&lt;<a href=3D"mailto:netconf-bounces@ietf.org" =
class=3D"">netconf-bounces@ietf.org</a>&gt; On Behalf Of Mahesh<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; &gt; =
Jethanandani<o:p class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; =
&gt; Sent: Tuesday, June 2, 2020 7:48 PM<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; To: Netconf &lt;<a =
href=3D"mailto:netconf@ietf.org" class=3D"">netconf@ietf.org</a>&gt;<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; &gt; Subject: =
[netconf] WG LC for three drafts<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt;<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; NETCONF WG,<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt;<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; The authors of<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; &gt;<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; &gt; - =
draft-ietf-netconf-crypto-types<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; - draft-ietf-netconf-keystore<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; &gt; - =
draft-ietf-netconf-trust-anchors<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt;<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; have indicated that these drafts are =
ready for Last Call (LC).<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt;<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; This kicks of a 2 week WG LC for the =
three drafts. Please review and<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; send<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; any<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; comments to the WG mailing list or by =
responding to this e-mail.<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; Comments can be statements such as, I =
read/reviewed the document and<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; believe it is ready for publication, or =
I have concerns about the<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; document. For the<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; latter,<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; &gt; please indicate =
what your concerns are.<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt;<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; Any reports on implementation status or =
plans to implement are also<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; very useful.<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt;<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; Thanks.<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt;<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; Mahesh Jethanandani (as co-chair)<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; &gt; <a =
href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a><o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt;<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt;<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt;<o:p class=3D""></o:p></p><p =
class=3D"MsoPlainText">&gt; &gt; =
_______________________________________________<o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; &gt; netconf mailing =
list<o:p class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; &gt; <a =
href=3D"mailto:netconf@ietf.org" class=3D"">netconf@ietf.org</a><o:p =
class=3D""></o:p></p><p class=3D"MsoPlainText">&gt; &gt; <a =
href=3D"https://www.ietf.org/mailman/listinfo/netconf" =
class=3D"">https://www.ietf.org/mailman/listinfo/netconf</a><o:p =
class=3D""></o:p></p></div></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_904B8E49-53BB-4EB5-BA38-46B0A2878A52--


From nobody Mon Jun 15 07:59:46 2020
Return-Path: <01000172b87e40fb-56f5a8d3-b671-4837-8ff3-4c377f720c0c-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A553A0D9B for <netconf@ietfa.amsl.com>; Mon, 15 Jun 2020 07:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 ffw2hgbILA3H for <netconf@ietfa.amsl.com>; Mon, 15 Jun 2020 07:59:43 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A8C3A0D3B for <netconf@ietf.org>; Mon, 15 Jun 2020 07:59:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1592233181; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=HF9QZydMvDpKr3DpYghSBdYwfPY7DE9ut1jNkavJAVA=; b=MJJbVoG2K6Q1+8NgcJTJlz6TrjI6kVmrsksmeK7wxgD8EPOkTbfGeeGl5xyxn0tu Q404wj+M9bb7wTFWsO6VyUXOgISFLJUl5XfqSklzOJHGSuezF6+cR3d9mo0RR6ryBvg xtWOUMRLvKdLsudm+I9T4vzve1ETeDSQihBecVhI=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000172b87e40fb-56f5a8d3-b671-4837-8ff3-4c377f720c0c-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4103BAC3-F0A1-4CA4-9553-37D5C3123845"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 15 Jun 2020 14:59:41 +0000
In-Reply-To: <DBAPR07MB701671D1E66A7C53FB559072A0810@DBAPR07MB7016.eurprd07.prod.outlook.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>
To: tom petch <ietfc@btconnect.com>
References: <0100017233fe7ff7-8e22b4b1-aa03-4c8e-bf9d-fdbc7d3e41fd-000000@email.amazonses.com> <85A8ECA9-8875-45FA-839B-50CE35F6C8BA@gmail.com> <DBAPR07MB701671D1E66A7C53FB559072A0810@DBAPR07MB7016.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.15-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/4SNP-U3rGxwddk7keYkbDPwgoww>
Subject: Re: [netconf] Last Call on Re: Today's update to client-server drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2020 14:59:45 -0000

--Apple-Mail=_4103BAC3-F0A1-4CA4-9553-37D5C3123845
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Tom,


> On Jun 12, 2020, at 12:30 PM, tom petch <ietfc@btconnect.com> wrote:
>=20
> From: netconf <netconf-bounces@ietf.org> on behalf of Mahesh =
Jethanandani <mjethanandani@gmail.com>
> Sent: 22 May 2020 06:14
>=20
> <tp>
> I am sure I saw a Last Call but cannot now find it.

It looks like you have now found/reply to that thread. :)


> I wonder if there is anyone in the IETF who is familiar with this work =
and with RFC8635;  would these I-D meet the needs of RFC8635 which I =
have always seen as one of the two use cases for this work?

I just read the first couple pages.  Yes, this work, keystore in =
particular, seems complementary to RFC 8635.  Both the =
=E2=80=9Crouter-driven=E2=80=9D and =E2=80=9Coperator-driven=E2=80=9D =
methods are supported though, with the recent removal of the =
key-generation RPCs, the =E2=80=9Coperator-driven=E2=80=9D approach is =
tempered a bit.

Note that the paragraph at the top of Page 3 mimics Section 5.3 =
(Migrating Configuration to Another Server) in the keystore draft:

   For example, when an operator wants to support hot-swappable routers,
   the same private key needs to be installed in the soon-to-be online
   router that was used by the soon-to-be offline router.  This
   motivated the operator-driven method.



> In passing, trust anchors registers prefix ta; logical except that the =
I-D uses ts

Good catch.  Corrected here: =
https://github.com/netconf-wg/trust-anchors/commit/43017b3a448d46a47526b13=
8df551748b92df146 =
<https://github.com/netconf-wg/trust-anchors/commit/43017b3a448d46a47526b1=
38df551748b92df146>


> Tom Petch
>=20
> What would it take to get the remaining drafts into WGLC?


I recently answered this question for Mahesh here: =
https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe-v0l6MI/=
 =
<https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe-v0l6MI=
/>



Kent // contributor




>> On May 20, 2020, at 2:30 PM, Kent Watsen <kent+ietf@watsen.net> =
wrote:
>>=20
>>=20
>> The entire suite of drafts were updated today.
>> The first three drafts are ready for WGLC.
>> All of the other drafts are almost ready for WGLC.
>> Below is the Change Log entry for each draft.
>>=20
>> K.
>>=20
>>=20
>> For all drafts:
>>=20
>>  o  Added a "Note to Reviewers" note to first page.
>>=20
>>=20
>> For crypto-types:
>>=20
>>  o  Removed the IANA-maintained registries for symmetric, asymmetric,
>>      and hash algorithms.
>>=20
>>  o  Removed the "generate-symmetric-key" and =
"generate-asymmetric-key"
>>      RPCs.
>>=20
>>  o  Removed the "algorithm" node in the various symmetric and
>>      asymmetric key groupings.
>>=20
>>  o  Added 'typedef csr' and 'feature certificate-signing-request-
>>     generation'.
>>=20
>>  o  Refined a usage of "end-entity-cert-grouping" to make the "cert"
>>      node mandatory true.
>>=20
>>=20
>> For trust-anchors:
>>=20
>>  o  Removed "algorithm" node from examples.
>>=20
>>  o  Removed the no longer used statements supporting the old "ssh-
>>      public-key" and "raw-public-key" nodes.
>>=20
>>=20
>> For keystore:
>>=20
>>  o  Removed augments to the "generate-symmetric-key" and "generate-
>>      asymmetric-key" groupings.
>>=20
>>  o  Removed "generate-symmetric-key" and "generate-asymmetric-key"
>>      examples.
>>=20
>>  o  Removed the "algorithm" nodes from remaining examples.
>>=20
>>  o  Renamed/updated the "Support for Built-in Keys" section.
>>=20
>>  o  Added new section "Encrypting Keys in Configuration".
>>=20
>>=20
>> For tcp-client-server:
>>=20
>>  o  Removed commented out "grouping tcp-system-grouping" statement
>>      kept for reviewers.
>>=20
>>=20
>> For ssh-client-server:
>>=20
>>  o  Updated the "keepalives" containers to address Michal Vasko's
>>      request to align with RFC 8071
>>=20
>>  o  Removed algorithm-mapping tables from the "SSH Common Model"
>>      section
>>=20
>>  o  Removed 'algorithm' node from examples.
>>=20
>>  o  Added feature "client-identity-publickey"
>>=20
>>  o  Removed "choice auth-type", as auth-types aren't exclusive.
>>=20
>>  o  Renamed both "client-certs" and "server-certs" to "ee-certs"
>>=20
>>  o  Switch "must" to assert the public-key-format is "subject-public-
>>      key-info-format" when certificates are used.
>>=20
>>=20
>> For tls-client-server:
>>=20
>>  o  Updated the "keepalives" containers in part to address Michal
>>      Vasko's request to align with RFC 8071 and in part to better =
align to RFC 6520
>>=20
>>  o  Removed algorithm-mapping tables from the "TLS Common Model"
>>      section
>>=20
>>  o  Removed the 'algorithm' node from the examples.
>>=20
>>  o  Renamed both "client-certs" and "server-certs" to "ee-certs"
>>=20
>>=20
>> For http-client-server:
>>=20
>>  o  Removed "protocol-versions" from ietf-http-server based on HTTP =
WG
>>      feedback.
>>=20
>>  o  Slightly restructured the "proxy-server" definition in ietf-http-
>>      client.
>>=20
>>  o  Added http-client example show proxy server use.
>>=20
>>=20
>> For netconf-client-server:
>>=20
>>  o  Updated examples to remove the 'algorithm' nodes.
>>=20
>>  o  Updated examples to reflect the new TLS keepalives structure.
>>=20
>>  o  Added keepalives to the tcp-client-parameters section in the
>>      netconf-server SSH-based call-home example.
>>=20
>>  o  Added a TLS-based call-home example to the netconf-client =
example.
>>=20
>>=20
>> For restonf-client-server:
>>=20
>>  o  Updated examples to remove the 'algorithm' nodes.
>>=20
>>  o  Updated examples to reflect the new TLS keepalives structure.
>>=20
>>  o  Removed the 'protocol-versions' node from the restconf-server
>>      examples.
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netconf mailing list
>> netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>=20
> Mahesh Jethanandani (as co-chair)
> mjethanandani@gmail.com
>=20
>=20
>=20
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


--Apple-Mail=_4103BAC3-F0A1-4CA4-9553-37D5C3123845
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Hi =
Tom,<div class=3D""><br class=3D""><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Jun 12, 2020, at 12:30 PM, =
tom petch &lt;<a href=3D"mailto:ietfc@btconnect.com" =
class=3D"">ietfc@btconnect.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">From: =
netconf &lt;<a href=3D"mailto:netconf-bounces@ietf.org" =
class=3D"">netconf-bounces@ietf.org</a>&gt; on behalf of Mahesh =
Jethanandani &lt;<a href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a>&gt;<br class=3D"">Sent: 22 May =
2020 06:14<br class=3D""><br class=3D"">&lt;tp&gt;<br class=3D"">I am =
sure I saw a Last Call but cannot now find it.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div>It looks =
like you have now found/reply to that thread. :)</div><div><br =
class=3D""></div><div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D"">I wonder if there is anyone =
in the IETF who is familiar with this work and with RFC8635; &nbsp;would =
these I-D meet the needs of RFC8635 which I have always seen as one of =
the two use cases for this work?<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>I =
just read the first couple pages. &nbsp;Yes, this work, keystore in =
particular, seems complementary to RFC 8635. &nbsp;Both the =
=E2=80=9Crouter-driven=E2=80=9D and =E2=80=9Coperator-driven=E2=80=9D =
methods are supported though, with the recent removal of the =
key-generation RPCs, the =E2=80=9Coperator-driven=E2=80=9D approach is =
tempered a bit.</div><div><br class=3D""></div><div>Note that the =
paragraph at the top of Page 3 mimics Section 5.3 (Migrating =
Configuration to Another Server) in the keystore draft:</div><div><br =
class=3D""></div><div><pre class=3D"newpage" style=3D"font-size: =
13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; =
color: rgb(0, 0, 0); font-variant-ligatures: normal; orphans: 2; widows: =
2;">   For example, when an operator wants to support hot-swappable =
routers,
   the same private key needs to be installed in the soon-to-be online
   router that was used by the soon-to-be offline router.  This
   motivated the operator-driven method.
</pre><div class=3D""><br class=3D""></div></div><div><br =
class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div class=3D"">In passing, trust anchors registers prefix =
ta; logical except that the I-D uses ts<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>Good =
catch. &nbsp;Corrected here:&nbsp;<a =
href=3D"https://github.com/netconf-wg/trust-anchors/commit/43017b3a448d46a=
47526b138df551748b92df146" =
class=3D"">https://github.com/netconf-wg/trust-anchors/commit/43017b3a448d=
46a47526b138df551748b92df146</a></div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D"">Tom Petch<br class=3D""><br class=3D"">What would it take to =
get the remaining drafts into WGLC?<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div><br =
class=3D""></div><div class=3D"">I recently answered this question for =
Mahesh here:&nbsp;<a =
href=3D"https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe=
-v0l6MI/" =
class=3D"">https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pH=
Yhe-v0l6MI/</a></div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D"">Kent // contributor</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D""><blockquote =
type=3D"cite" class=3D"">On May 20, 2020, at 2:30 PM, Kent Watsen &lt;<a =
href=3D"mailto:kent+ietf@watsen.net" =
class=3D"">kent+ietf@watsen.net</a>&gt; wrote:<br class=3D""><br =
class=3D""><br class=3D"">The entire suite of drafts were updated =
today.<br class=3D"">The first three drafts are ready for WGLC.<br =
class=3D"">All of the other drafts are almost ready for WGLC.<br =
class=3D"">Below is the Change Log entry for each draft.<br class=3D""><br=
 class=3D"">K.<br class=3D""><br class=3D""><br class=3D"">For all =
drafts:<br class=3D""><br class=3D""> &nbsp;o &nbsp;Added a "Note to =
Reviewers" note to first page.<br class=3D""><br class=3D""><br =
class=3D"">For crypto-types:<br class=3D""><br class=3D""> &nbsp;o =
&nbsp;Removed the IANA-maintained registries for symmetric, =
asymmetric,<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and hash =
algorithms.<br class=3D""><br class=3D""> &nbsp;o &nbsp;Removed the =
"generate-symmetric-key" and "generate-asymmetric-key"<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RPCs.<br class=3D""><br class=3D""> =
&nbsp;o &nbsp;Removed the "algorithm" node in the various symmetric =
and<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;asymmetric key =
groupings.<br class=3D""><br class=3D""> &nbsp;o &nbsp;Added 'typedef =
csr' and 'feature certificate-signing-request-<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;generation'.<br class=3D""><br class=3D""> =
&nbsp;o &nbsp;Refined a usage of "end-entity-cert-grouping" to make the =
"cert"<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;node mandatory =
true.<br class=3D""><br class=3D""><br class=3D"">For trust-anchors:<br =
class=3D""><br class=3D""> &nbsp;o &nbsp;Removed "algorithm" node from =
examples.<br class=3D""><br class=3D""> &nbsp;o &nbsp;Removed the no =
longer used statements supporting the old "ssh-<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;public-key" and "raw-public-key" nodes.<br =
class=3D""><br class=3D""><br class=3D"">For keystore:<br class=3D""><br =
class=3D""> &nbsp;o &nbsp;Removed augments to the =
"generate-symmetric-key" and "generate-<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;asymmetric-key" groupings.<br class=3D""><br=
 class=3D""> &nbsp;o &nbsp;Removed "generate-symmetric-key" and =
"generate-asymmetric-key"<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;examples.<br class=3D""><br class=3D""> =
&nbsp;o &nbsp;Removed the "algorithm" nodes from remaining examples.<br =
class=3D""><br class=3D""> &nbsp;o &nbsp;Renamed/updated the "Support =
for Built-in Keys" section.<br class=3D""><br class=3D""> &nbsp;o =
&nbsp;Added new section "Encrypting Keys in Configuration".<br =
class=3D""><br class=3D""><br class=3D"">For tcp-client-server:<br =
class=3D""><br class=3D""> &nbsp;o &nbsp;Removed commented out "grouping =
tcp-system-grouping" statement<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;kept for reviewers.<br class=3D""><br =
class=3D""><br class=3D"">For ssh-client-server:<br class=3D""><br =
class=3D""> &nbsp;o &nbsp;Updated the "keepalives" containers to address =
Michal Vasko's<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;request to =
align with RFC 8071<br class=3D""><br class=3D""> &nbsp;o &nbsp;Removed =
algorithm-mapping tables from the "SSH Common Model"<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;section<br class=3D""><br class=3D""> =
&nbsp;o &nbsp;Removed 'algorithm' node from examples.<br class=3D""><br =
class=3D""> &nbsp;o &nbsp;Added feature "client-identity-publickey"<br =
class=3D""><br class=3D""> &nbsp;o &nbsp;Removed "choice auth-type", as =
auth-types aren't exclusive.<br class=3D""><br class=3D""> &nbsp;o =
&nbsp;Renamed both "client-certs" and "server-certs" to "ee-certs"<br =
class=3D""><br class=3D""> &nbsp;o &nbsp;Switch "must" to assert the =
public-key-format is "subject-public-<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;key-info-format" when certificates are =
used.<br class=3D""><br class=3D""><br class=3D"">For =
tls-client-server:<br class=3D""><br class=3D""> &nbsp;o &nbsp;Updated =
the "keepalives" containers in part to address Michal<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Vasko's request to align with RFC 8071 and =
in part to better align to RFC 6520<br class=3D""><br class=3D""> =
&nbsp;o &nbsp;Removed algorithm-mapping tables from the "TLS Common =
Model"<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;section<br =
class=3D""><br class=3D""> &nbsp;o &nbsp;Removed the 'algorithm' node =
from the examples.<br class=3D""><br class=3D""> &nbsp;o &nbsp;Renamed =
both "client-certs" and "server-certs" to "ee-certs"<br class=3D""><br =
class=3D""><br class=3D"">For http-client-server:<br class=3D""><br =
class=3D""> &nbsp;o &nbsp;Removed "protocol-versions" from =
ietf-http-server based on HTTP WG<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;feedback.<br class=3D""><br class=3D""> =
&nbsp;o &nbsp;Slightly restructured the "proxy-server" definition in =
ietf-http-<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;client.<br =
class=3D""><br class=3D""> &nbsp;o &nbsp;Added http-client example show =
proxy server use.<br class=3D""><br class=3D""><br class=3D"">For =
netconf-client-server:<br class=3D""><br class=3D""> &nbsp;o =
&nbsp;Updated examples to remove the 'algorithm' nodes.<br class=3D""><br =
class=3D""> &nbsp;o &nbsp;Updated examples to reflect the new TLS =
keepalives structure.<br class=3D""><br class=3D""> &nbsp;o &nbsp;Added =
keepalives to the tcp-client-parameters section in the<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;netconf-server SSH-based call-home =
example.<br class=3D""><br class=3D""> &nbsp;o &nbsp;Added a TLS-based =
call-home example to the netconf-client example.<br class=3D""><br =
class=3D""><br class=3D"">For restonf-client-server:<br class=3D""><br =
class=3D""> &nbsp;o &nbsp;Updated examples to remove the 'algorithm' =
nodes.<br class=3D""><br class=3D""> &nbsp;o &nbsp;Updated examples to =
reflect the new TLS keepalives structure.<br class=3D""><br class=3D""> =
&nbsp;o &nbsp;Removed the 'protocol-versions' node from the =
restconf-server<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;examples.<br class=3D""><br class=3D""><br =
class=3D""><br class=3D""><br =
class=3D"">_______________________________________________<br =
class=3D"">netconf mailing list<br class=3D""><a =
href=3D"mailto:netconf@ietf.org" class=3D"">netconf@ietf.org</a><br =
class=3D"">https://www.ietf.org/mailman/listinfo/netconf<br =
class=3D""></blockquote><br class=3D"">Mahesh Jethanandani (as =
co-chair)<br class=3D""><a href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a><br class=3D""><br class=3D""><br =
class=3D""><br =
class=3D"">_______________________________________________<br =
class=3D"">netconf mailing list<br class=3D"">netconf@ietf.org<br =
class=3D"">https://www.ietf.org/mailman/listinfo/netconf<br =
class=3D""></div></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_4103BAC3-F0A1-4CA4-9553-37D5C3123845--


From nobody Mon Jun 15 08:17:34 2020
Return-Path: <01000172b88e8bd1-dd9d3f02-0ab9-423f-a9c5-92ac9e682243-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132123A0D3F for <netconf@ietfa.amsl.com>; Mon, 15 Jun 2020 08:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 mOz_GHufYsoc for <netconf@ietfa.amsl.com>; Mon, 15 Jun 2020 08:17:31 -0700 (PDT)
Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7393A0D3E for <netconf@ietf.org>; Mon, 15 Jun 2020 08:17:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1592234249; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=CVXH1m6/rn4lV5o0NcKrJmZ0NXRlCPD/0lEj8eSS1JA=; b=gM5b+17y+MISl2mbUyNXjBW98Dd7MdRSiEnoeMNN11iDF5aGcP+M/7ussR4e2HhH DLPGU43naEcSagfZvhkO1RAFGfwQQ4caDX1EDx1KsZ00y1Y1wdJSEfda+/rAXMuiUIW at9Szd9MRnHYJn27n+Fanrda17bh8+dr8LW0w3C4=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000172b88e8bd1-dd9d3f02-0ab9-423f-a9c5-92ac9e682243-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6032566C-941C-4CBF-A0D0-220DC969F5CA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 15 Jun 2020 15:17:29 +0000
In-Reply-To: <DBAPR07MB7016F753766FCE8AD12A2F5DA09E0@DBAPR07MB7016.eurprd07.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: tom petch <ietfc@btconnect.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com> <DBAPR07MB7016F753766FCE8AD12A2F5DA09E0@DBAPR07MB7016.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.15-54.240.48.93
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/zOmDWuUSmRK_x3qC82U6YfN1Od0>
Subject: Re: [netconf] WG LC for three drafts or two of them
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2020 15:17:33 -0000

--Apple-Mail=_6032566C-941C-4CBF-A0D0-220DC969F5CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Tom,


> On Jun 13, 2020, at 7:29 AM, tom petch <ietfc@btconnect.com> wrote:
>=20
> I have concerns about trust-anchors and crypto-types.  They are both =
more or less non-existent when it comes to text.  I do not want to have =
to reverse engineer the YANG or XML to find out what RPC or action there =
are, what types of cipher suites and such like are supported - and =
perhaps those that are not such as raw keys.  I would expect there to be =
five or ten pages of such in each.

This is an interesting comment.   How do other folks feel about this?

Generally, perhaps to a fault, I try to let the YANG modules do the =
talking.  Not only is the YANG syntax more exact, but it eliminates =
potentially-inconsistent duplicate text and, of course, the effort to =
create the duplicate text. =20

That said, now that we=E2=80=99re near/at the end, creating some =
duplicate text may now be reasonable.  FWIW, there is no limitation on =
cipher-suites but, perhaps to your point, some introduction text could =
say that. =20

A reasonable compromise might be to mimic what I did in Section 2 of =
draft-kwatsen-netconf-sztp-csr, whereby it has my normal =
(overview/diagrams + examples + yang module) subsections, but there=E2=80=99=
s more text surrounding the diagrams and examples making those sections =
more readable...

It=E2=80=99s funny that you say you don=E2=80=99t want to =
reverse-engineer the YANG, as many times I feel the opposite, not =
wanting to have to read the RFC, when the YANG module should be self =
standing.  I=E2=80=99m not minimizing your critique, just finding humor =
in the irony.  ;)


>  Look for example at layer0-types or layer1-types for modules with =
what I would regard as adequate text.


I recently answered this question for Mahesh here: =
https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe-v0l6MI/=
 =
<https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe-v0l6MI=
/>


Kent // contributor


> Tom Petch
>=20
> From: netconf <netconf-bounces@ietf.org> on behalf of Eric Voit =
(evoit) <evoit=3D40cisco.com@dmarc.ietf.org>
> Sent: 12 June 2020 21:03
>=20
>>> -----Original Message-----
>=20
>>> From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh
>=20
>>> Jethanandani
>=20
>>> Sent: Tuesday, June 2, 2020 7:48 PM
>=20
>>> To: Netconf <netconf@ietf.org>
>=20
>>> Subject: [netconf] WG LC for three drafts
>=20
>>>=20
>=20
>>> NETCONF WG,
>=20
>>>=20
>=20
>>> The authors of
>=20
>>>=20
>=20
>>> - draft-ietf-netconf-crypto-types
>=20
>>> - draft-ietf-netconf-keystore
>=20
>>> - draft-ietf-netconf-trust-anchors
>=20
>>>=20
>=20
>>> have indicated that these drafts are ready for Last Call (LC).
>=20
>>>=20
>=20
>>> This kicks of a 2 week WG LC for the three drafts. Please review and
>=20
>>> send
>=20
>> any
>=20
>>> comments to the WG mailing list or by responding to this e-mail.
>=20
>>> Comments can be statements such as, I read/reviewed the document and
>=20
>>> believe it is ready for publication, or I have concerns about the
>=20
>>> document. For the
>=20
>> latter,
>=20
>>> please indicate what your concerns are.
>=20
>>>=20
>=20
>>> Any reports on implementation status or plans to implement are also
>=20
>>> very useful.
>=20
>>>=20
>=20
>>> Thanks.
>=20
>>>=20
>=20
>>> Mahesh Jethanandani (as co-chair)
>=20
>>> mjethanandani@gmail.com
>=20
>>>=20
>=20
>>>=20
>=20
>>>=20
>=20
>>> _______________________________________________
>=20
>>> netconf mailing list
>=20
>>> netconf@ietf.org
>=20
>>> https://www.ietf.org/mailman/listinfo/netconf


--Apple-Mail=_6032566C-941C-4CBF-A0D0-220DC969F5CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Hi =
Tom,<div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D""><div><blockquote type=3D"cite" =
class=3D""><div class=3D"">On Jun 13, 2020, at 7:29 AM, tom petch &lt;<a =
href=3D"mailto:ietfc@btconnect.com" class=3D"">ietfc@btconnect.com</a>&gt;=
 wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D"">I have concerns about trust-anchors and crypto-types. =
&nbsp;They are both more or less non-existent when it comes to text. =
&nbsp;I do not want to have to reverse engineer the YANG or XML to find =
out what RPC or action there are, what types of cipher suites and such =
like are supported - and perhaps those that are not such as raw keys. =
&nbsp;I would expect there to be five or ten pages of such in =
each.</div></div></blockquote><div><br class=3D""></div><div>This is an =
interesting comment. &nbsp; How do other folks feel about =
this?</div><div><br class=3D""></div><div>Generally, perhaps to a fault, =
I try to let the YANG modules do the talking. &nbsp;Not only =
is&nbsp;<span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" =
class=3D"">the YANG syntax more exact, but it</span>&nbsp;eliminates =
potentially-inconsistent duplicate text and, of course, the effort to =
create the duplicate text. &nbsp;</div><div><br class=3D""></div><div>That=
 said, now that we=E2=80=99re near/at the end, creating some duplicate =
text may now be reasonable. &nbsp;FWIW, there is no limitation on =
cipher-suites but, perhaps to your point, some introduction text could =
say that. &nbsp;</div><div><br class=3D""></div><div>A reasonable =
compromise might be to mimic what I did in&nbsp;Section 2 of =
draft-kwatsen-netconf-sztp-csr, whereby it has my normal =
(overview/diagrams + examples + yang module) subsections, but there=E2=80=99=
s more text surrounding the diagrams and examples making those sections =
more readable...</div><div><br class=3D""></div><div>It=E2=80=99s funny =
that you say you don=E2=80=99t want to reverse-engineer the YANG, as =
many times I feel the opposite, not wanting to have to read the RFC, =
when the YANG module should be self standing. &nbsp;I=E2=80=99m not =
minimizing your critique, just finding humor in the irony. =
&nbsp;;)</div><div><br class=3D""></div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D""> &nbsp;Look for =
example at layer0-types or layer1-types for modules with what I would =
regard as adequate text.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div><br class=3D""></div><div class=3D"">I recently =
answered this question for Mahesh here:&nbsp;<a =
href=3D"https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe=
-v0l6MI/" =
class=3D"">https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pH=
Yhe-v0l6MI/</a></div><div class=3D""><br class=3D""></div><div =
class=3D""><br style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" =
class=3D""></div><div class=3D"">Kent // contributor</div><div =
class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
 class=3D"">Tom Petch<br class=3D""><br class=3D"">From: netconf &lt;<a =
href=3D"mailto:netconf-bounces@ietf.org" =
class=3D"">netconf-bounces@ietf.org</a>&gt; on behalf of Eric Voit =
(evoit) &lt;<a href=3D"mailto:evoit=3D40cisco.com@dmarc.ietf.org" =
class=3D"">evoit=3D40cisco.com@dmarc.ietf.org</a>&gt;<br class=3D"">Sent: =
12 June 2020 21:03<br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D""><blockquote type=3D"cite" class=3D"">-----Original =
Message-----<br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">From: netconf &lt;<a href=3D"mailto:netconf-bounces@ietf.org" =
class=3D"">netconf-bounces@ietf.org</a>&gt; On Behalf Of Mahesh<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">Jethanandani<br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">Sent: Tuesday, June 2, 2020 7:48 PM<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">To: =
Netconf &lt;<a href=3D"mailto:netconf@ietf.org" =
class=3D"">netconf@ietf.org</a>&gt;<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">Subject: =
[netconf] WG LC for three drafts<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">NETCONF =
WG,<br class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">The =
authors of<br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D""><br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">- draft-ietf-netconf-crypto-types<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">- =
draft-ietf-netconf-keystore<br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">- draft-ietf-netconf-trust-anchors<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">have =
indicated that these drafts are ready for Last Call (LC).<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">This kicks =
of a 2 week WG LC for the three drafts. Please review and<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">send<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D"">any<br class=3D""></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">comments to the WG mailing list or by responding to this =
e-mail.<br class=3D""></blockquote></blockquote><br class=3D""><blockquote=
 type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">Comments =
can be statements such as, I read/reviewed the document and<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">believe it =
is ready for publication, or I have concerns about the<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">document. =
For the<br class=3D""></blockquote></blockquote><br class=3D""><blockquote=
 type=3D"cite" class=3D"">latter,<br class=3D""></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">please indicate what your concerns are.<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">Any =
reports on implementation status or plans to implement are also<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">very =
useful.<br class=3D""></blockquote></blockquote><br class=3D""><blockquote=
 type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">Thanks.<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">Mahesh =
Jethanandani (as co-chair)<br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D""><a href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">_______________________________________________<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">netconf =
mailing list<br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D""><a href=3D"mailto:netconf@ietf.org" =
class=3D"">netconf@ietf.org</a><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><a =
href=3D"https://www.ietf.org/mailman/listinfo/netconf" =
class=3D"">https://www.ietf.org/mailman/listinfo/netconf</a><br =
class=3D""></blockquote></blockquote></div></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_6032566C-941C-4CBF-A0D0-220DC969F5CA--


From nobody Mon Jun 15 14:13:02 2020
Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C923A115C for <netconf@ietfa.amsl.com>; Mon, 15 Jun 2020 14:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.587
X-Spam-Level: 
X-Spam-Status: No, score=-9.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=G8sFSdQ/; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=UKmQJnjt
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrdbU6PaDujt for <netconf@ietfa.amsl.com>; Mon, 15 Jun 2020 14:12:54 -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 888AB3A115A for <netconf@ietf.org>; Mon, 15 Jun 2020 14:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11230; q=dns/txt; s=iport; t=1592255574; x=1593465174; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Cm+vIm42O1OKWL59Ls6L2xWLKFko4JB1QaizKWduElM=; b=G8sFSdQ/U6dSpM2zJFv9aOEKgJRwRhjgQkVNmER/To1uXvwcMGSFsgFK 7P/sTROSJFJ1imTrnBQcJnjnbtEY+r73j1QxL6wXWBJQj8H9ej/G6+UFr 304m5vqBrdftlGtHfAh6/lteud8QsCEfqFSO0YTExRyhthE7IuldqDC10 Y=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3Ajbxj/hOeROp3LpE4jTUl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwz3kDAQZ7W7bRChvaF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGB8/ifFDU5Hu/8W1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAADJ4+de/4wNJK1mHQEBAQEJARI?= =?us-ascii?q?BBQUBgXYIAQsBgSIvUQdvKy0vLAqEGoNGA4RYkDqMFYRogS6BJANVBAcBAQE?= =?us-ascii?q?JAwEBLQIEAQGERAKCLwIkNAkOAgMBAQsBAQUBAQECAQYEbYVbDIVzAgEDEhE?= =?us-ascii?q?KEwEBNwEPAgEIPwMCAgIwFBECBAENBQgGFIMFgX5NAx8PAappAoE5iGF2gTK?= =?us-ascii?q?DAQEBBYUyGIIHBwmBOAGBUoERiCOBQxqBQT+BVIJNPoQ/FR+CXjOCLZoQmjE?= =?us-ascii?q?KglmEJoJTkkKeZ5EXni0CBAIEBQIOAQEFgVM5gVZwFYMkUBcCDY4eg3GKVnQ?= =?us-ascii?q?3AgYBBwEBAwl8jwcBgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.73,516,1583193600";  d="p7s'?scan'208,217,223";a="783134222"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jun 2020 21:12:52 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 05FLCqLh025720 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Jun 2020 21:12:53 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Jun 2020 16:12:52 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Jun 2020 17:12:51 -0400
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 15 Jun 2020 16:12:51 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aJhRGhXAA/hXoCEhERJJdFPiTjX0khZwKJqv34HnMXUYkOL0h8MAI8a1pQ+ruehVQIT1VEG54EDKGMCekpZlW0+lki8uJsLWHtRQLKCfYa+PhvgNK26iJzIwn9TmdIboDVlBL0iex9buhK+mUSTpv3SIcxtW0vsF3nQNbkUEarsdy71q0LcSBBq/eTi69Tt9jG5ufROZpZxRDk5Pe/KMTVJOh1tmTTQTh7Pi38WMO6EPWHL46LmoMLFmE/MsSCRwdmzaiKc27EeDLAgMggv41v887qp9J/lY0T2HaWrBf0L8MlypLCs+CTS8m3asfqzLTM+X6H2Yg+iO5ytlQsgBkg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K3gLyAShdLa1vFY7z8KO1VYdBno7wq0xy52LYiBkqjM=; b=m1FCAeYHgdLSabSyk3Z4vkJZ8vLj83QXVK/0WXz61EwsV1Pd9iyNoLwrnb+qrhK7TlZlxGsjWxPLIDPQNd/n4hBv3rwzXlt28SbsKJKZaSkBgW2OoBOwr7K/YnjrvwaqMqkNOGA54hw7E+OORG/shSmmoBby0q5AvjxlvmKl6lY4a9lQhTukoIMR3ixLDhQhVetF3IO4mqNrrHp+TcX/RNrKkvnRLNwLkShGClMDdPWntddb+0dPF4mD534eCBLd//LqeFPzWd06qbxJFNcC3SZmYvUe2V01YF94ONeOn3Szi2iFi5DByIXrd13zA+r21kr8CPCr8pLkGH1pJex7YA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=K3gLyAShdLa1vFY7z8KO1VYdBno7wq0xy52LYiBkqjM=; b=UKmQJnjt/vAW6qmWflYSbf7IueO3qo1mqpB11jtHfG0g2ye+Q260qQqJUZ5nOgLtOHs5UDMECnL1vQpDcrFaONhVvS5f6CNbnhNLb91HOF7MgIVVYHd3UkH1ayFPs38OOKYgENIPjiZ8MR1jXprc1TpzCrWA9S8yE9u9cAnPWak=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3524.namprd11.prod.outlook.com (2603:10b6:208:73::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19; Mon, 15 Jun 2020 21:12:50 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290%7]) with mapi id 15.20.3088.029; Mon, 15 Jun 2020 21:12:50 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>, tom petch <ietfc@btconnect.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts or two of them
Thread-Index: AQHWQ1m5OU7YCGRUykyXa34zwEJyqw==
Date: Mon, 15 Jun 2020 21:12:50 +0000
Message-ID: <BL0PR11MB31226D006E6F4736AF2D021BA19C0@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com> <DBAPR07MB7016F753766FCE8AD12A2F5DA09E0@DBAPR07MB7016.eurprd07.prod.outlook.com> <01000172b88e8bd1-dd9d3f02-0ab9-423f-a9c5-92ac9e682243-000000@email.amazonses.com>
In-Reply-To: <01000172b88e8bd1-dd9d3f02-0ab9-423f-a9c5-92ac9e682243-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 68a8d3af-8b56-47d0-beca-08d81170dc7b
x-ms-traffictypediagnostic: BL0PR11MB3524:
x-microsoft-antispam-prvs: <BL0PR11MB3524D9BE88DB39498BB36F5FA19C0@BL0PR11MB3524.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 04359FAD81
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 4Jj0Oa5I3jeLGVNE82zNfrR2QRvf4pBIaKNZoc7z03Z9j9POS+ITsWGPjtlTT1U+u9B+uzQbHGAQevMBRDHfLxGxJqcueMv2WeLb6vv7axn9el2wEHyjmVykauO+izo5JM/Sa33Jzk2XVyVQ0ywBRrMijNhH/3uGCMgEISxJb53pKWO/xYngcOvYFuXjWIP8myrzLbPzaLGQNNQV8hWn8miSGNbaL8ZAgrKDbO/UOhg9NcsJoM7wsbZxBhv2Op/wyBizxgw3aCAl90fiTIBK3GN5PDcpgMnLl+3qo+r6Prj08FiTPM0DDXCYPpD4mCACJuwszogKe9kPkPV88ZzwVQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(396003)(39860400002)(136003)(366004)(346002)(376002)(5660300002)(99936003)(76116006)(186003)(64756008)(66946007)(66616009)(66446008)(66556008)(66476007)(8936002)(8676002)(4326008)(478600001)(110136005)(26005)(33656002)(2906002)(71200400001)(316002)(4744005)(9686003)(7696005)(52536014)(6506007)(86362001)(53546011)(55016002); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: 1wWZOOhpTdoSgqlBEFg9aG0jQ7aiqcxbg1IabfPeJG2S6L/ZPF9+xvUzL2geJMz8EpuDvK3gxF8Ua91WBpjrzBX4lvAxSb1bzo9XuI5mD06tuPRJe3BX7kH7AgFMfRncnzwJoqaN/myNU/xIg1HgcZdRAc63F66dmQazZFI3Cvke75emo4I0h8tjZV9ANjVvf5HOGpeYf8Yih00gofxNdLFSVNIdmcZapB+o4w/k98YrURVH9eSnk55QQoSc+c6eSY031sbFePO7vr5XBpDhmOS+f8nfGkXD9gXQU5SXKMY7SxOwckP5s7UemGpmI1xVAvQa1uRykPZS9N2XNawDA9GPgFNvcVIFeu4dKGN5HPXTq8iG+R7noNxhrUIhMBsaYQ7siyPqK+R1vATz/2gLvOq+wVvXlHxGfv3DKTpxogFo9jT9J8r8iNc+s3CRr88P9ZpLzUS6TmfLnPzGZr34f7gUTyauYPp1j6yb0Iwc2n4=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary="----=_NextPart_000_01AA_01D64338.30E4F830"; protocol="application/x-pkcs7-signature"; micalg=SHA1
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 68a8d3af-8b56-47d0-beca-08d81170dc7b
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 21:12:50.3691 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OabiYwMLqgLHDldOq8Nq70K9/ZhhLyw93IKjHxuze1zXArgoyfyEE3ZwmepIseuR
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3524
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/UAM5dgGI_qy1W7O8eJYKkxS1Tio>
Subject: Re: [netconf] WG LC for three drafts or two of them
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2020 21:13:00 -0000

------=_NextPart_000_01AA_01D64338.30E4F830
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_01AB_01D64338.30E4F830"


------=_NextPart_001_01AB_01D64338.30E4F830
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 7bit

>From Kent Watsen, June 15, 2020 11:17 AM





Hi Tom,





On Jun 13, 2020, at 7:29 AM, tom petch <ietfc@btconnect.com 
<mailto:ietfc@btconnect.com> > wrote:



I have concerns about trust-anchors and crypto-types.  They are both more or 
less non-existent when it comes to text.  I do not want to have to reverse 
engineer the YANG or XML to find out what RPC or action there are, what types 
of cipher suites and such like are supported - and perhaps those that are not 
such as raw keys.  I would expect there to be five or ten pages of such in 
each.



This is an interesting comment.   How do other folks feel about this?



Generally, perhaps to a fault, I try to let the YANG modules do the talking. 
Not only is the YANG syntax more exact, but it eliminates 
potentially-inconsistent duplicate text and, of course, the effort to create 
the duplicate text.



<eric> I prefer minimal, non-duplicative RFC content where possible.  Since 
the YANG model has to have the content anyway, it might as well provide the 
structural basis for the critical content.



Eric




------=_NextPart_001_01AB_01D64338.30E4F830
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta =
name=3DGenerator content=3D"Microsoft Word 15 (filtered =
medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
	{mso-style-name:msonormal;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><b>From =
</b>Kent Watsen<b>,</b> June 15, 2020 11:17 AM<br><br><o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Hi =
Tom,<o:p></o:p></p><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><div><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><p =
class=3DMsoNormal>On Jun 13, 2020, at 7:29 AM, tom petch &lt;<a =
href=3D"mailto:ietfc@btconnect.com">ietfc@btconnect.com</a>&gt; =
wrote:<o:p></o:p></p></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><div><p class=3DMsoNormal>I =
have concerns about trust-anchors and crypto-types. &nbsp;They are both =
more or less non-existent when it comes to text. &nbsp;I do not want to =
have to reverse engineer the YANG or XML to find out what RPC or action =
there are, what types of cipher suites and such like are supported - and =
perhaps those that are not such as raw keys. &nbsp;I would expect there =
to be five or ten pages of such in =
each.<o:p></o:p></p></div></div></blockquote><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>This is an interesting comment. &nbsp; How do other =
folks feel about this?<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Generally, perhaps to a fault, I try to let the YANG =
modules do the talking. &nbsp;Not only is&nbsp;<span =
style=3D'color:black'>the YANG syntax more exact, but =
it</span>&nbsp;eliminates potentially-inconsistent duplicate text and, =
of course, the effort to create the duplicate text. =
&nbsp;<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>&lt;eric&gt; I prefer minimal, non-duplicative RFC =
content where possible.=C2=A0 Since the YANG model has to have the =
content anyway, it might as well provide the structural basis for the =
critical content.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Eric<o:p></o:p></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div></body></html>
------=_NextPart_001_01AB_01D64338.30E4F830--

------=_NextPart_000_01AA_01D64338.30E4F830
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw
ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz
Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX
DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g
Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2
tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI
zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl
zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS
qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk
UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD
VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB
BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO
VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup
SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p
+slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg
lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA
AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD
aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD
VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz
guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I
4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG
VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+
FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ
BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC
NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j
BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j
aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG
CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw
NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3
LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF
AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo
0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp
9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt
U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ
MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04
96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv
eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg
Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw
EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM
D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE
S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO
yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M
mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v
Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp
W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB
Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v
c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp
c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E
MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV
HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G
A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr
+GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ
KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0
JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f
1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG
+gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG
A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjE1MjExMjQ3WjAjBgkqhkiG
9w0BCQQxFgQU6xRZf8P+FXaMkEs6z/LJ54yRDt0wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK
EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN
AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK
AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw
CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH
BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B
AQEFAASCAQBrIhgrQ4cm87/WEDv9dd4rK84NX3WI3UM/YRva0KFSKp9ePqe22TVjjiSJvzqc41Ew
66zFrzeuqARTkt/CrdPP+HYi0we5R2xawaA6Zqwp0ggJ7OFAhTnNZPhcpyRlJhxXdev1BMzbATj7
Esldbpsb86NO1oB/pk8z9pRruqBlfmyv2o08+lh2/qJ+h6608+n6KIsdrjp7aDLwCXjKQ3HPAZZS
aicxJxsFMJ1HRMVqpVADuawRcaZmL2Ex9cp0ar/vz728H+JtUf1C4k+3xne6K2NBPC9COGLmYKHB
Z8PpRUjp18rX5z5ffG2GO3qlJid4Kl8AQCU8SEHDPh2NOVVCAAAAAAAA

------=_NextPart_000_01AA_01D64338.30E4F830--


From nobody Tue Jun 16 07:44:12 2020
Return-Path: <internet-drafts@ietf.org>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EC93A169A; Tue, 16 Jun 2020 07:44:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
Cc: netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netconf@ietf.org
Message-ID: <159231865102.2579.15342612996294042117@ietfa.amsl.com>
Date: Tue, 16 Jun 2020 07:44:11 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/rq1yjrmD0mOyDB1XyE38pWP1z88>
Subject: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-06.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2020 14:44:11 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : YANG Groupings for TCP Clients and TCP Servers
        Authors         : Kent Watsen
                          Michael Scharf
	Filename        : draft-ietf-netconf-tcp-client-server-06.txt
	Pages           : 26
	Date            : 2020-06-16

Abstract:
   This document defines three YANG modules: the first defines a
   grouping for configuring a generic TCP client, the second defines a
   grouping for configuring a generic TCP server, and the third defines
   a grouping common to the TCP clients and TCP servers.

Editorial Note (To be removed by RFC Editor)

   This draft contains placeholder values that need to be replaced with
   finalized values at the time of publication.  This note summarizes
   all of the substitutions that are needed.  No other RFC Editor
   instructions are specified elsewhere in this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements:

   o  "DDDD" --> the assigned RFC value for this draft

   Artwork in this document contains placeholder values for the date of
   publication of this draft.  Please apply the following replacement:

   o  "2020-06-16" --> the publication date of this draft

   The following Appendix section is to be removed prior to publication:

   o  Appendix A.  Change Log

Note to Reviewers (To be removed by RFC Editor)

   This document presents a YANG module or modules that is/are part of a
   collection of drafts that work together to produce the ultimate goal
   of the NETCONF WG: to define configuration modules for NETCONF client
   and servers, and RESTCONF client and servers.

   The relationship between the various drafts in the collection is
   presented in the below diagram.

                                  crypto-types
                                    ^      ^
                                   /        \
                                  /          \
                       trust-anchors        keystore
                         ^     ^              ^  ^
                         |     +---------+    |  |
                         |               |    |  |
                         |       +------------+  |
   tcp-client-server     |      /        |       |
      ^    ^        ssh-client-server    |       |
      |    |           ^            tls-client-server
      |    |           |              ^     ^        http-client-server
      |    |           |              |     |                 ^
      |    |           |        +-----+     +---------+       |
      |    |           |        |                     |       |
      |    +-----------|--------|--------------+      |       |
      |                |        |              |      |       |
      +-----------+    |        |              |      |       |
                  |    |        |              |      |       |
                  |    |        |              |      |       |
               netconf-client-server       restconf-client-server


   Full draft names and link to drafts:

   o  draft-ietf-netconf-crypto-types (html [1])

   o  draft-ietf-netconf-trust-anchors (html [2])

   o  draft-ietf-netconf-keystore (html [3])

   o  draft-ietf-netconf-tcp-client-server (html [4])

   o  draft-ietf-netconf-ssh-client-server (html [5])

   o  draft-ietf-netconf-tls-client-server (html [6])

   o  draft-ietf-netconf-http-client-server (html [7])

   o  draft-ietf-netconf-netconf-client-server (html [8])

   o  draft-ietf-netconf-restconf-client-server (html [9])


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-06
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tcp-client-server-06


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

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



From nobody Tue Jun 16 07:59:05 2020
Return-Path: <01000172bda38ff6-995a4ea9-c660-4526-b24a-c7922a344289-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E409F3A16BB for <netconf@ietfa.amsl.com>; Tue, 16 Jun 2020 07:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 bGeTQrBX1CmU for <netconf@ietfa.amsl.com>; Tue, 16 Jun 2020 07:59:00 -0700 (PDT)
Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53D73A1689 for <netconf@ietf.org>; Tue, 16 Jun 2020 07:58:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1592319512; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=2jYMoO0fQqaUlXnhP7aOapu4VK65VXQjLget3IAv3nY=; b=MJH+9l9syBl+NPKqy4EgZMfBeZK2Hn1xBw+XWd3Yuv8arFwuL9028q5IZg9VDCnW up3obvNBu+Kdu9rcmU1CexrNzwZXqVzEl43zLxAvXAlaPeaKuV87D4fxWqk2L/70x5p dKZ7qGmD1RdWH/Md7j4/fW18lEdHpBuFm3bX6G6U=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Kent Watsen <kent@watsen.net>
In-Reply-To: <159231865102.2579.15342612996294042117@ietfa.amsl.com>
Date: Tue, 16 Jun 2020 14:58:32 +0000
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000172bda38ff6-995a4ea9-c660-4526-b24a-c7922a344289-000000@email.amazonses.com>
References: <159231865102.2579.15342612996294042117@ietfa.amsl.com>
To: "netconf@ietf.org" <netconf@ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.16-54.240.48.95
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/87JNXu6jJ1qJJujO16Keg3GxBiA>
Subject: Re: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-06.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2020 14:59:02 -0000

Dear WG,

This update adds support for TCP proxies (e.g., SOCKS4 and SOCKS5).

The desire for proxy support came from a review from the =E2=80=9Chttpbis"=
 WG of the http-client-server draft, whereby they noted the need for =
proxy support and, upon further discussion, it was determined that there =
are both TCP-based proxies and HTTP-based proxies.  This draft defines =
the support for the TCP-based proxies, while the http-client-server =
draft will define support for the HTTP-based proxies.  This update was =
reviewed by Michael Sharf, co-chair of the TCPM WG (and co-author of =
this draft).

This draft is now ready for WGLC.

Kent // contributor


> On Jun 16, 2020, at 10:44 AM, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Network Configuration WG of the IETF.
>=20
>        Title           : YANG Groupings for TCP Clients and TCP =
Servers
>        Authors         : Kent Watsen
>                          Michael Scharf
> 	Filename        : draft-ietf-netconf-tcp-client-server-06.txt
> 	Pages           : 26
> 	Date            : 2020-06-16
>=20
> Abstract:
>   This document defines three YANG modules: the first defines a
>   grouping for configuring a generic TCP client, the second defines a
>   grouping for configuring a generic TCP server, and the third defines
>   a grouping common to the TCP clients and TCP servers.
>=20
> Editorial Note (To be removed by RFC Editor)
>=20
>   This draft contains placeholder values that need to be replaced with
>   finalized values at the time of publication.  This note summarizes
>   all of the substitutions that are needed.  No other RFC Editor
>   instructions are specified elsewhere in this document.
>=20
>   Artwork in this document contains shorthand references to drafts in
>   progress.  Please apply the following replacements:
>=20
>   o  "DDDD" --> the assigned RFC value for this draft
>=20
>   Artwork in this document contains placeholder values for the date of
>   publication of this draft.  Please apply the following replacement:
>=20
>   o  "2020-06-16" --> the publication date of this draft
>=20
>   The following Appendix section is to be removed prior to =
publication:
>=20
>   o  Appendix A.  Change Log
>=20
> Note to Reviewers (To be removed by RFC Editor)
>=20
>   This document presents a YANG module or modules that is/are part of =
a
>   collection of drafts that work together to produce the ultimate goal
>   of the NETCONF WG: to define configuration modules for NETCONF =
client
>   and servers, and RESTCONF client and servers.
>=20
>   The relationship between the various drafts in the collection is
>   presented in the below diagram.
>=20
>                                  crypto-types
>                                    ^      ^
>                                   /        \
>                                  /          \
>                       trust-anchors        keystore
>                         ^     ^              ^  ^
>                         |     +---------+    |  |
>                         |               |    |  |
>                         |       +------------+  |
>   tcp-client-server     |      /        |       |
>      ^    ^        ssh-client-server    |       |
>      |    |           ^            tls-client-server
>      |    |           |              ^     ^        http-client-server
>      |    |           |              |     |                 ^
>      |    |           |        +-----+     +---------+       |
>      |    |           |        |                     |       |
>      |    +-----------|--------|--------------+      |       |
>      |                |        |              |      |       |
>      +-----------+    |        |              |      |       |
>                  |    |        |              |      |       |
>                  |    |        |              |      |       |
>               netconf-client-server       restconf-client-server
>=20
>=20
>   Full draft names and link to drafts:
>=20
>   o  draft-ietf-netconf-crypto-types (html [1])
>=20
>   o  draft-ietf-netconf-trust-anchors (html [2])
>=20
>   o  draft-ietf-netconf-keystore (html [3])
>=20
>   o  draft-ietf-netconf-tcp-client-server (html [4])
>=20
>   o  draft-ietf-netconf-ssh-client-server (html [5])
>=20
>   o  draft-ietf-netconf-tls-client-server (html [6])
>=20
>   o  draft-ietf-netconf-http-client-server (html [7])
>=20
>   o  draft-ietf-netconf-netconf-client-server (html [8])
>=20
>   o  draft-ietf-netconf-restconf-client-server (html [9])
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-06
> =
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server=
-06
>=20
> A diff from the previous version is available at:
> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-tcp-client-server-0=
6
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
>=20
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nobody Tue Jun 16 16:37:44 2020
Return-Path: <mjethanandani@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF853A0A80 for <netconf@ietfa.amsl.com>; Tue, 16 Jun 2020 16:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 54PxnqeeWkQI for <netconf@ietfa.amsl.com>; Tue, 16 Jun 2020 16:37:41 -0700 (PDT)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 AF53A3A0A7D for <netconf@ietf.org>; Tue, 16 Jun 2020 16:37:41 -0700 (PDT)
Received: by mail-pj1-x102e.google.com with SMTP id m2so128375pjv.2 for <netconf@ietf.org>; Tue, 16 Jun 2020 16:37:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:date:references:to:in-reply-to:message-id;  bh=+XSiPbLLTrz7EmBMqYrj+zIOYu72BHOnz7xX/bucxsc=; b=CRRJhtbbWGWH/8iFgv+0bu6i/2TcJmT3dPyZLZEmlMCETMforu47Q4h6QHfQuEMqub wRacvs+twYXNulKsu5NSlqr6weIUQkZEbUoXGQDf88IpI4A64PbAfI6rhnQ1ZNemwhXu u3yqKXTLNLGoFtDpwwnkilC/5VoNargXwOPEnuu7gCl7HM+kchNNLvoxU6U4jXAPbSIH +6I0RhAg1AMATydpU6UZPpU1t9c5JbFr9t5uC6f7MCR5u4xscquQzC/8sS1NAJ1TKoO3 b2sDNwsRMsdnj1kdUbc90ky9f/OvFxDZStLmXVC7LsyWqJO4d9BR7aGiHZYcNauCezfZ CNEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=+XSiPbLLTrz7EmBMqYrj+zIOYu72BHOnz7xX/bucxsc=; b=HRp0t4k43ML1CBcYYvGR0bmizdggHnQmKJwfaLlIsIFjtnF+EDbxfhA1XLIfs4w73U 25yl1cQWUFqrSbU8FbHZ9qZsAoyaGICoecq4whlg2oQQO3y+/LsccU6aQd8pZkLLGEmP 66hiuv0Fk+Tds/lDjwUb3uWehV42S7/yIVY21jF+nwhc/7v7xKCC2cISIv8hd9VEOT+r i13kmo+QVv9D9cXOmlEytU9TUzNCqXcLkxw81t08yjX40e7y0un6UjQ9zy7Gesbtqkgj dJxzyVpqMjIo8+3J1krd2TNPkW8au+lB6m4MFNqmHDDTOgw1Pbzz59slN23/ldiRXGGf 8EqA==
X-Gm-Message-State: AOAM5328LdPUCf9HSXuL5NNolDUkRpIUlcK++Fn8y7C7D0/MC9g2kVVx dWI+VkNpVwoMj478YqZWZMRjudmIjA4=
X-Google-Smtp-Source: ABdhPJyxJ8gWPFt8Nmx/6oey1P2LUcaAEpBedMtT72MvuaqUBhub3inSoYwMs3xrijlA406m/oNmcw==
X-Received: by 2002:a17:90a:f0d4:: with SMTP id fa20mr5282563pjb.160.1592350660510;  Tue, 16 Jun 2020 16:37:40 -0700 (PDT)
Received: from ?IPv6:2601:647:5600:5020:c80b:fb17:1422:39d0? ([2601:647:5600:5020:c80b:fb17:1422:39d0]) by smtp.gmail.com with ESMTPSA id nl5sm3804375pjb.36.2020.06.16.16.37.38 for <netconf@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2020 16:37:38 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2F841AAD-5306-4D1A-82C7-D7E45E99954E"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Date: Tue, 16 Jun 2020 16:37:38 -0700
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com>
To: Netconf <netconf@ietf.org>
In-Reply-To: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com>
Message-Id: <6420A299-607B-4824-B234-48901154234D@gmail.com>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/a2kByJuXp1tGRHAMsQEkKoQn5ak>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2020 23:37:43 -0000

--Apple-Mail=_2F841AAD-5306-4D1A-82C7-D7E45E99954E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The WGLC on these three drafts has received insufficient review at this =
time. I am going to extend the LC by another week to allow for more =
review of these documents. While specific comments would be great, even =
saying =E2=80=9CI have reviewed the draft, and support its =
publication=E2=80=9D is helpful.

As a reminder, we are following option 3 in this=C2=A0message =
<https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe-v0l6MI=
/>. What that means is that once Kent has updated the tcp-client-server =
draft, it will be added to this set of drafts for LC before 108. The =
remaining drafts, ssh-client-server, tls-client-server =
http-client-server, netconf-client-server, restconf-client-server will =
be sent for LC after 108.

Thanks.

> On Jun 2, 2020, at 4:48 PM, Mahesh Jethanandani =
<mjethanandani@gmail.com> wrote:
>=20
> NETCONF WG,
>=20
> The authors of
>=20
> - draft-ietf-netconf-crypto-types
> - draft-ietf-netconf-keystore
> - draft-ietf-netconf-trust-anchors
>=20
> have indicated that these drafts are ready for Last Call (LC).
>=20
> This kicks of a 2 week WG LC for the three drafts. Please review and =
send any comments to the WG mailing list or by responding to this =
e-mail. Comments can be statements such as, I read/reviewed the document =
and believe it is ready for publication, or I have concerns about the =
document. For the latter, please indicate what your concerns are.=20
>=20
> Any reports on implementation status or plans to implement are also =
very useful.
>=20
> Thanks.
>=20

Mahesh Jethanandani (as co-chair)
mjethanandani@gmail.com


--Apple-Mail=_2F841AAD-5306-4D1A-82C7-D7E45E99954E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div =
class=3D""><div class=3D"" style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><div =
class=3D"">The WGLC on these three drafts has received insufficient =
review at this time. I am going to extend the LC by another week to =
allow for more review of these documents. While specific comments would =
be great, even saying =E2=80=9CI have reviewed the draft, and support =
its publication=E2=80=9D is helpful.<div class=3D""><br =
class=3D""></div><div class=3D"">As a reminder, we are following option =
3 in&nbsp;<a =
href=3D"https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe=
-v0l6MI/" class=3D"">this&nbsp;message</a>. What that means is that once =
Kent has updated the tcp-client-server draft, it will be added to this =
set of drafts for LC before 108. The remaining drafts, =
ssh-client-server, tls-client-server http-client-server, =
netconf-client-server, restconf-client-server will be sent for LC after =
108.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Thanks.</div></div></div></div><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Jun 2, 2020, at 4:48 PM, =
Mahesh Jethanandani &lt;<a href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D"">NETCONF WG,<br class=3D""><br class=3D"">The authors of<br =
class=3D""><br class=3D"">- draft-ietf-netconf-crypto-types<br =
class=3D"">- draft-ietf-netconf-keystore<br class=3D"">- =
draft-ietf-netconf-trust-anchors<br class=3D""><br class=3D"">have =
indicated that these drafts are ready for Last Call (LC).<br =
class=3D""><br class=3D"">This kicks of a 2 week WG LC for the three =
drafts. Please review and send any comments to the WG mailing list or by =
responding to this e-mail. Comments can be statements such as, I =
read/reviewed the document and believe it is ready for publication, or I =
have concerns about the document. For the latter, please indicate what =
your concerns are. <br class=3D""><br class=3D"">Any reports on =
implementation status or plans to implement are also very useful.<br =
class=3D""><br class=3D"">Thanks.<br class=3D""><br =
class=3D""></div></div></blockquote><br class=3D""><div class=3D""><div =
class=3D"">Mahesh Jethanandani (as co-chair)<br class=3D""><a =
href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a><br class=3D""><br =
class=3D""></div></div></div></body></html>=

--Apple-Mail=_2F841AAD-5306-4D1A-82C7-D7E45E99954E--


From nobody Wed Jun 17 00:54:24 2020
Return-Path: <ietfc@btconnect.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4833A003D for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 00:54:22 -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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 1q9MXNTdzEnw for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 00:54:21 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2112.outbound.protection.outlook.com [40.107.22.112]) (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 C15323A005B for <netconf@ietf.org>; Wed, 17 Jun 2020 00:54:20 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cyihDKYERf9C4MRRBpd4f0KYS5K0U7oOh+OBxt/DDWojOXdX3dg5RFC555GrtRlCoUfBjAz0XEG8isYxwsQ3rCBkBE+HDhgjhuzPFYxh93gzWWjMJdMPHDtxb7zZCRN2lvJSEvqCUui/f2fu4r04riINlr/6ECrYIaKqkYSDB/HOu2lR07N2WdTjJo0A3ygCNRY1TKmcUkk9tPFZbV2Ag4lv/aYMH7d2YA+JNNn5erxx6AHmZj6eQX/eLI0iOm/thN9JuEDGii2z2bp5krRtWeTrWUFbk/bB1sAH+m6am1EynFJJAu/9DFzLQYim/5yAC3TKjUiUHW7/UBnci0xDVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2gm2ZOwXATXyo8onEryrZ7WZ2lsDS3WUhyEsfeNfd88=; b=mBcemV9dr5uJuiRp1xJF3mQMOsPnw1dKeKs6YOK4CSHEJL8qs88FYhZonm6A2if/4QIeHmWMLC5IHOmdIKyQ1HFdxWRR3sviJEgWoVTNWfSd3St88c3z1iRJgOqVxdYdvDAg8Drs4RONcaGbSW9Moum+bjyVjqyR0F2qu7E0ux4vwrv/3Fio8J6M/U5nvT3M1oUtDzAxPgB5sM4LUCJdr8dqYdTzrTT0C2r7XOhq1gljZt0VIQIm7fKJeGqE60iNAK9HTfdQLQl+nqHK9NCBoV1uLVvUl1cSl7mh4Mp3DbGsLBfiIT/WGnfP5HDI9skpl1ErU7996fdJhmpT4z6aSw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2gm2ZOwXATXyo8onEryrZ7WZ2lsDS3WUhyEsfeNfd88=; b=YqK4nTiPBqcCpNUhSwGrt5VWqYaWly84OoBsTSSc+BK769HZwuQaCLazTEcEyx0ERhq6qC4gw6fMDGsGCdkBJIKX+Y8COV9hDhFyCFNpEu3Wd98bR5D2FQtnV4Zb5t9j6fUTKPr7hEXe7VPhm5dLzF9X00KWhGAwb6DaJG7+6Kw=
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com (2603:10a6:10:198::14) by DB7PR07MB4716.eurprd07.prod.outlook.com (2603:10a6:5:35::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.13; Wed, 17 Jun 2020 07:54:18 +0000
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65]) by DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65%7]) with mapi id 15.20.3109.018; Wed, 17 Jun 2020 07:54:18 +0000
From: tom petch <ietfc@btconnect.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts
Thread-Index: AQHWOThMOtlQSxaDHEC0TmDma2Bnbqjb+8wAgACIXbU=
Date: Wed, 17 Jun 2020 07:54:18 +0000
Message-ID: <DBAPR07MB7016CB0104CC8718037DE35EA09A0@DBAPR07MB7016.eurprd07.prod.outlook.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com>, <6420A299-607B-4824-B234-48901154234D@gmail.com>
In-Reply-To: <6420A299-607B-4824-B234-48901154234D@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
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=btconnect.com;
x-originating-ip: [86.139.211.29]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e99841d3-22ee-4560-ce7c-08d81293a336
x-ms-traffictypediagnostic: DB7PR07MB4716:
x-microsoft-antispam-prvs: <DB7PR07MB47160DE59A3A1D9CBB2BBD9DA09A0@DB7PR07MB4716.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04371797A5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TxvwK/arxIIUWrBMYFGeq+TZqHprg6KZYUorsO7M0+lqlBYOBBf8F+RTvsAMyAF9R84sPpcmE40qoKg0ssZYGWGToN5Y0OwSnVeE6EfDJhRrQ7tim3J6KGC5j7cZjM8JWWLNyHvjF2sTVOnDc9VfsChzm3UGs8QH9esONKNARsTeoouLS4zyUiXfmtoqnoq0Sqz/VnoBmrLvpRrT698m8ecGFkpeIveD34xaIz1lCfZ9riKr88iPqONajDBu+L/1ed6YFvNQUBz0cDpKEJGABC4tNj8BmNpepNsYM5RJrlyK7m3Rsj57LBSHxETMEQ1Ppnc1Lb51wQRJ3Gj5sfvUMJJaVkF8upJadrq3Pvb49bveZYf+M2xFIGKdR+JQG5A04ay/13FSVXP/CIXd6Dh0JQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DBAPR07MB7016.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(39860400002)(366004)(346002)(396003)(136003)(376002)(55016002)(7696005)(316002)(86362001)(71200400001)(33656002)(110136005)(9686003)(2906002)(8676002)(186003)(91956017)(8936002)(26005)(66946007)(76116006)(66476007)(5660300002)(83380400001)(52536014)(64756008)(66446008)(66556008)(53546011)(478600001)(6506007); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: T91wv/xaFcqDkvlmrK4SAJc4j46h5PCSPpp6eRYLsC/1XBefD3eLM0bQjMqcQcJc283RQ3K3jk3+P0aNHPvykW46e38c54hzUNug35ArmrROpzyEqqf71i6KWlPzunjV8wGByVfweEjMFtuUvJxq0WQCkAGZESGbQFtZZiXPih+DxEsysdr6Gh/vCl0ITafHZa9zNw5Yerl1QuICJKiIFecTjN6f0nYv59LcpkuLGd5akvsCzUIu8ES/hfIlsyiLnkC+65FxqTAWQjW7rx/fn4MC+xIeSgn+nldtIovub+xVD91HggrJ7YYLWVRaNfcZUzWOpdBG0cASZGv+n10PNpwM39yjB8+nquHFblI0U0dfEv13Uh5DhEpj0OkvePc53rJslaF0kHHOAGNDYWTs0zwER/+aVIkslzpvQrFkKhIisfmHJR+KzIDYI8kNObc7C3CNakg+m+Rzmc58pSLPwXHl58Xxf7RIs9RxeMhVas/9UEUJoesjrYXqAPiIrRAS
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e99841d3-22ee-4560-ce7c-08d81293a336
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 07:54:18.0143 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: BkZ+ZvtVxPejFUoDPQTjN+5sGS6BMpMiiXxiAdb7ZDPWuWGusywywFY5WwGONclW3FDApBcINpHnvAQtXnjZWw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4716
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/dn-HSuAe0ov-_7DMfvC6C32SX4U>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 07:54:22 -0000

From: netconf <netconf-bounces@ietf.org> on behalf of Mahesh Jethanandani <=
mjethanandani@gmail.com>=0A=
Sent: 17 June 2020 00:37=0A=
=0A=
The WGLC on these three drafts has received insufficient review at this tim=
e. I am going to extend the LC by another week to allow for more review of =
these documents. While specific comments would be great, even saying =93I h=
ave reviewed the draft, and support its publication=94 is helpful.=0A=
=0A=
<tp>=0A=
Sorry to be contrary but I have reviewed the draft and do not support publi=
cation was my take on  the types as I want to read text before I reverse en=
gineer the YANG.  For all three, and probably for those yet to come, I thin=
k that they all need something that places them in context because there ar=
e so many of them and they interact.  The ASCII diagram in them currently i=
s likely fine for those of us who have seen them evolve but likely inadequa=
te for those outside the WG.  (Of course those who are new to the I-D will =
not have the baggage of history and so may not have such a problem:-)  Thin=
k of the TSVWG author who wants to know where to find what to include in th=
eir model.  Should there be a separate  I-D providing an introduction?  May=
 be.=0A=
Tom Petch=0A=
=0A=
=0A=
=0A=
=0A=
As a reminder, we are following option 3 in this message<https://mailarchiv=
e.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe-v0l6MI/>. What that means =
is that once Kent has updated the tcp-client-server draft, it will be added=
 to this set of drafts for LC before 108. The remaining drafts, ssh-client-=
server, tls-client-server http-client-server, netconf-client-server, restco=
nf-client-server will be sent for LC after 108.=0A=
=0A=
Thanks.=0A=
=0A=
On Jun 2, 2020, at 4:48 PM, Mahesh Jethanandani <mjethanandani@gmail.com<ma=
ilto:mjethanandani@gmail.com>> wrote:=0A=
=0A=
NETCONF WG,=0A=
=0A=
The authors of=0A=
=0A=
- draft-ietf-netconf-crypto-types=0A=
- draft-ietf-netconf-keystore=0A=
- draft-ietf-netconf-trust-anchors=0A=
=0A=
have indicated that these drafts are ready for Last Call (LC).=0A=
=0A=
This kicks of a 2 week WG LC for the three drafts. Please review and send a=
ny comments to the WG mailing list or by responding to this e-mail. Comment=
s can be statements such as, I read/reviewed the document and believe it is=
 ready for publication, or I have concerns about the document. For the latt=
er, please indicate what your concerns are.=0A=
=0A=
Any reports on implementation status or plans to implement are also very us=
eful.=0A=
=0A=
Thanks.=0A=
=0A=
=0A=
Mahesh Jethanandani (as co-chair)=0A=
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>=0A=
=0A=


From nobody Wed Jun 17 03:53:35 2020
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441003A094A for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 03:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 PkM7hG9zU1IG for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 03:53:32 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB153A0944 for <netconf@ietf.org>; Wed, 17 Jun 2020 03:53:31 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 554424C1; Wed, 17 Jun 2020 12:53:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Ut_Du1fvZ_HR; Wed, 17 Jun 2020 12:53:29 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Jun 2020 12:53:29 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id F21CB20154; Wed, 17 Jun 2020 12:53:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id P5I5RzPiXyuT; Wed, 17 Jun 2020 12:53:28 +0200 (CEST)
Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 7756B200E4; Wed, 17 Jun 2020 12:53:28 +0200 (CEST)
Date: Wed, 17 Jun 2020 12:53:28 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Netconf <netconf@ietf.org>
Message-ID: <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/-ooxVS5WL1Y4iCwemVAgc7puX48>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 10:53:34 -0000

I have reviewed the I-Ds today and here are my comments:

* general comments

  - These drafts needs serious reviews by security domain experts.
    This all looks reasonable to me but since this is all about
    security, we need to set the bar high to get things right.

  - I think the work is in a good shape but the documents need another
    round of tweaks to get them ready.

* draft-ietf-netconf-crypto-types-15.txt

  - I agree with others that this document lacks introductory
    material.

  - Perhaps the title should reflect that this document is not
    just defining types but also groupings.

  - The public-key-grouping says that it captures a public key and its
    associated algorithm but I am not sure how this is done or is the
    idea that every algorithm requires a different public-key-format?

  - The asymmetric-key-pair-grouping says that it captures a private
    key and its associated public key and algorithm but I am not sure
    how this is done or is the idea that every algorithm requires a
    different private-key-format? I also wonder how this grouping
    captures the associated public key.

  - Do we have to be prepared for alternate cert formats in the
    future?

  - The certificate-expiration notification of the
    trust-anchor-certs-grouping probably needs adjustment; I assume
    this applies to any certificate the the cert leaf-list.

  - Is there any semantic difference between
    trust-anchor-cert-grouping and end-entity-cert-grouping, i.e., why
    do we need two groupings? Same question for
    trust-anchor-certs-grouping and end-entity-certs-grouping. If
    there is a semantic difference, perhaps this should be highlighted
    in the grouping description.

  - I have not checked the examples.

* draft-ietf-netconf-trust-anchors-10.txt

  - I agree with others that this document lacks introductory
    material. I am personally not a fan of one sentence sections
    but that may be just a personal style / preference issue.

  - The idea that there are groupings that support locally defined
    crypto keys or references to a centralized trust store really
    deserves to be explained upfront. Yes, I can reverse engineer this
    from the definitions, but people who need to decide whether they
    want to implement this module may not have the time and energy to
    do this. Notice that the abstract only talks about bags that can
    be referenced.

  - How does the storage of user public ssh keys suggested in the
    example usage section relate to the data model in RFC 7317?

  - The authors listed on the document and in the yang module are
    different.

  - Do we need the truststore-supported feature? We do not have this
    in other YANG modules. Is the idea to distinguish implementations
    that only import groupings? Even in this case, should this not be
    handled by the yang library somehow?

  - Do the leaf names always look good in instance data? For example,
    is <truststore-reference> may not be the most descriptive name in
    instance data. Perhaps it would help to also have examples that
    show how various groupings are used, not just the bags.

  - I have to think about the 'copy to running' procedure described in
    section 3. Perhaps this is the way to go but who happens if things
    get out of sync?

  - Why is it useful to define truststore-grouping, i.e., why is this
    not just a part of the truststore container definition? How are
    the reference types going to work if you instantiate the
    truststore-grouping elsewhere?

  - I have not checked the examples.

* draft-ietf-netconf-keystore-17.txt

  - Looking at the overview figure (that is unfortunately to be
    removed), I wonder whether trust-anchors should be renamed to
    truststore as this seems to be the term used by the yang module.

  - I appreciate the introductory text that this I-D has (compared to
    the others).

  - Several pages of yang tree output without explanations is not very
    helpful. I suggest to break this into pieces and to explain for
    each grouping when it may be used (or not used).

  - I am not sure I understand the examples, more precisely, how
       <keystore-reference>rsa-asymmetric-key</keystore-reference>
    or
       <keystore-reference>
         <asymmetric-key>rsa-asymmetric-key</asymmetric-key>
         <certificate>ex-rsa-cert</certificate>
       </keystore-reference>
    will be interpreted.

  - What is the informative reference to RFC8342 in the YANG module?

  - Do we need the keystore-supported feature? See discussion above.

  - Should the support for encrypted keys be moved to the cryto-types
    module? Is there a reason why we add the feature to have keys
    encrypted here? Perhaps this is sensible, I am just trying to
    check whether this has been given some thought.

  - Why is it useful to define keystore-grouping, i.e., why is this
    not just a part of the keystore container definition? How are the
    reference types going to work if you instantiate the
    keystore-grouping elsewhere?

  - I have to think about the 'copy to running' procedure described in
    section 4. Perhaps this is the way to go but who happens if things
    get out of sync? What is a system provided cert is exceeding its
    lifetime (does this even lead to a stream of notifications)?

  - The text in 5.3 scares me a bit. Migrating root keys may be seen
    as a bad idea by some. If you have a new device with new root
    keys, then you better re-encrypt or re-key instead of patching the
    root key.  Or are you essentially saying that encrypted keys
    should be encrypted with a key-encryption-key instead of the 'root
    key'?

  - I am not sure how one implements the 'MUST ensure that the
    strength of the key being configured is not greater than the
    strength of the underlying secure transport' nor am I sure that
    the consequences are really desirable, i.e., I can never move to
    'more secure keys' than what the transport currently allows. I
    think I understand the argument that says a key can't be more
    trustworthy than the transport used to configure it but I do not
    think we should disallow upgrade paths.

  - I have not checked the examples.

/js

On Tue, Jun 02, 2020 at 04:48:07PM -0700, Mahesh Jethanandani wrote:
> NETCONF WG,
> 
> The authors of
> 
> - draft-ietf-netconf-crypto-types
> - draft-ietf-netconf-keystore
> - draft-ietf-netconf-trust-anchors
> 
> have indicated that these drafts are ready for Last Call (LC).
> 
> This kicks of a 2 week WG LC for the three drafts. Please review and send any comments to the WG mailing list or by responding to this e-mail. Comments can be statements such as, I read/reviewed the document and believe it is ready for publication, or I have concerns about the document. For the latter, please indicate what your concerns are. 
> 
> Any reports on implementation status or plans to implement are also very useful.
> 
> Thanks.
> 
> Mahesh Jethanandani (as co-chair)
> mjethanandani@gmail.com
> 
> 
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>


From nobody Wed Jun 17 07:59:43 2020
Return-Path: <rsalz@akamai.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8BA3A07B6 for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 07:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=akamai.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 Q0NLybn9Nik9 for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 07:59:39 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 0C54D3A07A5 for <netconf@ietf.org>; Wed, 17 Jun 2020 07:59:38 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 05HEwmHB003374; Wed, 17 Jun 2020 15:59:38 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=4yDqj4vpUPks+ZbOEZcKAKPPAQeRJ4SJqknVjqkXifQ=; b=oVuSoSmNvYPPNH7lmUCs1KcnNh/JmQxOIZJA0KGUHYk/8WmGpnUT4f5UFVNXg3vYuuKP RSGKAaSuOnbR93eW40LdyR6VUCMDFUtRoqQ1fe/a4fJ8G2uaA47EG964gdTR245G7oAE jHOvT3ZADDtry7TPeETmzKomfmrl2yRc+VoPgQIPntpfoi8lDxFqtYR1qpavQ0r7ZdeY I7xIsbmEvKI9TbbwApDhLRNhPRWzN+mBE/QO44ei0FNNCTYYyx/mz094uJSHsxfv/9KV Goo14ORvLwr+xHfMrakOvpuMyd72bWbqzm2ZpcfNGuVG4lrbbTo7kLl2lmm+W1CLOlIS zA== 
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 31qhedf8dt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Jun 2020 15:59:37 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05HEkYbx021665; Wed, 17 Jun 2020 10:59:36 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint2.akamai.com with ESMTP id 31qjm10ndk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 17 Jun 2020 10:59:36 -0400
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 17 Jun 2020 09:59:35 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Wed, 17 Jun 2020 09:59:35 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Mahesh Jethanandani" <mjethanandani@gmail.com>
CC: Netconf <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts
Thread-Index: AQHWOThMaW9TVQbVp0aakzz8vRafn6jdDHEAgAABtAA=
Date: Wed, 17 Jun 2020 14:59:34 +0000
Message-ID: <14453F87-3F9D-40AA-A4E5-DAD7D66B480C@akamai.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de>
In-Reply-To: <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.38.20061401
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.112.103]
Content-Type: text/plain; charset="utf-8"
Content-ID: <B7325777E78F7544B3E70D0BA9BA6E12@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-17_04:2020-06-17, 2020-06-17 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 suspectscore=0 phishscore=0 mlxlogscore=597 adultscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006170114
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-17_04:2020-06-17, 2020-06-17 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 mlxlogscore=575 mlxscore=0 malwarescore=0 bulkscore=0 cotscore=-2147483648 phishscore=0 lowpriorityscore=0 spamscore=0 adultscore=0 suspectscore=0 impostorscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006170117
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/NrjnBTq5hdZkkGZpNcOqDXGQ7iE>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 14:59:42 -0000

PiAgICAgIC0gVGhlc2UgZHJhZnRzIG5lZWRzIHNlcmlvdXMgcmV2aWV3cyBieSBzZWN1cml0eSBk
b21haW4gZXhwZXJ0cy4NCiAgICAgICAgVGhpcyBhbGwgbG9va3MgcmVhc29uYWJsZSB0byBtZSBi
dXQgc2luY2UgdGhpcyBpcyBhbGwgYWJvdXQNCiAgICAgICAgc2VjdXJpdHksIHdlIG5lZWQgdG8g
c2V0IHRoZSBiYXIgaGlnaCB0byBnZXQgdGhpbmdzIHJpZ2h0Lg0KDQpGb3Igd2hhdCBpdCdzIHdv
cnRoLCBJJ3ZlIGhhZCBhIGNvdXBsZSBvZiBkaXNjdXNzaW9ucyB3aXRoIEtlbnQgb24gdGhlc2Ug
b3ZlciB0aW1lLiAgSSB0aGluayByZXF1ZXN0aW5nIGFuIGFkZGl0aW9uYWwgc2VjdXJpdHkgZGly
ZWN0b3JhdGUgZWFybHkgcmV2aWV3IGlzIHByb2JhYnkgYSBnb29kIGlkZWEuDQoNCj4gICAgICAt
IERvIHdlIGhhdmUgdG8gYmUgcHJlcGFyZWQgZm9yIGFsdGVybmF0ZSBjZXJ0IGZvcm1hdHMgaW4g
dGhlDQogICAgICAgIGZ1dHVyZT8NCg0KTm8uIDopIElmIHNvbWV0aGluZyBjb21lIHRvIGRpc3Bs
YWNlIFg1MDl2MywgbWFueSB0aGluZ3Mgd2lsbCBoYXZlIHRvIHVuZGVyZ28gc29tZSBmdW5kYW1l
bnRhbCBjaGFuZ2VzLg0KDQogDQoNCg==


From nobody Wed Jun 17 09:23:38 2020
Return-Path: <ietfc@btconnect.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634433A09DE for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 09:23: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 SkiKnbOs7dXg for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 09:23:34 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2100.outbound.protection.outlook.com [40.107.20.100]) (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 760A93A09DB for <netconf@ietf.org>; Wed, 17 Jun 2020 09:23:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H+ZL8IfAWmVoXSPDKrBuqYu0C6xVL8S7TKyW8UqH1tbK81SchOlU6z3WzKytzICysAooEM6uYl3I+UiT1u+wx1hZ5WFgcJjs1ou1hLqHRGiw9oG3TjLUhud4+GWrQyCzXlIR80MT7VUw1BDy+kK0wq195NgA+SGHwlYQzTAT3E2DmpPgiUUKorkOL6yOAN/3DFkvgFlZKbTQBH/TzMRzFsCC3Fs0h+r7Um3DMdZnB3KwiFF3eXaiqxJl8hC9YcImNN/uY/hiu6Yb9uo7e2ZmhUq22BEfCXq9VWea5g/2KLjPCu8kVa9A4juHylNHBXKg/86rR8m3ppAE4mCTVnI37w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vG2dAFFVGiqYRDoRee9XDDgq6Yh9i1CjRCkie8juhFY=; b=P8XIe2RKh+p6dFn41uLs/gsClB3ar7Ep6Q/x+qpSBwgEAEASgzNQn9eye7+cIF7WcvoonMBCkR+AMNVJyzbqNcx1Me/zw2Ssn/SHyABHWBYNBh5M/BWf3hjNprD5LzCwRLXU+INwkzYt8qVhao9XS5L3/I9ao1aMdV0VRDSZREYOi9q8cGfXxmUYe2ZRz2zWU1JDKJxB+dsfbFkLqbBZI0DnJvyAXLrDe1rDyLIKJrU7IR3ikPuNqlb6l+I4YmEFWKtshshEM6+HmPmF65W2S96fKv2LsSy/JWH7amTHv+lUEpZjaGvjbJAUCPBBtEQJenM+5Osa+8MuBZ5sitBdJQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vG2dAFFVGiqYRDoRee9XDDgq6Yh9i1CjRCkie8juhFY=; b=swDL96wpqbbUziMEQ5gyoHdB+R7s6yLd+I3Znz6Nw7i9vZBa0GazoMLOfL0Am34zlQHOJJgQvARjolQP0beXMl/oWU4uDQbJ0jrQQpRQ5fOX1aE134YTzQ6KohTFF383e43L9NhovecNKNVUbXdhabrpIEYP5tystWIiXL9mKog=
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com (2603:10a6:10:198::14) by DB6PR0701MB2216.eurprd07.prod.outlook.com (2603:10a6:4:50::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.9; Wed, 17 Jun 2020 16:23:31 +0000
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65]) by DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65%7]) with mapi id 15.20.3109.018; Wed, 17 Jun 2020 16:23:31 +0000
From: tom petch <ietfc@btconnect.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: Netconf <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts or two of them
Thread-Index: AQHWQXXxqA+PBQ9xTESoskd/uJ8I1ajdArkB
Date: Wed, 17 Jun 2020 16:23:31 +0000
Message-ID: <DBAPR07MB7016369E32D8534F7C967719A09A0@DBAPR07MB7016.eurprd07.prod.outlook.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com>, <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com>, <DBAPR07MB7016F753766FCE8AD12A2F5DA09E0@DBAPR07MB7016.eurprd07.prod.outlook.com>
In-Reply-To: <DBAPR07MB7016F753766FCE8AD12A2F5DA09E0@DBAPR07MB7016.eurprd07.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.139.211.29]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 35b663be-1b66-43fd-26b1-08d812dac679
x-ms-traffictypediagnostic: DB6PR0701MB2216:
x-microsoft-antispam-prvs: <DB6PR0701MB22164670B13FD862122D8073A09A0@DB6PR0701MB2216.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04371797A5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 91VLer/h5a1aTz/GQD5KKNvjGgSXydxWwivO9fRXqebjxuXJnACwE0JjXFQj6eODgYdladeN2ShCC8e9aWsT2cz6MeyNWBa3n/16JiA0L6J09nCM4XZrWe4Zj6CdCNnQ3ObT5L6QnNuQ1n85wk7G6TiD/DhLmYl0jtS3B+Bo7su4Z5dofa1+LHSuFwt1D8+9EZZI7L94nkC8ryfQ0b04xKpBByq9lkg7pnKIdqSdG1G1WIounFGSVVoi8Wd2NYV+jQ2UQAXS5dyOc3qg3dONjWk6aWH/OIBFsZSAKOEosP7rR4EPmXhDOOIJoejoEt/SeccvXvPGZm1ePQJbCTFV0SOacdHJIemdaIUYUYPGYfJRiLFvqQ5g4bSjImwrpWPua/bxHjY1hHXuJPyuiH9bDA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DBAPR07MB7016.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(396003)(39860400002)(346002)(136003)(376002)(366004)(52536014)(91956017)(76116006)(966005)(86362001)(83380400001)(7696005)(71200400001)(5660300002)(316002)(66946007)(66476007)(66556008)(66446008)(8936002)(6506007)(478600001)(64756008)(53546011)(9686003)(186003)(33656002)(26005)(4326008)(2906002)(8676002)(55016002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: ZwiBkEMPd9cyAfvROWBJBOdhYPArRz0W7NSO0syMUU08g1I0weWg0fS09rR6pS3JLhLUcqsFrccTuoIqD2SFXFnl50vJkGNqpL7EAiPCwvZc9HWvS5NZiX7vPijtmSbzGoq//svAOoyDI/YAxg20NoIk4kIuhhyWdzOn7fskAkRMdRQiTA8AlpFF9sJePp2FyrJHfzFDKoLdpuM3QEzs2B+JU3J6h8YNtROdg5u86+bg0RAgAZfAoUZHsyq/SmafM+sEfRk8pjQ25vzAne0I3gVYHGvKoMR2qr34/Ctq+QE1BhBaq1/6sx5NZ5hDtOcHVVFuLmXFiWS4oOdjyQC8yxMbbFQ8rt1KdwHaknHoaMqMmrsImIotuEazGnMaYaku5HGUJ5SYUzqMH0c9Ef04OeK512wZQlsR0DsWU6EeeHSDnBy3CZHoaJoHXo5NN1Du5t682IgJvmmq6F8r0bYoRkZ8RGk2ME/zeSNXpWIxlfcNjGhkAZe3b8HpMpcyeBXr
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 35b663be-1b66-43fd-26b1-08d812dac679
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 16:23:31.2952 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GVhBJsAbJMAG/FoYB6lUddbPA7bROZ0j4r7nZbF044qdXDvziTYHdflbyXa5n1OyLFCT4hnVyoaFtAOuSdYzbw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2216
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/7o-30k1UrcdPdMA9AxI6-vDmv38>
Subject: Re: [netconf] WG LC for three drafts or two of them
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 16:23:37 -0000

From: netconf <netconf-bounces@ietf.org> on behalf of tom petch <ietfc@btco=
nnect.com>=0A=
Sent: 13 June 2020 12:29=0A=
=0A=
<tp>=0A=
I thought about the text I would like to see in crypto-types and starting w=
ith identity since they are simplest I came up with =0A=
NEW=0A=
This module contains YANG identity for private keys, public keys and symmet=
ric keys.=0A=
=0A=
>From the base "private-key-format" there are derived identity for =0A=
- rsa-private-key-format as defined in RFC 3447=0A=
- ec-private-key-format as defined in RFC5915 =0A=
- one-asymmetric-key-format as defined in RFC 5958,=0A=
          encoded using ASN.1 distinguished encoding rules=0A=
          (DER), as specified in ITU-T X.690.";=0A=
- encrypted-one-asymmetric-key-format, as defined in RFC 5958,=0A=
          encoded using ASN.1 distinguished encoding rules (DER),=0A=
          as specified in ITU-T X.690.";=0A=
      =0A=
>From the base "public-key-format" there are derived identity for =0A=
- ssh-public-key-format as specified by RFC 4253, Section 6.6, i.e.:=0A=
- subject-public-key-info-format as described in RFC 5280 encoded using ASN=
.1=0A=
          distinguished encoding rules (DER), as specified in=0A=
          ITU-T X.690.";=0A=
=0A=
>From the base "symmetric-key-format" there are derived identity for =0A=
-  octet-string-key-format encoded as a raw octet string.=0A=
-  one-symmetric-key-format as defined in RFC 6031 and=0A=
          encoded using ASN.1 distinguished encoding rules=0A=
          (DER), as specified in ITU-T X.690.=0A=
-  encrypted-one-symmetric-key-format as defined=0A=
          in RFC 6031 and encoded using ASN.1 distinguished=0A=
          encoding rules (DER), as specified in ITU-T X.690.";=0A=
            Specification of Basic Encoding Rules (BER),=0A=
            Canonical Encoding Rules (CER) and Distinguished=0A=
            Encoding Rules (DER)=0A=
=0A=
Obviously all I have done is take the text and reformatted it. I debated ab=
out keeping the references to CMS.  The aim is to tell the reader whether o=
r not to dig deeper into the YANG in order to use it.  For groupings I see =
more new text needed=0A=
=0A=
Tom Petch=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
I have concerns about trust-anchors and crypto-types.  They are both more o=
r less non-existent when it comes to text.  I do not want to have to revers=
e engineer the YANG or XML to find out what RPC or action there are, what t=
ypes of cipher suites and such like are supported - and perhaps those that =
are not such as raw keys.  I would expect there to be five or ten pages of =
such in each.  Look for example at layer0-types or layer1-types for modules=
 with what I would regard as adequate text.=0A=
=0A=
Tom Petch=0A=
=0A=
From: netconf <netconf-bounces@ietf.org> on behalf of Eric Voit (evoit) <ev=
oit=3D40cisco.com@dmarc.ietf.org>=0A=
Sent: 12 June 2020 21:03=0A=
=0A=
> > -----Original Message-----=0A=
=0A=
> > From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh=0A=
=0A=
> > Jethanandani=0A=
=0A=
> > Sent: Tuesday, June 2, 2020 7:48 PM=0A=
=0A=
> > To: Netconf <netconf@ietf.org>=0A=
=0A=
> > Subject: [netconf] WG LC for three drafts=0A=
=0A=
> >=0A=
=0A=
> > NETCONF WG,=0A=
=0A=
> >=0A=
=0A=
> > The authors of=0A=
=0A=
> >=0A=
=0A=
> > - draft-ietf-netconf-crypto-types=0A=
=0A=
> > - draft-ietf-netconf-keystore=0A=
=0A=
> > - draft-ietf-netconf-trust-anchors=0A=
=0A=
> >=0A=
=0A=
> > have indicated that these drafts are ready for Last Call (LC).=0A=
=0A=
> >=0A=
=0A=
> > This kicks of a 2 week WG LC for the three drafts. Please review and=0A=
=0A=
> > send=0A=
=0A=
> any=0A=
=0A=
> > comments to the WG mailing list or by responding to this e-mail.=0A=
=0A=
> > Comments can be statements such as, I read/reviewed the document and=0A=
=0A=
> > believe it is ready for publication, or I have concerns about the=0A=
=0A=
> > document. For the=0A=
=0A=
> latter,=0A=
=0A=
> > please indicate what your concerns are.=0A=
=0A=
> >=0A=
=0A=
> > Any reports on implementation status or plans to implement are also=0A=
=0A=
> > very useful.=0A=
=0A=
> >=0A=
=0A=
> > Thanks.=0A=
=0A=
> >=0A=
=0A=
> > Mahesh Jethanandani (as co-chair)=0A=
=0A=
> > mjethanandani@gmail.com=0A=
=0A=
> >=0A=
=0A=
> >=0A=
=0A=
> >=0A=
=0A=
> > _______________________________________________=0A=
=0A=
> > netconf mailing list=0A=
=0A=
> > netconf@ietf.org=0A=
=0A=
> > https://www.ietf.org/mailman/listinfo/netconf=0A=
=0A=
_______________________________________________=0A=
netconf mailing list=0A=
netconf@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netconf=0A=


From nobody Wed Jun 17 10:59:51 2020
Return-Path: <01000172c36f9602-0647d5e3-4a24-42b6-92b8-c10542feb59f-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51CE3A0AE9 for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 10:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 icQ9u__WvMrb for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 10:59:31 -0700 (PDT)
Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228333A0AE2 for <netconf@ietf.org>; Wed, 17 Jun 2020 10:59:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1592416769; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=iWPLt/vqQq/UV0prS6mWKkEULNOm1uUG7D8BDh+JjfU=; b=hv/IVcUZ3bg2i6YhWH1HeY2YE84UCKBvdmfexUghHI5wqgpVuHP3FR7o1Xv1DLI5 Qr1P2QWxZx7O0kS7QDvAFtjWrfYaSIggTjU2tKN3hSOz7G1cOmmsz4KLgrHzij9GtG1 pGc4gPv0LUlVajR3J8XcPnqgSf2xmwVfXalFGvQU=
From: Kent Watsen <kent@watsen.net>
Message-ID: <01000172c36f9602-0647d5e3-4a24-42b6-92b8-c10542feb59f-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D9AA496D-F20F-4FE4-8E11-FB8288E3A930"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 17 Jun 2020 17:59:29 +0000
In-Reply-To: <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.17-54.240.48.94
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ronodLQvdwrhj3rf4EdyHOVQkbs>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 17:59:47 -0000

--Apple-Mail=_D9AA496D-F20F-4FE4-8E11-FB8288E3A930
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

HI Juergen,

Thank you for your review!

Responses below.

Kent


> On Jun 17, 2020, at 6:53 AM, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:
>=20
> I have reviewed the I-Ds today and here are my comments:
>=20
> * general comments
>=20
>  - These drafts needs serious reviews by security domain experts.
>    This all looks reasonable to me but since this is all about
>    security, we need to set the bar high to get things right.

Undoubtedly, though things are dramatically simpler now without trying =
to define the =E2=80=9Calgorithm=E2=80=9D nodes.  =20


>  - I think the work is in a good shape but the documents need another
>    round of tweaks to get them ready.

Good to hear. =20

FWIW, I=E2=80=99m aware of several implementations, of the higher-level =
drafts, which bodes well to these models being close.  I can=E2=80=99t =
vouch that every node has been implemented, but huge swaths have.


> * draft-ietf-netconf-crypto-types-15.txt
>=20
>  - I agree with others that this document lacks introductory
>    material.

It=E2=80=99s a fair point.

Being a WG document, text-contributions would be greatly appreciated.  =
Perhaps the WG could divvy up sections?


>  - Perhaps the title should reflect that this document is not
>    just defining types but also groupings.

I=E2=80=99ve ping-ponged on this a few times myself. =20

The idea was worse before, when the =E2=80=9Calgorithm=E2=80=9D nodes =
were being defined, as then there were identities in the mix as well, =
which, if all were reflected in the title, was a mouthful.  At that time =
I silently resolved that =E2=80=9Ctypes=E2=80=9D could be thought of in =
the general, as opposed to the specifically =E2=80=9Ctypedefs=E2=80=9D.  =
But now that the =E2=80=9Calgorithm=E2=80=9D nodes are out, it seems =
more reasonable, how about:

OLD: Common YANG Data Types for Cryptography
NEW: Common YANG Data Types and Groupings for Cryptography


>  - The public-key-grouping says that it captures a public key and its
>    associated algorithm but I am not sure how this is done or is the
>    idea that every algorithm requires a different public-key-format?
>=20
>  - The asymmetric-key-pair-grouping says that it captures a private
>    key and its associated public key and algorithm but I am not sure
>    how this is done or is the idea that every algorithm requires a
>    different private-key-format? I also wonder how this grouping
>    captures the associated public key.

Both of the above comments were mentioned by Eric and fixed here =
https://github.com/netconf-wg/crypto-types/commit/690c016b201241e13a1e324b=
49ba5e9db0d6c417 =
<https://github.com/netconf-wg/crypto-types/commit/690c016b201241e13a1e324=
b49ba5e9db0d6c417>.



>  - Do we have to be prepared for alternate cert formats in the
>    future?

In theory, yes; in practice, unlikely.  Of course, we should attempt to =
do it right, so...

Searching for the strings =E2=80=9Ccertificate=E2=80=9D and =E2=80=9CX.509=
=E2=80=9D, I think the issue is just description text asserting things =
must be X.509 when not true.  For instance, CMS allows for non-X.509 =
certs and so it=E2=80=99s unnecessary for the text to say otherwise.  Is =
this your sentiment as well?

[update: I just saw Rich Salz=E2=80=99s comment on this.  It=E2=80=99s =
true the world is skewed to X.509-based certs.  Do we still attempt to =
makes the minimum description text adjustments?]



>  - The certificate-expiration notification of the
>    trust-anchor-certs-grouping probably needs adjustment; I assume
>    this applies to any certificate the the cert leaf-list.

Yes, a notification could be for any =E2=80=9Ccert=E2=80=9D entry in the =
leaf-list.  What adjustment is needed?  Is it just the description text? =
 Or are you thinking that the notification will be unable to identify =
the specific leaf-list entry that is expiring?

For NETCONF, it seems that the XPath would be able to identity the =
specific certificate (e.g., [1], [2], etc.).   RESTCONF might be =
problematic though, maybe the full cert is listed?

Digging deeper, I note that =E2=80=9Cleaf-list cert=E2=80=9D appears =
only in two groupings:

  1) the "end-entity-certs-grouping=E2=80=9D grouping
       - this grouping isn=E2=80=99t used anywhere (AFAIK) and could be =
removed

   2) the "trust-anchor-certs-grouping=E2=80=9D grouping
       - this grouping is used in the truststore draft, but only in the =
definition
         of the "local-or-truststore-certs-grouping=E2=80=9D grouping, =
and then only to
         support the =E2=80=9Clocal=E2=80=9D case=E2=80=A6
       - FWIW, the =E2=80=9Ctruststore=E2=80=9D case is a =
"certificate-bag-ref=E2=80=9D, that is, a bag=20
         of certs...
       - at first I was thinking that we could adjust the =E2=80=9Clocal=E2=
=80=9D case to use
         the "trust-anchor-cert-cms=E2=80=9D typedef but, actually, it =
already does.
         That is, it is a leaf-list of CMS structs=E2=80=A6
       - another option would be to expand the =E2=80=9Clocal=E2=80=9D =
case to be a =E2=80=9Clist=E2=80=9D
         instead of a =E2=80=9Cleaf-list=E2=80=9D.  This would =
necessitate each cert to have
         a =E2=80=9Ckey=E2=80=9D (e.g., name), but that is how it is in =
the truststore's bag
         definition, so probably okay...
 =20
?


>  - Is there any semantic difference between
>    trust-anchor-cert-grouping and end-entity-cert-grouping, i.e., why
>    do we need two groupings? Same question for
>    trust-anchor-certs-grouping and end-entity-certs-grouping. If
>    there is a semantic difference, perhaps this should be highlighted
>    in the grouping description.

There is a huge semantic difference (albeit, no syntactic difference), =
TAs and EEs are used in entirely different ways.

The =E2=80=9C*-certs-grouping=E2=80=9D groupings were discussed above, =
and maybe will be removed but, if they stay, the same comment applies =
(huge semantic difference).


>  - I have not checked the examples.

All examples are validated each time the draft is built.



> * draft-ietf-netconf-trust-anchors-10.txt
>=20
>  - I agree with others that this document lacks introductory
>    material. I am personally not a fan of one sentence sections
>    but that may be just a personal style / preference issue.

Same response as above.


>  - The idea that there are groupings that support locally defined
>    crypto keys or references to a centralized trust store really
>    deserves to be explained upfront. Yes, I can reverse engineer this
>    from the definitions, but people who need to decide whether they
>    want to implement this module may not have the time and energy to
>    do this. Notice that the abstract only talks about bags that can
>    be referenced.

This goes with the previous comment, but it helps a lot to have the =
specific omission called out.


>  - How does the storage of user public ssh keys suggested in the
>    example usage section relate to the data model in RFC 7317?

Firstly, note that the ct:ssh-public-key-format identity defines the =
same structure as RFC 7317, but I think your question may be more along =
the lines of if there is a redundancy, to which, I don=E2=80=99t think =
so, at least not necessarily=E2=80=A6

RFC 7317 regards system-level users, e.g., is SSH-ing directly to a =
server, whereas here, as well in the ssh-client-server draft, the =
SSH-server may be application-level.

That said, the truststore could (really, SHOULD) be used to configure =
the system-level SSH server as well, as it portends to have security =
protections beyond regular config.  This is analogous the folks =
migrating to storing TAs in system-level mechanisms, such as Mac=E2=80=99s=
 =E2=80=9Ckeychain=E2=80=9D.

What makes sense to me is to have a future 7317bis that migrates that =
definition to use the =E2=80=9Cts:local-or-truststore-public-keys-grouping=
=E2=80=9D grouping.


>  - The authors listed on the document and in the yang module are
>    different.

Fixed in my local copy.


>  - Do we need the truststore-supported feature? We do not have this
>    in other YANG modules. Is the idea to distinguish implementations
>    that only import groupings? Even in this case, should this not be
>    handled by the yang library somehow?

The "truststore-supported=E2=80=9D feature is used to prune out the =
=E2=80=9Ctruststore=E2=80=9D case from the various =E2=80=9Clocal-of =
truststore=E2=80=9D groupings.  Yes, it is for implementations that do =
not implement the module (they only import the groupings).  I=E2=80=99m =
unsure how YANG Library could be used differently, that is, it's already =
currently used to indicate if the module is implemented/imported as well =
as what features are supported.


>  - Do the leaf names always look good in instance data? For example,
>    is <truststore-reference> may not be the most descriptive name in
>    instance data.

All of the downstream drafts (ssh-, tls-, netconf-, restconf-) have =
examples illustrating "truststore-reference=E2=80=9D in use.  [and the =
ssh- and tls- drafts have examples illustrating "keystore-reference=E2=80=9D=
 in use].


> Perhaps it would help to also have examples that
>    show how various groupings are used, not just the bags.

This would entail defining an example module to instantiate those =
groupings (such as is done in the crypto-types and keystore drafts).  If =
the goal is to make this draft as readable as possible in a standalone =
fashion, then perhaps that should be done.  Or perhaps we could just =
point readers to the examples in the aforementioned drafts?


>  - I have to think about the 'copy to running' procedure described in
>    section 3. Perhaps this is the way to go but who happens if things
>    get out of sync?

We previously had "require-instance false=E2=80=9D statements (also in =
the keystore draft), but they were removed (see the Change Log) because =
it seemed skewed to throwout validation for 99% of the TAs/keys in =
orderbto support the 1% case for builtin TA/keys.  So we moved to the =
current approach, which isn=E2=80=99t ideal, but seems better then the =
alternative...

FWIW, it=E2=80=99s intended (though perhaps not stated) that the server =
will reject any attempt to configure a new TA certificate.  That is, =
only a subset of the certificate can appear in <running>.  Any attempt =
to configure a new cert, or change an exist cert, should cause the =
commit to fail.   In this way, configurations that refer to the builtin =
definitions can be assured that the values used are only those approved =
by the manufacturer.=20



>  - Why is it useful to define truststore-grouping, i.e., why is this
>    not just a part of the truststore container definition? How are
>    the reference types going to work if you instantiate the
>    truststore-grouping elsewhere?

I use this grouping in a project outside the IETF, where there are a =
multiplicity of context specific truststores.  I use the features to =
disable to default =E2=80=9Clocal-or-truststore=E2=80=9D cases and then =
augment-in my own case statement containing a reference to my =
context-specific truststore.


>  - I have not checked the examples.

All examples are validated each time the draft is built.



> * draft-ietf-netconf-keystore-17.txt
>=20
>  - Looking at the overview figure (that is unfortunately to be
>    removed), I wonder whether trust-anchors should be renamed to
>    truststore as this seems to be the term used by the yang module.

The artwork is helpful, but it=E2=80=99s easy to see that it won=E2=80=99t=
 age well - right?  For instance, already there are other WGs using some =
of this work and, let=E2=80=99s not forget the =E2=80=9Csyslog=E2=80=9D =
draft that has been parked in NETMOD for ~2 years due to a MISREF to the =
TLS draft...



>  - I appreciate the introductory text that this I-D has (compared to
>    the others).

Good to know, thanks.


>  - Several pages of yang tree output without explanations is not very
>    helpful. I suggest to break this into pieces and to explain for
>    each grouping when it may be used (or not used).

This suggestion is in line with the response I gave Tom, regarding it =
being consistent with what I did in the =E2=80=9Csztp-csr=E2=80=9D =
draft.  I think the trick is to rename the section from =E2=80=9CTree =
Diagram=E2=80=9D to =E2=80=9CData Model Overview=E2=80=9D and go from =
there...



>  - I am not sure I understand the examples, more precisely, how
>       <keystore-reference>rsa-asymmetric-key</keystore-reference>
>    or
>       <keystore-reference>
>         <asymmetric-key>rsa-asymmetric-key</asymmetric-key>
>         <certificate>ex-rsa-cert</certificate>
>       </keystore-reference>
>    will be interpreted.

I don=E2=80=99t follow.  I think that you=E2=80=99re in Section =
3.2.2...the paragraph preceding the example says:

   The following example illustrates what two configured keys, one local
   and the other remote, might look like.  This example consistent with
   other examples above (i.e., the referenced key is in an example =
above).

Probably that text should say =E2=80=9C=E2=80=A6in the example found in =
Section 3.2.1=E2=80=9D, but maybe your comment about something else?
 =20


>  - What is the informative reference to RFC8342 in the YANG module?

That comment is a holdover from -06, when there was a =
=E2=80=9Crequire-instance false=E2=80=9D in the YANG module.  I just =
removed that RFC8342 reference in my local copy.


>  - Do we need the keystore-supported feature? See discussion above.

Same response as above for the "truststore-supported=E2=80=9D feature.


>  - Should the support for encrypted keys be moved to the cryto-types
>    module? Is there a reason why we add the feature to have keys
>    encrypted here? Perhaps this is sensible, I am just trying to
>    check whether this has been given some thought.

In order to persist an encrypted key, it is necessary to reference the =
other key that was used to encrypt the key (so the server knows how to =
decrypt the key). =20

The expectation is that the other key will be in the keystore, but note =
that a =E2=80=9Cchoice=E2=80=9D node is used for the references, and all =
the existing cases are protected by =E2=80=9Cfeature=E2=80=9D =
statements, so that, e.g., a =E2=80=9Clocal=E2=80=9D key or key in a =
context-specific instance of the keystore grouping can be used =
alternatively.

To your point, we could move the essence of the encrypted-key support =
directly into the key groupings in the crypto-types draft, but leave the =
=E2=80=9Ccase=E2=80=9D statement empty, and then have the keystore draft =
augment in =E2=80=9Ccase=E2=80=9D statements for keys in the keystore, =
when the keystore module is =E2=80=9Cimplemented=E2=80=9D.  Makes sense?


>  - Why is it useful to define keystore-grouping, i.e., why is this
>    not just a part of the keystore container definition? How are the
>    reference types going to work if you instantiate the
>    keystore-grouping elsewhere?

Same response as above for the "truststore-grouping=E2=80=9D.


>  - I have to think about the 'copy to running' procedure described in
>    section 4. Perhaps this is the way to go but who happens if things
>    get out of sync? What is a system provided cert is exceeding its
>    lifetime (does this even lead to a stream of notifications)?

In addition to the comment above regarding Section 3 in the truststore =
draft=E2=80=A6

Things getting out of sync here is less likely (then they are in =
truststore), in that builtin keys are undoubtedly going to be =
=E2=80=9Chidden=E2=80=9D and therefore any attempt to config a builtin =
key under a different name will fail, as a hidden key (where the secret =
key data is missing) cannot be configured.

We do want to support users adding user-defined certificates (e.g., =
LDevID), as is illustrated in Section 4.


>  - The text in 5.3 scares me a bit. Migrating root keys may be seen
>    as a bad idea by some. If you have a new device with new root
>    keys, then you better re-encrypt or re-key instead of patching the
>    root key.  Or are you essentially saying that encrypted keys
>    should be encrypted with a key-encryption-key instead of the 'root
>    key'?

More the latter.  The 2nd-to-last paragraph intends to say this.=20


>  - I am not sure how one implements the 'MUST ensure that the
>    strength of the key being configured is not greater than the
>    strength of the underlying secure transport' nor am I sure that
>    the consequences are really desirable, i.e., I can never move to
>    'more secure keys' than what the transport currently allows. I
>    think I understand the argument that says a key can't be more
>    trustworthy than the transport used to configure it but I do not
>    think we should disallow upgrade paths.

Changed to a SHOULD in my local copy.


>  - I have not checked the examples.

All examples are validated each time the draft is built.


Kent // contributor


>=20
> /js
>=20
> On Tue, Jun 02, 2020 at 04:48:07PM -0700, Mahesh Jethanandani wrote:
>> NETCONF WG,
>>=20
>> The authors of
>>=20
>> - draft-ietf-netconf-crypto-types
>> - draft-ietf-netconf-keystore
>> - draft-ietf-netconf-trust-anchors
>>=20
>> have indicated that these drafts are ready for Last Call (LC).
>>=20
>> This kicks of a 2 week WG LC for the three drafts. Please review and =
send any comments to the WG mailing list or by responding to this =
e-mail. Comments can be statements such as, I read/reviewed the document =
and believe it is ready for publication, or I have concerns about the =
document. For the latter, please indicate what your concerns are.=20
>>=20
>> Any reports on implementation status or plans to implement are also =
very useful.
>>=20
>> Thanks.
>>=20
>> Mahesh Jethanandani (as co-chair)
>> mjethanandani@gmail.com
>>=20
>>=20
>>=20
>> _______________________________________________
>> netconf mailing list
>> netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>=20
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


--Apple-Mail=_D9AA496D-F20F-4FE4-8E11-FB8288E3A930
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">HI =
Juergen,<div class=3D""><br class=3D""></div><div class=3D"">Thank you =
for your review!</div><div class=3D""><br class=3D""></div><div =
class=3D"">Responses below.</div><div class=3D""><br class=3D""></div><div=
 class=3D"">Kent</div><div class=3D""><br class=3D""><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Jun =
17, 2020, at 6:53 AM, Juergen Schoenwaelder &lt;<a =
href=3D"mailto:j.schoenwaelder@jacobs-university.de" =
class=3D"">j.schoenwaelder@jacobs-university.de</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">I =
have reviewed the I-Ds today and here are my comments:<br class=3D""><br =
class=3D"">* general comments<br class=3D""><br class=3D""> &nbsp;- =
These drafts needs serious reviews by security domain experts.<br =
class=3D""> &nbsp;&nbsp;&nbsp;This all looks reasonable to me but since =
this is all about<br class=3D""> &nbsp;&nbsp;&nbsp;security, we need to =
set the bar high to get things right.<br =
class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>Undoubtedly, though things are dramatically =
simpler now without trying to define the =E2=80=9Calgorithm=E2=80=9D =
nodes. &nbsp;&nbsp;</div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""> &nbsp;- I think the work is in a good shape but the =
documents need another<br class=3D""> &nbsp;&nbsp;&nbsp;round of tweaks =
to get them ready.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div><div style=3D"caret-color: rgb(0, 0, 0); color: =
rgb(0, 0, 0);">Good to hear. &nbsp;</div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0);"><br class=3D""></div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">FWIW, I=E2=80=99=
m aware of several implementations, of the higher-level drafts, which =
bodes well to these models being close. &nbsp;I can=E2=80=99t vouch that =
every node has been implemented, but huge swaths have.</div><div =
class=3D""><br class=3D""></div></div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D"">* =
draft-ietf-netconf-crypto-types-15.txt<br class=3D""><br class=3D""> =
&nbsp;- I agree with others that this document lacks introductory<br =
class=3D""> &nbsp;&nbsp;&nbsp;material.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>It=E2=80=
=99s a fair point.</div><div><br class=3D""></div><div>Being a WG =
document, text-contributions would be greatly appreciated. &nbsp;Perhaps =
the WG could divvy up sections?</div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""> &nbsp;- Perhaps the title should reflect that this document =
is not<br class=3D""> &nbsp;&nbsp;&nbsp;just defining types but also =
groupings.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>I=E2=80=99ve ping-ponged on this a few times =
myself. &nbsp;</div><div><br class=3D""></div><div>The idea was worse =
before, when the =E2=80=9Calgorithm=E2=80=9D nodes were being defined, =
as then there were identities in the mix as well, which, if all were =
reflected in the title, was a mouthful. &nbsp;At that time I silently =
resolved that =E2=80=9Ctypes=E2=80=9D could be thought of in the =
general, as opposed to the specifically =E2=80=9Ctypedefs=E2=80=9D. =
&nbsp;But now that the =E2=80=9Calgorithm=E2=80=9D nodes are out, it =
seems more reasonable, how about:</div><div><br class=3D""></div><div>OLD:=
 Common YANG Data Types for Cryptography</div>NEW:&nbsp;Common YANG Data =
Types and Groupings for Cryptography</div><div><br =
class=3D""></div><div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D"">&nbsp;- The =
public-key-grouping says that it captures a public key and its<br =
class=3D""> &nbsp;&nbsp;&nbsp;associated algorithm but I am not sure how =
this is done or is the<br class=3D""> &nbsp;&nbsp;&nbsp;idea that every =
algorithm requires a different public-key-format?<br class=3D""><br =
class=3D""> &nbsp;- The asymmetric-key-pair-grouping says that it =
captures a private<br class=3D""> &nbsp;&nbsp;&nbsp;key and its =
associated public key and algorithm but I am not sure<br class=3D""> =
&nbsp;&nbsp;&nbsp;how this is done or is the idea that every algorithm =
requires a<br class=3D""> &nbsp;&nbsp;&nbsp;different =
private-key-format? I also wonder how this grouping<br class=3D""> =
&nbsp;&nbsp;&nbsp;captures the associated public key.<br =
class=3D""></div></div></blockquote><br class=3D""><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Both of the =
above comments were mentioned by Eric and fixed here&nbsp;<a =
href=3D"https://github.com/netconf-wg/crypto-types/commit/690c016b201241e1=
3a1e324b49ba5e9db0d6c417" =
class=3D"">https://github.com/netconf-wg/crypto-types/commit/690c016b20124=
1e13a1e324b49ba5e9db0d6c417</a>.</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
 class=3D""> &nbsp;- Do we have to be prepared for alternate cert =
formats in the<br class=3D""> &nbsp;&nbsp;&nbsp;future?<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>In =
theory, yes; in practice, unlikely. &nbsp;Of course, we should attempt =
to do it right, so...</div><div><br class=3D""></div><div>Searching for =
the strings =E2=80=9Ccertificate=E2=80=9D and =E2=80=9CX.509=E2=80=9D, I =
think the issue is just description text asserting things must be X.509 =
when not true. &nbsp;For instance, CMS allows for non-X.509 certs and so =
it=E2=80=99s unnecessary for the text to say otherwise. &nbsp;Is this =
your sentiment as well?</div><div><br class=3D""></div><div>[update: I =
just saw Rich Salz=E2=80=99s comment on this. &nbsp;It=E2=80=99s true =
the world is skewed to X.509-based certs. &nbsp;Do we still attempt to =
makes the minimum description text adjustments?]</div><div><br =
class=3D""></div><div><br class=3D""></div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D""> &nbsp;- The =
certificate-expiration notification of the<br class=3D""> =
&nbsp;&nbsp;&nbsp;trust-anchor-certs-grouping probably needs adjustment; =
I assume<br class=3D""> &nbsp;&nbsp;&nbsp;this applies to any =
certificate the the cert leaf-list.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>Yes, =
a notification could be for any =E2=80=9Ccert=E2=80=9D entry in the =
leaf-list. &nbsp;What adjustment is needed? &nbsp;Is it just the =
description text? &nbsp;Or are you thinking that the notification will =
be unable to identify the specific leaf-list entry that is =
expiring?</div><div><br class=3D""></div><div>For NETCONF, it seems that =
the XPath would be able to identity the specific certificate (e.g., [1], =
[2], etc.). &nbsp; RESTCONF might be problematic though, maybe the full =
cert is listed?</div><div><br class=3D""></div><div>Digging deeper, I =
note that =E2=80=9Cleaf-list cert=E2=80=9D appears only in two =
groupings:</div><div><br class=3D""></div><div>&nbsp; 1) the =
"end-entity-certs-grouping=E2=80=9D grouping</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;- this grouping isn=E2=80=99t used anywhere (AFAIK) and =
could be removed</div><div><br class=3D""></div><div>&nbsp; &nbsp;2) the =
"trust-anchor-certs-grouping=E2=80=9D grouping</div><div>&nbsp; &nbsp; =
&nbsp; &nbsp;- this grouping is used in the truststore draft, but only =
in the definition</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;of the =
"local-or-truststore-certs-grouping=E2=80=9D grouping, and then only =
to</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;support the =E2=80=9Clocal=E2=
=80=9D case=E2=80=A6</div><div>&nbsp; &nbsp; &nbsp; &nbsp;- FWIW, the =
=E2=80=9Ctruststore=E2=80=9D case is a "certificate-bag-ref=E2=80=9D, =
that is, a bag&nbsp;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;of =
certs...</div><div>&nbsp; &nbsp; &nbsp; &nbsp;- at first I was thinking =
that we could adjust the =E2=80=9Clocal=E2=80=9D case to =
use</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the =
"trust-anchor-cert-cms=E2=80=9D typedef but, actually, it already =
does.</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;That is, it is a =
leaf-list of CMS structs=E2=80=A6</div><div>&nbsp; &nbsp; &nbsp; &nbsp;- =
another option would be to expand the =E2=80=9Clocal=E2=80=9D case to be =
a =E2=80=9Clist=E2=80=9D</div><div>&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;instead of a =E2=80=9Cleaf-list=E2=80=9D. &nbsp;This would =
necessitate each cert to have</div><div>&nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;a =E2=80=9Ckey=E2=80=9D (e.g., name), but that is how it is in the =
truststore's bag</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;definition, =
so probably okay...</div><div>&nbsp;&nbsp;</div><div>?</div><div><br =
class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div class=3D""> &nbsp;- Is there any semantic difference =
between<br class=3D""> &nbsp;&nbsp;&nbsp;trust-anchor-cert-grouping and =
end-entity-cert-grouping, i.e., why<br class=3D""> &nbsp;&nbsp;&nbsp;do =
we need two groupings? Same question for<br class=3D""> =
&nbsp;&nbsp;&nbsp;trust-anchor-certs-grouping and =
end-entity-certs-grouping. If<br class=3D""> &nbsp;&nbsp;&nbsp;there is =
a semantic difference, perhaps this should be highlighted<br class=3D""> =
&nbsp;&nbsp;&nbsp;in the grouping description.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>There =
is a huge semantic difference (albeit, no syntactic difference), TAs and =
EEs are used in entirely different ways.</div><div><br =
class=3D""></div><div>The =E2=80=9C*-certs-grouping=E2=80=9D groupings =
were discussed above, and maybe will be removed but, if they stay, the =
same comment applies (huge semantic difference).</div><div><br =
class=3D""></div><div><br class=3D""></div><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D""> &nbsp;- I have not checked =
the examples.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>All examples are validated each time the draft is =
built.</div><div><br class=3D""></div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D"">* draft-ietf-netconf-trust-anchors-10.txt<br class=3D""><br =
class=3D""> &nbsp;- I agree with others that this document lacks =
introductory<br class=3D""> &nbsp;&nbsp;&nbsp;material. I am personally =
not a fan of one sentence sections<br class=3D""> &nbsp;&nbsp;&nbsp;but =
that may be just a personal style / preference issue.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>Same =
response as above.</div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""> &nbsp;- The idea that there are groupings that support =
locally defined<br class=3D""> &nbsp;&nbsp;&nbsp;crypto keys or =
references to a centralized trust store really<br class=3D""> =
&nbsp;&nbsp;&nbsp;deserves to be explained upfront. Yes, I can reverse =
engineer this<br class=3D""> &nbsp;&nbsp;&nbsp;from the definitions, but =
people who need to decide whether they<br class=3D""> =
&nbsp;&nbsp;&nbsp;want to implement this module may not have the time =
and energy to<br class=3D""> &nbsp;&nbsp;&nbsp;do this. Notice that the =
abstract only talks about bags that can<br class=3D""> =
&nbsp;&nbsp;&nbsp;be referenced.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>This =
goes with the previous comment, but it helps a lot to have the specific =
omission called out.</div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""> &nbsp;- How does the storage of user public ssh keys =
suggested in the<br class=3D""> &nbsp;&nbsp;&nbsp;example usage section =
relate to the data model in RFC 7317?<br =
class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>Firstly, note that the ct:ssh-public-key-format =
identity defines the same structure as RFC 7317, but I think your =
question may be more along the lines of if there is a redundancy, to =
which, I don=E2=80=99t think so, at least not =
necessarily=E2=80=A6</div><div><br class=3D""></div><div>RFC 7317 =
regards system-level users, e.g., is SSH-ing directly to a server, =
whereas here, as well in the ssh-client-server draft, the SSH-server may =
be application-level.</div><div><br class=3D""></div><div>That said, the =
truststore could (really, SHOULD) be used to configure the system-level =
SSH server as well, as it portends to have security protections beyond =
regular config. &nbsp;This is analogous the folks migrating to storing =
TAs in system-level mechanisms, such as Mac=E2=80=99s =
=E2=80=9Ckeychain=E2=80=9D.</div><div><br class=3D""></div><div>What =
makes sense to me is to have a future&nbsp;<font color=3D"#000000" =
class=3D"">7317bis that migrates that definition to use =
the&nbsp;=E2=80=9Cts:local-or-truststore-public-keys-grouping=E2=80=9D =
grouping.</font></div><div><br class=3D""></div><br class=3D""><blockquote=
 type=3D"cite" class=3D""><div class=3D""><div class=3D""> &nbsp;- The =
authors listed on the document and in the yang module are<br class=3D""> =
&nbsp;&nbsp;&nbsp;different.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div>Fixed in =
my local copy.</div><div><br class=3D""></div><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""> &nbsp;- Do we need the truststore-supported feature? We do =
not have this<br class=3D""> &nbsp;&nbsp;&nbsp;in other YANG modules. Is =
the idea to distinguish implementations<br class=3D""> =
&nbsp;&nbsp;&nbsp;that only import groupings? Even in this case, should =
this not be<br class=3D""> &nbsp;&nbsp;&nbsp;handled by the yang library =
somehow?<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>The "truststore-supported=E2=80=9D feature is used =
to prune out the =E2=80=9Ctruststore=E2=80=9D case from the various =
=E2=80=9Clocal-of truststore=E2=80=9D groupings. &nbsp;Yes, it is for =
implementations that do not implement the module (they only import the =
groupings). &nbsp;I=E2=80=99m unsure how YANG Library could be used =
differently, that is, it's already currently used to indicate if the =
module is implemented/imported as well as what features are =
supported.</div><div><br class=3D""></div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D""> &nbsp;- Do the =
leaf names always look good in instance data? For example,<br class=3D""> =
&nbsp;&nbsp;&nbsp;is &lt;truststore-reference&gt; may not be the most =
descriptive name in<br class=3D""> &nbsp;&nbsp;&nbsp;instance data. =
</div></div></blockquote><div><br class=3D""></div><div><div>All of the =
downstream drafts (ssh-, tls-, netconf-, restconf-) have examples =
illustrating "truststore-reference=E2=80=9D in use. &nbsp;[and the ssh- =
and tls- drafts have examples&nbsp;<span style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0);" =
class=3D"">illustrating</span>&nbsp;"keystore-reference=E2=80=9D in =
use].</div><div class=3D""><br class=3D""></div></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D"">Perhaps it would help to also have examples that<br class=3D"">=
 &nbsp;&nbsp;&nbsp;show how various groupings are used, not just the =
bags.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>This would entail defining an example module to =
instantiate those groupings (such as is done in the crypto-types and =
keystore drafts). &nbsp;If the goal is to make this draft as readable as =
possible in a standalone fashion, then perhaps that should be done. =
&nbsp;Or perhaps we could just point readers to the examples in the =
aforementioned drafts?</div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D"">&nbsp;- I have to think about the 'copy to running' procedure =
described in<br class=3D""> &nbsp;&nbsp;&nbsp;section 3. Perhaps this is =
the way to go but who happens if things<br class=3D""> =
&nbsp;&nbsp;&nbsp;get out of sync?<br =
class=3D""></div></div></blockquote><div><br class=3D""></div>We =
previously had "require-instance false=E2=80=9D statements (also in the =
keystore draft), but they were removed (see the Change Log) because it =
seemed skewed to throwout validation for 99% of the TAs/keys in orderbto =
support the 1% case for builtin TA/keys. &nbsp;So we moved to the =
current approach, which isn=E2=80=99t ideal, but seems better then the =
alternative...</div><div><br class=3D""></div><div>FWIW, it=E2=80=99s =
intended (though perhaps not stated) that the server will reject any =
attempt to configure a new TA certificate. &nbsp;That is, only a subset =
of the certificate can appear in &lt;running&gt;. &nbsp;Any attempt to =
configure a new cert, or change an exist cert, should cause the commit =
to fail. &nbsp; In this way, configurations that refer to the builtin =
definitions can be assured that the values used are only those approved =
by the manufacturer.&nbsp;</div><div><br class=3D""></div><div><br =
class=3D""></div><div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D""> &nbsp;- Why is it useful to =
define truststore-grouping, i.e., why is this<br class=3D""> =
&nbsp;&nbsp;&nbsp;not just a part of the truststore container =
definition? How are<br class=3D""> &nbsp;&nbsp;&nbsp;the reference types =
going to work if you instantiate the<br class=3D""> =
&nbsp;&nbsp;&nbsp;truststore-grouping elsewhere?<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>I use =
this grouping in a project outside the IETF, where there are a =
multiplicity of context specific truststores. &nbsp;I use the features =
to disable to default =E2=80=9Clocal-or-truststore=E2=80=9D cases and =
then augment-in my own case statement containing a reference to my =
context-specific truststore.</div><div><br class=3D""></div><div><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
 class=3D""> &nbsp;- I have not checked the examples.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">All examples =
are validated each time the draft is built.</div></div><div><br =
class=3D""></div><div><br class=3D""></div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D"">* =
draft-ietf-netconf-keystore-17.txt<br class=3D""><br class=3D""> &nbsp;- =
Looking at the overview figure (that is unfortunately to be<br class=3D"">=
 &nbsp;&nbsp;&nbsp;removed), I wonder whether trust-anchors should be =
renamed to<br class=3D""> &nbsp;&nbsp;&nbsp;truststore as this seems to =
be the term used by the yang module.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>The =
artwork is helpful, but it=E2=80=99s easy to see that it won=E2=80=99t =
age well - right? &nbsp;For instance, already there are other WGs using =
some of this work and, let=E2=80=99s not forget the =E2=80=9Csyslog=E2=80=9D=
 draft that has been parked in NETMOD for ~2 years due to a MISREF to =
the TLS draft...</div><div><br class=3D""></div><div><br =
class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div class=3D""> &nbsp;- I appreciate the introductory text =
that this I-D has (compared to<br class=3D""> &nbsp;&nbsp;&nbsp;the =
others).<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>Good to know, thanks.</div><div><br =
class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div class=3D"">&nbsp;- Several pages of yang tree output =
without explanations is not very<br class=3D""> =
&nbsp;&nbsp;&nbsp;helpful. I suggest to break this into pieces and to =
explain for<br class=3D""> &nbsp;&nbsp;&nbsp;each grouping when it may =
be used (or not used).<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>This suggestion is in line with the response I =
gave Tom, regarding it being consistent with what I did in the =
=E2=80=9Csztp-csr=E2=80=9D draft. &nbsp;I think the trick is to rename =
the section from =E2=80=9CTree Diagram=E2=80=9D to =E2=80=9CData Model =
Overview=E2=80=9D and go from there...</div><div><br =
class=3D""></div><div><br class=3D""></div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D""> &nbsp;- I am =
not sure I understand the examples, more precisely, how<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;keystore-reference&gt;rsa-asymmetr=
ic-key&lt;/keystore-reference&gt;<br class=3D""> &nbsp;&nbsp;&nbsp;or<br =
class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;keystore-reference&gt;<br =
class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;asymmetric-key&gt;rsa-=
asymmetric-key&lt;/asymmetric-key&gt;<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;certificate&gt;ex-rsa-=
cert&lt;/certificate&gt;<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;/keystore-reference&gt;<br =
class=3D""> &nbsp;&nbsp;&nbsp;will be interpreted.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>I =
don=E2=80=99t follow. &nbsp;I think that you=E2=80=99re in Section =
3.2.2...the paragraph preceding the example says:</div><div><br =
class=3D""></div><div><div class=3D"">&nbsp; &nbsp;The following example =
illustrates what two configured keys, one local</div><div =
class=3D"">&nbsp; &nbsp;and the other remote, might look like. =
&nbsp;This example consistent with</div><div class=3D"">&nbsp; =
&nbsp;other examples above (i.e., the referenced key is in an =
example&nbsp;<span style=3D"color: rgb(0, 0, 0); font-size: 13.3333px; =
orphans: 2; widows: 2;" class=3D"">above).</span></div><div class=3D""><br=
 class=3D""></div><div class=3D"">Probably that text should say =E2=80=9C=E2=
=80=A6in the example found in Section 3.2.1=E2=80=9D, but maybe your =
comment about something else?</div><div =
class=3D"">&nbsp;&nbsp;</div></div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""> &nbsp;- What is the informative reference to RFC8342 in the =
YANG module?<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>That comment is a holdover from -06, when there =
was a =E2=80=9Crequire-instance false=E2=80=9D in the YANG module. =
&nbsp;I just removed that RFC8342 reference in my local =
copy.</div><div><br class=3D""></div><div><br class=3D""></div><blockquote=
 type=3D"cite" class=3D""><div class=3D""><div class=3D""> &nbsp;- Do we =
need the keystore-supported feature? See discussion above.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>Same =
response as above for the "truststore-supported=E2=80=9D =
feature.</div><div><br class=3D""></div><div><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
 class=3D""> &nbsp;- Should the support for encrypted keys be moved to =
the cryto-types<br class=3D""> &nbsp;&nbsp;&nbsp;module? Is there a =
reason why we add the feature to have keys<br class=3D""> =
&nbsp;&nbsp;&nbsp;encrypted here? Perhaps this is sensible, I am just =
trying to<br class=3D""> &nbsp;&nbsp;&nbsp;check whether this has been =
given some thought.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>In order to persist an encrypted key, it is =
necessary to reference the other key that was used to encrypt the key =
(so the server knows how to decrypt the key). &nbsp;</div><div><br =
class=3D""></div><div>The expectation is that the other key will be in =
the keystore, but note that a =E2=80=9Cchoice=E2=80=9D node is used for =
the references, and all the existing cases are protected by =
=E2=80=9Cfeature=E2=80=9D statements, so that, e.g., a =E2=80=9Clocal=E2=80=
=9D key or key in a context-specific instance of the keystore grouping =
can be used alternatively.</div><div><br class=3D""></div><div>To your =
point, we could move the essence of the encrypted-key support directly =
into the key groupings in the crypto-types draft, but leave the =
=E2=80=9Ccase=E2=80=9D statement empty, and then have the keystore draft =
augment in =E2=80=9Ccase=E2=80=9D statements for keys in the keystore, =
when the keystore module is =E2=80=9Cimplemented=E2=80=9D. &nbsp;Makes =
sense?</div><div><br class=3D""></div><div><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
 class=3D"">&nbsp;- Why is it useful to define keystore-grouping, i.e., =
why is this<br class=3D""> &nbsp;&nbsp;&nbsp;not just a part of the =
keystore container definition? How are the<br class=3D""> =
&nbsp;&nbsp;&nbsp;reference types going to work if you instantiate =
the<br class=3D""> &nbsp;&nbsp;&nbsp;keystore-grouping elsewhere?<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Same response =
as above for the "truststore-grouping=E2=80=9D.</div><div class=3D""><br =
class=3D""></div></div><div><br class=3D""></div><blockquote type=3D"cite"=
 class=3D""><div class=3D""><div class=3D""> &nbsp;- I have to think =
about the 'copy to running' procedure described in<br class=3D""> =
&nbsp;&nbsp;&nbsp;section 4. Perhaps this is the way to go but who =
happens if things<br class=3D""> &nbsp;&nbsp;&nbsp;get out of sync? What =
is a system provided cert is exceeding its<br class=3D""> =
&nbsp;&nbsp;&nbsp;lifetime (does this even lead to a stream of =
notifications)?<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>In addition to the comment above regarding Section =
3 in the truststore draft=E2=80=A6</div><div><br =
class=3D""></div><div>Things getting out of sync here is less likely =
(then they are in truststore), in that builtin keys are undoubtedly =
going to be =E2=80=9Chidden=E2=80=9D and therefore any attempt to config =
a builtin key under a different name will fail, as a hidden key (where =
the secret key data is missing) cannot be configured.</div><div><br =
class=3D""></div><div>We do want to support users adding user-defined =
certificates (e.g., LDevID), as is illustrated in Section =
4.</div><div><br class=3D""></div><div><br class=3D""></div><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D""> &nbsp;- The =
text in 5.3 scares me a bit. Migrating root keys may be seen<br =
class=3D""> &nbsp;&nbsp;&nbsp;as a bad idea by some. If you have a new =
device with new root<br class=3D""> &nbsp;&nbsp;&nbsp;keys, then you =
better re-encrypt or re-key instead of patching the<br class=3D""> =
&nbsp;&nbsp;&nbsp;root key. &nbsp;Or are you essentially saying that =
encrypted keys<br class=3D""> &nbsp;&nbsp;&nbsp;should be encrypted with =
a key-encryption-key instead of the 'root<br class=3D""> =
&nbsp;&nbsp;&nbsp;key'?<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>More the latter. &nbsp;The 2nd-to-last paragraph =
intends to say this.&nbsp;</div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""> &nbsp;- I am not sure how one implements the 'MUST ensure =
that the<br class=3D""> &nbsp;&nbsp;&nbsp;strength of the key being =
configured is not greater than the<br class=3D""> =
&nbsp;&nbsp;&nbsp;strength of the underlying secure transport' nor am I =
sure that<br class=3D""> &nbsp;&nbsp;&nbsp;the consequences are really =
desirable, i.e., I can never move to<br class=3D""> =
&nbsp;&nbsp;&nbsp;'more secure keys' than what the transport currently =
allows. I<br class=3D""> &nbsp;&nbsp;&nbsp;think I understand the =
argument that says a key can't be more<br class=3D""> =
&nbsp;&nbsp;&nbsp;trustworthy than the transport used to configure it =
but I do not<br class=3D""> &nbsp;&nbsp;&nbsp;think we should disallow =
upgrade paths.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>Changed to a SHOULD in my local =
copy.</div><div><br class=3D""></div><div><br class=3D""></div><blockquote=
 type=3D"cite" class=3D""><div class=3D""><div class=3D""> &nbsp;- I =
have not checked the examples.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">All examples =
are validated each time the draft is built.</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div class=3D"">Kent=
 // contributor</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div></div><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D""><br class=3D"">/js<br =
class=3D""><br class=3D"">On Tue, Jun 02, 2020 at 04:48:07PM -0700, =
Mahesh Jethanandani wrote:<br class=3D""><blockquote type=3D"cite" =
class=3D"">NETCONF WG,<br class=3D""><br class=3D"">The authors of<br =
class=3D""><br class=3D"">- draft-ietf-netconf-crypto-types<br =
class=3D"">- draft-ietf-netconf-keystore<br class=3D"">- =
draft-ietf-netconf-trust-anchors<br class=3D""><br class=3D"">have =
indicated that these drafts are ready for Last Call (LC).<br =
class=3D""><br class=3D"">This kicks of a 2 week WG LC for the three =
drafts. Please review and send any comments to the WG mailing list or by =
responding to this e-mail. Comments can be statements such as, I =
read/reviewed the document and believe it is ready for publication, or I =
have concerns about the document. For the latter, please indicate what =
your concerns are. <br class=3D""><br class=3D"">Any reports on =
implementation status or plans to implement are also very useful.<br =
class=3D""><br class=3D"">Thanks.<br class=3D""><br class=3D"">Mahesh =
Jethanandani (as co-chair)<br class=3D""><a =
href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a><br class=3D""><br class=3D""><br =
class=3D""><br =
class=3D"">_______________________________________________<br =
class=3D"">netconf mailing list<br class=3D"">netconf@ietf.org<br =
class=3D"">https://www.ietf.org/mailman/listinfo/netconf<br =
class=3D""></blockquote><br class=3D"">-- <br class=3D"">Juergen =
Schoenwaelder =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Jacobs =
University Bremen gGmbH<br class=3D"">Phone: +49 421 200 3587 =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Campus Ring 1 | 28759 =
Bremen | Germany<br class=3D"">Fax: &nbsp;&nbsp;+49 421 200 3103 =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a =
href=3D"https://www.jacobs-university.de/" =
class=3D"">https://www.jacobs-university.de/</a>&gt;<br class=3D""><br =
class=3D"">_______________________________________________<br =
class=3D"">netconf mailing list<br class=3D""><a =
href=3D"mailto:netconf@ietf.org" class=3D"">netconf@ietf.org</a><br =
class=3D"">https://www.ietf.org/mailman/listinfo/netconf<br =
class=3D""></div></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_D9AA496D-F20F-4FE4-8E11-FB8288E3A930--


From nobody Wed Jun 17 11:16:51 2020
Return-Path: <jlindbla@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201633A0AD6 for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 11:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level: 
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 header.b=JcZZtel4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DOhKeRQh
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8NUn4HSOk-H for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 11:16:48 -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 6E4E63A0AD5 for <netconf@ietf.org>; Wed, 17 Jun 2020 11:16:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1612; q=dns/txt; s=iport; t=1592417808; x=1593627408; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=dD9IxM83fIS/WIlRYRoqwcIttpUaX/i/oaVCFVnqtew=; b=JcZZtel4/2n4AmLKXdDSmsXKjglNoe51e55felOVgB8C/gD30N3tjDlX WMTVx2RICRq7JzyzI2KJJfwdqff22j9s3xHx/mbc3Xegr7oAzpj9La3r3 oH+w6ly6pItDiYjXRxCiQM5vIBtzpSrv4YCh4u3B8ULNu/tTXL6E2rIPj 4=;
IronPort-PHdr: =?us-ascii?q?9a23=3ATIXOWhzvmEmGwhzXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWFt/RgkFGPWp/UuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHC2LUYTH9zxNBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRDADXXOpe/5BdJa1mHgE8DAILFYM?= =?us-ascii?q?cUQdvWC8sCodgA40amHeCUgNVCwEBAQwBASUIAgQBAYZgAiQ4EwIDAQELAQE?= =?us-ascii?q?FAQEBAgEGBG2FWwELhgsoBgEBOBEBPkInBDWDBAGCSwMuAQMLrDYCgTmIYXS?= =?us-ascii?q?BNIMBAQEFgTIBFg9xgnIYgg4DBoE4gmeJeBqBQT+BOAwQgk2EY4Nfgi2PBAu?= =?us-ascii?q?MW5hjCoJaiECQYQMdnm6RI4oQlCkCBAIEBQIOAQEFgWoiQ4ETcBVlAYI+UBc?= =?us-ascii?q?CDZIPilZ0NwIGCAEBAwl8jwABgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.73,523,1583193600"; d="scan'208";a="768818511"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jun 2020 18:16:47 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 05HIGkeP020366 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <netconf@ietf.org>; Wed, 17 Jun 2020 18:16:47 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 17 Jun 2020 13:16:46 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 17 Jun 2020 14:16:45 -0400
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 17 Jun 2020 14:16:45 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RdFUWDDpsMDC8D5NECcUdtWcPryYIJQoMwpCWVxk5YBe7R9QM+AMr0GSERjU+nWEWZL+WtIpVgVfLsMYHnQplN6rJvrMVvqfHzPvnSOZtRj9E2tjPNk61SGlLyWJNO2gs5crjFPoF6JxSfj4pMireUQHJdF+yTa/lMUI8zpnszChtlTiwIe5fRUd+FV8Dgu97GGGxTQT2irJTlpe9f8Dw/Yvs8aw27myO0q7XycKfxANNfDzIRSsWqcbRU71D9INY7FkipDLmIBE7wvZCeHJ1dROH8+1yRlJzbCmSf5EXpe6jWOTiX84eWsPlMo026NjuaDmnv2T65hHpNFwkT9tOg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dD9IxM83fIS/WIlRYRoqwcIttpUaX/i/oaVCFVnqtew=; b=ZbISWMxnZnVhfOZo5vaBNePy3iokpl0foU6ZySmKsY5IVJvNwPi3dsy2KwR7qkrF5WKPHDQNY1PvsvErDk3BDMjGOYHhIuswOHPkab/+2f2y/wVK9t2SJOuBpuWoLxsC0la5IuSCvLXJ0dpBlYhDln2fCqTQNH4BZ16NsaksXCblB/VU+xV4wOurzcr7412VB0PQaVZk1m2GZJKmZlaC5nD4FmduTRqbA4hPGbCPXK4Eh0urAuDscsJ+n9kW3TaaKNbl1sVi5vxbzneCAGZXSbwIatwDdUn4+gS9sMDn328oA3zeB18pGfXlup0UY72bxT8FV5U+GR3BHTqAWMKrwQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dD9IxM83fIS/WIlRYRoqwcIttpUaX/i/oaVCFVnqtew=; b=DOhKeRQhhV4zv4hfl6i9IOrAnOaEXgKMTkhrgjBO1zbT0XoOa9d/Pnq+8FRf1SACLKmjeOq30lsrLlDDjOABIr+trS3Uc/gVSxplWRhjkO+5NDSdjfLUHer0S+jqdWGaU1htUbOZ44xLCqcxPeXAhg1iNwZ89fCl9iToFD1b+PM=
Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by DM6PR11MB3676.namprd11.prod.outlook.com (2603:10b6:5:137::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19; Wed, 17 Jun 2020 18:16:44 +0000
Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::e903:7b03:4757:bcc2]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::e903:7b03:4757:bcc2%4]) with mapi id 15.20.3109.021; Wed, 17 Jun 2020 18:16:44 +0000
From: "Jan Lindblad (jlindbla)" <jlindbla@cisco.com>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: RESTCONF error responses when streaming
Thread-Index: AQHWRNN0JYZvVqk3OUy9aZDOPyhBOA==
Date: Wed, 17 Jun 2020 18:16:44 +0000
Message-ID: <681EC915-A2E8-4806-BD12-5B9D482549E5@cisco.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [213.67.237.150]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6bfbd229-1bd4-4629-a5c3-08d812ea975d
x-ms-traffictypediagnostic: DM6PR11MB3676:
x-microsoft-antispam-prvs: <DM6PR11MB3676AB3C7130C94CADF27019CA9A0@DM6PR11MB3676.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-forefront-prvs: 04371797A5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: A6oLBLorJA1yqfURk1/y87K5Bg0ZnA4rT4AthDlZQ23swwsgUdnkG804IKuPBQej2b1rogkEaJT2vcc6CKCOTj3pFUJwmlE1z0hgrWW6pnD/AGFH29/aGkWdqW73Dhb/aBnCRHubkvisOPrOD3XVLuNXZMtlohRpFKugHmkW2Xm2nMcWqWJ5pP/urRhTyDzOiQdmhl06YLYOamXU3awdatP7OJG3Vin1p9rD6rc4E79J4mFbqHYvyFBKPw4Mttn4lbF+Q/Yke+952tlm2lf1tERSN5r34Svtplgfxy3y69UgxR/C3qu1f4p1l3VIOCTDEI3h87K0WElNzcXcmC1KEfOu+/y2DIj6aiwGYt9DgbJE6jG70Qk1Kd8wdOMZCAI6z5m26KVxKRFrjfnDEA12uw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DM6PR11MB2841.namprd11.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(396003)(366004)(346002)(39860400002)(136003)(376002)(66946007)(66476007)(64756008)(36756003)(2906002)(8936002)(8676002)(478600001)(966005)(76116006)(86362001)(66446008)(91956017)(66556008)(6486002)(83380400001)(6512007)(2616005)(71200400001)(5660300002)(33656002)(6916009)(6506007)(186003)(316002)(26005); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: KPDXH5mpaTp1jPxUXREaMKzlYXpUQRzoC/TfThJm3a6DLN3RrdktLzB7INfjx8E+AcxsDAvnaL/XZshQnqUEYfOOHdwlI9YI28u0IKugsBEh+c6ysSsBFyaLl6A6jJ1mf5Td3jWx1yP05dGUzbzKHFZFHy2o9pLO2RSnNJ7MS66ZRiEb+SXdfTMNePdistosVZZc41fnOypHzUn4eqnAKlJy45VISl1qpGjxtVZ3IGHa1xqy5+FjLLg90Xd9hl+0sSPfV5GOQoJTB61HeGKQtGjztMkHOd24hJdnMJnsvUD8zwQxAiF3nZs3pfz69fylaVbZMjtpch+ClsoaSDnEhj0OqKA+RrL1vPSwHZd2MubLGzpUr6W9gDzZD6TOizI0atL9BEqLupXtW6n2F0iTvckbLFbsqZm7BkfzpFfKUuViAt32PWswSBTTttRx3Hw4QLx3Gx1qAGwaPjC8nGsbf8MBuARvRbH+VHFwvvXaw8FX8pbcRTLBKL2mZQO6Us1e
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6E7C769BC22D7A4EB7AC2D12CCE26259@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6bfbd229-1bd4-4629-a5c3-08d812ea975d
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 18:16:44.3779 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qQ6rKSPfkZ4lPXqwJ19LxDHjR6rzvDVdyoUyjJvMgNDSrj76DsIVBV+4vYBPqz/pXGTwFDLFSDTFoFFBDVRHJw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3676
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/d1TZ5m_hkpCdpufn3Qdx_sf8k_M>
Subject: [netconf] RESTCONF error responses when streaming
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 18:16:50 -0000

Hi all,

RFC 8040 has some nice examples of RESTCONF requests that return errors, i.=
e. invalid-value 400, access-denied 403, in-use 409, etc. But what if the s=
erver streams/pipes the output back to the client, and everything looks fin=
e to begin with?=20

Let's say the client does a GET /restconf/data/example-jukebox:jukebox/libr=
ary . In our example here, the library is huge, so the implementation strea=
ms back the responses. Half way through, the database chokes on something a=
nd shuts down. It's now too late to return operation-failed 412, since the =
status code is returned in the response header.

Which of the following alternatives best describes the behaviour that the R=
ESTCONF server should implement in the above situation?

a) Simply close the client connection
b) Return a <nc:errors> tag right where the problem is detected, xmlns:nc=
=3D"urn:ietf:params:xml:ns:yang:ietf-restconf" (assuming XML media type)
b2) Return a "ietf-restconf:errors" tag right where the problem is detected=
 (assuming JSON media type)
c) Provide closing tags/brackets to return to the "top level", then return =
a <nc:errors>/"ietf-restconf:errors" blurb
d) None of the above
e) No valid reply exists

Looking for general REST answers to this problem, it looks like some people=
 have created a mime-multipart message encoding which allows status codes t=
o be sent in a follow up mime part. Would anything like that be usable in a=
 situation like this?
https://stackoverflow.com/questions/56980068/when-to-write-headers-for-a-st=
reaming-response

Best Regards,
/jan


From nobody Wed Jun 17 11:33:10 2020
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F6B3A0C7A for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 11:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 IDi1zPpHO_QD for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 11:33:06 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C633A0C7D for <netconf@ietf.org>; Wed, 17 Jun 2020 11:33:06 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id F25B24C1; Wed, 17 Jun 2020 20:33:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id TvOF16dcjh7F; Wed, 17 Jun 2020 20:33:04 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Jun 2020 20:33:04 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2364200E4; Wed, 17 Jun 2020 20:33:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id tjw35xBXur5K; Wed, 17 Jun 2020 20:33:04 +0200 (CEST)
Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 4739820154; Wed, 17 Jun 2020 20:33:04 +0200 (CEST)
Date: Wed, 17 Jun 2020 20:33:03 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Jan Lindblad (jlindbla)" <jlindbla=40cisco.com@dmarc.ietf.org>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20200617183303.cicdrblkqyx3pgew@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Jan Lindblad (jlindbla)" <jlindbla=40cisco.com@dmarc.ietf.org>,  "netconf@ietf.org" <netconf@ietf.org>
References: <681EC915-A2E8-4806-BD12-5B9D482549E5@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <681EC915-A2E8-4806-BD12-5B9D482549E5@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/JgIefpbHHmt7B_KSlZvInJSiaI4>
Subject: Re: [netconf] RESTCONF error responses when streaming
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 18:33:09 -0000

It should be standard HTTP behaviour and the best bet likely is to
simply close the connection. If you use chunked encoding, then the
response is known to be incomplete. It seems wrong to try to handle
this situation with special error tags that are RESTCONF specific
since this problem is not RESTCONF specific.

/js

On Wed, Jun 17, 2020 at 06:16:44PM +0000, Jan Lindblad (jlindbla) wrote:
> Hi all,
> 
> RFC 8040 has some nice examples of RESTCONF requests that return errors, i.e. invalid-value 400, access-denied 403, in-use 409, etc. But what if the server streams/pipes the output back to the client, and everything looks fine to begin with? 
> 
> Let's say the client does a GET /restconf/data/example-jukebox:jukebox/library . In our example here, the library is huge, so the implementation streams back the responses. Half way through, the database chokes on something and shuts down. It's now too late to return operation-failed 412, since the status code is returned in the response header.
> 
> Which of the following alternatives best describes the behaviour that the RESTCONF server should implement in the above situation?
> 
> a) Simply close the client connection
> b) Return a <nc:errors> tag right where the problem is detected, xmlns:nc="urn:ietf:params:xml:ns:yang:ietf-restconf" (assuming XML media type)
> b2) Return a "ietf-restconf:errors" tag right where the problem is detected (assuming JSON media type)
> c) Provide closing tags/brackets to return to the "top level", then return a <nc:errors>/"ietf-restconf:errors" blurb
> d) None of the above
> e) No valid reply exists
> 
> Looking for general REST answers to this problem, it looks like some people have created a mime-multipart message encoding which allows status codes to be sent in a follow up mime part. Would anything like that be usable in a situation like this?
> https://stackoverflow.com/questions/56980068/when-to-write-headers-for-a-streaming-response
> 
> Best Regards,
> /jan
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>


From nobody Wed Jun 17 11:43:54 2020
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4546C3A0AFE for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 11:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 074NBlDIEShU for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 11:43:51 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D745D3A0AE7 for <netconf@ietf.org>; Wed, 17 Jun 2020 11:43:50 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8E584830; Wed, 17 Jun 2020 20:43:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Dft36QPOwcZJ; Wed, 17 Jun 2020 20:43:49 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Jun 2020 20:43:49 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 446FE20154; Wed, 17 Jun 2020 20:43:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id YBUX8dENOEKR; Wed, 17 Jun 2020 20:43:49 +0200 (CEST)
Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 1587B200E4; Wed, 17 Jun 2020 20:43:49 +0200 (CEST)
Date: Wed, 17 Jun 2020 20:43:48 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>
Message-ID: <20200617184348.em65geuk53arj5kr@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Salz, Rich" <rsalz@akamai.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de> <14453F87-3F9D-40AA-A4E5-DAD7D66B480C@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14453F87-3F9D-40AA-A4E5-DAD7D66B480C@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/O2uyYxtK3hPmRJVhpQlQIrN8Xeo>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 18:43:52 -0000

On Wed, Jun 17, 2020 at 02:59:34PM +0000, Salz, Rich wrote:
> 
> >      - Do we have to be prepared for alternate cert formats in the
>         future?
> 
> No. :) If something come to displace X509v3, many things will have to undergo some fundamental changes.
>

I accept the answer and the answer helps to get work finished so its
likely the right answer. That said, 5 years ago, who would have
believed our dns traffic is json encoded blurbs over https?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>


From nobody Wed Jun 17 12:10:19 2020
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CC03A0D09 for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 12:10:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 yDo-GrdTUh6j for <netconf@ietfa.amsl.com>; Wed, 17 Jun 2020 12:10:15 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6502A3A0CEC for <netconf@ietf.org>; Wed, 17 Jun 2020 12:10:15 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id EF55082B; Wed, 17 Jun 2020 21:10:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id SUic_DCVc-NG; Wed, 17 Jun 2020 21:10:13 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 17 Jun 2020 21:10:13 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96D9320154; Wed, 17 Jun 2020 21:10:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id las6flMO5CEl; Wed, 17 Jun 2020 21:10:12 +0200 (CEST)
Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id D8779200E4; Wed, 17 Jun 2020 21:10:12 +0200 (CEST)
Date: Wed, 17 Jun 2020 21:10:09 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kent@watsen.net>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20200617191009.hn7ftmkrzxiysqwr@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Kent Watsen <kent@watsen.net>, Mahesh Jethanandani <mjethanandani@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de> <01000172c36f9602-0647d5e3-4a24-42b6-92b8-c10542feb59f-000000@email.amazonses.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <01000172c36f9602-0647d5e3-4a24-42b6-92b8-c10542feb59f-000000@email.amazonses.com>
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/IMQtw3Yye6Wdej9D-j0bbrI1Ivw>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 19:10:18 -0000

On Wed, Jun 17, 2020 at 05:59:29PM +0000, Kent Watsen wrote:
>=20
> >  - Perhaps the title should reflect that this document is not
> >    just defining types but also groupings.
>=20
> I=E2=80=99ve ping-ponged on this a few times myself. =20
>=20
> The idea was worse before, when the =E2=80=9Calgorithm=E2=80=9D nodes w=
ere being defined, as then there were identities in the mix as well, whic=
h, if all were reflected in the title, was a mouthful.  At that time I si=
lently resolved that =E2=80=9Ctypes=E2=80=9D could be thought of in the g=
eneral, as opposed to the specifically =E2=80=9Ctypedefs=E2=80=9D.  But n=
ow that the =E2=80=9Calgorithm=E2=80=9D nodes are out, it seems more reas=
onable, how about:
>=20
> OLD: Common YANG Data Types for Cryptography
> NEW: Common YANG Data Types and Groupings for Cryptography
>

Works for me.
=20
> >  - The certificate-expiration notification of the
> >    trust-anchor-certs-grouping probably needs adjustment; I assume
> >    this applies to any certificate the the cert leaf-list.
>=20
> Yes, a notification could be for any =E2=80=9Ccert=E2=80=9D entry in th=
e leaf-list.  What adjustment is needed?  Is it just the description text=
?  Or are you thinking that the notification will be unable to identify t=
he specific leaf-list entry that is expiring?
>=20
> For NETCONF, it seems that the XPath would be able to identity the spec=
ific certificate (e.g., [1], [2], etc.).   RESTCONF might be problematic =
though, maybe the full cert is listed?
>=20
> Digging deeper, I note that =E2=80=9Cleaf-list cert=E2=80=9D appears on=
ly in two groupings:
>=20
>   1) the "end-entity-certs-grouping=E2=80=9D grouping
>        - this grouping isn=E2=80=99t used anywhere (AFAIK) and could be=
 removed
>=20
>    2) the "trust-anchor-certs-grouping=E2=80=9D grouping
>        - this grouping is used in the truststore draft, but only in the=
 definition
>          of the "local-or-truststore-certs-grouping=E2=80=9D grouping, =
and then only to
>          support the =E2=80=9Clocal=E2=80=9D case=E2=80=A6
>        - FWIW, the =E2=80=9Ctruststore=E2=80=9D case is a "certificate-=
bag-ref=E2=80=9D, that is, a bag=20
>          of certs...
>        - at first I was thinking that we could adjust the =E2=80=9Cloca=
l=E2=80=9D case to use
>          the "trust-anchor-cert-cms=E2=80=9D typedef but, actually, it =
already does.
>          That is, it is a leaf-list of CMS structs=E2=80=A6
>        - another option would be to expand the =E2=80=9Clocal=E2=80=9D =
case to be a =E2=80=9Clist=E2=80=9D
>          instead of a =E2=80=9Cleaf-list=E2=80=9D.  This would necessit=
ate each cert to have
>          a =E2=80=9Ckey=E2=80=9D (e.g., name), but that is how it is in=
 the truststore's bag
>          definition, so probably okay...

Giving certs a name and using a list may make things simpler. But I
have no overview of all the usage implications (since I did not look
at the other documents).

> >  - Is there any semantic difference between
> >    trust-anchor-cert-grouping and end-entity-cert-grouping, i.e., why
> >    do we need two groupings? Same question for
> >    trust-anchor-certs-grouping and end-entity-certs-grouping. If
> >    there is a semantic difference, perhaps this should be highlighted
> >    in the grouping description.
>=20
> There is a huge semantic difference (albeit, no syntactic difference), =
TAs and EEs are used in entirely different ways.

Yes, but if its the same structure, why do we need two definitions of
the structure?
=20
> The =E2=80=9C*-certs-grouping=E2=80=9D groupings were discussed above, =
and maybe will be removed but, if they stay, the same comment applies (hu=
ge semantic difference).
>=20
>=20
> >  - I have not checked the examples.
>=20
> All examples are validated each time the draft is built.
>=20

Thats what I hoped / expected. ;-)
=20
> >  - How does the storage of user public ssh keys suggested in the
> >    example usage section relate to the data model in RFC 7317?
>=20
> Firstly, note that the ct:ssh-public-key-format identity defines the sa=
me structure as RFC 7317, but I think your question may be more along the=
 lines of if there is a redundancy, to which, I don=E2=80=99t think so, a=
t least not necessarily=E2=80=A6
>=20
> RFC 7317 regards system-level users, e.g., is SSH-ing directly to a ser=
ver, whereas here, as well in the ssh-client-server draft, the SSH-server=
 may be application-level.

This assumes there is such a difference, which is an assumption but not a=
 requirement.
=20
> That said, the truststore could (really, SHOULD) be used to configure t=
he system-level SSH server as well, as it portends to have security prote=
ctions beyond regular config.  This is analogous the folks migrating to s=
toring TAs in system-level mechanisms, such as Mac=E2=80=99s =E2=80=9Ckey=
chain=E2=80=9D.
>=20
> What makes sense to me is to have a future 7317bis that migrates that d=
efinition to use the =E2=80=9Cts:local-or-truststore-public-keys-grouping=
=E2=80=9D grouping.

Yes, perhaps it is OK to stay silent about and to keep a record
somewhere that this needs to be looked at when 7317 is being revised.

> >  - Do we need the truststore-supported feature? We do not have this
> >    in other YANG modules. Is the idea to distinguish implementations
> >    that only import groupings? Even in this case, should this not be
> >    handled by the yang library somehow?
>=20
> The "truststore-supported=E2=80=9D feature is used to prune out the =E2=
=80=9Ctruststore=E2=80=9D case from the various =E2=80=9Clocal-of trustst=
ore=E2=80=9D groupings.  Yes, it is for implementations that do not imple=
ment the module (they only import the groupings).  I=E2=80=99m unsure how=
 YANG Library could be used differently, that is, it's already currently =
used to indicate if the module is implemented/imported as well as what fe=
atures are supported.
>

I assume (have not checked) that you don't toggle the implement bit in
the yang library if you just import type definitions and groupings.

> >  - Do the leaf names always look good in instance data? For example,
> >    is <truststore-reference> may not be the most descriptive name in
> >    instance data.
>=20
> All of the downstream drafts (ssh-, tls-, netconf-, restconf-) have exa=
mples illustrating "truststore-reference=E2=80=9D in use.  [and the ssh- =
and tls- drafts have examples illustrating "keystore-reference=E2=80=9D i=
n use].
>

I guess I will eventually have to look at them...
=20
> > Perhaps it would help to also have examples that
> >    show how various groupings are used, not just the bags.
>=20
> This would entail defining an example module to instantiate those group=
ings (such as is done in the crypto-types and keystore drafts).  If the g=
oal is to make this draft as readable as possible in a standalone fashion=
, then perhaps that should be done.  Or perhaps we could just point reade=
rs to the examples in the aforementioned drafts?
>

My preference is to point to the other drafts. These are likely
non-normative references, i.e., they are not problematic process wise

> >  - I have to think about the 'copy to running' procedure described in
> >    section 3. Perhaps this is the way to go but who happens if things
> >    get out of sync?
>=20
> We previously had "require-instance false=E2=80=9D statements (also in =
the keystore draft), but they were removed (see the Change Log) because i=
t seemed skewed to throwout validation for 99% of the TAs/keys in orderbt=
o support the 1% case for builtin TA/keys.  So we moved to the current ap=
proach, which isn=E2=80=99t ideal, but seems better then the alternative.=
..
>=20
> FWIW, it=E2=80=99s intended (though perhaps not stated) that the server=
 will reject any attempt to configure a new TA certificate.  That is, onl=
y a subset of the certificate can appear in <running>.  Any attempt to co=
nfigure a new cert, or change an exist cert, should cause the commit to f=
ail.   In this way, configurations that refer to the builtin definitions =
can be assured that the values used are only those approved by the manufa=
cturer.=20
>=20

Spelling this out would make me happy. The server has to enforce
consistency here.

> >  - Why is it useful to define truststore-grouping, i.e., why is this
> >    not just a part of the truststore container definition? How are
> >    the reference types going to work if you instantiate the
> >    truststore-grouping elsewhere?
>=20
> I use this grouping in a project outside the IETF, where there are a mu=
ltiplicity of context specific truststores.  I use the features to disabl=
e to default =E2=80=9Clocal-or-truststore=E2=80=9D cases and then augment=
-in my own case statement containing a reference to my context-specific t=
ruststore.
>=20

Well, to do this properly, one would have to invent a way to make the
references to different truststores. You are essentially dropping the
truststore and adding new ones, no? Still a hack, like cut'n'paste.
=20
> > * draft-ietf-netconf-keystore-17.txt
> >=20
> >  - Looking at the overview figure (that is unfortunately to be
> >    removed), I wonder whether trust-anchors should be renamed to
> >    truststore as this seems to be the term used by the yang module.
>=20
> The artwork is helpful, but it=E2=80=99s easy to see that it won=E2=80=99=
t age well - right?  For instance, already there are other WGs using some=
 of this work and, let=E2=80=99s not forget the =E2=80=9Csyslog=E2=80=9D =
draft that has been parked in NETMOD for ~2 years due to a MISREF to the =
TLS draft...
>=20

I can't follow, artwork is no different than text.

> >  - Several pages of yang tree output without explanations is not very
> >    helpful. I suggest to break this into pieces and to explain for
> >    each grouping when it may be used (or not used).
>=20
> This suggestion is in line with the response I gave Tom, regarding it b=
eing consistent with what I did in the =E2=80=9Csztp-csr=E2=80=9D draft. =
 I think the trick is to rename the section from =E2=80=9CTree Diagram=E2=
=80=9D to =E2=80=9CData Model Overview=E2=80=9D and go from there...
>=20

Short tree diagrams very helpful, multi pages tree diagramm are almost
pointless (and can always be generated when needed). The art is to
slice things into meaningful pieces.

>=20
> >  - I am not sure I understand the examples, more precisely, how
> >       <keystore-reference>rsa-asymmetric-key</keystore-reference>
> >    or
> >       <keystore-reference>
> >         <asymmetric-key>rsa-asymmetric-key</asymmetric-key>
> >         <certificate>ex-rsa-cert</certificate>
> >       </keystore-reference>
> >    will be interpreted.
>=20
> I don=E2=80=99t follow.  I think that you=E2=80=99re in Section 3.2.2..=
.the paragraph preceding the example says:
>=20
>    The following example illustrates what two configured keys, one loca=
l
>    and the other remote, might look like.  This example consistent with
>    other examples above (i.e., the referenced key is in an example abov=
e).
>=20
> Probably that text should say =E2=80=9C=E2=80=A6in the example found in=
 Section 3.2.1=E2=80=9D, but maybe your comment about something else?
  =20
Please ignore my comment, I was confused.

> >  - Should the support for encrypted keys be moved to the cryto-types
> >    module? Is there a reason why we add the feature to have keys
> >    encrypted here? Perhaps this is sensible, I am just trying to
> >    check whether this has been given some thought.
>=20
> In order to persist an encrypted key, it is necessary to reference the =
other key that was used to encrypt the key (so the server knows how to de=
crypt the key). =20
>=20
> The expectation is that the other key will be in the keystore, but note=
 that a =E2=80=9Cchoice=E2=80=9D node is used for the references, and all=
 the existing cases are protected by =E2=80=9Cfeature=E2=80=9D statements=
, so that, e.g., a =E2=80=9Clocal=E2=80=9D key or key in a context-specif=
ic instance of the keystore grouping can be used alternatively.
>=20
> To your point, we could move the essence of the encrypted-key support d=
irectly into the key groupings in the crypto-types draft, but leave the =E2=
=80=9Ccase=E2=80=9D statement empty, and then have the keystore draft aug=
ment in =E2=80=9Ccase=E2=80=9D statements for keys in the keystore, when =
the keystore module is =E2=80=9Cimplemented=E2=80=9D.  Makes sense?
>=20

I have no strong opinion - it just felt that adding encrypted keys
later adds additional noise, more groupings to understand and to deal
with.

> >  - The text in 5.3 scares me a bit. Migrating root keys may be seen
> >    as a bad idea by some. If you have a new device with new root
> >    keys, then you better re-encrypt or re-key instead of patching the
> >    root key.  Or are you essentially saying that encrypted keys
> >    should be encrypted with a key-encryption-key instead of the 'root
> >    key'?
>=20
> More the latter.  The 2nd-to-last paragraph intends to say this.=20

Perhaps this recommendation should be spelled out clearer and the
=C2=A7obscure copy root keys approach be given as a reason to have such
key-encryption-keys.

> >  - I am not sure how one implements the 'MUST ensure that the
> >    strength of the key being configured is not greater than the
> >    strength of the underlying secure transport' nor am I sure that
> >    the consequences are really desirable, i.e., I can never move to
> >    'more secure keys' than what the transport currently allows. I
> >    think I understand the argument that says a key can't be more
> >    trustworthy than the transport used to configure it but I do not
> >    think we should disallow upgrade paths.
>=20
> Changed to a SHOULD in my local copy.

Works for me.=20

/js=20

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>


From nobody Thu Jun 18 01:39:00 2020
Return-Path: <ietfc@btconnect.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDF73A0FD9 for <netconf@ietfa.amsl.com>; Thu, 18 Jun 2020 01:38:59 -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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 j9PPtDRWa8vs for <netconf@ietfa.amsl.com>; Thu, 18 Jun 2020 01:38:56 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2100.outbound.protection.outlook.com [40.107.22.100]) (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 5CA223A0FD8 for <netconf@ietf.org>; Thu, 18 Jun 2020 01:38:56 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KTMhG3uj48UCoRntcd79/dnhy+UknuOj8hXSb/j1xhn5pqZDwLMBKqFzuwRcIjFj1F3nHT7KK9++LqDgnzPGBgQ+5iu5M6v+XVLTFI2WxkG5YsmGn2+LHDJk/A+BtYqVD7tnraxFeZFClJidLpNyx9Ge+/kvU5pCeMFhNQHsi+7TzpczOPTRkNDuJ+cQm1WGGg5sFCxS7QZtwmBvuPAHKy8OOuHL3vD0w8/0WA2Wo7sSCjNx3+vNFvoJDC7UVeeL2/SFDBRiLhiMYTQOtOzI+rKxNf8SWBhjS4R9XG9WnUfPLefz5p97icNpvRejalQ8GXEIP5VhenviX9JOhw2KlA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VfIWqyEILLLptA2f0yNbVlgNfqMyqHN7ZofBZp/ivLs=; b=J7keH2UWJQSQPOywZ9IlQRo2xV59PDyL+NVX4VZbya3l/uEgST8ffPVL8zo0Ephf0VfCSn/Dkh/a6tTuk5o5GpUfdNUKSu9jkqV9ugaloyzE5Zvg/sfdNnywOlrA8N3uvnYr0OQDOXhyij3E9l74o2nZCC89f1J5viqU3Pkx5mmq4sEpqSqslnv2KZnz0NTz7UdcLluA0org6kgGzxMqP4MZJyllMdRkNLMy/CW2z2FgrdXKfObSBg0WtEZyuoUzu2gT9h71Xy2STrQ2OxsU8etvue0MkUnMuifA/Vq7lkmLeFdJOxZN55ym4hw3X7VB1j7H2prnOId5DGWxqE9piA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VfIWqyEILLLptA2f0yNbVlgNfqMyqHN7ZofBZp/ivLs=; b=EtudHkynkycOvrzLSX04bCUKTXAOAEqGuxX/PHTYLvNJffwwEfK3e1UkLwkSjsZbRVBq9hv0kYeI4FAWMm0SLn+sOwswzk9ZztN949X3ur8c6ewQjzmUTlSp4H+DgNcHUu+EA1gsoFsC0WT/OPP+PttZSGyQ7MNO8z1wHbcAmW8=
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com (2603:10a6:10:198::14) by DB7PR07MB3979.eurprd07.prod.outlook.com (2603:10a6:5:1::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.7; Thu, 18 Jun 2020 08:38:53 +0000
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65]) by DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65%7]) with mapi id 15.20.3109.018; Thu, 18 Jun 2020 08:38:53 +0000
From: tom petch <ietfc@btconnect.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Mahesh Jethanandani <mjethanandani@gmail.com>
CC: Netconf <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts
Thread-Index: AQHWOThMOtlQSxaDHEC0TmDma2BnbqjcuJ8AgABEwwCAASchSw==
Date: Thu, 18 Jun 2020 08:38:53 +0000
Message-ID: <DBAPR07MB7016CEC8A92F3AF1D3EB4450A09B0@DBAPR07MB7016.eurprd07.prod.outlook.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de>, <14453F87-3F9D-40AA-A4E5-DAD7D66B480C@akamai.com>
In-Reply-To: <14453F87-3F9D-40AA-A4E5-DAD7D66B480C@akamai.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.139.211.29]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4576e643-db04-412a-e4f9-08d813630871
x-ms-traffictypediagnostic: DB7PR07MB3979:
x-microsoft-antispam-prvs: <DB7PR07MB39793E8E4A71E32213D8A086A09B0@DB7PR07MB3979.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0438F90F17
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0mp7uQBt6z+SJy15ZaaztVJQJ1Yl06U/xYqVsF0sr8105ocB1MvfolZeBqjUkfGJWE1yYLK11LQbLf2uW1/QvRxC8WsZ0qln2QmnhMNvLJUqZknQfftN98k7+CztWXBspRhDi58pBnrZCUWho31pVRi1h2kXvV/LC0MalQwDNQdnLJCH+d1Ja92klb9kgv84+Pf8CsYWXE7/9vDc879++4cj9pj92vQrHyESKGwsU6CohqZZ2uYS4O25mZzNlRrYbQEkach6h7qL0JrzpPMU9vZDaQIE3pEYX5imQ2P1+0vPujdNZdADWkKnxM6Ac0xLLu2fJCaMjDArdPkQXqc4PCLwws/zX95sXSyxLbfNhBx3ce44L+B1HxvR7oq38GZ/RnOhxpyyPgQytfZOVBR4Ng==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DBAPR07MB7016.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(136003)(39860400002)(366004)(346002)(376002)(396003)(83380400001)(71200400001)(5660300002)(8936002)(110136005)(8676002)(186003)(52536014)(316002)(26005)(7696005)(478600001)(55016002)(53546011)(66476007)(66556008)(64756008)(66446008)(33656002)(6506007)(66946007)(91956017)(76116006)(9686003)(966005)(2906002)(86362001)(4326008); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: uivxAsCFTMFsJduMbh2GwsDZ/If/vK7z9NSjXeiMqV85x2aUGTP2N/txMUxsOTY9b+iGG+6dTrrvbRRyw6Css04R2dH7rPQF1Rk5tO3FiARQPFRkHY+QFwiTrYsrTqEIsmtt7UX/0RHrZ6ihLXkWoJ7UaTZqJN8Km0htC9Ela0YpIRmgh81528pemMoFSGaK5AVH5MqX8M7bBDDbl71hyqR2CnQ7BVSdtRgXrKfO3wgtRo0rbN+GyLLOW+3s43gY+qbSbhsBoANIMdv/flTOQWD6HBECbCfHhIoBBACYyv3AZ8aar5/4F1dxNOvLBjYeMam019qCAuYJKgWwuM0F6p+seCYHe/Av4TtHKaI1+JSaQS4Evkig2ZyRkET+0c1qLp8t7/ENos3bU8x+1Kp8/s2dAvjiOn038Gb2XR2R3/LuvrmAE4CPLwmc9CCv8165Oyllx8mPbEZvL6qQBZNoFYl+txA/mTgHizQw7lIn6SY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4576e643-db04-412a-e4f9-08d813630871
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 08:38:53.5460 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: PknGjeGeB3IvgccKRrEV6CY03C9mJr8mMedHFS0dBBKyRi99Ab3mkDoukrlW8cT+2qf5N8nU79mZXwue9J6whg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB3979
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/VBvwBwBm0B0BgoLrX1-t0R-Urvs>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 08:38:59 -0000

From: netconf <netconf-bounces@ietf.org> on behalf of Salz, Rich <rsalz=3D4=
0akamai.com@dmarc.ietf.org>=0A=
Sent: 17 June 2020 15:59=0A=
To: Juergen Schoenwaelder; Mahesh Jethanandani=0A=
=0A=
>      - These drafts needs serious reviews by security domain experts.=0A=
        This all looks reasonable to me but since this is all about=0A=
        security, we need to set the bar high to get things right.=0A=
=0A=
For what it's worth, I've had a couple of discussions with Kent on these ov=
er time.  I think requesting an additional security directorate early revie=
w is probaby a good idea.=0A=
=0A=
>      - Do we have to be prepared for alternate cert formats in the=0A=
        future?=0A=
=0A=
No. :) If something come to displace X509v3, many things will have to under=
go some fundamental changes.=0A=
=0A=
<tp>=0A=
Rich=0A=
=0A=
I have seen work in the IETF on alternative cert formats but cannot lay my =
hands on it.  It might have come from IEEE or BBF or some such.  As you say=
, replacing X.509 would cause widespread changes but an alternative alongsi=
de for some environments - IoT? - might happen in our lifetimes.=0A=
=0A=
Tom Petch=0A=
=0A=
=0A=
_______________________________________________=0A=
netconf mailing list=0A=
netconf@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netconf=0A=


From nobody Thu Jun 18 04:43:33 2020
Return-Path: <ietfc@btconnect.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD363A0C6F for <netconf@ietfa.amsl.com>; Thu, 18 Jun 2020 04:43:31 -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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 gQ_xJfoWtyN1 for <netconf@ietfa.amsl.com>; Thu, 18 Jun 2020 04:43:29 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2139.outbound.protection.outlook.com [40.107.20.139]) (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 1CE5C3A0B69 for <netconf@ietf.org>; Thu, 18 Jun 2020 04:43:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e1epTSK6PXcE+TXcRrZzNPjjPcInBftogP6Q18oCn3/c8t4n26F6ExoauIRMUSNI5fdUaKeQsLyuEYmuMyGoDDop3S7Z4VNEO4/AoeDhRX9CWh92amoEDqcblo/AgDKk2UiOw8rS63EUJiWqVv38nIticloZDAGFbzg8TchjqUCrGNldorGSYdNE0erqHipqhBabOKUNNUqV7uHW6BkwjZGaWHuiaEGQY2BcvsJpDGAYAfG+z/R9+CR7kZ2o1HxNOOksuNmIcaGLi2g77ZdV+fyYCcGa0Otlaw9TqigMdiCmJj4bQUFU3XrORY/MwSlMaEuJ/o+aP15gRvr9OIJWHw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IJ8QL0WxFRiTEEhpOKO+Kl+ruIprU1DETnop00WL468=; b=ELP9gs39e002fhGQ1HKFpuF/YMU8klrY2GbWuVmQQ/0HFZDHWc9Q737k+GL2MQD8TwuytoqHRHMJFJL40BquvzetWFeHx2wRBU2o3qtoFD+B+i46kils9qfpEvbllqVETdfkuO14oKQsL8wV81bVUyHvqQVwo9mHDV1S3VM1o5R6xw8NWSBo2c6r6KL4fFkMjFN8i54rQm8be9Ravn1focYVSgTt/qJfvxaqxa3KO3+J+MMPkE1J5VV7j5qJ/9qKDWzo+iiE5KeWLpVjSW20bYgvLtR6KA2yopahEdfYNC1uIcva8+SM8o9EKzK8kehT+ye3P13HpuyANr6bc+NpWg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IJ8QL0WxFRiTEEhpOKO+Kl+ruIprU1DETnop00WL468=; b=bRghWqMWGRjif3BEa/KSRlprfFTf2e5YLe9s8OJzFGrCC/12vqdmZdDb4G8AKoITm7jhU0k4sorJm5ov5Jvw4P1/hAdKxpw0I/oPpAJaxVt+/iHt4JoDPopgwwFsm4Sqb5UPBx9Glw9GWscvwsnhjH6zskgVrDVP5HPQ28r21vg=
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com (2603:10a6:10:198::14) by DB7PR07MB6122.eurprd07.prod.outlook.com (2603:10a6:10:85::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.10; Thu, 18 Jun 2020 11:43:22 +0000
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65]) by DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65%7]) with mapi id 15.20.3109.018; Thu, 18 Jun 2020 11:43:22 +0000
From: tom petch <ietfc@btconnect.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: Netconf <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts or two of them
Thread-Index: AQHWQXXxqA+PBQ9xTESoskd/uJ8I1ajdArkBgAFEZsg=
Date: Thu, 18 Jun 2020 11:43:22 +0000
Message-ID: <DBAPR07MB7016633BBB363EC5C259DE0CA09B0@DBAPR07MB7016.eurprd07.prod.outlook.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com>, <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com>, <DBAPR07MB7016F753766FCE8AD12A2F5DA09E0@DBAPR07MB7016.eurprd07.prod.outlook.com>, <DBAPR07MB7016369E32D8534F7C967719A09A0@DBAPR07MB7016.eurprd07.prod.outlook.com>
In-Reply-To: <DBAPR07MB7016369E32D8534F7C967719A09A0@DBAPR07MB7016.eurprd07.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.139.211.29]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2efe096f-5579-4396-1f8f-08d8137ccddb
x-ms-traffictypediagnostic: DB7PR07MB6122:
x-microsoft-antispam-prvs: <DB7PR07MB612222B658D6B4C0BCE9FA8DA09B0@DB7PR07MB6122.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0438F90F17
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: SemQ2leLsuxAqHTvmGj17BQ20Ntp98x9MYYK5XJxRDcj+FdP8s1wnTBDTUYI+FSSkfSjZvYNS1Zve68fiHcHhEUCoMqYYSPUEf7MjGD8ddj6xyd9rtN6F+HXcwBQIR3/jNaaLxGOdzJwdImbFFuTeVy7rO+Mx8rPwdSOzN65iXbB9PrPsrIerxvieXZJs3Lif24fX46dm/5W/rSovkWkGs3/v3xHIfO6+q1YqApH4Qsc2g9/nbNVh9vGP2k+cRhN4FFrgiFxhaF6ReIA7/MewxjveLfrmsNIa+acKGDFW3B4ZbvgEJahle8dnBdhjxFWY1Fis56YAGXcsjTsKv4yNBMeO2Xje0zjz+sx8Yrlb1Kh0B8rPdNcLQvRRV37hBZ7bYn34agHroOExgf9REUOLw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DBAPR07MB7016.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(346002)(396003)(376002)(366004)(39860400002)(136003)(86362001)(5660300002)(478600001)(55016002)(966005)(9686003)(6506007)(30864003)(53546011)(76116006)(66556008)(91956017)(64756008)(66946007)(8936002)(66476007)(7696005)(33656002)(66446008)(316002)(8676002)(2906002)(186003)(26005)(4326008)(83380400001)(71200400001)(52536014); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: KkY+EcvOgVX51RqvBeqHVfFbPZ5KTdlRlVVok8ReV3sjpoA5GzQvzydRKY6nPtX06LUQkcdS5sRPAJG26/BMININXhRLEsnKzylXTWcit6BtXHVR+LgBxnF9dNCWkDdyrIfncY69sCImuRWe1LEhRIKDkJ5yf8PERVRbjRoan85UP4chaaqZkC94/BgpqxsNvSVCH+QPA6sOTZiUJy+yd7/Jjh30pfsUxZB8wzTIzHr61h7mJ86h7kb8JVi/KP0kgC65xStadk7vM1gsPStemhPM2uHxihB9ypI5EOcxfJlM9ROJy9FYnRtR8OaIMJREREyRCZMGdn3LQ8LsA8+48sAYh0NLtKEl4oYE00FhYUWy0NbMzU72QF+J99aR7aAXRzqthw27zBxib5hck3gx8Sq9kxCkUEqy0fo56VhXYtsdHLq2vCZuif4hAYbXjSAEFTxinlJFugEKiPObklvEX51R7byajIa/tLzLX+VdIwk=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2efe096f-5579-4396-1f8f-08d8137ccddb
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 11:43:22.1959 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QFlT+/t6mAr8PWbsFCRUu9+CL+Ay9UVC+EPZI0IRNuAdYphVgsUjC2EJ9TYbfNmZ8MyQQD8/7qBHVCI2IJ5EkQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6122
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/WNdJPuBfymcflbJC-k8jkJfmvTE>
Subject: Re: [netconf] WG LC for three drafts or two of them
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 11:43:32 -0000

I thought some more and here is the text that I would have liked to have re=
ad in crypto-types before diving into the YANG.  It is a tribute to the pai=
nstaking work of Kent that almost all I have done is cut and paste, removin=
g duplicate phrases.  The IPR is all Kent's.=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=0A=
=0A=
X This module contains YANG identity, typedef and grouping for use by YANG =
modules involved with security.=0A=
=0A=
X.1 This module contains YANG identity for private keys, public keys and sy=
mmetric keys.=0A=
=0A=
>From the base "private-key-format" there are derived identity for =0A=
- rsa-private-key-format for use with RSA as defined in RFC 3447=0A=
- ec-private-key-format for use with Elliptic Curve as defined in RFC5915 [=
**format]=0A=
- one-asymmetric-key-format as defined for use with CMS (Cryptographic Mess=
age Syntax) as defined RFC 5958, encoded using ASN.1 DER (Distinguished Enc=
oding Rules) as specified in ITU-T X.690.=0A=
- encrypted-one-asymmetric-key-format as defined for CMS use in RFC 5958, e=
ncoded using ASN.1 DER.=0A=
      =0A=
>From the base "public-key-format" there are derived identity for =0A=
- ssh-public-key-format as defined for use with SSH as specified by RFC 425=
3, Section 6.6.=0A=
- subject-public-key-info-format as defined for use with X.509 in RFC 5280,=
 encoded using ASN.1 DER.=0A=
=0A=
>From the base "symmetric-key-format" there are derived identity for =0A=
- octet-string-key-format encoded as a raw octet string.=0A=
- one-symmetric-key-format as defined for use with CMS in RFC 6031 and=0A=
          encoded using ASN.1 DER=0A=
- encrypted-one-symmetric-key-format as defined for use with CMS =0A=
          in RFC 6031 and encoded using ASN.1 DER=0A=
=0A=
=0A=
X.2 This module contains typedef for X.509 certificate, CMS structures and =
trust anchors.=0A=
=0A=
'csr' is derived from 'binary' and is for use with a CertificationRequest  =
        as specified in PKCS#10, RFC 2986, encoded in DER.  No other types =
are derived from this base.=0A=
=0A=
'x509' (without the period) is derived from 'binary' and for use for a X.50=
9 Certificate (RFC5280), encoded in DER.  From 'x509' are derived =0A=
- trust-anchor-cert-x509 a X.509 self-signed certificate (RFC5280)=0A=
- end-entity-cert-x509 a X.509 certificate for end entities, i.e. a certifi=
cate that is neither self-signed nor having the 'cA' bit in the basic const=
raints extension set to true (RFC 5280 Section 4.2.10)=0A=
=0A=
'crl' is derived from 'binary' and is for use for a X.509 'CertificateList'=
 structure, as specified in RFC 5280, encoded in DER.  No other types are d=
erived from this base.=0A=
=0A=
'cms' is derived from 'binary' and for use for a CMS ContentInfo structure =
encoded in DER (RFC5652 Section 2).  From 'cms' are derived =0A=
- data-content-cms =0A=
           a CMS structure whose top-most content type MUST be=0A=
           the 'data content type' (RFC 5652 Section 4)=0A=
- signed-data-cms - a structure whose top-most content type MUST be the=0A=
          'signed-data content type' (Section 5 RFC 5652)=0A=
- enveloped-data-cms  =0A=
         "A CMS structure whose top-most content type MUST be the=0A=
          'enveloped-data content type' (Section 6 RFC 5652)=0A=
- digested-data-cms {=0A=
         "A CMS structure whose top-most content type MUST be the=0A=
          'digested-data content type' (Section 7 RFC 5652)=0A=
- encrypted-data-cms {=0A=
         "A CMS structure whose top-most content type MUST be the=0A=
          'encrypted-data content type' (Section 8 RFC 5652)=0A=
- authenticated-data-cms {=0A=
          "A CMS structure whose top-most content type MUST be the=0A=
          'authenticated-data content type' (Section 9 RFC 5652)=0A=
=0A=
>From 'signed-data-cms' are derived=0A=
- trust-anchor-cert-cms is a CMS SignedData structure that contains a singl=
e chain of X.509 (RFC 5280) certificates which authenticate the certificate=
 presented by a client or end-entity.  The chain must include a root certif=
icate; this may be the only certificate present when that is also the certi=
ficate for the client or end-entity. Objects relating to the revocation sta=
tus of the certificates MAY be present.  This uses the degenerate form of t=
he SignedData structure (RFC 5652 Section 5.2) as is commonly used to disse=
minate X.509 certificates and revocation objects.=0A=
=0A=
-  end-entity-cert-cms is a CMS SignedData structure that contains the end =
entity certificate itself and MAY contain any number of intermediate certif=
icates leading up to a trust anchor certificate which MAY be included as we=
ll.  This differs from 'trust-anchor-cert-cms' in that the root certificate=
 and intermediate certificates, if any, are optional.  Other certificates M=
UST NOT be present but objects relating to the revocation status of the cer=
tificates MAY be present.  This uses the degenerate form of the SignedData =
structure (RFC 5652 Section 5.2) as is commonly used to disseminate X.509 c=
ertificates and revocation objects.=0A=
=0A=
=0A=
X.3 This module contains YANG grouping related to keys and certificates. Th=
e groupings for keys all contain NACM (Network Configuration Access Control=
 Model), RFC 8341, default deny for the key leaf itself.  The groupings for=
 end entity certificates and for trust anchors contain a YANG notification =
that the certificate is, or is about to, expire and also contain a NACM def=
ault deny. =0A=
=0A=
symmetric-key-grouping contains a leaf whose type is derived from 'symmetri=
c-key-format'.  The format of the key is a YANG 'choice' of 'binary' or 'em=
pty'; the latter is for use with a hidden key.=0A=
=0A=
public-key-grouping contains a leaf which is the public key in 'binary' and=
 whose format is derived from the type 'public-key-format'.=0A=
=0A=
asymmetric-key-pair-grouping uses the public-key-grouping and contains a le=
af  for the private key format whose type is derived from the type private-=
key-format and for the key itself whose type is binary or empty; the latter=
 is for use with a hidden key.       =0A=
=0A=
trust-anchor-cert-grouping contains a leaf of type 'trust-anchor-cert-cms'=
=0A=
=0A=
trust-anchor-certs-grouping contains a leaf list of type 'trust-anchor-cert=
-cms'=0A=
=0A=
end-entity-cert-grouping contains leaf of type 'end-entity-cert-cms'=0A=
=0A=
end-entity-certs-grouping contains a leaf list of type 'end-entity-cert-cms=
'=0A=
=0A=
generate-csr-grouping contains a YANG action to generate a signed Certifica=
tionRequest); the associated node MUST have a 'public-key-format' value of =
'subject-public-key-info-format'. 'input' to the action are the 'subject' a=
nd 'atributes' fields of  CertificationRequestInfo as specified in RFC 2986=
, Section 4.1, encoded in DER. 'output' of the action is a leaf of type 'cs=
r' as described above.=0A=
=0A=
asymmetric-key-pair-with-cert-grouping contains a private/public key pair a=
nd an associated certificate. The grouping uses; =0A=
- asymmetric-key-pair-grouping=0A=
- end-entity-cert-grouping=0A=
- generate-csr-grouping=0A=
as defined above.=0A=
=0A=
asymmetric-key-pair-with-certs-grouping is similar to 'asymmetric-key-pair-=
with-cert-grouping' but contains a list of end entity certificates for the =
public key where, for example, there are separate certificate for IDevID an=
d LDevID [reference**]=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=0A=
=0A=
________________________________________=0A=
From: netconf <netconf-bounces@ietf.org> on behalf of tom petch <ietfc@btco=
nnect.com>=0A=
Sent: 17 June 2020 17:23=0A=
To: Kent Watsen=0A=
Cc: Netconf=0A=
Subject: Re: [netconf] WG LC for three drafts or two of them=0A=
=0A=
From: netconf <netconf-bounces@ietf.org> on behalf of tom petch <ietfc@btco=
nnect.com>=0A=
Sent: 13 June 2020 12:29=0A=
=0A=
<tp>=0A=
I thought about the text I would like to see in crypto-types and starting w=
ith identity since they are simplest I came up with=0A=
NEW=0A=
This module contains YANG identity for private keys, public keys and symmet=
ric keys.=0A=
=0A=
>From the base "private-key-format" there are derived identity for=0A=
- rsa-private-key-format as defined in RFC 3447=0A=
- ec-private-key-format as defined in RFC5915=0A=
- one-asymmetric-key-format as defined in RFC 5958,=0A=
          encoded using ASN.1 distinguished encoding rules=0A=
          (DER), as specified in ITU-T X.690.";=0A=
- encrypted-one-asymmetric-key-format, as defined in RFC 5958,=0A=
          encoded using ASN.1 distinguished encoding rules (DER),=0A=
          as specified in ITU-T X.690.";=0A=
=0A=
>From the base "public-key-format" there are derived identity for=0A=
- ssh-public-key-format as specified by RFC 4253, Section 6.6, i.e.:=0A=
- subject-public-key-info-format as described in RFC 5280 encoded using ASN=
.1=0A=
          distinguished encoding rules (DER), as specified in=0A=
          ITU-T X.690.";=0A=
=0A=
>From the base "symmetric-key-format" there are derived identity for=0A=
-  octet-string-key-format encoded as a raw octet string.=0A=
-  one-symmetric-key-format as defined in RFC 6031 and=0A=
          encoded using ASN.1 distinguished encoding rules=0A=
          (DER), as specified in ITU-T X.690.=0A=
-  encrypted-one-symmetric-key-format as defined=0A=
          in RFC 6031 and encoded using ASN.1 distinguished=0A=
          encoding rules (DER), as specified in ITU-T X.690.";=0A=
            Specification of Basic Encoding Rules (BER),=0A=
            Canonical Encoding Rules (CER) and Distinguished=0A=
            Encoding Rules (DER)=0A=
=0A=
Obviously all I have done is take the text and reformatted it. I debated ab=
out keeping the references to CMS.  The aim is to tell the reader whether o=
r not to dig deeper into the YANG in order to use it.  For groupings I see =
more new text needed=0A=
=0A=
Tom Petch=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
I have concerns about trust-anchors and crypto-types.  They are both more o=
r less non-existent when it comes to text.  I do not want to have to revers=
e engineer the YANG or XML to find out what RPC or action there are, what t=
ypes of cipher suites and such like are supported - and perhaps those that =
are not such as raw keys.  I would expect there to be five or ten pages of =
such in each.  Look for example at layer0-types or layer1-types for modules=
 with what I would regard as adequate text.=0A=
=0A=
Tom Petch=0A=
=0A=
From: netconf <netconf-bounces@ietf.org> on behalf of Eric Voit (evoit) <ev=
oit=3D40cisco.com@dmarc.ietf.org>=0A=
Sent: 12 June 2020 21:03=0A=
=0A=
> > -----Original Message-----=0A=
=0A=
> > From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh=0A=
=0A=
> > Jethanandani=0A=
=0A=
> > Sent: Tuesday, June 2, 2020 7:48 PM=0A=
=0A=
> > To: Netconf <netconf@ietf.org>=0A=
=0A=
> > Subject: [netconf] WG LC for three drafts=0A=
=0A=
> >=0A=
=0A=
> > NETCONF WG,=0A=
=0A=
> >=0A=
=0A=
> > The authors of=0A=
=0A=
> >=0A=
=0A=
> > - draft-ietf-netconf-crypto-types=0A=
=0A=
> > - draft-ietf-netconf-keystore=0A=
=0A=
> > - draft-ietf-netconf-trust-anchors=0A=
=0A=
> >=0A=
=0A=
> > have indicated that these drafts are ready for Last Call (LC).=0A=
=0A=
> >=0A=
=0A=
> > This kicks of a 2 week WG LC for the three drafts. Please review and=0A=
=0A=
> > send=0A=
=0A=
> any=0A=
=0A=
> > comments to the WG mailing list or by responding to this e-mail.=0A=
=0A=
> > Comments can be statements such as, I read/reviewed the document and=0A=
=0A=
> > believe it is ready for publication, or I have concerns about the=0A=
=0A=
> > document. For the=0A=
=0A=
> latter,=0A=
=0A=
> > please indicate what your concerns are.=0A=
=0A=
> >=0A=
=0A=
> > Any reports on implementation status or plans to implement are also=0A=
=0A=
> > very useful.=0A=
=0A=
> >=0A=
=0A=
> > Thanks.=0A=
=0A=
> >=0A=
=0A=
> > Mahesh Jethanandani (as co-chair)=0A=
=0A=
> > mjethanandani@gmail.com=0A=
=0A=
> >=0A=
=0A=
> >=0A=
=0A=
> >=0A=
=0A=
> > _______________________________________________=0A=
=0A=
> > netconf mailing list=0A=
=0A=
> > netconf@ietf.org=0A=
=0A=
> > https://www.ietf.org/mailman/listinfo/netconf=0A=
=0A=
_______________________________________________=0A=
netconf mailing list=0A=
netconf@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netconf=0A=
=0A=
_______________________________________________=0A=
netconf mailing list=0A=
netconf@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netconf=0A=


From nobody Thu Jun 18 06:00:59 2020
Return-Path: <rsalz@akamai.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3826F3A0CFD for <netconf@ietfa.amsl.com>; Thu, 18 Jun 2020 06:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=akamai.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 3Jqbbkxy5IqP for <netconf@ietfa.amsl.com>; Thu, 18 Jun 2020 06:00:56 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 9D3AE3A0CE4 for <netconf@ietf.org>; Thu, 18 Jun 2020 06:00:56 -0700 (PDT)
Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 05ICxaWM021391; Thu, 18 Jun 2020 14:00:52 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Su8UE7vHy107ZjfiG6T5+O5FPaGAkyyTHPUBAV4Y3Zk=; b=XQsRHz23QZP0efApctrr+ZBPgLI/PKtKdB9mlOV4GFPOScQwCs/iGprsn+jMwJRFtBDg mv/J2u+FwkAmbxpHo7AwN92bTv5ETo4yq1t2doj/KEQpo4mGAvTM7cjT10+aYkQ9EMyR 1+csWFJLVP/+2YsoNVij14Kzmo1g5hDhYNOklAPnKLgNtIo4VfSalamDQdhOy0PE1YYi /NQRMt4z58Q+zbOgHHjJLPjT7XT/Ec9B+8McOwwcdcz1GF+Sowd4BR0v0ePC+qTrGyY+ ajMRJLsvO/iIhXDBCtsZxonBk4Y20Kc1LZoWjW0FSoidf674M1zhbqM8xm7Lr5BDbISE /Q== 
Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 31qqye1j5s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Jun 2020 14:00:50 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05ICZn6m005640; Thu, 18 Jun 2020 09:00:49 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint3.akamai.com with ESMTP id 31qjmjq1ke-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Jun 2020 09:00:47 -0400
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 18 Jun 2020 08:00:43 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Thu, 18 Jun 2020 08:00:43 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: tom petch <ietfc@btconnect.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Mahesh Jethanandani <mjethanandani@gmail.com>
CC: Netconf <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts
Thread-Index: AQHWOThMaW9TVQbVp0aakzz8vRafn6jdDHEAgAABtACAAWsHgIAABhgA
Date: Thu, 18 Jun 2020 13:00:42 +0000
Message-ID: <768CC0BC-D11E-4F2D-A950-4E7FB1750CEE@akamai.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de> <14453F87-3F9D-40AA-A4E5-DAD7D66B480C@akamai.com> <DBAPR07MB7016CEC8A92F3AF1D3EB4450A09B0@DBAPR07MB7016.eurprd07.prod.outlook.com>
In-Reply-To: <DBAPR07MB7016CEC8A92F3AF1D3EB4450A09B0@DBAPR07MB7016.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.38.20061401
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.39.135]
Content-Type: text/plain; charset="utf-8"
Content-ID: <E78DC93BCC041148941E074B4FF58DDF@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-18_11:2020-06-18, 2020-06-18 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 phishscore=0 bulkscore=0 mlxscore=0 mlxlogscore=676 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006180096
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-18_12:2020-06-18, 2020-06-18 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 mlxscore=0 bulkscore=0 spamscore=0 mlxlogscore=646 phishscore=0 adultscore=0 clxscore=1011 lowpriorityscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006180099
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/S7N33uvIYL3R-QzI7b-Dr8dsPEc>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 13:00:58 -0000

SVRVIGlzIHdvcmtpbmcgb24gWDUwOXY0LCBidXQgdGhhdCBpc24ndCBnb2luZyB0byBiZSBzbWFs
bGVyIHRoYW4gWDUwOXYzIGFuZCBub3QgY2xlYXIgdG8gbWUgdXNlZnVsIGZvciBJb1QuDQogDQoN
Cg==


From nobody Thu Jun 18 06:41:40 2020
Return-Path: <01000172c7a9cda8-3214ef17-890f-4f42-a9ab-b5b3730350a7-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505D43A0F52 for <netconf@ietfa.amsl.com>; Thu, 18 Jun 2020 06:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 ye-Y__D4VpU5 for <netconf@ietfa.amsl.com>; Thu, 18 Jun 2020 06:41:35 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5253A0F51 for <netconf@ietf.org>; Thu, 18 Jun 2020 06:41:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1592487694; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=SyJn9zO37Ob98mDV+5LrMGDT2R4N+uMNd4Cig01LU+c=; b=BEl5TLoQxXK3daGsPRH2DH4X6SJD00vxtBqB5CQ0qZFVI7oAXeozW+tSQdEVteuX rmTNXjzEQgWptZ98hKEjOA3dyfPqLe0IXSK82delakM2LHL/qaZsZdZ0pRWKIovBzY3 b+1XDLeAOk4XkbysrEosY7E+OQlqli6inSy/UiAc=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000172c7a9cda8-3214ef17-890f-4f42-a9ab-b5b3730350a7-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8C11C88A-7A1E-4A6C-AEF6-1DCDE8A053E3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 18 Jun 2020 13:41:33 +0000
In-Reply-To: <DBAPR07MB7016633BBB363EC5C259DE0CA09B0@DBAPR07MB7016.eurprd07.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: tom petch <ietfc@btconnect.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com> <DBAPR07MB7016F753766FCE8AD12A2F5DA09E0@DBAPR07MB7016.eurprd07.prod.outlook.com> <DBAPR07MB7016369E32D8534F7C967719A09A0@DBAPR07MB7016.eurprd07.prod.outlook.com> <DBAPR07MB7016633BBB363EC5C259DE0CA09B0@DBAPR07MB7016.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.18-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/RK8iBi2fGmmwsYtZQE7pfPPw6cA>
Subject: Re: [netconf] WG LC for three drafts or two of them
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 13:41:38 -0000

--Apple-Mail=_8C11C88A-7A1E-4A6C-AEF6-1DCDE8A053E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Tom,

Thank you!

This text is a superset of the text sent yesterday, so I=E2=80=99ll =
focus on consuming this content instead.  Reading it, two thoughts =
arise:

1) Much of this text should surround tree diagram snippets.   As Juergen =
implied yesterday, a wall of tree diagram artwork alone doesn=E2=80=99t =
make for a great =E2=80=9Coverview=E2=80=9D.

2) It is too bad that RFC 8340 doesn=E2=80=99t define a way to represent =
identities, features, or typedefs (note that both identities and =
features can form trees too).  I=E2=80=99ll likely devise my own format =
for the =E2=80=9Coverview=E2=80=9D section, around which some of your =
text would go.

PS: I have no IPR on this work either, it all goes to the IETF.

Kent // contributor


> On Jun 18, 2020, at 7:43 AM, tom petch <ietfc@btconnect.com> wrote:
>=20
> I thought some more and here is the text that I would have liked to =
have read in crypto-types before diving into the YANG.  It is a tribute =
to the painstaking work of Kent that almost all I have done is cut and =
paste, removing duplicate phrases.  The IPR is all Kent's.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>=20
> X This module contains YANG identity, typedef and grouping for use by =
YANG modules involved with security.
>=20
> X.1 This module contains YANG identity for private keys, public keys =
and symmetric keys.
>=20
> =46rom the base "private-key-format" there are derived identity for=20
> - rsa-private-key-format for use with RSA as defined in RFC 3447
> - ec-private-key-format for use with Elliptic Curve as defined in =
RFC5915 [**format]
> - one-asymmetric-key-format as defined for use with CMS (Cryptographic =
Message Syntax) as defined RFC 5958, encoded using ASN.1 DER =
(Distinguished Encoding Rules) as specified in ITU-T X.690.
> - encrypted-one-asymmetric-key-format as defined for CMS use in RFC =
5958, encoded using ASN.1 DER.
>=20
> =46rom the base "public-key-format" there are derived identity for=20
> - ssh-public-key-format as defined for use with SSH as specified by =
RFC 4253, Section 6.6.
> - subject-public-key-info-format as defined for use with X.509 in RFC =
5280, encoded using ASN.1 DER.
>=20
> =46rom the base "symmetric-key-format" there are derived identity for=20=

> - octet-string-key-format encoded as a raw octet string.
> - one-symmetric-key-format as defined for use with CMS in RFC 6031 and
>          encoded using ASN.1 DER
> - encrypted-one-symmetric-key-format as defined for use with CMS=20
>          in RFC 6031 and encoded using ASN.1 DER
>=20
>=20
> X.2 This module contains typedef for X.509 certificate, CMS structures =
and trust anchors.
>=20
> 'csr' is derived from 'binary' and is for use with a =
CertificationRequest          as specified in PKCS#10, RFC 2986, encoded =
in DER.  No other types are derived from this base.
>=20
> 'x509' (without the period) is derived from 'binary' and for use for a =
X.509 Certificate (RFC5280), encoded in DER.  =46rom 'x509' are derived=20=

> - trust-anchor-cert-x509 a X.509 self-signed certificate (RFC5280)
> - end-entity-cert-x509 a X.509 certificate for end entities, i.e. a =
certificate that is neither self-signed nor having the 'cA' bit in the =
basic constraints extension set to true (RFC 5280 Section 4.2.10)
>=20
> 'crl' is derived from 'binary' and is for use for a X.509 =
'CertificateList' structure, as specified in RFC 5280, encoded in DER.  =
No other types are derived from this base.
>=20
> 'cms' is derived from 'binary' and for use for a CMS ContentInfo =
structure encoded in DER (RFC5652 Section 2).  =46rom 'cms' are derived=20=

> - data-content-cms=20
>           a CMS structure whose top-most content type MUST be
>           the 'data content type' (RFC 5652 Section 4)
> - signed-data-cms - a structure whose top-most content type MUST be =
the
>          'signed-data content type' (Section 5 RFC 5652)
> - enveloped-data-cms =20
>         "A CMS structure whose top-most content type MUST be the
>          'enveloped-data content type' (Section 6 RFC 5652)
> - digested-data-cms {
>         "A CMS structure whose top-most content type MUST be the
>          'digested-data content type' (Section 7 RFC 5652)
> - encrypted-data-cms {
>         "A CMS structure whose top-most content type MUST be the
>          'encrypted-data content type' (Section 8 RFC 5652)
> - authenticated-data-cms {
>          "A CMS structure whose top-most content type MUST be the
>          'authenticated-data content type' (Section 9 RFC 5652)
>=20
> =46rom 'signed-data-cms' are derived
> - trust-anchor-cert-cms is a CMS SignedData structure that contains a =
single chain of X.509 (RFC 5280) certificates which authenticate the =
certificate presented by a client or end-entity.  The chain must include =
a root certificate; this may be the only certificate present when that =
is also the certificate for the client or end-entity. Objects relating =
to the revocation status of the certificates MAY be present.  This uses =
the degenerate form of the SignedData structure (RFC 5652 Section 5.2) =
as is commonly used to disseminate X.509 certificates and revocation =
objects.
>=20
> -  end-entity-cert-cms is a CMS SignedData structure that contains the =
end entity certificate itself and MAY contain any number of intermediate =
certificates leading up to a trust anchor certificate which MAY be =
included as well.  This differs from 'trust-anchor-cert-cms' in that the =
root certificate and intermediate certificates, if any, are optional.  =
Other certificates MUST NOT be present but objects relating to the =
revocation status of the certificates MAY be present.  This uses the =
degenerate form of the SignedData structure (RFC 5652 Section 5.2) as is =
commonly used to disseminate X.509 certificates and revocation objects.
>=20
>=20
> X.3 This module contains YANG grouping related to keys and =
certificates. The groupings for keys all contain NACM (Network =
Configuration Access Control Model), RFC 8341, default deny for the key =
leaf itself.  The groupings for end entity certificates and for trust =
anchors contain a YANG notification that the certificate is, or is about =
to, expire and also contain a NACM default deny.=20
>=20
> symmetric-key-grouping contains a leaf whose type is derived from =
'symmetric-key-format'.  The format of the key is a YANG 'choice' of =
'binary' or 'empty'; the latter is for use with a hidden key.
>=20
> public-key-grouping contains a leaf which is the public key in =
'binary' and whose format is derived from the type 'public-key-format'.
>=20
> asymmetric-key-pair-grouping uses the public-key-grouping and contains =
a leaf  for the private key format whose type is derived from the type =
private-key-format and for the key itself whose type is binary or empty; =
the latter is for use with a hidden key.      =20
>=20
> trust-anchor-cert-grouping contains a leaf of type =
'trust-anchor-cert-cms'
>=20
> trust-anchor-certs-grouping contains a leaf list of type =
'trust-anchor-cert-cms'
>=20
> end-entity-cert-grouping contains leaf of type 'end-entity-cert-cms'
>=20
> end-entity-certs-grouping contains a leaf list of type =
'end-entity-cert-cms'
>=20
> generate-csr-grouping contains a YANG action to generate a signed =
CertificationRequest); the associated node MUST have a =
'public-key-format' value of 'subject-public-key-info-format'. 'input' =
to the action are the 'subject' and 'atributes' fields of  =
CertificationRequestInfo as specified in RFC 2986, Section 4.1, encoded =
in DER. 'output' of the action is a leaf of type 'csr' as described =
above.
>=20
> asymmetric-key-pair-with-cert-grouping contains a private/public key =
pair and an associated certificate. The grouping uses;=20
> - asymmetric-key-pair-grouping
> - end-entity-cert-grouping
> - generate-csr-grouping
> as defined above.
>=20
> asymmetric-key-pair-with-certs-grouping is similar to =
'asymmetric-key-pair-with-cert-grouping' but contains a list of end =
entity certificates for the public key where, for example, there are =
separate certificate for IDevID and LDevID [reference**]
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>=20
> ________________________________________
> From: netconf <netconf-bounces@ietf.org> on behalf of tom petch =
<ietfc@btconnect.com>
> Sent: 17 June 2020 17:23
> To: Kent Watsen
> Cc: Netconf
> Subject: Re: [netconf] WG LC for three drafts or two of them
>=20
> From: netconf <netconf-bounces@ietf.org> on behalf of tom petch =
<ietfc@btconnect.com>
> Sent: 13 June 2020 12:29
>=20
> <tp>
> I thought about the text I would like to see in crypto-types and =
starting with identity since they are simplest I came up with
> NEW
> This module contains YANG identity for private keys, public keys and =
symmetric keys.
>=20
>> =46rom the base "private-key-format" there are derived identity for
> - rsa-private-key-format as defined in RFC 3447
> - ec-private-key-format as defined in RFC5915
> - one-asymmetric-key-format as defined in RFC 5958,
>          encoded using ASN.1 distinguished encoding rules
>          (DER), as specified in ITU-T X.690.";
> - encrypted-one-asymmetric-key-format, as defined in RFC 5958,
>          encoded using ASN.1 distinguished encoding rules (DER),
>          as specified in ITU-T X.690.";
>=20
>> =46rom the base "public-key-format" there are derived identity for
> - ssh-public-key-format as specified by RFC 4253, Section 6.6, i.e.:
> - subject-public-key-info-format as described in RFC 5280 encoded =
using ASN.1
>          distinguished encoding rules (DER), as specified in
>          ITU-T X.690.";
>=20
>> =46rom the base "symmetric-key-format" there are derived identity for
> -  octet-string-key-format encoded as a raw octet string.
> -  one-symmetric-key-format as defined in RFC 6031 and
>          encoded using ASN.1 distinguished encoding rules
>          (DER), as specified in ITU-T X.690.
> -  encrypted-one-symmetric-key-format as defined
>          in RFC 6031 and encoded using ASN.1 distinguished
>          encoding rules (DER), as specified in ITU-T X.690.";
>            Specification of Basic Encoding Rules (BER),
>            Canonical Encoding Rules (CER) and Distinguished
>            Encoding Rules (DER)
>=20
> Obviously all I have done is take the text and reformatted it. I =
debated about keeping the references to CMS.  The aim is to tell the =
reader whether or not to dig deeper into the YANG in order to use it.  =
For groupings I see more new text needed
>=20
> Tom Petch
>=20
>=20
>=20
>=20
>=20
> I have concerns about trust-anchors and crypto-types.  They are both =
more or less non-existent when it comes to text.  I do not want to have =
to reverse engineer the YANG or XML to find out what RPC or action there =
are, what types of cipher suites and such like are supported - and =
perhaps those that are not such as raw keys.  I would expect there to be =
five or ten pages of such in each.  Look for example at layer0-types or =
layer1-types for modules with what I would regard as adequate text.
>=20
> Tom Petch
>=20
> From: netconf <netconf-bounces@ietf.org> on behalf of Eric Voit =
(evoit) <evoit=3D40cisco.com@dmarc.ietf.org>
> Sent: 12 June 2020 21:03
>=20
>>> -----Original Message-----
>=20
>>> From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh
>=20
>>> Jethanandani
>=20
>>> Sent: Tuesday, June 2, 2020 7:48 PM
>=20
>>> To: Netconf <netconf@ietf.org>
>=20
>>> Subject: [netconf] WG LC for three drafts
>=20
>>>=20
>=20
>>> NETCONF WG,
>=20
>>>=20
>=20
>>> The authors of
>=20
>>>=20
>=20
>>> - draft-ietf-netconf-crypto-types
>=20
>>> - draft-ietf-netconf-keystore
>=20
>>> - draft-ietf-netconf-trust-anchors
>=20
>>>=20
>=20
>>> have indicated that these drafts are ready for Last Call (LC).
>=20
>>>=20
>=20
>>> This kicks of a 2 week WG LC for the three drafts. Please review and
>=20
>>> send
>=20
>> any
>=20
>>> comments to the WG mailing list or by responding to this e-mail.
>=20
>>> Comments can be statements such as, I read/reviewed the document and
>=20
>>> believe it is ready for publication, or I have concerns about the
>=20
>>> document. For the
>=20
>> latter,
>=20
>>> please indicate what your concerns are.
>=20
>>>=20
>=20
>>> Any reports on implementation status or plans to implement are also
>=20
>>> very useful.
>=20
>>>=20
>=20
>>> Thanks.
>=20
>>>=20
>=20
>>> Mahesh Jethanandani (as co-chair)
>=20
>>> mjethanandani@gmail.com
>=20
>>>=20
>=20
>>>=20
>=20
>>>=20
>=20
>>> _______________________________________________
>=20
>>> netconf mailing list
>=20
>>> netconf@ietf.org
>=20
>>> https://www.ietf.org/mailman/listinfo/netconf
>=20
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>=20
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


--Apple-Mail=_8C11C88A-7A1E-4A6C-AEF6-1DCDE8A053E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Hi =
Tom,<div class=3D""><br class=3D""></div><div class=3D"">Thank =
you!</div><div class=3D""><br class=3D""></div><div class=3D"">This text =
is a superset of the text sent yesterday, so I=E2=80=99ll focus on =
consuming this content instead. &nbsp;Reading it, two thoughts =
arise:</div><div class=3D""><br class=3D""></div><div class=3D"">1) Much =
of this text should surround tree diagram snippets. &nbsp; As Juergen =
implied yesterday, a wall of tree diagram artwork alone doesn=E2=80=99t =
make for a great =E2=80=9Coverview=E2=80=9D.</div><div class=3D""><br =
class=3D""></div><div class=3D"">2) It is too bad that RFC 8340 =
doesn=E2=80=99t define a way to represent identities, features, =
or&nbsp;<font color=3D"#000000" class=3D"">typedefs (note that both =
identities and features can form trees too). &nbsp;I=E2=80=99ll likely =
devise my own format for the&nbsp;=E2=80=9Coverview=E2=80=9D =
section,&nbsp;around which some of your text would go.</font></div><div =
class=3D""><font color=3D"#000000" class=3D""><br =
class=3D""></font></div><div class=3D""><font color=3D"#000000" =
class=3D"">PS: I have no IPR on this work either, it all goes to the =
IETF.</font></div><div class=3D""><font color=3D"#000000" class=3D""><br =
class=3D""></font></div><div class=3D""><font color=3D"#000000" =
class=3D"">Kent // contributor</font></div><div class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jun 18, 2020, at 7:43 AM, tom petch &lt;<a =
href=3D"mailto:ietfc@btconnect.com" class=3D"">ietfc@btconnect.com</a>&gt;=
 wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D"">I thought some more and here is the text that I would have =
liked to have read in crypto-types before diving into the YANG. &nbsp;It =
is a tribute to the painstaking work of Kent that almost all I have done =
is cut and paste, removing duplicate phrases. &nbsp;The IPR is all =
Kent's.<br =
class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D<br class=3D""><br class=3D"">X This module contains =
YANG identity, typedef and grouping for use by YANG modules involved =
with security.<br class=3D""><br class=3D"">X.1 This module contains =
YANG identity for private keys, public keys and symmetric keys.<br =
class=3D""><br class=3D"">=46rom the base "private-key-format" there are =
derived identity for <br class=3D"">- rsa-private-key-format for use =
with RSA as defined in RFC 3447<br class=3D"">- ec-private-key-format =
for use with Elliptic Curve as defined in RFC5915 [**format]<br =
class=3D"">- one-asymmetric-key-format as defined for use with CMS =
(Cryptographic Message Syntax) as defined RFC 5958, encoded using ASN.1 =
DER (Distinguished Encoding Rules) as specified in ITU-T X.690.<br =
class=3D"">- encrypted-one-asymmetric-key-format as defined for CMS use =
in RFC 5958, encoded using ASN.1 DER.<br class=3D""><br class=3D"">=46rom =
the base "public-key-format" there are derived identity for <br =
class=3D"">- ssh-public-key-format as defined for use with SSH as =
specified by RFC 4253, Section 6.6.<br class=3D"">- =
subject-public-key-info-format as defined for use with X.509 in RFC =
5280, encoded using ASN.1 DER.<br class=3D""><br class=3D"">=46rom the =
base "symmetric-key-format" there are derived identity for <br =
class=3D"">- octet-string-key-format encoded as a raw octet string.<br =
class=3D"">- one-symmetric-key-format as defined for use with CMS in RFC =
6031 and<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;encoded using =
ASN.1 DER<br class=3D"">- encrypted-one-symmetric-key-format as defined =
for use with CMS <br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in RFC 6031 and =
encoded using ASN.1 DER<br class=3D""><br class=3D""><br class=3D"">X.2 =
This module contains typedef for X.509 certificate, CMS structures and =
trust anchors.<br class=3D""><br class=3D"">'csr' is derived from =
'binary' and is for use with a CertificationRequest =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;as specified in =
PKCS#10, RFC 2986, encoded in DER. &nbsp;No other types are derived from =
this base.<br class=3D""><br class=3D"">'x509' (without the period) is =
derived from 'binary' and for use for a X.509 Certificate (RFC5280), =
encoded in DER. &nbsp;=46rom 'x509' are derived <br class=3D"">- =
trust-anchor-cert-x509 a X.509 self-signed certificate (RFC5280)<br =
class=3D"">- end-entity-cert-x509 a X.509 certificate for end entities, =
i.e. a certificate that is neither self-signed nor having the 'cA' bit =
in the basic constraints extension set to true (RFC 5280 Section =
4.2.10)<br class=3D""><br class=3D"">'crl' is derived from 'binary' and =
is for use for a X.509 'CertificateList' structure, as specified in RFC =
5280, encoded in DER. &nbsp;No other types are derived from this =
base.<br class=3D""><br class=3D"">'cms' is derived from 'binary' and =
for use for a CMS ContentInfo structure encoded in DER (RFC5652 Section =
2). &nbsp;=46rom 'cms' are derived <br class=3D"">- data-content-cms <br =
class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a CMS =
structure whose top-most content type MUST be<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the 'data =
content type' (RFC 5652 Section 4)<br class=3D"">- signed-data-cms - a =
structure whose top-most content type MUST be the<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'signed-data =
content type' (Section 5 RFC 5652)<br class=3D"">- enveloped-data-cms =
&nbsp;<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"A =
CMS structure whose top-most content type MUST be the<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'enveloped-data =
content type' (Section 6 RFC 5652)<br class=3D"">- digested-data-cms =
{<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"A CMS =
structure whose top-most content type MUST be the<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'digested-data =
content type' (Section 7 RFC 5652)<br class=3D"">- encrypted-data-cms =
{<br class=3D""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"A CMS =
structure whose top-most content type MUST be the<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'encrypted-data =
content type' (Section 8 RFC 5652)<br class=3D"">- =
authenticated-data-cms {<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"A CMS structure =
whose top-most content type MUST be the<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'authenticated-data =
content type' (Section 9 RFC 5652)<br class=3D""><br class=3D"">=46rom =
'signed-data-cms' are derived<br class=3D"">- trust-anchor-cert-cms is a =
CMS SignedData structure that contains a single chain of X.509 (RFC =
5280) certificates which authenticate the certificate presented by a =
client or end-entity. &nbsp;The chain must include a root certificate; =
this may be the only certificate present when that is also the =
certificate for the client or end-entity. Objects relating to the =
revocation status of the certificates MAY be present. &nbsp;This uses =
the degenerate form of the SignedData structure (RFC 5652 Section 5.2) =
as is commonly used to disseminate X.509 certificates and revocation =
objects.<br class=3D""><br class=3D"">- &nbsp;end-entity-cert-cms is a =
CMS SignedData structure that contains the end entity certificate itself =
and MAY contain any number of intermediate certificates leading up to a =
trust anchor certificate which MAY be included as well. &nbsp;This =
differs from 'trust-anchor-cert-cms' in that the root certificate and =
intermediate certificates, if any, are optional. &nbsp;Other =
certificates MUST NOT be present but objects relating to the revocation =
status of the certificates MAY be present. &nbsp;This uses the =
degenerate form of the SignedData structure (RFC 5652 Section 5.2) as is =
commonly used to disseminate X.509 certificates and revocation =
objects.<br class=3D""><br class=3D""><br class=3D"">X.3 This module =
contains YANG grouping related to keys and certificates. The groupings =
for keys all contain NACM (Network Configuration Access Control Model), =
RFC 8341, default deny for the key leaf itself. &nbsp;The groupings for =
end entity certificates and for trust anchors contain a YANG =
notification that the certificate is, or is about to, expire and also =
contain a NACM default deny. <br class=3D""><br =
class=3D"">symmetric-key-grouping contains a leaf whose type is derived =
from 'symmetric-key-format'. &nbsp;The format of the key is a YANG =
'choice' of 'binary' or 'empty'; the latter is for use with a hidden =
key.<br class=3D""><br class=3D"">public-key-grouping contains a leaf =
which is the public key in 'binary' and whose format is derived from the =
type 'public-key-format'.<br class=3D""><br =
class=3D"">asymmetric-key-pair-grouping uses the public-key-grouping and =
contains a leaf &nbsp;for the private key format whose type is derived =
from the type private-key-format and for the key itself whose type is =
binary or empty; the latter is for use with a hidden key. =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br class=3D""><br =
class=3D"">trust-anchor-cert-grouping contains a leaf of type =
'trust-anchor-cert-cms'<br class=3D""><br =
class=3D"">trust-anchor-certs-grouping contains a leaf list of type =
'trust-anchor-cert-cms'<br class=3D""><br =
class=3D"">end-entity-cert-grouping contains leaf of type =
'end-entity-cert-cms'<br class=3D""><br =
class=3D"">end-entity-certs-grouping contains a leaf list of type =
'end-entity-cert-cms'<br class=3D""><br class=3D"">generate-csr-grouping =
contains a YANG action to generate a signed CertificationRequest); the =
associated node MUST have a 'public-key-format' value of =
'subject-public-key-info-format'. 'input' to the action are the =
'subject' and 'atributes' fields of &nbsp;CertificationRequestInfo as =
specified in RFC 2986, Section 4.1, encoded in DER. 'output' of the =
action is a leaf of type 'csr' as described above.<br class=3D""><br =
class=3D"">asymmetric-key-pair-with-cert-grouping contains a =
private/public key pair and an associated certificate. The grouping =
uses; <br class=3D"">- asymmetric-key-pair-grouping<br class=3D"">- =
end-entity-cert-grouping<br class=3D"">- generate-csr-grouping<br =
class=3D"">as defined above.<br class=3D""><br =
class=3D"">asymmetric-key-pair-with-certs-grouping is similar to =
'asymmetric-key-pair-with-cert-grouping' but contains a list of end =
entity certificates for the public key where, for example, there are =
separate certificate for IDevID and LDevID [reference**]<br =
class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D<br class=3D""><br =
class=3D"">________________________________________<br class=3D"">From: =
netconf &lt;<a href=3D"mailto:netconf-bounces@ietf.org" =
class=3D"">netconf-bounces@ietf.org</a>&gt; on behalf of tom petch =
&lt;<a href=3D"mailto:ietfc@btconnect.com" =
class=3D"">ietfc@btconnect.com</a>&gt;<br class=3D"">Sent: 17 June 2020 =
17:23<br class=3D"">To: Kent Watsen<br class=3D"">Cc: Netconf<br =
class=3D"">Subject: Re: [netconf] WG LC for three drafts or two of =
them<br class=3D""><br class=3D"">From: netconf &lt;<a =
href=3D"mailto:netconf-bounces@ietf.org" =
class=3D"">netconf-bounces@ietf.org</a>&gt; on behalf of tom petch =
&lt;<a href=3D"mailto:ietfc@btconnect.com" =
class=3D"">ietfc@btconnect.com</a>&gt;<br class=3D"">Sent: 13 June 2020 =
12:29<br class=3D""><br class=3D"">&lt;tp&gt;<br class=3D"">I thought =
about the text I would like to see in crypto-types and starting with =
identity since they are simplest I came up with<br class=3D"">NEW<br =
class=3D"">This module contains YANG identity for private keys, public =
keys and symmetric keys.<br class=3D""><br class=3D""><blockquote =
type=3D"cite" class=3D"">=46rom the base "private-key-format" there are =
derived identity for<br class=3D""></blockquote>- rsa-private-key-format =
as defined in RFC 3447<br class=3D"">- ec-private-key-format as defined =
in RFC5915<br class=3D"">- one-asymmetric-key-format as defined in RFC =
5958,<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;encoded using =
ASN.1 distinguished encoding rules<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(DER), as =
specified in ITU-T X.690.";<br class=3D"">- =
encrypted-one-asymmetric-key-format, as defined in RFC 5958,<br =
class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;encoded using =
ASN.1 distinguished encoding rules (DER),<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;as specified in =
ITU-T X.690.";<br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">=46rom the base "public-key-format" there are derived =
identity for<br class=3D""></blockquote>- ssh-public-key-format as =
specified by RFC 4253, Section 6.6, i.e.:<br class=3D"">- =
subject-public-key-info-format as described in RFC 5280 encoded using =
ASN.1<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;distinguished =
encoding rules (DER), as specified in<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ITU-T X.690.";<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">=46rom =
the base "symmetric-key-format" there are derived identity for<br =
class=3D""></blockquote>- &nbsp;octet-string-key-format encoded as a raw =
octet string.<br class=3D"">- &nbsp;one-symmetric-key-format as defined =
in RFC 6031 and<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;encoded using =
ASN.1 distinguished encoding rules<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(DER), as =
specified in ITU-T X.690.<br class=3D"">- =
&nbsp;encrypted-one-symmetric-key-format as defined<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in RFC 6031 and =
encoded using ASN.1 distinguished<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;encoding rules =
(DER), as specified in ITU-T X.690.";<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Specific=
ation of Basic Encoding Rules (BER),<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Canonica=
l Encoding Rules (CER) and Distinguished<br class=3D""> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Encoding=
 Rules (DER)<br class=3D""><br class=3D"">Obviously all I have done is =
take the text and reformatted it. I debated about keeping the references =
to CMS. &nbsp;The aim is to tell the reader whether or not to dig deeper =
into the YANG in order to use it. &nbsp;For groupings I see more new =
text needed<br class=3D""><br class=3D"">Tom Petch<br class=3D""><br =
class=3D""><br class=3D""><br class=3D""><br class=3D""><br class=3D"">I =
have concerns about trust-anchors and crypto-types. &nbsp;They are both =
more or less non-existent when it comes to text. &nbsp;I do not want to =
have to reverse engineer the YANG or XML to find out what RPC or action =
there are, what types of cipher suites and such like are supported - and =
perhaps those that are not such as raw keys. &nbsp;I would expect there =
to be five or ten pages of such in each. &nbsp;Look for example at =
layer0-types or layer1-types for modules with what I would regard as =
adequate text.<br class=3D""><br class=3D"">Tom Petch<br class=3D""><br =
class=3D"">From: netconf &lt;<a href=3D"mailto:netconf-bounces@ietf.org" =
class=3D"">netconf-bounces@ietf.org</a>&gt; on behalf of Eric Voit =
(evoit) &lt;<a href=3D"mailto:evoit=3D40cisco.com@dmarc.ietf.org" =
class=3D"">evoit=3D40cisco.com@dmarc.ietf.org</a>&gt;<br class=3D"">Sent: =
12 June 2020 21:03<br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D""><blockquote type=3D"cite" class=3D"">-----Original =
Message-----<br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">From: netconf &lt;<a href=3D"mailto:netconf-bounces@ietf.org" =
class=3D"">netconf-bounces@ietf.org</a>&gt; On Behalf Of Mahesh<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">Jethanandani<br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">Sent: Tuesday, June 2, 2020 7:48 PM<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">To: =
Netconf &lt;<a href=3D"mailto:netconf@ietf.org" =
class=3D"">netconf@ietf.org</a>&gt;<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">Subject: =
[netconf] WG LC for three drafts<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">NETCONF =
WG,<br class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">The =
authors of<br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D""><br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">- draft-ietf-netconf-crypto-types<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">- =
draft-ietf-netconf-keystore<br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">- draft-ietf-netconf-trust-anchors<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">have =
indicated that these drafts are ready for Last Call (LC).<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">This kicks =
of a 2 week WG LC for the three drafts. Please review and<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">send<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D"">any<br class=3D""></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">comments to the WG mailing list or by responding to this =
e-mail.<br class=3D""></blockquote></blockquote><br class=3D""><blockquote=
 type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">Comments =
can be statements such as, I read/reviewed the document and<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">believe it =
is ready for publication, or I have concerns about the<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">document. =
For the<br class=3D""></blockquote></blockquote><br class=3D""><blockquote=
 type=3D"cite" class=3D"">latter,<br class=3D""></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">please indicate what your concerns are.<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">Any =
reports on implementation status or plans to implement are also<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">very =
useful.<br class=3D""></blockquote></blockquote><br class=3D""><blockquote=
 type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">Thanks.<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">Mahesh =
Jethanandani (as co-chair)<br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D""><a href=3D"mailto:mjethanandani@gmail.com" =
class=3D"">mjethanandani@gmail.com</a><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">_______________________________________________<br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">netconf =
mailing list<br class=3D""></blockquote></blockquote><br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D""><a href=3D"mailto:netconf@ietf.org" =
class=3D"">netconf@ietf.org</a><br =
class=3D""></blockquote></blockquote><br class=3D""><blockquote =
type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D""><a =
href=3D"https://www.ietf.org/mailman/listinfo/netconf" =
class=3D"">https://www.ietf.org/mailman/listinfo/netconf</a><br =
class=3D""></blockquote></blockquote><br =
class=3D"">_______________________________________________<br =
class=3D"">netconf mailing list<br class=3D""><a =
href=3D"mailto:netconf@ietf.org" class=3D"">netconf@ietf.org</a><br =
class=3D"">https://www.ietf.org/mailman/listinfo/netconf<br class=3D""><br=
 class=3D"">_______________________________________________<br =
class=3D"">netconf mailing list<br class=3D"">netconf@ietf.org<br =
class=3D"">https://www.ietf.org/mailman/listinfo/netconf<br =
class=3D""></div></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_8C11C88A-7A1E-4A6C-AEF6-1DCDE8A053E3--


From nobody Thu Jun 18 08:34:59 2020
Return-Path: <ietfc@btconnect.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277EE3A0D41 for <netconf@ietfa.amsl.com>; Thu, 18 Jun 2020 08:34:56 -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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 bKOSBqpKJOBo for <netconf@ietfa.amsl.com>; Thu, 18 Jun 2020 08:34:53 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2122.outbound.protection.outlook.com [40.107.21.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9803A099A for <netconf@ietf.org>; Thu, 18 Jun 2020 08:34:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PVm4dsgMoZQgiapGLeILYUX9XMr+7mKmkMTWIO+KGn0iOhcVZt/Y3FthwQJj5x6QeKtZ+ZBe3KMBZUELosg271T0QGTUtBvIL60qHt8CtpWea8r2992MxbBiMGkh5lrEHzCV24kEcwtvdeyUgX9d3LxJC48VQPTldQnMchKp153HjkT/3ix4llCnQfa7nvrUcKNwaP/kX7WyO75HDRhaomdslB3BmKHa9/8aI3MjVttK8zKSotkxV569bP7a4miIGAc7yRi8oDlEn9UQuHiMILbaydvzTnDpWKqWqXacI0uaD7umsq9JcqvBfmH8+cDAijuBCLMllFBch0zyMw/xww==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gZGF6fBjZMte8tAlOiOWoXR340fNn7U3eatL4+69Q3Y=; b=UtCq+9YIqsBUujpyNsLojl8rJaf1QEpij981hXAU0A+X/ZyXCOIxQVb0xNOGep1MUCGs9rP1239jBslI0VhSTPmCY5Y0ZCCqZVHU6mdapCwHHhhTuR5u2Y4aB+cbOz4nqK8+KtgN9V2ZGbOo0X2EIh6Igcr3gBFMjqh1xKCALFqxlD6cSlFPV7N7wDrGc7Oah5yM7caNazSZzbL2bMfGSPK5VXrb02eCfY65Re8GnRuohdKgxJfd+NQSWUrbiXCoBmyzPwCQl2VSyhGJnzRS0xRrTQQLbWxc+MWrSCu339tCh11usQN3kUDD6zDunPF53QxD8Q5VDJ6mc11QaHRdPQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gZGF6fBjZMte8tAlOiOWoXR340fNn7U3eatL4+69Q3Y=; b=ijBx/DedvVuFkXZdY9F9MUUnFbHmIw3fpgcMP9S0bClrEOUrNlcWpl7Aq6r/vqvQltlAYTP0RRUZplO5oG/v4AB5q6q7O/R0wpHRLWArlXZNmOb0vMOQIbrQLw5LpyjoI9o7aEBx6emfdNrr43We9Fhf0jcPV2xeDOShO37SPFE=
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com (2603:10a6:10:198::14) by DB7PR07MB5435.eurprd07.prod.outlook.com (2603:10a6:10:7f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.13; Thu, 18 Jun 2020 15:34:34 +0000
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65]) by DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::592c:285:6786:bc65%7]) with mapi id 15.20.3109.018; Thu, 18 Jun 2020 15:34:34 +0000
From: tom petch <ietfc@btconnect.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts or two of them
Thread-Index: AQHWQXXxqA+PBQ9xTESoskd/uJ8I1ajdArkBgAFEZsiAACJQgIAAHdc/
Date: Thu, 18 Jun 2020 15:34:34 +0000
Message-ID: <DBAPR07MB701633CE8D0C31D9766B1B03A09B0@DBAPR07MB7016.eurprd07.prod.outlook.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com> <DBAPR07MB7016F753766FCE8AD12A2F5DA09E0@DBAPR07MB7016.eurprd07.prod.outlook.com> <DBAPR07MB7016369E32D8534F7C967719A09A0@DBAPR07MB7016.eurprd07.prod.outlook.com> <DBAPR07MB7016633BBB363EC5C259DE0CA09B0@DBAPR07MB7016.eurprd07.prod.outlook.com>, <01000172c7a9cda8-3214ef17-890f-4f42-a9ab-b5b3730350a7-000000@email.amazonses.com>
In-Reply-To: <01000172c7a9cda8-3214ef17-890f-4f42-a9ab-b5b3730350a7-000000@email.amazonses.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.139.211.29]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3060260e-d979-4f54-fce0-08d8139d1a45
x-ms-traffictypediagnostic: DB7PR07MB5435:
x-microsoft-antispam-prvs: <DB7PR07MB5435EFCECD7E3F2AA96F3DD3A09B0@DB7PR07MB5435.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0438F90F17
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gsWtEbiAPSGFm8tYBzwQ35bb0/vPtGvV9A4wgDSDFsJmfnPSuSne6Vo96d7ZlDJ71TcnvyLnEmR/+pbUqX51XEpQfLEd3iW5ZUClcT27Wyxu7RddceFIT3JfJBHdXg9iokx7vCdCCTalGODr4WCzKwKpNU/NEN9BniR/kCEw9BmYopgWXeJgLvyiRpAlAxyfZhpsKfeZLk5pRL2XyoA63f8BF2J6Lu2gCQn0kW4KR3ZumVMdEa+9vMP0V/QJOu7pJ4i13oLfYeqYwjNbsufcRP84ZgZCAhJchOnc62D6xUIqTDf7678C+DYCPRQT9W2JvADblA9DmpI9dbpiYJ9lJoihKO48tidzjC0Ee7JzQDfFq9eXHLwdhzpeb4NAlp284Vkw+gkmvVcJpC4SK3HV4w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DBAPR07MB7016.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(396003)(376002)(136003)(39860400002)(366004)(346002)(91956017)(7696005)(76116006)(26005)(5660300002)(66556008)(64756008)(33656002)(8676002)(66946007)(30864003)(66476007)(52536014)(66446008)(8936002)(53546011)(6506007)(2906002)(83380400001)(478600001)(186003)(316002)(966005)(4326008)(86362001)(9686003)(55016002)(71200400001); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: EmahPkGJITYh3NYDlDNjNJV2t7n5kvJXVbkZyLLcTFBSjKWmVu7+p/pTiAJtEkxkpFp/vnI5X7QrkIdhpeblQV23YWO0oJrLTtfbsdpMl4UbH7abzKUm41vahxS8iznXTv1zeweZF+uZytXLRAe8lExf6yBH4yxpZYQzaz2qjjIwY2r8+m8KiBSTkQhcFLoha/EPEonyFLb1ZrLDo0z/ZFw/x+QHny58d12FHY7bsYwSpblFcCMJgAi13Bw4uzEc3t/7J0gNN+m6eMKja/oy0LdijkYfAS7eBYvSxMIWreBC6pBmiiVYJ5zSOX8hGxigN9RC058e6qcCFh0ZWBSuULR67y+StEpz9ZUJD9ExVLwsyAqCY6yo1QVmDLev0DdxpP8xXhaRJ1ERy3ZXvsUpmkWADb6FuUWgE541Qe0grEQlL/9CKu3t5GwY3nMe92JzfmXgvTWcx+83ufL5nTVwmH+lGqt7Q7xHOmzwhmjqtjM=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3060260e-d979-4f54-fce0-08d8139d1a45
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 15:34:34.2700 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rEUF3JlL7KksA1Av7xp36JG4XwddNjRnFeWsNmSwntVpPnq+cUzBtQNb/6CmMQnjnbcks5xkE/V+2yiqWZ/rxQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5435
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/qC3oGXwYmi8Twnwpa-h1Tn0ANMU>
Subject: Re: [netconf] WG LC for three drafts or two of them
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 15:34:58 -0000

From: Kent Watsen <kent+ietf@watsen.net>=0A=
Sent: 18 June 2020 14:41=0A=
=0A=
Hi Tom,=0A=
=0A=
Thank you!=0A=
=0A=
This text is a superset of the text sent yesterday, so I=92ll focus on cons=
uming this content instead.  Reading it, two thoughts arise:=0A=
=0A=
1) Much of this text should surround tree diagram snippets.   As Juergen im=
plied yesterday, a wall of tree diagram artwork alone doesn=92t make for a =
great =93overview=94.=0A=
=0A=
<tp>=0A=
I am unconvinced about surrounding tree snippets in this case.  I note that=
 Juergen said=0A=
'  - Is there any semantic difference between=0A=
     trust-anchor-cert-grouping and end-entity-cert-grouping, i.e., why=0A=
     do we need two groupings? Same question for=0A=
     trust-anchor-certs-grouping and end-entity-certs-grouping. If=0A=
     there is a semantic difference, perhaps this should be highlighted=0A=
     in the grouping description'=0A=
and if you are reverse engineering the YANG I think that that is a likely v=
iew.  What I did was put the text side by side. no intervening YANG or tree=
 diagram or ..., when I think that the semantic difference is clearer to th=
e reader.  It may then be a question as to whether or not we need both but =
I think that my formatting brings out the existing semantic difference whic=
h inserting anything YANG or YANG-like obscures.=0A=
=0A=
Tom Petch=0A=
=0A=
=0A=
=0A=
2) It is too bad that RFC 8340 doesn=92t define a way to represent identiti=
es, features, or typedefs (note that both identities and features can form =
trees too).  I=92ll likely devise my own format for the =93overview=94 sect=
ion, around which some of your text would go.=0A=
=0A=
PS: I have no IPR on this work either, it all goes to the IETF.=0A=
=0A=
Kent // contributor=0A=
=0A=
=0A=
On Jun 18, 2020, at 7:43 AM, tom petch <ietfc@btconnect.com<mailto:ietfc@bt=
connect.com>> wrote:=0A=
=0A=
I thought some more and here is the text that I would have liked to have re=
ad in crypto-types before diving into the YANG.  It is a tribute to the pai=
nstaking work of Kent that almost all I have done is cut and paste, removin=
g duplicate phrases.  The IPR is all Kent's.=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=0A=
=0A=
X This module contains YANG identity, typedef and grouping for use by YANG =
modules involved with security.=0A=
=0A=
X.1 This module contains YANG identity for private keys, public keys and sy=
mmetric keys.=0A=
=0A=
>From the base "private-key-format" there are derived identity for=0A=
- rsa-private-key-format for use with RSA as defined in RFC 3447=0A=
- ec-private-key-format for use with Elliptic Curve as defined in RFC5915 [=
**format]=0A=
- one-asymmetric-key-format as defined for use with CMS (Cryptographic Mess=
age Syntax) as defined RFC 5958, encoded using ASN.1 DER (Distinguished Enc=
oding Rules) as specified in ITU-T X.690.=0A=
- encrypted-one-asymmetric-key-format as defined for CMS use in RFC 5958, e=
ncoded using ASN.1 DER.=0A=
=0A=
>From the base "public-key-format" there are derived identity for=0A=
- ssh-public-key-format as defined for use with SSH as specified by RFC 425=
3, Section 6.6.=0A=
- subject-public-key-info-format as defined for use with X.509 in RFC 5280,=
 encoded using ASN.1 DER.=0A=
=0A=
>From the base "symmetric-key-format" there are derived identity for=0A=
- octet-string-key-format encoded as a raw octet string.=0A=
- one-symmetric-key-format as defined for use with CMS in RFC 6031 and=0A=
         encoded using ASN.1 DER=0A=
- encrypted-one-symmetric-key-format as defined for use with CMS=0A=
         in RFC 6031 and encoded using ASN.1 DER=0A=
=0A=
=0A=
X.2 This module contains typedef for X.509 certificate, CMS structures and =
trust anchors.=0A=
=0A=
'csr' is derived from 'binary' and is for use with a CertificationRequest  =
        as specified in PKCS#10, RFC 2986, encoded in DER.  No other types =
are derived from this base.=0A=
=0A=
'x509' (without the period) is derived from 'binary' and for use for a X.50=
9 Certificate (RFC5280), encoded in DER.  From 'x509' are derived=0A=
- trust-anchor-cert-x509 a X.509 self-signed certificate (RFC5280)=0A=
- end-entity-cert-x509 a X.509 certificate for end entities, i.e. a certifi=
cate that is neither self-signed nor having the 'cA' bit in the basic const=
raints extension set to true (RFC 5280 Section 4.2.10)=0A=
=0A=
'crl' is derived from 'binary' and is for use for a X.509 'CertificateList'=
 structure, as specified in RFC 5280, encoded in DER.  No other types are d=
erived from this base.=0A=
=0A=
'cms' is derived from 'binary' and for use for a CMS ContentInfo structure =
encoded in DER (RFC5652 Section 2).  From 'cms' are derived=0A=
- data-content-cms=0A=
          a CMS structure whose top-most content type MUST be=0A=
          the 'data content type' (RFC 5652 Section 4)=0A=
- signed-data-cms - a structure whose top-most content type MUST be the=0A=
         'signed-data content type' (Section 5 RFC 5652)=0A=
- enveloped-data-cms=0A=
        "A CMS structure whose top-most content type MUST be the=0A=
         'enveloped-data content type' (Section 6 RFC 5652)=0A=
- digested-data-cms {=0A=
        "A CMS structure whose top-most content type MUST be the=0A=
         'digested-data content type' (Section 7 RFC 5652)=0A=
- encrypted-data-cms {=0A=
        "A CMS structure whose top-most content type MUST be the=0A=
         'encrypted-data content type' (Section 8 RFC 5652)=0A=
- authenticated-data-cms {=0A=
         "A CMS structure whose top-most content type MUST be the=0A=
         'authenticated-data content type' (Section 9 RFC 5652)=0A=
=0A=
>From 'signed-data-cms' are derived=0A=
- trust-anchor-cert-cms is a CMS SignedData structure that contains a singl=
e chain of X.509 (RFC 5280) certificates which authenticate the certificate=
 presented by a client or end-entity.  The chain must include a root certif=
icate; this may be the only certificate present when that is also the certi=
ficate for the client or end-entity. Objects relating to the revocation sta=
tus of the certificates MAY be present.  This uses the degenerate form of t=
he SignedData structure (RFC 5652 Section 5.2) as is commonly used to disse=
minate X.509 certificates and revocation objects.=0A=
=0A=
-  end-entity-cert-cms is a CMS SignedData structure that contains the end =
entity certificate itself and MAY contain any number of intermediate certif=
icates leading up to a trust anchor certificate which MAY be included as we=
ll.  This differs from 'trust-anchor-cert-cms' in that the root certificate=
 and intermediate certificates, if any, are optional.  Other certificates M=
UST NOT be present but objects relating to the revocation status of the cer=
tificates MAY be present.  This uses the degenerate form of the SignedData =
structure (RFC 5652 Section 5.2) as is commonly used to disseminate X.509 c=
ertificates and revocation objects.=0A=
=0A=
=0A=
X.3 This module contains YANG grouping related to keys and certificates. Th=
e groupings for keys all contain NACM (Network Configuration Access Control=
 Model), RFC 8341, default deny for the key leaf itself.  The groupings for=
 end entity certificates and for trust anchors contain a YANG notification =
that the certificate is, or is about to, expire and also contain a NACM def=
ault deny.=0A=
=0A=
symmetric-key-grouping contains a leaf whose type is derived from 'symmetri=
c-key-format'.  The format of the key is a YANG 'choice' of 'binary' or 'em=
pty'; the latter is for use with a hidden key.=0A=
=0A=
public-key-grouping contains a leaf which is the public key in 'binary' and=
 whose format is derived from the type 'public-key-format'.=0A=
=0A=
asymmetric-key-pair-grouping uses the public-key-grouping and contains a le=
af  for the private key format whose type is derived from the type private-=
key-format and for the key itself whose type is binary or empty; the latter=
 is for use with a hidden key.=0A=
=0A=
trust-anchor-cert-grouping contains a leaf of type 'trust-anchor-cert-cms'=
=0A=
=0A=
trust-anchor-certs-grouping contains a leaf list of type 'trust-anchor-cert=
-cms'=0A=
=0A=
end-entity-cert-grouping contains leaf of type 'end-entity-cert-cms'=0A=
=0A=
end-entity-certs-grouping contains a leaf list of type 'end-entity-cert-cms=
'=0A=
=0A=
generate-csr-grouping contains a YANG action to generate a signed Certifica=
tionRequest); the associated node MUST have a 'public-key-format' value of =
'subject-public-key-info-format'. 'input' to the action are the 'subject' a=
nd 'atributes' fields of  CertificationRequestInfo as specified in RFC 2986=
, Section 4.1, encoded in DER. 'output' of the action is a leaf of type 'cs=
r' as described above.=0A=
=0A=
asymmetric-key-pair-with-cert-grouping contains a private/public key pair a=
nd an associated certificate. The grouping uses;=0A=
- asymmetric-key-pair-grouping=0A=
- end-entity-cert-grouping=0A=
- generate-csr-grouping=0A=
as defined above.=0A=
=0A=
asymmetric-key-pair-with-certs-grouping is similar to 'asymmetric-key-pair-=
with-cert-grouping' but contains a list of end entity certificates for the =
public key where, for example, there are separate certificate for IDevID an=
d LDevID [reference**]=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=0A=
=0A=
________________________________________=0A=
From: netconf <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> o=
n behalf of tom petch <ietfc@btconnect.com<mailto:ietfc@btconnect.com>>=0A=
Sent: 17 June 2020 17:23=0A=
To: Kent Watsen=0A=
Cc: Netconf=0A=
Subject: Re: [netconf] WG LC for three drafts or two of them=0A=
=0A=
From: netconf <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> o=
n behalf of tom petch <ietfc@btconnect.com<mailto:ietfc@btconnect.com>>=0A=
Sent: 13 June 2020 12:29=0A=
=0A=
<tp>=0A=
I thought about the text I would like to see in crypto-types and starting w=
ith identity since they are simplest I came up with=0A=
NEW=0A=
This module contains YANG identity for private keys, public keys and symmet=
ric keys.=0A=
=0A=
>From the base "private-key-format" there are derived identity for=0A=
- rsa-private-key-format as defined in RFC 3447=0A=
- ec-private-key-format as defined in RFC5915=0A=
- one-asymmetric-key-format as defined in RFC 5958,=0A=
         encoded using ASN.1 distinguished encoding rules=0A=
         (DER), as specified in ITU-T X.690.";=0A=
- encrypted-one-asymmetric-key-format, as defined in RFC 5958,=0A=
         encoded using ASN.1 distinguished encoding rules (DER),=0A=
         as specified in ITU-T X.690.";=0A=
=0A=
>From the base "public-key-format" there are derived identity for=0A=
- ssh-public-key-format as specified by RFC 4253, Section 6.6, i.e.:=0A=
- subject-public-key-info-format as described in RFC 5280 encoded using ASN=
.1=0A=
         distinguished encoding rules (DER), as specified in=0A=
         ITU-T X.690.";=0A=
=0A=
>From the base "symmetric-key-format" there are derived identity for=0A=
-  octet-string-key-format encoded as a raw octet string.=0A=
-  one-symmetric-key-format as defined in RFC 6031 and=0A=
         encoded using ASN.1 distinguished encoding rules=0A=
         (DER), as specified in ITU-T X.690.=0A=
-  encrypted-one-symmetric-key-format as defined=0A=
         in RFC 6031 and encoded using ASN.1 distinguished=0A=
         encoding rules (DER), as specified in ITU-T X.690.";=0A=
           Specification of Basic Encoding Rules (BER),=0A=
           Canonical Encoding Rules (CER) and Distinguished=0A=
           Encoding Rules (DER)=0A=
=0A=
Obviously all I have done is take the text and reformatted it. I debated ab=
out keeping the references to CMS.  The aim is to tell the reader whether o=
r not to dig deeper into the YANG in order to use it.  For groupings I see =
more new text needed=0A=
=0A=
Tom Petch=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
I have concerns about trust-anchors and crypto-types.  They are both more o=
r less non-existent when it comes to text.  I do not want to have to revers=
e engineer the YANG or XML to find out what RPC or action there are, what t=
ypes of cipher suites and such like are supported - and perhaps those that =
are not such as raw keys.  I would expect there to be five or ten pages of =
such in each.  Look for example at layer0-types or layer1-types for modules=
 with what I would regard as adequate text.=0A=
=0A=
Tom Petch=0A=
=0A=
From: netconf <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> o=
n behalf of Eric Voit (evoit) <evoit=3D40cisco.com@dmarc.ietf.org<mailto:ev=
oit=3D40cisco.com@dmarc.ietf.org>>=0A=
Sent: 12 June 2020 21:03=0A=
=0A=
-----Original Message-----=0A=
=0A=
From: netconf <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> O=
n Behalf Of Mahesh=0A=
=0A=
Jethanandani=0A=
=0A=
Sent: Tuesday, June 2, 2020 7:48 PM=0A=
=0A=
To: Netconf <netconf@ietf.org<mailto:netconf@ietf.org>>=0A=
=0A=
Subject: [netconf] WG LC for three drafts=0A=
=0A=
=0A=
=0A=
NETCONF WG,=0A=
=0A=
=0A=
=0A=
The authors of=0A=
=0A=
=0A=
=0A=
- draft-ietf-netconf-crypto-types=0A=
=0A=
- draft-ietf-netconf-keystore=0A=
=0A=
- draft-ietf-netconf-trust-anchors=0A=
=0A=
=0A=
=0A=
have indicated that these drafts are ready for Last Call (LC).=0A=
=0A=
=0A=
=0A=
This kicks of a 2 week WG LC for the three drafts. Please review and=0A=
=0A=
send=0A=
=0A=
any=0A=
=0A=
comments to the WG mailing list or by responding to this e-mail.=0A=
=0A=
Comments can be statements such as, I read/reviewed the document and=0A=
=0A=
believe it is ready for publication, or I have concerns about the=0A=
=0A=
document. For the=0A=
=0A=
latter,=0A=
=0A=
please indicate what your concerns are.=0A=
=0A=
=0A=
=0A=
Any reports on implementation status or plans to implement are also=0A=
=0A=
very useful.=0A=
=0A=
=0A=
=0A=
Thanks.=0A=
=0A=
=0A=
=0A=
Mahesh Jethanandani (as co-chair)=0A=
=0A=
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
_______________________________________________=0A=
=0A=
netconf mailing list=0A=
=0A=
netconf@ietf.org<mailto:netconf@ietf.org>=0A=
=0A=
https://www.ietf.org/mailman/listinfo/netconf=0A=
=0A=
_______________________________________________=0A=
netconf mailing list=0A=
netconf@ietf.org<mailto:netconf@ietf.org>=0A=
https://www.ietf.org/mailman/listinfo/netconf=0A=
=0A=
_______________________________________________=0A=
netconf mailing list=0A=
netconf@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netconf=0A=
=0A=


From nobody Fri Jun 19 09:03:19 2020
Return-Path: <session-request@ietf.org>
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7543A00D6; Fri, 19 Jun 2020 09:03:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool <session-request@ietf.org>
To: <session-request@ietf.org>
Cc: lflynn@amsl.com, rwilton@cisco.com, netconf-chairs@ietf.org, netconf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159258259743.19361.17853930524570917829@ietfa.amsl.com>
Date: Fri, 19 Jun 2020 09:03:17 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/PmbBSQLD64wg10wHSZDT-ygYYgc>
Subject: [netconf] netconf - Update to a Meeting Session Request for IETF 108
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2020 16:03:18 -0000

An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the netconf working group.


---------------------------------------------------------
Working Group Name: Network Configuration
Area Name: Operations and Management Area
Session Requester: Liz Flynn


Number of Sessions: 1
Length of Session(s):  100 Minutes
Number of Attendees: 65
Conflicts to Avoid: 
 Chair Conflict: netmod httpbis tcpm idr
 Technology Overlap: opsarea opsawg
 Key Participant Conflict: anima rats





People who must be present:
  Mahesh Jethanandani
  Kent Watsen
  Robert Wilton

Resources Requested:

Special Requests:
  Chair is not available on Friday
---------------------------------------------------------



From nobody Mon Jun 22 14:39:47 2020
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CCC3A11DB for <netconf@ietfa.amsl.com>; Mon, 22 Jun 2020 14:39:45 -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, 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 1CZA9rPB6J3t for <netconf@ietfa.amsl.com>; Mon, 22 Jun 2020 14:39:42 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CFC3A11DD for <netconf@ietf.org>; Mon, 22 Jun 2020 14:39:42 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 3649DF4078C; Mon, 22 Jun 2020 14:39:32 -0700 (PDT)
To: evoit@cisco.com, ludwig@clemm.org, alberto.gonzalez@microsoft.com, einarnn@cisco.com, ambtripa@cisco.com, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: kent+ietf@watsen.net, netconf@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20200622213932.3649DF4078C@rfc-editor.org>
Date: Mon, 22 Jun 2020 14:39:32 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ltGSulbtw2skRSngMtJf-hx_H0s>
Subject: [netconf] [Technical Errata Reported] RFC8639 (6211)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2020 21:39:45 -0000

The following errata report has been submitted for RFC8639,
"Subscription to YANG Notifications".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6211

--------------------------------------
Type: Technical
Reported by: kent watsen <kent+ietf@watsen.net>

Section: 7

Original Text
-------------
   A specification for a transport MUST identify any encodings that are
   supported.  If a configured subscription's transport allows different
   encodings, the specification MUST identify the default encoding.


Corrected Text
--------------
   A specification for a transport MUST identify any encodings that are
   supported.  If a configured subscription's transport allows different
   encodings, the specification MUST identify the default encoding, or
   provide a mechanism whereby supported encodings can be discovered.


Notes
-----
https://mailarchive.ietf.org/arch/msg/netconf/XBpoFqtRynfc0zaRggMEiEMBW2M/

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8639 (draft-ietf-netconf-subscribed-notifications-26)
--------------------------------------
Title               : Subscription to YANG Notifications
Publication Date    : September 2019
Author(s)           : E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy
Category            : PROPOSED STANDARD
Source              : Network Configuration
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Tue Jun 23 08:51:54 2020
Return-Path: <ietfc@btconnect.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28D83A0D9B for <netconf@ietfa.amsl.com>; Tue, 23 Jun 2020 08:51:51 -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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 K1RRIFOMBeOF for <netconf@ietfa.amsl.com>; Tue, 23 Jun 2020 08:51:50 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2091.outbound.protection.outlook.com [40.107.21.91]) (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 ACDF83A0D9C for <netconf@ietf.org>; Tue, 23 Jun 2020 08:51:49 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JX2+aLkmAqzFC8hJVHW7EKv0/sz0RMK3uHqqh3TbnRyuz44YI0t09nHuzkOuZ4ai99ztE63l5hmQi0pM/ICVM3eECUviqNdKdf6M2BMShxBlZuYEppjTX7c29XFpLfFKCzdVY3RxPTPfKP+FQfolOQ/gTzlSkOFWkw31zQZr+F4BP7SnJScoJznl5eAmhHBpMcir0rTBU2WUsUHasH5EhYI88nUcddJ/Jy14u3QhovPeLo5WmsX9jtwgFRITyH7pQZo1uh/kS6k1rUm6ALzwFng6YfI/ufjv3VQwHGO3pdM/ETyJUyru1aNNhbhwNqfaeqipQhgdRCHkHRmnLj7Tbg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aemxObu/8DHo3uh6+InT8FfTLBUHRQki8Q0LfV89StY=; b=jYHF/hL93qpvBsb/CBKMH3fMI5RmRAEgzy5KB7os52rEgQIzlKQkt1Il6QtDr8Ih4+v7uKbPwZVzk3p55B5f68grkolqFjFgg06EjCkBAldzM+emCklOzTLCITz4I7RVy4mEZdavRp4n/NMmUnpiqr30vGAFOb1NEWT3DH9+reWwXsuYgjaxCzBlsRO4UW2vAbJ+VvSbIHrdwnsgcttnQS5DcAzRay25hSXhuPvvzj76k4ej9zp3zrisUSJOPMd8TMkkl2Tdmo2ahM2Hju4CcOvrpYXHIvTTdSMGI4JTR/ik+wlH8a6/sDanZu0SODmxDwuwSCc45785qmQSbgyQGw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aemxObu/8DHo3uh6+InT8FfTLBUHRQki8Q0LfV89StY=; b=wSQN3XYHTsxEXsWGF+5OQTWnyMobmj2stZaxHx4bl6O7c994o5dV3lhRzZyoAMXNGv6Dr7nTvdR5+JR8n5LNoPNJ+fYOTkZv7jK2ipf6UFO61zg8kOhjqm1qe+TOD1K68jnLghuneLb7FzZvBEsR+BZ261F2jcquvLHR69lKLNY=
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com (2603:10a6:10:198::14) by DB7PR07MB6122.eurprd07.prod.outlook.com (2603:10a6:10:85::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.13; Tue, 23 Jun 2020 15:51:47 +0000
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::b09b:5a3b:9735:bf26]) by DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::b09b:5a3b:9735:bf26%5]) with mapi id 15.20.3131.016; Tue, 23 Jun 2020 15:51:47 +0000
From: tom petch <ietfc@btconnect.com>
To: "Salz, Rich" <rsalz@akamai.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Mahesh Jethanandani <mjethanandani@gmail.com>
CC: Netconf <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts
Thread-Index: AQHWOThMOtlQSxaDHEC0TmDma2BnbqjcuJ8AgABEwwCAASchS4AASf4AgAgKz7k=
Date: Tue, 23 Jun 2020 15:51:47 +0000
Message-ID: <DBAPR07MB70168354EBA4459C5D4500C4A0940@DBAPR07MB7016.eurprd07.prod.outlook.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de> <14453F87-3F9D-40AA-A4E5-DAD7D66B480C@akamai.com> <DBAPR07MB7016CEC8A92F3AF1D3EB4450A09B0@DBAPR07MB7016.eurprd07.prod.outlook.com>, <768CC0BC-D11E-4F2D-A950-4E7FB1750CEE@akamai.com>
In-Reply-To: <768CC0BC-D11E-4F2D-A950-4E7FB1750CEE@akamai.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.128.101.145]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d2c8f27c-0fb4-4138-ede9-08d8178d5600
x-ms-traffictypediagnostic: DB7PR07MB6122:
x-microsoft-antispam-prvs: <DB7PR07MB612246A535CAA6F2DF3BB9BCA0940@DB7PR07MB6122.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 04433051BF
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MI5/xjBTahavmPHKPMTSVjOrzfjdpRUkI1VYCIT3yeicaNk0blunWroRUwOUYMlpNm3rWGvMPoTxIyXXFo835jWAYiy9UGumHlsZNFn2AnEFh29dvNEH6gqCpkiO8Nims+pc/yp7CjUNcFFbx9GsYObe06W0ya31hoBeUrro3sPHEqpQ7Cy7ng1q1V9GVmZWy9o5nvXrFTeU8peE5dFYallMVzqxpIotY+qsIBzAJdRjJ70Fcr/CXO31vV0xB7VqmSA0wiqRhohWwNK7mWuXZy4psLaw+IBH9WBaCLN6W7AHZ4GcSW5POU0ccmZlCQEx
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:DBAPR07MB7016.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(39860400002)(136003)(376002)(396003)(366004)(346002)(7696005)(5660300002)(478600001)(4326008)(4744005)(316002)(66946007)(91956017)(55016002)(9686003)(76116006)(186003)(110136005)(66476007)(66556008)(64756008)(2906002)(66446008)(86362001)(33656002)(26005)(6506007)(8936002)(71200400001)(52536014)(8676002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: +bUJjIhF30w4jOeBqisB8ysvenZdpcv5ZH9RRn1pyvebqfwBjueUM9Y7pAm/PJVW5Dn39PmMWMF6gyIp6KjD9Z6uIOm2m6GQfVcsxKhd9qPRWortr4ow4hvlkFTFkyrPxYUmkL7x+4DVk66fMw+2MrpRxEYHKSSW7ujOVA5myajWrsrxC5rRwVhfDYXhKp4Ht68Ag3Znu9j4KTSvFmjY1ea515zD1F59xOatF/jCWbDtMbXyvT8ykuCcB6XYBg6PlYw7vWn01l2glaQkCYXtOy14TE+v7fvzpcaRvzZkUkbMm4hUCUvzpnSNccZ0QNFDvcXpsBv+3wRryv5R5uXzMlE5O9CCta6yAUaduJM29tsplfweDJ0tzagKmTtR+F1ouc8OmkmdDymkgvO29zTVHEvIV3PegzAgJb1UZVZ2crxpzgUn3OQROunnuWQM3n11idTttbI16Un3ff6AKPKm3Ln2Nk1K32qh8ubY0s/u7cPnli6uq5iHwtFnBsdU3hiw
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DBAPR07MB7016.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d2c8f27c-0fb4-4138-ede9-08d8178d5600
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 15:51:47.2708 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: z+8aEWb2veCsEh34vjbtODmdWCkxyZ3NockjnGdroYLTfYPlLQ8JrR+2TgO6wtagTF48IioA4G5EOCq2XsyISw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6122
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/2VrAEK-9iVZ2VSN_XyCEZK1YiuE>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2020 15:51:52 -0000

From: Salz, Rich <rsalz@akamai.com>=0A=
Sent: 18 June 2020 14:00=0A=
=0A=
ITU is working on X509v4, but that isn't going to be smaller than X509v3 an=
d not clear to me useful for IoT.=0A=
=0A=
Rich=0A=
IEEE1609.2 is what I had in mind since it got quite a bit of attention on t=
he TLS WG list in August 2018.  I don't know how widely it is used.=0A=
=0A=
Tom Petch=0A=


From nobody Tue Jun 23 11:21:22 2020
Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2993A08EB for <netconf@ietfa.amsl.com>; Tue, 23 Jun 2020 11:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level: 
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 header.b=a3xZdFfz; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=CNlG1v3x
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ydiPDt1YwKz for <netconf@ietfa.amsl.com>; Tue, 23 Jun 2020 11:21:18 -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 2BF1D3A08EA for <netconf@ietf.org>; Tue, 23 Jun 2020 11:21:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30903; q=dns/txt; s=iport; t=1592936478; x=1594146078; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=n8wzJ2p3lzpFm7HmwqfBrKWH9nj7C0Ts/n69BrxNvIw=; b=a3xZdFfzC/eEmgYFsQ85+WQy2HhWLwwVBdrBA5lCYr9j6aNbZVMsprzJ 7MOhddDe6lpg5FoTDX+jyas2kYHud/EyLGOE7pleknl+V5VGasMLWqp8+ cFG5U/BTWcLaC2l+aZ4I/9zzOKwif2NDlY/pycchiRrMG7fH7BCtqRv2m c=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3AVbOcABzzRBXg0aTXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWBt+pkkETEW8Pd5u4Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoLkFJA8v4IVvfvi764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DIAAAER/Je/4ENJK1dCRoBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAYIKgSMvKSgHbystLywKhBqDRgONRooAiV+?= =?us-ascii?q?CEIJmgUKBEANVBAcBAQEJAwEBGAEOBgIEAQGEAkUCghMCJDgTAgMBAQsBAQU?= =?us-ascii?q?BAQECAQYEbYVbDIVyAQEBAQIBAQEQEQoTAQEsCwEEBwQCAQgRBAEBIQcDAgI?= =?us-ascii?q?CHwYLFAkIAgQOBQgGDQeDBTiBRk0DDhEPAQ6saQKBOYhhdoEygwEBAQWBMgE?= =?us-ascii?q?DAw0+AgGDCg0LggcHAwaBOIFTgRSEV4NigUMagUE/gRFDgk0+gXkhQgEBAgE?= =?us-ascii?q?BFYEaEgIaFRYJgl4zgi2PK5Q5MI9QL00KglqEKYJUgUaCYYkchQuCcYkkhRy?= =?us-ascii?q?CXohRghubR4JYkVsCBAIEBQIOAQEFgWoigUAPB3AVO4JpUBcCDY4eCwEXgQI?= =?us-ascii?q?BAYJKhRSFQnQCCQkjAgYBBwEBAwl8jk8BgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.75,272,1589241600";  d="p7s'?scan'208,217";a="516333995"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jun 2020 18:21:17 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 05NILGM8001905 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Jun 2020 18:21:16 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 23 Jun 2020 13:21:16 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 23 Jun 2020 14:21:15 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 23 Jun 2020 13:21:15 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DJr96MZBTkUvGKj1v9nEVZO+zSN6Fdjufd9qI71AG7TPweTL9riVZqdqsYRo3tAiRzRUh24R0tebYriIuUjdFsu5WKrE7vwfNBxXd2cMf9Ogm/M8HfOyWKc0YCrHdOJnVcYxIGfvJG8S/YAR+dFdbhCFrse9NC6To/iWX0RzhKJVCq7EBuP+X3rZblh1PWuzTyi670BS8Khvv6EBJWw6zrwaL2Pgwu0uNNQwOn9iMjSw6vBg1AVODxWFC2yidAjV6pVmD5e0SjCRAUHVDgsQXU6TP5bJ8s4ZnQiiUJ80kO7yvHiTuY6nwfSNBdfWmX29c7InE2Re3Y8Aj2DEjUUPOg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CHqxOaTGAL0ShfdPzwAO0sH6nt5047NSrEqlP6I874k=; b=Qm69J/uWD8H59WlvFLUMJTZ9LmP0MhkbjsjsSA2+RuvHwTTzDisCLADFsAkjZLKCarFeIjvQzZVDg2igoDNOFyVugs2TlFgpJ5tacBsoZQ9ySwoetiW5UzuQWDud1V8T01NOMkXnOjUdOFd2EEwO4EUGHE5r8z0lndY1+KPOaikg5CXIVx7h8FXQ1txciL1R4SU3yfI1Sjq0/L8A51VrGsBiGFK2k3hivj6mzssqO1ezuzZeeOh5TapoSyKGKzwO0YcvxUCiFoppwOQBLuKt1fr571AnjW+Wdf8ks3WiRq8sh8e5YM7F6gc65kuJjZyKXsAV+PsJCcVlYtKEoc3mOg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CHqxOaTGAL0ShfdPzwAO0sH6nt5047NSrEqlP6I874k=; b=CNlG1v3x9pQ0lTJ+Bt8IGnPAfNr4yWwhiEK6f5eMTuPMMtmWNBCEFRNvH/KU77F+J0NOuUi0lnCYWRFhOAY91FXBksUdCiPn2OwjQNaYcHdx0zLiOFjBp1109ZNncYvXNE1GRlPDwlLHodnEizfNn2OSZM4xGW/yS9HG1kXyra4=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4367.namprd11.prod.outlook.com (2603:10b6:208:18b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Tue, 23 Jun 2020 18:21:14 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290%7]) with mapi id 15.20.3109.027; Tue, 23 Jun 2020 18:21:14 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts
Thread-Index: AQHWOThTTo+30icCv0mQD3Parb0A+ajVR//QgAApLlCABGC6AIAMy4Aw
Date: Tue, 23 Jun 2020 18:21:14 +0000
Message-ID: <BL0PR11MB3122DEA645C8EA03E881ADEAA1940@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <BL0PR11MB3122ABE4CF14BAF3805DFF2FA1810@BL0PR11MB3122.namprd11.prod.outlook.com> <BL0PR11MB3122B9D49C37501D64E762C6A1810@BL0PR11MB3122.namprd11.prod.outlook.com> <01000172b867d075-422297fc-0982-4464-91f3-edd5c9bce6fb-000000@email.amazonses.com>
In-Reply-To: <01000172b867d075-422297fc-0982-4464-91f3-edd5c9bce6fb-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0f74abdc-0860-43b1-c80c-08d817a236c7
x-ms-traffictypediagnostic: MN2PR11MB4367:
x-microsoft-antispam-prvs: <MN2PR11MB4367D915BF4B37EAEB599885A1940@MN2PR11MB4367.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04433051BF
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0MZVPSTb8yuB3rSMNBshqRkdpZt4nIz0KQqb4pGUJireddt51h0oThrPlXLb63/qkvh9lQ0np506uyZ2Ofwy/qHvqDmiF5qZ8BgudSits3AnQOinvusHFraz1sqXCNcRlHo4wq0dOF8r8M8RgAjwDWOUV935qukP1j4HXKg8mq6oyQVzMH1doZqv6os8hydLvrHGnM0X3/B/82mHVCNFG7Twctu7Rv9m0+yp1B7R9Mgca5dMNOLFrN4FbNT4Q4lE1mkYGShbYVQlgIUStBEoLcnpAjaHhuGqCc650rREEIsG6PRli2I09FXahed2HnaSVTC5G+TKxT6ERaC+aDXqmD+7WT0rLZCktcr4DO5h3vxf7fTC76V6KnP4pm340hnEWgQTtQWRKLtSmLsnzs1BQvLpfEvgWUBGLyw0n6mLyUXD9W7meo+JXlYi7TxGhGaau/PXbwLQRENmvyUifVcpPXKbx5gglrgQ50n9eWVakNU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(366004)(396003)(39860400002)(136003)(376002)(346002)(5660300002)(8936002)(99936003)(40265005)(2906002)(64756008)(66476007)(66556008)(66946007)(66616009)(4326008)(9686003)(8676002)(55016002)(83380400001)(478600001)(186003)(966005)(33656002)(86362001)(76116006)(7696005)(9326002)(52536014)(71200400001)(26005)(53546011)(316002)(6506007)(66446008)(166002)(15398625002)(43620500001); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: MCtOVFu+wP8g9jKIpYg1JU0Yi12lfMeXSxvnzrHk4Em7/54+3J4Sw4kYyjsSkF9VjEOANXrYpO3GW0FC0txelWvUh9KEzpDVqtygSSO8gacxLrL0Jwa36LeX6QF845yMb5dvXBntYXW2PzoKGVddD5UY8pT96Z5MQY3E1k1OLQhCW32+GogeYcXKoseA3CFXtb0j4hPiM0W3eM8ugeO15il4PRliZifMAu8myUyaIyyieBElkgmwVIwXUxz86SYmavZZZ6jxMUgLiSAFu6iQow+YtEa4BRkEJwtzbjR7/JIxT4jfdz5GqvLOddi6Xqg15LYcpmJZtmy7WCpJ5pAKJOJZ9FlkUPq/hEXO/AuoFVP1kJ67joTqB06OAVKI0y1fl1yjVRp6U1NbnMgPwjFwzBJGpkJDzmv+bXEuj6ESfC0VNneesxGmAHeX4gwt0R4R+SDjCgJ3RjSknlOa4lpGeDKV3Amnws02EqYkGtfjvqP4bLXDpZLJjRKs3I4f3M0o
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_023B_01D64969.8A9FF1E0"; micalg=SHA1
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f74abdc-0860-43b1-c80c-08d817a236c7
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 18:21:14.1719 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wxrUkACFi5oQWfEiCfOHK0FhtPy6ttn+PLOSrtj+7tGz0fnWSZYj8mbxDd4x7GTK
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4367
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/CErvRP1N5o2TuaD6pqS5Mwf-97k>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2020 18:21:21 -0000

------=_NextPart_000_023B_01D64969.8A9FF1E0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_023C_01D64969.8A9FF1E0"


------=_NextPart_001_023C_01D64969.8A9FF1E0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Kent,

=20

I am fine with extracting the Algorithm Types as you describe below. =20

=20

Still, there are people who need this info, such as the RATS WG.  =
Therefore as a starting point for the discussion in the RATS WG, I have =
created ietf-asymmetric-algs.yang =
<https://github.com/ietf-rats/draft-voit-rats-trusted-path-routing/blob/m=
aster/ietf-asymmetric-algs@2020-06-12.yang>  which (non-accidentally) is =
named similarly to your iana-asymmetic-algs.yang model that isn't =
progressing right now to WGLC.  ietf-asymmetric-algs.yang has an =
immediate need by ietf-tpm-remote-attestation.yang =
<https://github.com/ietf-rats/draft-voit-rats-trusted-path-routing/blob/m=
aster/ietf-tpm-remote-attestation@2020-06-23.yang> , and will part of =
the next version of draft-ietf-rats-yang-tpm-charra =
<https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/?includ=
e_text=3D1> .  It does follow what you suggest with the multiple base =
statements approach.

=20

If nobody wants to steward a merged TCG & IANA identity inheritance =
hierarchy of algorithm types, we will shrink the identities within =
ietf-asymmetric-algs.yang to just those relevant to TCG/TPMs.  But =
hopefully there will be someone willing to steward a merged TCG & IANA =
inheritance hierarchy.

=20

Eric

=20

From: Kent Watsen <kent+ietf@watsen.net>=20
Sent: Monday, June 15, 2020 10:35 AM
To: Eric Voit (evoit) <evoit@cisco.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] WG LC for three drafts

=20

Hi Eric,

=20

Thank you for your review.  This message addresses both your prior =
messages=E2=80=A6

=20

=20





On Jun 12, 2020, at 4:03 PM, Eric Voit (evoit) <evoit@cisco.com =
<mailto:evoit@cisco.com> > wrote:

=20

Hi Kent,

=20

I have been reading farther, and I see that the full =
iana-hash-algs@2020-03-08.yang <mailto:iana-hash-algs@2020-03-08.yang>  =
has been removed from -v15.  That is where the TCG identity algorithms =
might have been merged in my thread below.

=20

A few thought based on that:

=20

(1) In the draft-ietf-netconf-crypto-types, in the YANG model you should =
likely remove the description text which claims support for "algorithm" =
in three of the grouping statements.

=20

Good catch!  Fixed here:

=20

https://github.com/netconf-wg/crypto-types/commit/690c016b201241e13a1e324=
b49ba5e9db0d6c417

=20





 (2) Are there plans to evolve iana-hash-algo.yang anywhere?  In your =
May 14th message, you  say :  "Assuming a future effort mimicked Option =
#2, then "yes=E2=80=9D, as I=E2=80=99d expect an =
"ietf-ssh-common:generate-asymmetric-key=E2=80=9D RPC to contain an =
=E2=80=9Cinput=E2=80=9D node that is an identityref to the =
=E2=80=9Cssh-asymmetric-algorithm=E2=80=9D identity.".   I would be =
willing to help on that work.

=20

I have no plans to work on the "algorithms=E2=80=9D problem again.  Not =
that I wouldn=E2=80=99t like to, but I need to scale back how much =
unsupported time I volunteer for.  Generally speaking, I=E2=80=99m =
gracefully winding down my work in progress, while being hyper-cautious =
about signing up for new work.  This is why, e.g., I=E2=80=99m not =
pushing "YANG-next=E2=80=9D or =E2=80=9Crestconf-collections=E2=80=9D =
anymore, though both are really important to me.  That said, I=E2=80=99m =
open to contract-work, if that makes sense at all...

=20

More below.





=20

Thanks,

Eric

=20

=20

=20

> -----Original Message-----

> From: netconf <netconf-bounces@ietf.org =
<mailto:netconf-bounces@ietf.org> > On Behalf Of Eric Voit (evoit)

> Sent: Friday, June 12, 2020 1:42 PM

> To: Kent Watsen <kent+ietf@watsen.net <mailto:kent+ietf@watsen.net> >

> Cc: Netconf <netconf@ietf.org <mailto:netconf@ietf.org> >

> Subject: Re: [netconf] WG LC for three drafts

>=20

> Hi Kent,

>=20

> I have been reading draft-ietf-netconf-crypto-types, and the thread:

Virtual

> "hum" for the "key generation" issue discussed at virtual meeting.

>=20

> I have a couple questions on the previous "asymmetric-algorithm-type"  =
and

> what is now in "asymmetric-key-pair-grouping".  My reading is that =
instead

> of the previous ENUMs of -v14, other applications/WGs will now need to

> create identities for the various algorithm types.  And this is fine.

=20

=20

That was the idea at the time but, as you noticed, we since ditched the =
=E2=80=9Calgorithms=E2=80=9D node altogether  :sigh:

=20





> If I have this correct, then each of the TCGAlgorithm Registry ID =
values

of

> TPM2 specifications in Table 9

> https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-

> Part-2-

> Structures-01.38.pdf

> could have its own identity.   And there would be no barrier to each =
of

> these identities also having another base identity that might be =
"tpm2-

> algorithm".  In this correct?

=20

I believe so.  I haven=E2=80=99t looked at the TCG Algorithm Registry, =
but certainly, "identity-stmt=E2=80=9D allows multiple "base-stmt".   =
Some might be concerned for interoperability, but a solution might =
support polymorphic definitions.  Regardless, the original plan was (and =
I assume would be again, if/when the work is picked up) to enable the =
server to specify (e.g., via a =E2=80=9Cconfig false=E2=80=9D list) =
which algorithms it supports.

=20

=20

> If this is correct, my second question is whether there will be an =
attempt

to

> ask other YANG models to import these application identities =
elsewhere?

> As you and Rob note in the thread, trying to predict the desired =
identity

> inheritance hierarchy is non-trivial.

=20

I=E2=80=99m unsure about this, but I think polymorphism would go a long =
way to alleviate the issue...

=20

=20

Kent // as a contributor

=20





>=20

> Thanks,

> Eric

>=20

> > -----Original Message-----

> > From: netconf <netconf-bounces@ietf.org =
<mailto:netconf-bounces@ietf.org> > On Behalf Of Mahesh

> > Jethanandani

> > Sent: Tuesday, June 2, 2020 7:48 PM

> > To: Netconf <netconf@ietf.org <mailto:netconf@ietf.org> >

> > Subject: [netconf] WG LC for three drafts

> >

> > NETCONF WG,

> >

> > The authors of

> >

> > - draft-ietf-netconf-crypto-types

> > - draft-ietf-netconf-keystore

> > - draft-ietf-netconf-trust-anchors

> >

> > have indicated that these drafts are ready for Last Call (LC).

> >

> > This kicks of a 2 week WG LC for the three drafts. Please review and

> > send

> any

> > comments to the WG mailing list or by responding to this e-mail.

> > Comments can be statements such as, I read/reviewed the document and

> > believe it is ready for publication, or I have concerns about the

> > document. For the

> latter,

> > please indicate what your concerns are.

> >

> > Any reports on implementation status or plans to implement are also

> > very useful.

> >

> > Thanks.

> >

> > Mahesh Jethanandani (as co-chair)

> > mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>=20

> >

> >

> >

> > _______________________________________________

> > netconf mailing list

> > netconf@ietf.org <mailto:netconf@ietf.org>=20

> > https://www.ietf.org/mailman/listinfo/netconf

=20


------=_NextPart_001_023C_01D64969.8A9FF1E0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta =
name=3DGenerator content=3D"Microsoft Word 15 (filtered =
medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
	{mso-style-name:msonormal;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri",sans-serif;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US =
link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1><p =
class=3DMsoNormal>Hi Kent,<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>I am fine =
with extracting the Algorithm Types as you describe below. =
=C2=A0<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Still, there are people who need this info, such as =
the RATS WG. =C2=A0Therefore as a starting point for the discussion in =
the RATS WG, I have created <a =
href=3D"https://github.com/ietf-rats/draft-voit-rats-trusted-path-routing=
/blob/master/ietf-asymmetric-algs@2020-06-12.yang">ietf-asymmetric-algs.y=
ang</a> which (non-accidentally) is named similarly to your =
iana-asymmetic-algs.yang model that isn't progressing right now to =
WGLC.=C2=A0 ietf-asymmetric-algs.yang has an immediate need by <a =
href=3D"https://github.com/ietf-rats/draft-voit-rats-trusted-path-routing=
/blob/master/ietf-tpm-remote-attestation@2020-06-23.yang">ietf-tpm-remote=
-attestation.yang</a>, and will part of the next version of <a =
href=3D"https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/=
?include_text=3D1">draft-ietf-rats-yang-tpm-charra</a>.=C2=A0 It does =
follow what you suggest with the multiple base statements =
approach.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>If nobody wants to steward a merged TCG &amp; IANA =
identity inheritance hierarchy of algorithm types, we will shrink the =
identities within ietf-asymmetric-algs.yang to just those relevant to =
TCG/TPMs.=C2=A0 But hopefully there will be someone willing to steward a =
merged TCG &amp; IANA inheritance hierarchy.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Eric<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div =
style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'><div><div style=3D'border:none;border-top:solid #E1E1E1 =
1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b>From:</b> Kent =
Watsen &lt;kent+ietf@watsen.net&gt; <br><b>Sent:</b> Monday, June 15, =
2020 10:35 AM<br><b>To:</b> Eric Voit (evoit) =
&lt;evoit@cisco.com&gt;<br><b>Cc:</b> =
netconf@ietf.org<br><b>Subject:</b> Re: [netconf] WG LC for three =
drafts<o:p></o:p></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Hi =
Eric,<o:p></o:p></p><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Thank you for your review. &nbsp;This message =
addresses both your prior messages=E2=80=A6<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p =
class=3DMsoNormal><br><br><o:p></o:p></p><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><p =
class=3DMsoNormal>On Jun 12, 2020, at 4:03 PM, Eric Voit (evoit) &lt;<a =
href=3D"mailto:evoit@cisco.com">evoit@cisco.com</a>&gt; =
wrote:<o:p></o:p></p></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><div><p =
class=3DMsoPlainText>Hi Kent,<o:p></o:p></p><p =
class=3DMsoPlainText>&nbsp;<o:p></o:p></p><p class=3DMsoPlainText>I have =
been reading farther, and I see that the full <a =
href=3D"mailto:iana-hash-algs@2020-03-08.yang">iana-hash-algs@2020-03-08.=
yang</a> has been removed from -v15.&nbsp; That is where the TCG =
identity algorithms might have been merged in my thread =
below.<o:p></o:p></p><p class=3DMsoPlainText>&nbsp;<o:p></o:p></p><p =
class=3DMsoPlainText>A few thought based on that:<o:p></o:p></p><p =
class=3DMsoPlainText>&nbsp;<o:p></o:p></p><p class=3DMsoPlainText>(1) In =
the draft-ietf-netconf-crypto-types, in the YANG model you should likely =
remove the description text which claims support for =
&quot;algorithm&quot; in three of the grouping =
statements.<o:p></o:p></p></div></div></blockquote><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Good catch! &nbsp;Fixed =
here:<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><a =
href=3D"https://github.com/netconf-wg/crypto-types/commit/690c016b201241e=
13a1e324b49ba5e9db0d6c417">https://github.com/netconf-wg/crypto-types/com=
mit/690c016b201241e13a1e324b49ba5e9db0d6c417</a><o:p></o:p></p></div><div=
><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><p =
class=3DMsoNormal><br><br><o:p></o:p></p><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><p =
class=3DMsoPlainText>&nbsp;(2) Are there plans to evolve =
iana-hash-algo.yang anywhere?&nbsp; In your May 14th message, you =
&nbsp;say :&nbsp; &quot;<span style=3D'color:#8EDA5B'>Assuming a future =
effort mimicked Option #2, then &quot;yes=E2=80=9D, as I=E2=80=99d =
expect an &quot;ietf-ssh-common:generate-asymmetric-key=E2=80=9D RPC to =
contain an =E2=80=9Cinput=E2=80=9D node that is an identityref to the =
=E2=80=9Cssh-asymmetric-algorithm=E2=80=9D =
identity.&quot;</span>.&nbsp;&nbsp; I would be willing to help on that =
work.<o:p></o:p></p></div></blockquote><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>I =
have no plans to work on the &quot;algorithms=E2=80=9D problem again. =
&nbsp;Not that I wouldn=E2=80=99t like to, but I need to scale back how =
much unsupported time I<span style=3D'color:black'>&nbsp;volunteer for. =
&nbsp;Generally speaking, I=E2=80=99m&nbsp;gracefully winding down my =
work in progress, while being hyper-cautious about signing up for new =
work. &nbsp;This is why, e.g., I=E2=80=99m not pushing =
&quot;YANG-next=E2=80=9D&nbsp;or&nbsp;=E2=80=9Crestconf-collections=E2=80=
=9D anymore, though both are really important to me. &nbsp;That said, =
I=E2=80=99m open to contract-work, if that makes sense at =
all...</span><o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>More below.<o:p></o:p></p></div><p =
class=3DMsoNormal><br><br><o:p></o:p></p><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><p =
class=3DMsoPlainText>&nbsp;<o:p></o:p></p><p =
class=3DMsoPlainText>Thanks,<o:p></o:p></p><p =
class=3DMsoPlainText>Eric<o:p></o:p></p><p =
class=3DMsoPlainText>&nbsp;<o:p></o:p></p><p =
class=3DMsoPlainText>&nbsp;<o:p></o:p></p><p =
class=3DMsoPlainText>&nbsp;<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
-----Original Message-----<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
From: netconf &lt;<a =
href=3D"mailto:netconf-bounces@ietf.org">netconf-bounces@ietf.org</a>&gt;=
 On Behalf Of Eric Voit (evoit)<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; Sent: Friday, June 12, 2020 1:42 =
PM<o:p></o:p></p><p class=3DMsoPlainText>&gt; To: Kent Watsen &lt;<a =
href=3D"mailto:kent+ietf@watsen.net">kent+ietf@watsen.net</a>&gt;<o:p></o=
:p></p><p class=3DMsoPlainText>&gt; Cc: Netconf &lt;<a =
href=3D"mailto:netconf@ietf.org">netconf@ietf.org</a>&gt;<o:p></o:p></p><=
p class=3DMsoPlainText>&gt; Subject: Re: [netconf] WG LC for three =
drafts<o:p></o:p></p><p class=3DMsoPlainText>&gt; <o:p></o:p></p><p =
class=3DMsoPlainText>&gt; Hi Kent,<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; <o:p></o:p></p><p class=3DMsoPlainText>&gt; I =
have been reading draft-ietf-netconf-crypto-types, and the =
thread:<o:p></o:p></p><p class=3DMsoPlainText>Virtual<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &quot;hum&quot; for the &quot;key =
generation&quot; issue discussed at virtual meeting.<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; <o:p></o:p></p><p class=3DMsoPlainText>&gt; I =
have a couple questions on the previous =
&quot;asymmetric-algorithm-type&quot;&nbsp; and<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; what is now in =
&quot;asymmetric-key-pair-grouping&quot;.&nbsp; My reading is that =
instead<o:p></o:p></p><p class=3DMsoPlainText>&gt; of the previous ENUMs =
of -v14, other applications/WGs will now need to<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; create identities for the various algorithm =
types.&nbsp; And this is fine.<o:p></o:p></p></div></blockquote><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><p class=3DMsoNormal>That =
was the idea at the time but, as you noticed, we since ditched the =
=E2=80=9Calgorithms=E2=80=9D node altogether =
&nbsp;:sigh:<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><br><br><o:p></o:p></p><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><p =
class=3DMsoPlainText>&gt; If I have this correct, then each of the =
TCGAlgorithm Registry&nbsp;ID =
values<o:p></o:p></p></div></blockquote><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><p =
class=3DMsoPlainText>of<o:p></o:p></p><p class=3DMsoPlainText>&gt; TPM2 =
specifications in Table 9<o:p></o:p></p><p class=3DMsoPlainText>&gt; <a =
href=3D"https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-=
2.0-">https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.=
0-</a><o:p></o:p></p><p class=3DMsoPlainText>&gt; =
Part-2-<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
Structures-01.38.pdf<o:p></o:p></p><p class=3DMsoPlainText>&gt; could =
have its own identity.&nbsp;&nbsp; And there would be no barrier to each =
of<o:p></o:p></p><p class=3DMsoPlainText>&gt; these identities also =
having another base identity that might be &quot;tpm2-<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; algorithm&quot;.&nbsp; In this =
correct?<o:p></o:p></p></div></blockquote><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>I =
believe so. &nbsp;I haven=E2=80=99t looked at the TCG Algorithm =
Registry, but certainly, &quot;identity-stmt=E2=80=9D allows multiple =
&quot;base-stmt&quot;. &nbsp; Some might be concerned for =
interoperability, but a solution might support polymorphic definitions. =
&nbsp;Regardless, the original plan was (and I assume would be again, =
if/when the work is picked up) to enable the server to specify (e.g., =
via a =E2=80=9Cconfig false=E2=80=9D list) which algorithms it =
supports.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><p =
class=3DMsoPlainText>&gt; If this is correct, my second question is =
whether there will be an attempt<o:p></o:p></p><p =
class=3DMsoPlainText>to<o:p></o:p></p><p class=3DMsoPlainText>&gt; ask =
other YANG models to import these application identities =
elsewhere?<o:p></o:p></p><p class=3DMsoPlainText>&gt; As you and Rob =
note in the thread, trying to predict the desired =
identity<o:p></o:p></p><p class=3DMsoPlainText>&gt; inheritance =
hierarchy is non-trivial.<o:p></o:p></p></div></blockquote><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><p =
class=3DMsoNormal>I=E2=80=99m unsure about this, but I think =
polymorphism would go a long way to alleviate the =
issue...<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Kent // as a contributor<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><br><br><o:p></o:p></p><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><p =
class=3DMsoPlainText>&gt; <o:p></o:p></p><p class=3DMsoPlainText>&gt; =
Thanks,<o:p></o:p></p><p class=3DMsoPlainText>&gt; Eric<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; <o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&gt; -----Original Message-----<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; From: netconf &lt;<a =
href=3D"mailto:netconf-bounces@ietf.org">netconf-bounces@ietf.org</a>&gt;=
 On Behalf Of Mahesh<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; =
Jethanandani<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; Sent: =
Tuesday, June 2, 2020 7:48 PM<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&gt; To: Netconf &lt;<a =
href=3D"mailto:netconf@ietf.org">netconf@ietf.org</a>&gt;<o:p></o:p></p><=
p class=3DMsoPlainText>&gt; &gt; Subject: [netconf] WG LC for three =
drafts<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; NETCONF WG,<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; The authors of<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; - =
draft-ietf-netconf-crypto-types<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; - =
draft-ietf-netconf-keystore<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&gt; - draft-ietf-netconf-trust-anchors<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; have indicated that these drafts are =
ready for Last Call (LC).<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&gt;<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; This kicks of a 2 =
week WG LC for the three drafts. Please review and<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; send<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; any<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&gt; comments to the WG mailing list or by responding to this =
e-mail.<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; Comments can be =
statements such as, I read/reviewed the document and<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; believe it is ready for publication, or I =
have concerns about the<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; =
document. For the<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
latter,<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; please indicate =
what your concerns are.<o:p></o:p></p><p class=3DMsoPlainText>&gt; =
&gt;<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; Any reports on =
implementation status or plans to implement are also<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; very useful.<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; Thanks.<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; Mahesh Jethanandani (as =
co-chair)<o:p></o:p></p><p class=3DMsoPlainText>&gt; &gt; <a =
href=3D"mailto:mjethanandani@gmail.com">mjethanandani@gmail.com</a><o:p><=
/o:p></p><p class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt;<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; =
_______________________________________________<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; netconf mailing list<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; <a =
href=3D"mailto:netconf@ietf.org">netconf@ietf.org</a><o:p></o:p></p><p =
class=3DMsoPlainText>&gt; &gt; <a =
href=3D"https://www.ietf.org/mailman/listinfo/netconf">https://www.ietf.o=
rg/mailman/listinfo/netconf</a><o:p></o:p></p></div></blockquote></div><p=
 class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div></div></body></html>
------=_NextPart_001_023C_01D64969.8A9FF1E0--

------=_NextPart_000_023B_01D64969.8A9FF1E0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw
ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz
Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX
DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g
Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2
tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI
zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl
zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS
qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk
UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD
VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB
BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO
VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup
SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p
+slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg
lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA
AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD
aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD
VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz
guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I
4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG
VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+
FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ
BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC
NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j
BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j
aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG
CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw
NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3
LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF
AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo
0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp
9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt
U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ
MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04
96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv
eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg
Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw
EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM
D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE
S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO
yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M
mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v
Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp
W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB
Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v
c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp
c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E
MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV
HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G
A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr
+GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ
KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0
JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f
1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG
+gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG
A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjIzMTgyMTEwWjAjBgkqhkiG
9w0BCQQxFgQUGOv2roe0qgrLfAwSJZ0aIJEYX68wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK
EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN
AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK
AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw
CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH
BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B
AQEFAASCAQAYsYIsDc+S3rT/WN/A+cL9tdTodF8ILpk97nWLnqQR8b6ywzzc1r5V2SGctjUutrbi
AS9bEI3L6E4oiJ3fhvEEd0WtU3x1h11zfBL2KSw1cVSUN1ILqCwBNY2Zk/0PBKC/kBK9nGJr4ajW
wOqrnXc9nDW1bG8U/c0xtorCWW69uqAo5ncUgpmW+yocL2A4AZO0WGTD9x2rdRvHTh6YR8BjpGxl
liF3c7HKGROkqK8gQnmZRUmUmPzbQXpiGzXWgS3HBSxlvmsUCL3XOoKPhWSEm9Zp2gIWkdC8JkKh
wEtyV7YX0+p6O2POT+soS1jIA34hAE8pbWAjMH7uQVX3toSDAAAAAAAA

------=_NextPart_000_023B_01D64969.8A9FF1E0--


From nobody Tue Jun 23 11:23:44 2020
Return-Path: <rsalz@akamai.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F833A08F6 for <netconf@ietfa.amsl.com>; Tue, 23 Jun 2020 11:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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=akamai.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 r_K3pyY2f2wU for <netconf@ietfa.amsl.com>; Tue, 23 Jun 2020 11:23:40 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 4F93E3A08EE for <netconf@ietf.org>; Tue, 23 Jun 2020 11:23:40 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 05NIIcSk021946; Tue, 23 Jun 2020 19:21:36 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=bAv8px/gvQSbCcs5sjT4l7ZShBv8bCcQhHvBYiYJ/lk=; b=dgy/caD12DdG4Hsl8jUWqNP6pPXEnf1pw3TWvg62y6lA97NI78QVCxsESbzD+/qYdbxv n2Ecq3dEFkujONmlIt7fAh6QBW36kNIyznH8KILh8AxGk1l3nlMwQDwk4EIFmOqId6vq qMRETCowMhqR1nIsThwixAwlv+Ixm+qDic1Vb/EFUyyM85o18eoTdcNLKXWMF1N1kCYn Y7T6/xU01cJjrWiiP2Pe042X3CrhHXgTjhBmI0DJWTEUhuttxUKR10xubNHecTKfblAr qB6dCcOAcESLW7A9TMO5t3gwtPzRwkLNc4QuKZUvsX8DTPBI44KG+765CfJqInptCL70 4Q== 
Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 31uk22fv52-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jun 2020 19:21:36 +0100
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05NHnii7003443; Tue, 23 Jun 2020 14:21:35 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint8.akamai.com with ESMTP id 31uk739775-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Jun 2020 14:21:35 -0400
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 23 Jun 2020 11:21:34 -0700
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Tue, 23 Jun 2020 13:21:35 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: tom petch <ietfc@btconnect.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Mahesh Jethanandani <mjethanandani@gmail.com>
CC: Netconf <netconf@ietf.org>
Thread-Topic: [netconf] WG LC for three drafts
Thread-Index: AQHWOThMaW9TVQbVp0aakzz8vRafn6jdDHEAgAABtACAAWsHgIAABhgAgAhOg4D//+bLAA==
Date: Tue, 23 Jun 2020 18:21:34 +0000
Message-ID: <6083B0C3-D577-4BED-B59E-8395DAD1689B@akamai.com>
References: <A1A5BD42-AB3F-477A-B291-81E213A2F0DB@gmail.com> <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de> <14453F87-3F9D-40AA-A4E5-DAD7D66B480C@akamai.com> <DBAPR07MB7016CEC8A92F3AF1D3EB4450A09B0@DBAPR07MB7016.eurprd07.prod.outlook.com> <768CC0BC-D11E-4F2D-A950-4E7FB1750CEE@akamai.com> <DBAPR07MB70168354EBA4459C5D4500C4A0940@DBAPR07MB7016.eurprd07.prod.outlook.com>
In-Reply-To: <DBAPR07MB70168354EBA4459C5D4500C4A0940@DBAPR07MB7016.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.38.20061401
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.35.141]
Content-Type: text/plain; charset="utf-8"
Content-ID: <C8EC6E9EEAED5D44B62404C1D70070A7@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-23_11:2020-06-23, 2020-06-23 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 malwarescore=0 spamscore=0 mlxlogscore=763 phishscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006120000 definitions=main-2006230124
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-23_12:2020-06-23, 2020-06-23 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=738 clxscore=1015 priorityscore=1501 phishscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 adultscore=0 impostorscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006120000 definitions=main-2006230126
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/omfFfrUAvwfOLENqCGKPYqdRvtA>
Subject: Re: [netconf] WG LC for three drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2020 18:23:42 -0000

PiAgICBJRUVFMTYwOS4yIGlzIHdoYXQgSSBoYWQgaW4gbWluZCBzaW5jZSBpdCBnb3QgcXVpdGUg
YSBiaXQgb2YgYXR0ZW50aW9uIG9uIHRoZSBUTFMgV0cgbGlzdCBpbiBBdWd1c3QgMjAxOC4gIEkg
ZG9uJ3Qga25vdyBob3cgd2lkZWx5IGl0IGlzIHVzZWQuDQoNCm9oIHRoYXQuICBUaGFua3MuDQoN
Cg==


From nobody Tue Jun 23 13:42:09 2020
Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2866E3A0A30 for <netconf@ietfa.amsl.com>; Tue, 23 Jun 2020 13:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level: 
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 header.b=b0UFM995; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=0HZwIVwK
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUFm-7p4TQC8 for <netconf@ietfa.amsl.com>; Tue, 23 Jun 2020 13:42:06 -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 C98D53A0A1D for <netconf@ietf.org>; Tue, 23 Jun 2020 13:42:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7778; q=dns/txt; s=iport; t=1592944925; x=1594154525; h=from:to:cc:subject:date:message-id:mime-version; bh=OVmijfJy22Iw1i+m0Rdr/ZDIAZHu25SM5eD16aXFlho=; b=b0UFM995TwM5tJvwWmEiEebQhEE5TOkZ5W+PKaX1+AhmTFhlCK52I9SU cuw3dPcxwk6Y8l1UJgrvLatk9/KREq3Y4FArHjMNho/7gkygcFKR8k6NE DIkDnbVS8ZJYF7+x9sU2bcB4yYT12sGbs7AStpoVnjPTA6R9vim9hshCE E=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3AQ4a+kxQ/PE75ghdXfjxNcAc9LNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNuJ9PtYkOfQ9abtRT9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Nq2Gp4DhUHB?= =?us-ascii?q?jjZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYCQBBaPJe/40NJK1mgQmDHCMuB4E?= =?us-ascii?q?aLS8sCodgA6YaglIDVQQHAQEBCQMBAS0CBAEBhEcCghMCJDgTAgMBAQsBAQU?= =?us-ascii?q?BAQECAQYEbYVbDIV1Fi4BATcBEQFQMCYBBA4NBhSDBYF+TQMfDwGtLgKBOYh?= =?us-ascii?q?hdIE0gwEBAQWFFxiCBwcJgTiBU4EUiV4BHRqBQT+BVIcwGoNFgi2aH5pBCoJ?= =?us-ascii?q?aBIQlglSSTp57r3oCBAIEBQIOAQEFgWoigVZwFYMkUBcCDZIPilZ0NwIGCAE?= =?us-ascii?q?BAwl8jk8BMV8BAQ?=
X-IronPort-AV: E=Sophos;i="5.75,272,1589241600";  d="p7s'?scan'208";a="512591288"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jun 2020 20:42:05 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 05NKg4DX031646 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Jun 2020 20:42:05 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 23 Jun 2020 15:42:03 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 23 Jun 2020 16:42:03 -0400
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 23 Jun 2020 16:42:03 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lmUeIdScAlutcTmjlIxvFzRS96ZYaR6/SO5EMmFE3tfUP8m/IPhodeg9sM2qqja+q2bXneb860bB70ws/kP1oydRJpzD72yhOvdp2aMjZfBU1BCS2RzgMbDCUDRtIsVIQ6YBQMECebhsQ8cjB355Z2hhZwMrYobwf22kw5kGHSjseFADTTGiy/Ov9e9antUkxdZRvOVnns+K6zAwemNDQbZR0O/Dug1ua4D9xT7ubhyvgV2t/7Mvc6HeRmU+lH/cECIM9y8GBmPH7aR3jf+Hd9BtEzLGkd2NKgWd6P4uGdfqm5Fd2ASqxFNe5wfsKwBxPDU5b9H16UUevSI0G8EL9Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ISpNdNFonwb745mnCEKsFEwMEMvsZXliU54ufoVpDFU=; b=jgsWBURCvfj71XYyUBRq9qBeMAOjUbmeRPa+KNu0Fv1xbTb1t794H+YndGxbKj1AYphTiEqYSD6fFkZf/hzA2yhd3KM6KYaDY0D/fuqD+C4FuBq5UEgAe5UOk9g4yH3OGO5oz6xLDiTNhy5AlzmzjQyrJczfEA/SXAwPuZraDk1bPl/GhlmoscyTmNhiiOtOhHsouQzVjlX8H6B7kj0zXlyPixt3ZvWo6T9UAHIqxQ2A6t1+uP8fkCbYtMlcRnSTlgojQpRIeVZeziNVQ9bWbZmTSjmoTXTLUH6MtM19/aS0iBr3+aF7iezlpYZZqCEUf2Bsyt9umNAJw6h87fCG+g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ISpNdNFonwb745mnCEKsFEwMEMvsZXliU54ufoVpDFU=; b=0HZwIVwKKPhxgQf+NzuDC37SWBS9NFqz/hjyirXkWbXFilPjke03xFSBIySch7VwYOrsSpFqUmOR877ACaE/QCBqdUxIrdfLg+/bwYJvXu6zVUIjsuwb9DGz6Cd2Rz3QEDDjNMhjWO8ZJTsl7pd1IqAmQmEhJ3hnMfgVfwgWWR8=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4680.namprd11.prod.outlook.com (2603:10b6:208:26d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Tue, 23 Jun 2020 20:42:02 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290%7]) with mapi id 15.20.3109.027; Tue, 23 Jun 2020 20:42:02 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Comments on draft-ietf-netconf-keystore v17
Thread-Index: AdZJi6eAeMmOZqZaQ3i6nM88A9zjLw==
Date: Tue, 23 Jun 2020 20:42:02 +0000
Message-ID: <BL0PR11MB31224C35E1100037780F7DE6A1940@BL0PR11MB3122.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [108.18.114.139]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 537ae3f2-35ce-4ec6-90f6-08d817b5e248
x-ms-traffictypediagnostic: MN2PR11MB4680:
x-microsoft-antispam-prvs: <MN2PR11MB46802D94E0D42D5FF53D9961A1940@MN2PR11MB4680.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 04433051BF
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 9wOv4TvisbadtesrkpraTdHSEOXlqvHtM0lmnDCwHG9ecGU3xyCZnfOxPg3miT3Ouewz615cu0HhF+AUsSpQWwyVZVv/jnVtDpjdnRsV+wzvawfFCcPtgpPZVb4Std5+s7uWHfxRTCah58n4kxGoLXyyJW5/Ls2Z4F4r57xinw+hRxHerK1zVJ0FGcztVR6i84ZNMpyuYCuFdubqedyRvg11EHpCESSpHABljyqUPXSbFyuar84XB2OvtLEPGlh5IzIaJ3NXZlBKhOgdx0hlo6D7WxQSYNCo91cmaisTI5j/x+GmGy203EToST6DUhDH
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(39860400002)(366004)(136003)(376002)(396003)(346002)(66574015)(55016002)(7696005)(9686003)(478600001)(186003)(6506007)(33656002)(316002)(26005)(86362001)(2906002)(99936003)(66616009)(66946007)(52536014)(66446008)(83380400001)(66476007)(5660300002)(4326008)(66556008)(8936002)(8676002)(71200400001)(76116006)(64756008); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: cFXQ+58ZRFqh+5DGOJxsJl6WuE52cbLyJMzt4l+FHz79D1nw7rwLvOivHR8IvJh4CA8P1BNVZviuIkVxVpePQiH979GukCcC2b7wYCqtv764nGAigqBs56d7Zxdok6NEMPV2PIUgouldvcoXo21RNcNFbWg4onE/arNNQyx936AoXuEgeIrZiqRQCoZ1ToHHKq7lV9kKFZE6S9UdlMMled7bUzxaERRGd9sZdl2A3FOUt55uehHNMNkqX9zK+zC/o8DZmw/YG92Qo9ztzxgIVPokc4HHlEmz6Gjlzp4UJCgxrHTaxXmHP2iYrhSNWsYYODWh2fXUQiWIvEK0tcpyTT1Zsg4tTRYg0SqfC11RRG39mxnauWcvXg87uHMpwWH65FyazsLzWiYRKcJ0iKAPY9VvW2x+q5nRtGaMQgIa9gU62AtM2I2FYQyCeS32niRAgs8ciso3QxU0GLiLhN3c2BxcAcuAE5iwU85V766LwqGYVDWzwRqT8sEwBQ0/sgjO
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0280_01D6497D.36D7A490"; micalg=SHA1
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 537ae3f2-35ce-4ec6-90f6-08d817b5e248
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 20:42:02.4372 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8LCCSgaXZFv6Vl2tUbUhUKMnw95Ny3DpTPZaGC/4f6HQpnqQ1fM/Iu4dx85cgFJh
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4680
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/KrU69Fd4qFIKv2tZngSlEpzyX9Q>
Subject: [netconf] Comments on draft-ietf-netconf-keystore v17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2020 20:42:08 -0000

------=_NextPart_000_0280_01D6497D.36D7A490
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Kent,

This is a well written document, and I do support progression.  I do have
some comments/questions...


(1) Section 1: You say:
   Special consideration has been given for systems that have
   cryptographic hardware, such as a Trusted Protection Module (TPM).
   These systems are unique in that the cryptographic hardware hides the
   secret key values.  To support such hardware, symmetric keys may have
   the value "hidden-key" and asymmetric keys may have the value
   "hidden-private-key".  While how such keys are created or destroyed
   is outside the scope of this document, the Keystore can contain
   entries for such keys, enabling them to be referenced by other
   configuration elements.

Question: Internally there might be several keystores on a router.  An
example is that there could be a TPMs for each different line card on a
router.  How is this YANG model about to expose which keys are associated
with specific TPMs?   E.g.: where in the model would you recommend such
augmentations to the grouping statements be made?


(2) This is likely a minor question:   I have seen a need for
"local-or-keystore-public-key-grouping" rather than
"local-or-keystore-asymmetric-key-grouping".  The only reason for the need
is that the private-key is never accessible (TPM again), and the private key
entries of the YANG model are never used.   Is there a reason why you didn't
have "local-or-keystore-public-key-grouping" beyond what could be perceived
as redundancy?


(3) Section 5:3 You Say:
   It was noted that, in this case, the second server would be
   unable to decrypt any of the keys encrypted by the first server.

Question: It is possible for the first server to encrypt a keystore using
the public key of the second server so that only the private key of the
second server would have access to these keys.  How do you see this option
playing in the migration process?

Thanks,
Eric

------=_NextPart_000_0280_01D6497D.36D7A490
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw
ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz
Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX
DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g
Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2
tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI
zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl
zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS
qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk
UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD
VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB
BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO
VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup
SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p
+slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg
lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA
AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD
aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD
VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz
guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I
4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG
VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+
FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ
BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC
NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j
BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j
aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG
CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw
NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3
LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF
AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo
0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp
9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt
U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ
MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04
96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv
eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg
Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw
EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM
D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE
S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO
yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M
mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v
Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp
W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB
Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v
c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp
c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E
MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV
HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G
A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr
+GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ
KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0
JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f
1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG
+gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG
A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjIzMjA0MTU5WjAjBgkqhkiG
9w0BCQQxFgQUgmMrvFZMA3ZH8iTEa1NxAWHK9D8wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK
EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN
AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK
AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw
CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH
BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B
AQEFAASCAQBFrloL5I+YH2O0/8ll3bDkkGWDgPq/Du2ovEmc9ZJ7WvoBouqFPvx78l0Kp3vhS1ZP
6Sb2dII3MmpNk/y4zJK44b0exVsdVBL2yKm1d+E08+5lYq7YRNt4r6JC3j97jex9nzmDC6SWP6TI
whB/ZKu1D1XRoiFOF8CCxOKrkq4JEhdRsh23wOlfxwlfg5Po6+8pfHkcanR3loZHyH/U91R7E9NJ
mXeD4fYL0ZUdyO9YjFA8GZ/u36kE9Fznw+Y5usHt4nw/CJDBsvNZYYKUNY883AaKJvVTauF2pgRz
yB55PFHnwicmLWYKCnk0qT39+HZWqe80f3lD1hq3UBkktDEPAAAAAAAA

------=_NextPart_000_0280_01D6497D.36D7A490--


From nobody Wed Jun 24 09:17:39 2020
Return-Path: <01000172e71ec86d-23dfc820-0f91-4f75-80ab-cdf0cb47760b-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1257D3A0FFB for <netconf@ietfa.amsl.com>; Wed, 24 Jun 2020 09:17:37 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 eN4wKzsCzPqg for <netconf@ietfa.amsl.com>; Wed, 24 Jun 2020 09:17:35 -0700 (PDT)
Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339403A0FF9 for <netconf@ietf.org>; Wed, 24 Jun 2020 09:17:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1593015454; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=7f1+H/Xec9Tic2T+DpgS3QOyf3M4vH4vAsvOl/CnMwE=; b=GSYYCsz7Zhjtm/dx8J7wgMjLRyhB6QiHbU+AxXzvspH8IKLm5O0gG9wGcIJYOiJg jIPbH+tzH4DlKQpNkDij/DeBhHYyD6z4LdD3Fb4Q+N//FXB/68yEDpWbTD9hkkatVW3 UZ/mZfLiUXSNNWLgsPIBWwlswMKtdYvxWXHtu7vI=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000172e71ec86d-23dfc820-0f91-4f75-80ab-cdf0cb47760b-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E2C9EA2C-17BA-4E4A-9193-DA1013414E80"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 24 Jun 2020 16:17:33 +0000
In-Reply-To: <BL0PR11MB31224C35E1100037780F7DE6A1940@BL0PR11MB3122.namprd11.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: "Eric Voit (evoit)" <evoit@cisco.com>
References: <BL0PR11MB31224C35E1100037780F7DE6A1940@BL0PR11MB3122.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.24-54.240.48.92
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/WU766fvV5Ez0HwmLt2n4OgOUlT8>
Subject: Re: [netconf] Comments on draft-ietf-netconf-keystore v17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2020 16:17:37 -0000

--Apple-Mail=_E2C9EA2C-17BA-4E4A-9193-DA1013414E80
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Erik,

Thank you for your comments.

Please see below for more.


> (1) Section 1: You say:
>   Special consideration has been given for systems that have
>   cryptographic hardware, such as a Trusted Protection Module (TPM).
>   These systems are unique in that the cryptographic hardware hides =
the
>   secret key values.  To support such hardware, symmetric keys may =
have
>   the value "hidden-key" and asymmetric keys may have the value
>   "hidden-private-key".  While how such keys are created or destroyed
>   is outside the scope of this document, the Keystore can contain
>   entries for such keys, enabling them to be referenced by other
>   configuration elements.
>=20
> Question: Internally there might be several keystores on a router.  An
> example is that there could be a TPMs for each different line card on =
a
> router.  How is this YANG model about to expose which keys are =
associated
> with specific TPMs?   E.g.: where in the model would you recommend =
such
> augmentations to the grouping statements be made?

I have a few responses.

1) Already the draft =E2=80=9Csupports=E2=80=9D the existence of a =
multiplicity of keystores.  Please refer to the exchange I had with =
Juergen on this thread regarding how my personal project does just this =
by a) NOT *implementing* "ietf-keystore=E2=80=9D and b) NOT enabling =
either the =E2=80=9Ckeystore-supported=E2=80=9D or =
=E2=80=9Clocal-definitions-supported=E2=80=9D features, while c) =
augmenting in new leafref definitions into the =E2=80=9Clocal-or-keystore=E2=
=80=9D choice statements pointing to my application-specific instances =
as needed.   All this to say that it=E2=80=99s possible.

2) That said, for the use-case you described, I=E2=80=99m unsure if I =
would recommend going down that path, as the =E2=80=9Ckeystore=E2=80=9D =
can be thought of as an abstraction whereby it doesn=E2=80=99t matter if =
there are zero or many underlying keystores feeding into it.  How would =
clients care?  For the most part, the =E2=80=9Cbuiltin=E2=80=9D keys and =
certs (e.g., IDevID) are read-only, with only the ability for the =
end-user to associate an LDevID for a builtin key being a quasi =
read-write scenario, but even then it seems trivial for the OS to figure =
out how to do the right thing, assuming there is a multiplicity of =
underlying TPMs.

Perhaps your question more regards the case of defining new (not =
builtin) TPM-protected keys whereby specifying the particular TPM that =
generates/protects the key is important.  As the quoted text above says, =
how such keys are created or destroyed is outside the scope of the =
document (so custom API can be used), but then I=E2=80=99d still expect =
that such keys to be presented in the one-and-only keystore without any =
designation to which TPM they resided in.

Reflecting back to when we were trying to define the so called =
=E2=80=9Ckey-gen=E2=80=9D RPCs (e.g., generate-asymmetric-key), the idea =
was to 1) allow the system to generate a =E2=80=9Chidden=E2=80=9D (aka =
TPM-protected key) and then, as a separate step 2) configure the =
generated key into the keystore whereby, if =E2=80=9Chidden=E2=80=9D, =
the system would be able to figure that out and do the right thing.  So =
it seems that the =E2=80=9Ccustom API=E2=80=9D mentioned above =
might=E2=80=99ve been implemented as an augmentation to said RPCs=E2=80=A6=


What=E2=80=99s the takeaway?  Perhaps this or something else?

OLD

   It is not required that a system has an operating system level
   Keystore utility to implement this module.

NEW

   It is not required that a system has an operating system level
   keystore utility, with or without HSM backing, to implement
   this module.  It is also possible that a system implementing
   the module to possess a multiplicity of operating system level
   Keystore utilities and/or a multiplicity of HSMs.



> (2) This is likely a minor question:   I have seen a need for
> "local-or-keystore-public-key-grouping" rather than
> "local-or-keystore-asymmetric-key-grouping".  The only reason for the =
need
> is that the private-key is never accessible (TPM again), and the =
private key
> entries of the YANG model are never used.   Is there a reason why you =
didn't
> have "local-or-keystore-public-key-grouping" beyond what could be =
perceived
> as redundancy?

That=E2=80=99s because public-keys alone are a Truststore thing (not a =
Keystore thing).  Looking at the "trust-anchors" draft you will find a =
=E2=80=9Clocal-or-truststore-public-keys-grouping=E2=80=9D grouping=E2=80=A6=
is this what you=E2=80=99re looking for?


> (3) Section 5:3 You Say:
>   It was noted that, in this case, the second server would be
>   unable to decrypt any of the keys encrypted by the first server.
>=20
> Question: It is possible for the first server to encrypt a keystore =
using
> the public key of the second server so that only the private key of =
the
> second server would have access to these keys.  How do you see this =
option
> playing in the migration process?

This is, in effect, exactly what the 2nd paragraph in that section =
describes:

   If the first
   server is still accessible, it may be possible to ask it to encrypt
   the key using the second server's root key.

But note the following sentence says:

   That said, a common
   scenario for needing to migrate configuration to another server is
   because the first server is no longer available.


Does this answer your question?

Kent // contributor



>=20
> Thanks,
> Eric


--Apple-Mail=_E2C9EA2C-17BA-4E4A-9193-DA1013414E80
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Hi =
Erik,<div class=3D""><br class=3D""></div><div class=3D"">Thank you for =
your comments.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Please see below for more.</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D"">(1) Section 1: You say:<br class=3D""> &nbsp;&nbsp;Special =
consideration has been given for systems that have<br class=3D""> =
&nbsp;&nbsp;cryptographic hardware, such as a Trusted Protection Module =
(TPM).<br class=3D""> &nbsp;&nbsp;These systems are unique in that the =
cryptographic hardware hides the<br class=3D""> &nbsp;&nbsp;secret key =
values. &nbsp;To support such hardware, symmetric keys may have<br =
class=3D""> &nbsp;&nbsp;the value "hidden-key" and asymmetric keys may =
have the value<br class=3D""> &nbsp;&nbsp;"hidden-private-key". =
&nbsp;While how such keys are created or destroyed<br class=3D""> =
&nbsp;&nbsp;is outside the scope of this document, the Keystore can =
contain<br class=3D""> &nbsp;&nbsp;entries for such keys, enabling them =
to be referenced by other<br class=3D""> &nbsp;&nbsp;configuration =
elements.<br class=3D""><br class=3D"">Question: Internally there might =
be several keystores on a router. &nbsp;An<br class=3D"">example is that =
there could be a TPMs for each different line card on a<br =
class=3D"">router. &nbsp;How is this YANG model about to expose which =
keys are associated<br class=3D"">with specific TPMs? &nbsp;&nbsp;E.g.: =
where in the model would you recommend such<br class=3D"">augmentations =
to the grouping statements be made?<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>I =
have a few responses.</div><div><br class=3D""></div><div>1) Already the =
draft =E2=80=9Csupports=E2=80=9D the existence of a multiplicity of =
keystores. &nbsp;Please refer to the exchange I had with Juergen on this =
thread regarding how my personal project does just this by a) NOT =
*implementing* "ietf-keystore=E2=80=9D and b) NOT enabling either the =
=E2=80=9Ckeystore-supported=E2=80=9D or =
=E2=80=9Clocal-definitions-supported=E2=80=9D features, while c) =
augmenting in new leafref definitions into the =E2=80=9Clocal-or-keystore=E2=
=80=9D choice statements pointing to my application-specific instances =
as needed. &nbsp; All this to say that it=E2=80=99s =
possible.</div><div><br class=3D""></div><div>2) That said, for the =
use-case you described, I=E2=80=99m unsure if I would recommend going =
down that path, as the =E2=80=9Ckeystore=E2=80=9D can be thought of as =
an abstraction whereby it doesn=E2=80=99t matter if there are zero or =
many underlying keystores feeding into it. &nbsp;How would clients care? =
&nbsp;For the most part, the =E2=80=9Cbuiltin=E2=80=9D keys and certs =
(e.g., IDevID) are read-only, with only the ability for the end-user to =
associate an LDevID for a builtin key being a quasi read-write scenario, =
but even then it seems trivial for the OS to figure out how to do the =
right thing, assuming there is a multiplicity of underlying =
TPMs.</div><div><br class=3D""></div><div>Perhaps your question more =
regards the case of defining new (not builtin) TPM-protected keys =
whereby specifying the particular TPM that generates/protects the key is =
important. &nbsp;As the quoted text above says, how such keys are =
created or destroyed is outside the scope of the document (so custom API =
can be used), but then I=E2=80=99d still expect that such keys to be =
presented in the one-and-only keystore without any designation to which =
TPM they resided in.</div><div class=3D""><br class=3D""></div><div =
class=3D""><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, =
0);">Reflecting back to when we were trying to define the so called =
=E2=80=9Ckey-gen=E2=80=9D RPCs (e.g., generate-asymmetric-key), the idea =
was to 1) allow the system to generate a =E2=80=9Chidden=E2=80=9D (aka =
TPM-protected key) and then, as a separate step 2) configure the =
generated key into the keystore whereby, if =E2=80=9Chidden=E2=80=9D, =
the system would be able to figure that out and do the right thing. =
&nbsp;So it seems that the =E2=80=9Ccustom API=E2=80=9D mentioned above =
might=E2=80=99ve been implemented as an augmentation to said =
RPCs=E2=80=A6</div></div><div class=3D""><br =
class=3D""></div><div>What=E2=80=99s the takeaway? &nbsp;Perhaps this or =
something else?</div><div><br class=3D""></div><div>OLD</div><div><br =
class=3D""></div><div><pre class=3D"newpage" style=3D"font-size: =
13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; =
color: rgb(0, 0, 0); font-variant-ligatures: normal; orphans: 2; widows: =
2;">   It is not required that a system has an operating system level
   Keystore utility to implement this module.
</pre><div class=3D""><br class=3D""></div><div class=3D"">NEW</div><div =
class=3D""><br class=3D""></div><div class=3D""><pre class=3D"newpage" =
style=3D"font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; =
break-before: page; color: rgb(0, 0, 0); font-variant-ligatures: normal; =
orphans: 2; widows: 2;">   It is not required that a system has an =
operating system level
   keystore utility, with or without HSM backing, to implement</pre><pre =
class=3D"newpage" style=3D"font-size: 13.3333px; margin-top: 0px; =
margin-bottom: 0px; break-before: page; color: rgb(0, 0, 0); =
font-variant-ligatures: normal; orphans: 2; widows: 2;">   this module.  =
It is also possible that a system implementing</pre><pre class=3D"newpage"=
 style=3D"font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; =
break-before: page; color: rgb(0, 0, 0); font-variant-ligatures: normal; =
orphans: 2; widows: 2;">   the module to possess a multiplicity of =
operating system level</pre><pre class=3D"newpage" style=3D"font-size: =
13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; =
color: rgb(0, 0, 0); font-variant-ligatures: normal; orphans: 2; widows: =
2;">   Keystore utilities and/or a multiplicity of HSMs.</pre></div><div =
class=3D""><br class=3D""></div></div><div><br class=3D""></div><div><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
 class=3D"">(2) This is likely a minor question: &nbsp;&nbsp;I have seen =
a need for<br class=3D"">"local-or-keystore-public-key-grouping" rather =
than<br class=3D"">"local-or-keystore-asymmetric-key-grouping". =
&nbsp;The only reason for the need<br class=3D"">is that the private-key =
is never accessible (TPM again), and the private key<br class=3D"">entries=
 of the YANG model are never used. &nbsp;&nbsp;Is there a reason why you =
didn't<br class=3D"">have "local-or-keystore-public-key-grouping" beyond =
what could be perceived<br class=3D"">as redundancy?<br =
class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>That=E2=80=99s because public-keys alone are a =
Truststore thing (not a Keystore thing). &nbsp;Looking at the =
"trust-anchors" draft you will find a =
=E2=80=9Clocal-or-truststore-public-keys-grouping=E2=80=9D grouping=E2=80=A6=
is this what you=E2=80=99re looking for?</div><div><br =
class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div class=3D"">(3) Section 5:3 You Say:<br class=3D""> =
&nbsp;&nbsp;It was noted that, in this case, the second server would =
be<br class=3D""> &nbsp;&nbsp;unable to decrypt any of the keys =
encrypted by the first server.<br class=3D""><br class=3D"">Question: It =
is possible for the first server to encrypt a keystore using<br =
class=3D"">the public key of the second server so that only the private =
key of the<br class=3D"">second server would have access to these keys. =
&nbsp;How do you see this option<br class=3D"">playing in the migration =
process?<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>This is, in effect, exactly what the 2nd paragraph =
in that section describes:</div><div><br class=3D""></div><div><pre =
class=3D"newpage" style=3D"font-size: 13.3333px; margin-top: 0px; =
margin-bottom: 0px; break-before: page; color: rgb(0, 0, 0); =
font-variant-ligatures: normal; orphans: 2; widows: 2;">   If the first
   server is still accessible, it may be possible to ask it to encrypt
   the key using the second server's root key.</pre><div class=3D""><br =
class=3D""></div></div><div>But note the following sentence =
says:</div><div><br class=3D""></div><div><pre class=3D"newpage" =
style=3D"font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; =
break-before: page; color: rgb(0, 0, 0); font-variant-ligatures: normal; =
orphans: 2; widows: 2;">   That said, a common
   scenario for needing to migrate configuration to another server is
   because the first server is no longer available.</pre><div =
class=3D""><br class=3D""></div></div><div><br class=3D""></div><div>Does =
this answer your question?</div><div><br class=3D""></div><div>Kent // =
contributor</div><div><br class=3D""></div><div><br =
class=3D""></div><div><br class=3D""></div><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D""><br class=3D"">Thanks,<br =
class=3D"">Eric<br class=3D""></div></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_E2C9EA2C-17BA-4E4A-9193-DA1013414E80--


From nobody Wed Jun 24 13:07:31 2020
Return-Path: <evoit@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4963A11B5 for <netconf@ietfa.amsl.com>; Wed, 24 Jun 2020 13:07:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level: 
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 header.b=DAoidzha; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=pK5d6zbT
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yAPWc_mPleV for <netconf@ietfa.amsl.com>; Wed, 24 Jun 2020 13:07:23 -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 E8A4E3A11AD for <netconf@ietf.org>; Wed, 24 Jun 2020 13:07:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26998; q=dns/txt; s=iport; t=1593029242; x=1594238842; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Zmfs9BvxrgV0pncwABUurhrzgcir9rJCRneGrc3dVE8=; b=DAoidzhatnzlyFh/rL3n+APRoARn0nwbTbdnX7F3fuCdKCe3E1Btslgu fhZToO2KaxWW1WVMFWubITYfZUp4F5XnNnKXs1nVRhE/wF6vhTCF3exqP 9nTwsz2m6njE3okciU8tAWZeRQ1w6ytapRyBqFCJJyIkegwxlKeG9RSE0 4=;
X-Files: smime.p7s : 3975
IronPort-PHdr: =?us-ascii?q?9a23=3Ax9U/qBxJqcMcQIHXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWBt+pkkETEW8Pd5u4Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoLkFJA8v4IVvfvi764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COBQAzsfNe/4ENJK1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCCoEjLyMuB28rLS8sCoQag0YDjUaYV4JSA1UEBwEBAQkDAQE?= =?us-ascii?q?tAgQBAYRHAoIVAiQ4EwIDAQELAQEFAQEBAgEGBG2FWwyFcgEBAQEDEhEKEwE?= =?us-ascii?q?BNwEPAgEIFS0CAgIwJQEBBA4NBhSDBYF+TQMfDwGsRgKBOYhhdoEygwEBAQW?= =?us-ascii?q?FKRiCBwcJgTiBU4EUiDqBJQEdGoFBP4FUgk0+hCUaFYJ9M4ItpB2QTgqCWoQ?= =?us-ascii?q?pglWSUYJxiSWFHogvhSCsWlWCVQIEAgQFAg4BAQWBaiKBVnAVgyRQFwINjh4?= =?us-ascii?q?MF4NOilZ0NwIGAQcBAQMJfI8+ATFfAQE?=
X-IronPort-AV: E=Sophos;i="5.75,276,1589241600";  d="p7s'?scan'208,217";a="531626314"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2020 20:07:21 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 05OK7Lpq031506 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jun 2020 20:07:21 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 24 Jun 2020 15:07:21 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 24 Jun 2020 15:07:20 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 24 Jun 2020 16:07:20 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kj0m064LA5uQGgyOGRG2nV+L6DHcJVTWYFFfYpwTaxdBf2QI30ioBB268bP3RpUOLkeLGH8YPjQKeKecb6tGyN8jitN7TnePorocYA0Xb9Pt6P8ZzwOv6fZ74ilgjJXXcakno4fU+K7D3Q+qU64lm1Uk4NQ9nbXBgKN1IhBDk+RX1tS7Xrah0XdtWWlO9IQr+AuPhgPG9FIUWcDrAQwXDlTNP6Qhdi0MzKUCqEGTh5km4jBKvJronEzjvYrJHdrMMiic0aK0Mc8fCZNEZoKtNC8CSStsmLiMbbbF/2+U+ADu13XRt0zltnkcM8nY4wD14mrmrVxEO75boY7VJRAYig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SDQ5h877yuTv/CX2P9htOyt6u/aZfEa6NBTgHo7plKs=; b=ETnwRL64KYHFUXm5X8Ysgg9yI4jaE/teBamDvw1rPrVNEdVF/FRXvlR1YJv/hNC4i3gFsy7qH5HsHWvPjsMWG983pZGXdRJXNIB02U0q0JsTkOXjF3+a17OEy1zu7p61SgiKRYroRURWDopx7gFIPw/NMo09cXszwsofKAIUXqxnDmjrvVKsI5nASEMdYkW7dQmQJyz6X2qbJNiReYgFpkFuJ6WixN8IcCc8kp4Q/3zo2gAtbigfVr+d3UoTwHplIPPmb4AbvaePDZSS7twKMUozc3CvUyOK1hHMT53O1ysqBt9dyV5N1sr40rL6iQDhw3ESHqmJ6VNTgbrSurbZKQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SDQ5h877yuTv/CX2P9htOyt6u/aZfEa6NBTgHo7plKs=; b=pK5d6zbTy3AcQ8RD0tBoPQxqFDWVUtHVZhDOSWlLh7+CkdjJdooIXg+GI/D+SfgOmAJYnwpy++x2TxdPVOEDJoNkcIi47V9ocLfhLg/V54yRFfik559/rR+TXQx3oCGEyAkFsyrDvBRpThEbc8oI5bakMdpFS0CK3vcTSfJqLbQ=
Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3027.namprd11.prod.outlook.com (2603:10b6:208:77::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Wed, 24 Jun 2020 20:07:19 +0000
Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290%7]) with mapi id 15.20.3109.027; Wed, 24 Jun 2020 20:07:19 +0000
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Comments on draft-ietf-netconf-keystore v17
Thread-Index: AdZJi6eAeMmOZqZaQ3i6nM88A9zjLwAt0+6AAAZlSdA=
Date: Wed, 24 Jun 2020 20:07:19 +0000
Message-ID: <BL0PR11MB3122AC25FCF3F06ECC30C7A7A1950@BL0PR11MB3122.namprd11.prod.outlook.com>
References: <BL0PR11MB31224C35E1100037780F7DE6A1940@BL0PR11MB3122.namprd11.prod.outlook.com> <01000172e71ec86d-23dfc820-0f91-4f75-80ab-cdf0cb47760b-000000@email.amazonses.com>
In-Reply-To: <01000172e71ec86d-23dfc820-0f91-4f75-80ab-cdf0cb47760b-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.72]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d37e3a9a-15ca-4705-c1bd-08d8187a331d
x-ms-traffictypediagnostic: BL0PR11MB3027:
x-microsoft-antispam-prvs: <BL0PR11MB30275AE1BAA9DF6295253AC3A1950@BL0PR11MB3027.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0444EB1997
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: cpgE9XArfxUnirW8OMKHkwcIULByBXAWqsqKEH9mBtnpqjv2WgpWLiNiQFGyLb+oJgWX97bgEkIrPqQv98l4Pk+mYnZzWZLBfI5fzS7cyQfawJRizVa63oNNmfc8bOASLR0jpqka0Z8Clabfcdd38TgVtilBs8lTTtniG68E6iktQPDoHXEwpVNSjodMmLoMEdWBB+73uhif/WYTCzhdh8FYDU2x4q4m/meiKj3uaLs+PHMfSEv4EI9iZkFdBLROO0z+RszC1umgMqIOoxpSrhLB/mAxfwYvyMOJiokqjieL1NJTlBAlWZWCNa3gfkeD6uWMEk37+4HExQVs7OL3Ug==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(396003)(376002)(346002)(7696005)(9326002)(316002)(26005)(71200400001)(186003)(6506007)(2906002)(55016002)(9686003)(83380400001)(478600001)(4326008)(8676002)(99936003)(66946007)(86362001)(76116006)(66574015)(8936002)(52536014)(64756008)(33656002)(66476007)(66616009)(66556008)(5660300002)(66446008); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: MQG4Hzh3E0luotj85ytzA4EdsZq0X7j3b5/PfB8sL++wZ3Lhdi5OR7tfgP60jaR6NYGa5xlhh/QpOeud6fm8SrOAidiGt6DX4bjintEMT/GXtGgIXhLFi+ZlCSqLQi4ZGZLYONM0+nBLVIMjT2tb0eSNDAauWL7RbL/8uxUksGcYIitHi4prYRQIg0hoPPUJ+GSt1s+3g44dDgGl3sWy7+FU5IAYzJcPKXvatCUN0BsUw9pzmLmMWAelQPa2zJB86gkxkQ9KtaOpG4p7a1q58ZWC3q69n7rTlauqffbhe4EA+11CSokGgoccFkAVgCBWQEKLjlWiXt0zchRyCeOtuJWGuGhfTLsUJntiJjUs/u4AUfplt/yfRlk2xZH4f9UlOiQZ5u56YM5Nrdqz5W73NTkt538bjOOFaXNHgozS3v2VuzSp7VQsnGzIgc6YoEKnrx4PjzqE3t3SSrGG2Dzfta2AsxDKIzqLqoMu0C5t0f4=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0430_01D64A3E.80A2F7C0"; micalg=SHA1
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d37e3a9a-15ca-4705-c1bd-08d8187a331d
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 20:07:19.4340 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mWeDTXPz9RFs1CPUWAVz2pOzCpZuD3Ys1YcmbZw+BihoBVJXADzhQDZCWRhhPZRL
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3027
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/RlgpS0v42absxUpB1_5wboTdZgU>
Subject: Re: [netconf] Comments on draft-ietf-netconf-keystore v17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2020 20:07:29 -0000

------=_NextPart_000_0430_01D64A3E.80A2F7C0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0431_01D64A3E.80A2F7C0"


------=_NextPart_001_0431_01D64A3E.80A2F7C0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Kent,

=20

From: Kent Watsen, June 24, 2020 12:18 PM



Hi Erik,

=20

Thank you for your comments.

=20

Please see below for more.

=20

=20

(1) Section 1: You say:
  Special consideration has been given for systems that have
  cryptographic hardware, such as a Trusted Protection Module (TPM).
  These systems are unique in that the cryptographic hardware hides the
  secret key values.  To support such hardware, symmetric keys may have
  the value "hidden-key" and asymmetric keys may have the value
  "hidden-private-key".  While how such keys are created or destroyed
  is outside the scope of this document, the Keystore can contain
  entries for such keys, enabling them to be referenced by other
  configuration elements.

Question: Internally there might be several keystores on a router.  An
example is that there could be a TPMs for each different line card on a
router.  How is this YANG model about to expose which keys are =
associated
with specific TPMs?   E.g.: where in the model would you recommend such
augmentations to the grouping statements be made?

=20

I have a few responses.

=20

1) Already the draft =E2=80=9Csupports=E2=80=9D the existence of a =
multiplicity of keystores.  Please refer to the exchange I had with =
Juergen on this thread regarding how my personal project does just this =
by a) NOT *implementing* "ietf-keystore=E2=80=9D and b) NOT enabling =
either the =E2=80=9Ckeystore-supported=E2=80=9D or =
=E2=80=9Clocal-definitions-supported=E2=80=9D features, while c) =
augmenting in new leafref definitions into the =
=E2=80=9Clocal-or-keystore=E2=80=9D choice statements pointing to my =
application-specific instances as needed.   All this to say that =
it=E2=80=99s possible.

=20

2) That said, for the use-case you described, I=E2=80=99m unsure if I =
would recommend going down that path, as the =E2=80=9Ckeystore=E2=80=9D =
can be thought of as an abstraction whereby it doesn=E2=80=99t matter if =
there are zero or many underlying keystores feeding into it.  How would =
clients care?  For the most part, the =E2=80=9Cbuiltin=E2=80=9D keys and =
certs (e.g., IDevID) are read-only, with only the ability for the =
end-user to associate an LDevID for a builtin key being a quasi =
read-write scenario, but even then it seems trivial for the OS to figure =
out how to do the right thing, assuming there is a multiplicity of =
underlying TPMs.

=20

Perhaps your question more regards the case of defining new (not =
builtin) TPM-protected keys whereby specifying the particular TPM that =
generates/protects the key is important.  As the quoted text above says, =
how such keys are created or destroyed is outside the scope of the =
document (so custom API can be used), but then I=E2=80=99d still expect =
that such keys to be presented in the one-and-only keystore without any =
designation to which TPM they resided in.

=20

Reflecting back to when we were trying to define the so called =
=E2=80=9Ckey-gen=E2=80=9D RPCs (e.g., generate-asymmetric-key), the idea =
was to 1) allow the system to generate a =E2=80=9Chidden=E2=80=9D (aka =
TPM-protected key) and then, as a separate step 2) configure the =
generated key into the keystore whereby, if =E2=80=9Chidden=E2=80=9D, =
the system would be able to figure that out and do the right thing.  So =
it seems that the =E2=80=9Ccustom API=E2=80=9D mentioned above =
might=E2=80=99ve been implemented as an augmentation to said =
RPCs=E2=80=A6

=20

What=E2=80=99s the takeaway?  Perhaps this or something else?

=20

OLD

=20

   It is not required that a system has an operating system level
   Keystore utility to implement this module.

=20

NEW

=20

   It is not required that a system has an operating system level
   keystore utility, with or without HSM backing, to implement
   this module.  It is also possible that a system implementing
   the module to possess a multiplicity of operating system level
   Keystore utilities and/or a multiplicity of HSMs.

=20

<eric> I certainly understand where you are trying to go better now.  =
And the second sentence in your NEW gets to my point.   So no further =
question on this one.

=20

(2) This is likely a minor question:   I have seen a need for
"local-or-keystore-public-key-grouping" rather than
"local-or-keystore-asymmetric-key-grouping".  The only reason for the =
need
is that the private-key is never accessible (TPM again), and the private =
key
entries of the YANG model are never used.   Is there a reason why you =
didn't
have "local-or-keystore-public-key-grouping" beyond what could be =
perceived
as redundancy?

=20

That=E2=80=99s because public-keys alone are a Truststore thing (not a =
Keystore thing).  Looking at the "trust-anchors" draft you will find a =
=E2=80=9Clocal-or-truststore-public-keys-grouping=E2=80=9D =
grouping=E2=80=A6is this what you=E2=80=99re looking for?

=20

<eric>  Ahh yes.   I should have checked this other draft.  Question =
resolved.



(3) Section 5:3 You Say:
  It was noted that, in this case, the second server would be
  unable to decrypt any of the keys encrypted by the first server.

Question: It is possible for the first server to encrypt a keystore =
using
the public key of the second server so that only the private key of the
second server would have access to these keys.  How do you see this =
option
playing in the migration process?

=20

This is, in effect, exactly what the 2nd paragraph in that section =
describes:

=20

   If the first
   server is still accessible, it may be possible to ask it to encrypt
   the key using the second server's root key.

=20

But note the following sentence says:

=20

   That said, a common
   scenario for needing to migrate configuration to another server is
   because the first server is no longer available.

=20

=20

Does this answer your question?

=20

<eric> It does answer the question.   As you later point out: "How this =
is achieved may vary".   Rather than a using the organization's crypto =
officer (per later in the paragraph) I prefer having a shared key =
negotiated between servers.  Sealing can then be used for the =
replication of information between servers.  =20

=20

But this isn't a draft about how to maintain redundancy in the keystore. =
 So I don't think any text changes are needed.

=20

Eric


Eric

=20

Kent // contributor

=20

=20

=20


Thanks,
Eric

=20


------=_NextPart_001_0431_01D64A3E.80A2F7C0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta =
name=3DGenerator content=3D"Microsoft Word 15 (filtered =
medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
	{mso-style-name:msonormal;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US =
link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1><p =
class=3DMsoNormal>Hi Kent,<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div =
style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'><p class=3DMsoNormal><b>From:</b> Kent Watsen, June 24, 2020 =
12:18 PM<br><br></p><p class=3DMsoNormal>Hi Erik,<o:p></o:p></p><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Thank you for your =
comments.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Please see below for more.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><div><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p =
class=3DMsoNormal>(1) Section 1: You say:<br>&nbsp;&nbsp;Special =
consideration has been given for systems that =
have<br>&nbsp;&nbsp;cryptographic hardware, such as a Trusted Protection =
Module (TPM).<br>&nbsp;&nbsp;These systems are unique in that the =
cryptographic hardware hides the<br>&nbsp;&nbsp;secret key values. =
&nbsp;To support such hardware, symmetric keys may =
have<br>&nbsp;&nbsp;the value &quot;hidden-key&quot; and asymmetric keys =
may have the value<br>&nbsp;&nbsp;&quot;hidden-private-key&quot;. =
&nbsp;While how such keys are created or destroyed<br>&nbsp;&nbsp;is =
outside the scope of this document, the Keystore can =
contain<br>&nbsp;&nbsp;entries for such keys, enabling them to be =
referenced by other<br>&nbsp;&nbsp;configuration =
elements.<br><br>Question: Internally there might be several keystores =
on a router. &nbsp;An<br>example is that there could be a TPMs for each =
different line card on a<br>router. &nbsp;How is this YANG model about =
to expose which keys are associated<br>with specific TPMs? =
&nbsp;&nbsp;E.g.: where in the model would you recommend =
such<br>augmentations to the grouping statements be =
made?<o:p></o:p></p></div></div></blockquote><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>I =
have a few responses.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>1) Already the draft =E2=80=9Csupports=E2=80=9D the =
existence of a multiplicity of keystores. &nbsp;Please refer to the =
exchange I had with Juergen on this thread regarding how my personal =
project does just this by a) NOT *implementing* =
&quot;ietf-keystore=E2=80=9D and b) NOT enabling either the =
=E2=80=9Ckeystore-supported=E2=80=9D or =
=E2=80=9Clocal-definitions-supported=E2=80=9D features, while c) =
augmenting in new leafref definitions into the =
=E2=80=9Clocal-or-keystore=E2=80=9D choice statements pointing to my =
application-specific instances as needed. &nbsp; All this to say that =
it=E2=80=99s possible.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>2) That said, for the use-case you described, =
I=E2=80=99m unsure if I would recommend going down that path, as the =
=E2=80=9Ckeystore=E2=80=9D can be thought of as an abstraction whereby =
it doesn=E2=80=99t matter if there are zero or many underlying keystores =
feeding into it. &nbsp;How would clients care? &nbsp;For the most part, =
the =E2=80=9Cbuiltin=E2=80=9D keys and certs (e.g., IDevID) are =
read-only, with only the ability for the end-user to associate an LDevID =
for a builtin key being a quasi read-write scenario, but even then it =
seems trivial for the OS to figure out how to do the right thing, =
assuming there is a multiplicity of underlying =
TPMs.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Perhaps your question more regards the case of =
defining new (not builtin) TPM-protected keys whereby specifying the =
particular TPM that generates/protects the key is important. &nbsp;As =
the quoted text above says, how such keys are created or destroyed is =
outside the scope of the document (so custom API can be used), but then =
I=E2=80=99d still expect that such keys to be presented in the =
one-and-only keystore without any designation to which TPM they resided =
in.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><div><p =
class=3DMsoNormal><span style=3D'color:black'>Reflecting back to when we =
were trying to define the so called =E2=80=9Ckey-gen=E2=80=9D RPCs =
(e.g., generate-asymmetric-key), the idea was to 1) allow the system to =
generate a =E2=80=9Chidden=E2=80=9D (aka TPM-protected key) and then, as =
a separate step 2) configure the generated key into the keystore =
whereby, if =E2=80=9Chidden=E2=80=9D, the system would be able to figure =
that out and do the right thing. &nbsp;So it seems that the =
=E2=80=9Ccustom API=E2=80=9D mentioned above might=E2=80=99ve been =
implemented as an augmentation to said =
RPCs=E2=80=A6<o:p></o:p></span></p></div></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>What=E2=80=99s the takeaway? &nbsp;Perhaps this or =
something else?<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>OLD<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><pre =
style=3D'break-before: page;font-variant-ligatures: normal;orphans: =
2;widows: 2'><span style=3D'color:black'>=C2=A0=C2=A0 It is not required =
that a system has an operating system =
level<o:p></o:p></span></pre><pre><span =
style=3D'color:black'>=C2=A0=C2=A0 Keystore utility to implement this =
module.<o:p></o:p></span></pre><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>NEW<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><pre =
style=3D'break-before: page;font-variant-ligatures: normal;orphans: =
2;widows: 2'><span style=3D'color:black'>=C2=A0=C2=A0 It is not required =
that a system has an operating system =
level<o:p></o:p></span></pre><pre><span =
style=3D'color:black'>=C2=A0=C2=A0 keystore utility, with or without HSM =
backing, to implement<o:p></o:p></span></pre><pre style=3D'break-before: =
page;font-variant-ligatures: normal;orphans: 2;widows: 2'><span =
style=3D'color:black'>=C2=A0=C2=A0 this module.=C2=A0 It is also =
possible that a system implementing<o:p></o:p></span></pre><pre =
style=3D'break-before: page;font-variant-ligatures: normal;orphans: =
2;widows: 2'><span style=3D'color:black'>=C2=A0=C2=A0 the module to =
possess a multiplicity of operating system =
level<o:p></o:p></span></pre><pre style=3D'break-before: =
page;font-variant-ligatures: normal;orphans: 2;widows: 2'><span =
style=3D'color:black'>=C2=A0=C2=A0 Keystore utilities and/or a =
multiplicity of HSMs.<o:p></o:p></span></pre></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div><div><p =
class=3DMsoNormal>&lt;eric&gt; I certainly understand where you are =
trying to go better now.=C2=A0 And the second sentence in your NEW gets =
to my point.=C2=A0=C2=A0 So no further question on this =
one.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p =
class=3DMsoNormal>(2) This is likely a minor question: &nbsp;&nbsp;I =
have seen a need =
for<br>&quot;local-or-keystore-public-key-grouping&quot; rather =
than<br>&quot;local-or-keystore-asymmetric-key-grouping&quot;. &nbsp;The =
only reason for the need<br>is that the private-key is never accessible =
(TPM again), and the private key<br>entries of the YANG model are never =
used. &nbsp;&nbsp;Is there a reason why you didn't<br>have =
&quot;local-or-keystore-public-key-grouping&quot; beyond what could be =
perceived<br>as =
redundancy?<o:p></o:p></p></div></div></blockquote><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>That=E2=80=99s because public-keys alone are a =
Truststore thing (not a Keystore thing). &nbsp;Looking at the =
&quot;trust-anchors&quot; draft you will find a =
=E2=80=9Clocal-or-truststore-public-keys-grouping=E2=80=9D =
grouping=E2=80=A6is this what you=E2=80=99re looking =
for?<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><p =
class=3DMsoNormal>&lt;eric&gt;=C2=A0 Ahh yes.=C2=A0=C2=A0 I should have =
checked this other draft.=C2=A0 Question =
resolved.<br><br><o:p></o:p></p><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p =
class=3DMsoNormal>(3) Section 5:3 You Say:<br>&nbsp;&nbsp;It was noted =
that, in this case, the second server would be<br>&nbsp;&nbsp;unable to =
decrypt any of the keys encrypted by the first server.<br><br>Question: =
It is possible for the first server to encrypt a keystore using<br>the =
public key of the second server so that only the private key of =
the<br>second server would have access to these keys. &nbsp;How do you =
see this option<br>playing in the migration =
process?<o:p></o:p></p></div></div></blockquote><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>This is, in effect, exactly what the 2nd paragraph in =
that section describes:<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><pre =
style=3D'break-before: page;font-variant-ligatures: normal;orphans: =
2;widows: 2'><span style=3D'color:black'>=C2=A0=C2=A0 If the =
first<o:p></o:p></span></pre><pre><span =
style=3D'color:black'>=C2=A0=C2=A0 server is still accessible, it may be =
possible to ask it to encrypt<o:p></o:p></span></pre><pre><span =
style=3D'color:black'>=C2=A0=C2=A0 the key using the second server's =
root key.<o:p></o:p></span></pre><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div><div><p =
class=3DMsoNormal>But note the following sentence =
says:<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><pre =
style=3D'break-before: page;font-variant-ligatures: normal;orphans: =
2;widows: 2'><span style=3D'color:black'>=C2=A0=C2=A0 That said, a =
common<o:p></o:p></span></pre><pre><span =
style=3D'color:black'>=C2=A0=C2=A0 scenario for needing to migrate =
configuration to another server is<o:p></o:p></span></pre><pre><span =
style=3D'color:black'>=C2=A0=C2=A0 because the first server is no longer =
available.<o:p></o:p></span></pre><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Does this answer your question?<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>&lt;eric&gt; =
It does answer the question.=C2=A0 =C2=A0As you later point out: =
&quot;How this is achieved may vary&quot;.=C2=A0=C2=A0 Rather than a =
using the organization's crypto officer (per later in the paragraph) I =
prefer having a shared key negotiated between servers.=C2=A0 Sealing can =
then be used for the replication of information between =
servers.=C2=A0=C2=A0 <o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>But this =
isn't a draft about how to maintain redundancy in the keystore. =C2=A0So =
I don't think any text changes are needed.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Eric<o:p></o:p></p><p =
class=3DMsoNormal><br>Eric<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Kent // contributor<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p =
class=3DMsoNormal><br>Thanks,<br>Eric<o:p></o:p></p></div></div></blockqu=
ote></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></div></div></body></html>
------=_NextPart_001_0431_01D64A3E.80A2F7C0--

------=_NextPart_000_0430_01D64A3E.80A2F7C0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw
ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz
Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX
DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g
Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2
tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI
zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl
zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS
qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk
UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD
VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB
BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO
VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup
SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p
+slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg
lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA
AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD
aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD
VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz
guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I
4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG
VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+
FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ
BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC
NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j
BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j
aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG
CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw
NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3
LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF
AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo
0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp
9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt
U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ
MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04
96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv
eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg
Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw
EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM
D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE
S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO
yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M
mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v
Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp
W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB
Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v
c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp
c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E
MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV
HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G
A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr
+GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ
KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0
JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f
1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG
+gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG
A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjI0MTk0NTM2WjAjBgkqhkiG
9w0BCQQxFgQUqpTiyWpLKuxckqzie+zsjN5D8qMwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK
EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN
AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK
AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw
CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH
BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B
AQEFAASCAQAH5aPSPD7PlU6fsA5FD86gfWjRlwViXDAD8VqcrrZvvwTVBE4X5I2THmXrlwLrVPuF
yRD4QI7sOqRO4DiRk3XX5PASy/42E0DBd4pwDY1Qso49ZLbsLI0zRfXqSKHyXd8xqsyzcYyjEFid
YmBz/coji+8E5Qi6CoaYLjrvincYptd4rEGOI1ZmfUSQI7MVU+c/KVCLb7qGH0v0ghnR2TdB+QRy
AncMTWfnzctd5Sjspc9jypeNAleZL8Suw95Nc0MhXUSzJsTX6qYkQ/V6qYLTwgswmg/5isyN71rl
IauuX9nq129pfG97b4LydkCu5SI//j0MABEDr58Jby5JokbpAAAAAAAA

------=_NextPart_000_0430_01D64A3E.80A2F7C0--


From nobody Wed Jun 24 13:30:47 2020
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52C83A116C for <netconf@ietfa.amsl.com>; Wed, 24 Jun 2020 13:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 V1OS8i7vzhWd for <netconf@ietfa.amsl.com>; Wed, 24 Jun 2020 13:30:42 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811993A1168 for <netconf@ietf.org>; Wed, 24 Jun 2020 13:30:42 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 10925670; Wed, 24 Jun 2020 22:30:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 5z90IGrQqjXb; Wed, 24 Jun 2020 22:30:40 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 24 Jun 2020 22:30:40 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id B332420154; Wed, 24 Jun 2020 22:30:40 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id s9gwR6I48Qsw; Wed, 24 Jun 2020 22:30:40 +0200 (CEST)
Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 4D78A200E4; Wed, 24 Jun 2020 22:30:40 +0200 (CEST)
Date: Wed, 24 Jun 2020 22:30:39 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Eric Voit (evoit)" <evoit=40cisco.com@dmarc.ietf.org>
Cc: Kent Watsen <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20200624203039.4jrmfqiyerccpkzh@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Eric Voit (evoit)" <evoit=40cisco.com@dmarc.ietf.org>, Kent Watsen <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
References: <BL0PR11MB31224C35E1100037780F7DE6A1940@BL0PR11MB3122.namprd11.prod.outlook.com> <01000172e71ec86d-23dfc820-0f91-4f75-80ab-cdf0cb47760b-000000@email.amazonses.com> <BL0PR11MB3122AC25FCF3F06ECC30C7A7A1950@BL0PR11MB3122.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <BL0PR11MB3122AC25FCF3F06ECC30C7A7A1950@BL0PR11MB3122.namprd11.prod.outlook.com>
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Roi59Jaf6aXyn3xNj3Xr1ILfrkU>
Subject: Re: [netconf] Comments on draft-ietf-netconf-keystore v17
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2020 20:30:45 -0000

On Wed, Jun 24, 2020 at 08:07:19PM +0000, Eric Voit (evoit) wrote:
>=20
> 1) Already the draft =E2=80=9Csupports=E2=80=9D the existence of a mult=
iplicity of keystores.  Please refer to the exchange I had with Juergen o=
n this thread regarding how my personal project does just this by a) NOT =
*implementing* "ietf-keystore=E2=80=9D and b) NOT enabling either the =E2=
=80=9Ckeystore-supported=E2=80=9D or =E2=80=9Clocal-definitions-supported=
=E2=80=9D features, while c) augmenting in new leafref definitions into t=
he =E2=80=9Clocal-or-keystore=E2=80=9D choice statements pointing to my a=
pplication-specific instances as needed.   All this to say that it=E2=80=99=
s possible.
>=20

True for some definition of "supports".

If the requirement is that we need to support multiple keystores, then
the container keystore should be turned into a list keystore. If the
requirement is to support multiple keystores located at various places
in the schema tree, well, then we likely can't do this properly with
plain YANG 1.1, but possibly with schema mount.

/js

PS: My definition of "supports" would imply interoperability. The
    current approach of "there is a grouping and if you tweak it
    enough it can give you multiple keystores" is not interoperable
    unless we standardize the tweaks.

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>


From nobody Thu Jun 25 07:12:17 2020
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D8A3A0B8C for <netconf@ietfa.amsl.com>; Thu, 25 Jun 2020 07:12:15 -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, 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 kC-qNIJu_Hg2 for <netconf@ietfa.amsl.com>; Thu, 25 Jun 2020 07:12:14 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6D83A0B83 for <netconf@ietf.org>; Thu, 25 Jun 2020 07:12:14 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 15C80F40711; Thu, 25 Jun 2020 07:12:01 -0700 (PDT)
To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: kent+ietf@watsen.net, netconf@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20200625141201.15C80F40711@rfc-editor.org>
Date: Thu, 25 Jun 2020 07:12:01 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/_odXdXyw0SFlavKHoFnMOyvD3ks>
Subject: [netconf] [Technical Errata Reported] RFC8040 (6215)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2020 14:12:16 -0000

The following errata report has been submitted for RFC8040,
"RESTCONF Protocol".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6215

--------------------------------------
Type: Technical
Reported by: Kent Watsen <kent+ietf@watsen.net>

Section: 4.3

Original Text
-------------
   If a retrieval request for a data resource representing a YANG
   leaf-list or list object identifies more than one instance and XML
   encoding is used in the response, then an error response containing a
   "400 Bad Request" status-line MUST be returned by the server.  The
   error-tag value "invalid-value" is used in this case.  Note that a
   non-configuration list is not required to define any keys.  In this
   case, the retrieval of a single list instance is not possible.


Corrected Text
--------------


Notes
-----
This whole paragraph should be removed because, according to Section 3.5 (Data Resource), the "list" and "leaf-leaf" themselves are not a data resources:

   A data resource represents a YANG data node that is a descendant node
   of a datastore resource.  Each YANG-defined data node can be uniquely
   targeted by the request-line of an HTTP method.  Containers, leafs,
   leaf-list entries, list entries, anydata nodes, and anyxml nodes are
   data resources.

No GET, PUT, POST, DELETE, or PATCH example in the RFC illustrates an operation on a "list" or "leaf-list" directly (i.e., without a key, which would then represent an element of the list or leaf-list).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8040 (draft-ietf-netconf-restconf-18)
--------------------------------------
Title               : RESTCONF Protocol
Publication Date    : January 2017
Author(s)           : A. Bierman, M. Bjorklund, K. Watsen
Category            : PROPOSED STANDARD
Source              : Network Configuration
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Mon Jun 29 10:53:19 2020
Return-Path: <0100017301362bb5-2b075a19-364f-40fa-9ad8-35d161a932fc-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DF93A08AF; Mon, 29 Jun 2020 10:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 g-ZEeB0L8ZfG; Mon, 29 Jun 2020 10:53:16 -0700 (PDT)
Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0AF23A08A2; Mon, 29 Jun 2020 10:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1593453194; h=From:Content-Type:Mime-Version:Subject:Date:References:Cc:To:Message-Id:Feedback-ID; bh=LMOqTbh+S76C4fQ9S2K0rlR0tY2JDQjcOV83jKgdCdA=; b=ORTg12PqzyPCKr0UwkIOV3TI04+9/54iXwTfB0eReB87dpVSpkwlu/7B1ShCB0a3 N9Mc1u0nW9648L2qJjtzBpnG0a/cfoxwUQykqSOQolQSwV+VNikEw8ssYq1+d8zwTUK ujjfN1fAxqd0NT9U4kzGpgw4FO/PafWVy33Shd1w=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4D70C0BF-9F55-42FD-BCA7-5A4A1ADD9574"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 29 Jun 2020 17:53:14 +0000
References: <159321547899.12018.9636080960886369588@ietfa.amsl.com>
Cc: "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
To: "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <0100017301362bb5-2b075a19-364f-40fa-9ad8-35d161a932fc-000000@email.amazonses.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.06.29-54.240.48.110
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/goxQJe3aqdAJTRM1wOXzt3Pme4k>
Subject: [netconf] Call for presentations (was: IETF 108 Preliminary Agenda)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2020 17:53:18 -0000

--Apple-Mail=_4D70C0BF-9F55-42FD-BCA7-5A4A1ADD9574
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

NETCONF WG,

According to the preliminary agenda (see below), NETCONF is scheduled to =
meet for 100-minutes on Thursday, July 30th from 14:10-15:50 UTC.

If you are interested in presenting to the WG, please send your =
presentation requests to the "netconf-chairs" alias (CC-ed) with the =
following information, for each presentation request, if more than one:

 - name of the drafts (if any)
 - name of presentation (usually the title of the draft)
 - name of the presenter(s)
 - desired time request (in minutes)


Authors, per the 108 Important Dates page =
<https://datatracker.ietf.org/meeting/108/important-dates>, the draft =
submission cutoff is in two weeks, on Monday July 13th.  Please be sure =
to update your drafts before then.

NETCONF Chairs


> Begin forwarded message:
>=20
> From: IETF Agenda <agenda@ietf.org>
> Subject: IETF 108 Preliminary Agenda
> Date: June 26, 2020 at 7:51:19 PM EDT
> To: "IETF Announcement List" <ietf-announce@ietf.org>
> Cc: 108all@ietf.org, ietf@ietf.org
> Reply-To: agenda@ietf.org
>=20
> The IETF 108 Preliminary Agenda has been posted. The final agenda will =
be published on Thursday, July 3, 2020.
>=20
> https://datatracker.ietf.org/meeting/108/agenda.html
> https://datatracker.ietf.org/meeting/108/agenda.txt
>=20
> The preliminary agenda includes all planned WG, RG, and ANRW sessions. =
We are still finalizing details for a few of our usual meeting-adjacent =
events, so please look out for further details about those. Information =
about side meeting signups will be available when the final agenda is =
posted.
>=20
> IETF 108 Information: https://www.ietf.org/how/meetings/108/
> Register online at: https://registration.ietf.org/108/
>=20
> Don=E2=80=99t forget to register for these exciting IETF 108 events!
>=20
>=20
> Hackathon=20
> 	Signup: https://registration.ietf.org/108/new/hackathon/
> 	More information: =
https://www.ietf.org/how/runningcode/hackathons/108-hackathon/
> 	Keep up to date by subscribing to:=20
> 	https://www.ietf.org/mailman/listinfo/hackathon
>=20
>=20
> Code Sprint
> 	More details coming soon!
>=20


--Apple-Mail=_4D70C0BF-9F55-42FD-BCA7-5A4A1ADD9574
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div =
class=3D"">NETCONF WG,</div><div class=3D""><br class=3D""></div><div =
class=3D"">According to the preliminary agenda (see below), NETCONF is =
scheduled to meet for 100-minutes on Thursday, July 30th =
from&nbsp;14:10-15:50 UTC.</div><div class=3D""><br class=3D""></div><div =
class=3D"">If you are interested in presenting to the WG, please send =
your&nbsp;presentation requests to the "netconf-chairs" alias (CC-ed) =
with&nbsp;the following information, for each presentation request, if =
more&nbsp;than one:<br class=3D""><br class=3D"">&nbsp;- name of the =
drafts (if any)<br class=3D"">&nbsp;- name of presentation (usually the =
title of the draft)<br class=3D"">&nbsp;- name of the presenter(s)<br =
class=3D""><div class=3D"">&nbsp;- desired time request (in =
minutes)</div><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D""><span style=3D"caret-color: rgb(0, 0, =
0); color: rgb(0, 0, 0);" class=3D"">Authors, per</span><a =
href=3D"https://datatracker.ietf.org/meeting/108/important-dates" =
class=3D""> the 108 Important Dates page</a><span style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0);" class=3D"">, the draft submission =
cutoff is in two weeks,&nbsp;</span><span style=3D"caret-color: rgb(0, =
0, 0); color: rgb(0, 0, 0);" class=3D"">on Monday July 13th. =
&nbsp;</span><span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, =
0);" class=3D"">Please be sure to update your drafts before =
then.</span><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, =
0);" class=3D""><br class=3D""></div></div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0);" class=3D"">NETCONF Chairs</div><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">Begin forwarded message:</div><br =
class=3D"Apple-interchange-newline"><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=3D""><span=
 style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">From: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D"">IETF Agenda &lt;<a =
href=3D"mailto:agenda@ietf.org" class=3D"">agenda@ietf.org</a>&gt;<br =
class=3D""></span></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px;" class=3D""><span =
style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">Subject: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D""><b class=3D"">IETF 108 =
Preliminary Agenda</b><br class=3D""></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;" class=3D""><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif; =
color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">Date: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D"">June 26, 2020 at 7:51:19 PM =
EDT<br class=3D""></span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=3D""><span=
 style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">To: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D"">"IETF Announcement List" &lt;<a =
href=3D"mailto:ietf-announce@ietf.org" =
class=3D"">ietf-announce@ietf.org</a>&gt;<br class=3D""></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;" class=3D""><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif; =
color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">Cc: </b></span><span =
style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, =
sans-serif;" class=3D""><a href=3D"mailto:108all@ietf.org" =
class=3D"">108all@ietf.org</a>, <a href=3D"mailto:ietf@ietf.org" =
class=3D"">ietf@ietf.org</a><br class=3D""></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;" class=3D""><span style=3D"font-family: =
-webkit-system-font, Helvetica Neue, Helvetica, sans-serif; =
color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">Reply-To: =
</b></span><span style=3D"font-family: -webkit-system-font, Helvetica =
Neue, Helvetica, sans-serif;" class=3D""><a =
href=3D"mailto:agenda@ietf.org" class=3D"">agenda@ietf.org</a><br =
class=3D""></span></div><br class=3D""><div class=3D""><div class=3D"">The=
 IETF 108 Preliminary Agenda has been posted. The final agenda will be =
published on Thursday, July 3, 2020.<br class=3D""><br class=3D""><a =
href=3D"https://datatracker.ietf.org/meeting/108/agenda.html" =
class=3D"">https://datatracker.ietf.org/meeting/108/agenda.html</a><br =
class=3D"">https://datatracker.ietf.org/meeting/108/agenda.txt<br =
class=3D""><br class=3D"">The preliminary agenda includes all planned =
WG, RG, and ANRW sessions. We are still finalizing details for a few of =
our usual meeting-adjacent events, so please look out for further =
details about those. Information about side meeting signups will be =
available when the final agenda is posted.<br class=3D""><br =
class=3D"">IETF 108 Information: =
https://www.ietf.org/how/meetings/108/<br class=3D"">Register online at: =
https://registration.ietf.org/108/<br class=3D""><br class=3D"">Don=E2=80=99=
t forget to register for these exciting IETF 108 events!<br class=3D""><br=
 class=3D""><br class=3D"">Hackathon <br class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Signup: =
https://registration.ietf.org/108/new/hackathon/<br class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>More =
information: =
https://www.ietf.org/how/runningcode/hackathons/108-hackathon/<br =
class=3D""><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>Keep up to date by subscribing to: <br class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>https://www.ietf.org/mailman/listinfo/hackathon<br class=3D""><br =
class=3D""><br class=3D"">Code Sprint<br class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>More =
details coming soon!<br class=3D""><br =
class=3D""></div></div></blockquote></div><br =
class=3D""></div></body></html>=

--Apple-Mail=_4D70C0BF-9F55-42FD-BCA7-5A4A1ADD9574--