From nobody Mon Feb 1 08:33:40 2021 Return-Path: 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 DB20A3A12BD for ; Mon, 1 Feb 2021 08:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 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, MALFORMED_FREEMAIL=1.591, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHcDpfsuRK3y for ; Mon, 1 Feb 2021 08:33:37 -0800 (PST) Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 14C433A113C for ; Mon, 1 Feb 2021 08:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612197216; bh=DflsjSfk71N2/wlKSiOqkYBNGDnUYXLZ/qKnGoydtcw=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject:Reply-To; b=EsX4d5qZ7ff+qX+O7vAeAZ6k0/8G2M2Eo1hCWJaXJe89s8CDB0yGMgsuoLZw71f/POT0rCLvFNy2geyXyM/6AdZqmMHh2BDZn8ER58MFZ7ua+SNieMqiqdGYdJO7h9NDxoR94L5g8X0kr0bPQjPe8C9jKy/J7zei59sxlxkyYIFUvj27Hg5GSZ1vQE3ns5wB63PfMDKQkrMkSSglPIR36NRyPPmz92JYfNNJ2Mcwh1WcJGVMu3DsbpT7yirppM6/d96SUt4axInVBS+AcWg0z9pggdxxc294aMH4ABtWS7dzfz6K2lgziOVHKz9mZy/QSvg/kLCoy3BNJR04L1JgUw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612197216; bh=xkZe+1TCwzPe4hzA7AGpiBi51ulRw12Zz8W8Ok1/ec6=; h=Date:Subject:From:To:From:Subject:Reply-To; b=BBZw76pk3Ha4dzaINvi0fGczRCIFIlizhiZN+LMILKsQVOcgh+aaxmgnaeLS3dl+7E1MVClSgAZagD67IROb/uoRew6BhPr2NZvA+pkpg6v1J0yYZ0ZPRVweO4XPxvq67OsKzEbETbRiLK045CFxKsm2F918d07dULZIeRG8Dyg/pg+U4y1ofccYmPB5eCa7IzTK4sDDY39eLrbJQp5qGee+jh52GgNgvZ4koOovrKGWuoLHHvTD0+Q6SzPQfTyBSILtNy8+TX7Z1Z6bLGW63zpdWDv/aZ04Z97bqrQctQTCo0oW62SVC7O8FdPqgqTcEn2PdZ/Jq+2tI5tb7AGXMQ== X-YMail-OSG: T8ZSR6UVM1l1B1MqMBI7aLOsKp3rHbKuENigqsC7Tqx_Hgfw2EbnWF5tRjLjHap MgYZWYxDnUC7IMy13K9R9K1A5ZyXLjtWuc_KeLJVXRK8aRCSB8A_yvEnmGuUzZ04DGj_rgYQ08qE WvXD7a7bvPDVoey_dl.m_Xl1uJDosOaUmVNaC0r9D2QgWQhMUFPySkSpPsSdw53IW0iE5Cy3kmdg ABJxZo7FJu.aZvR99oR4r9IPSlVI05C48Csj_DTtADL0bnsNLp3_qTNMwfQtLyN8mWRrYL3aCx1H J50Y1WSDaVQyu9Obi50cN.ly5TU1yc687cyBC_ScdRjBcNKHo5ucSsRwaexBnOVfbcPQEHHCMsFW BmqiHHDbDYMP83HEwt8v7ML7u7.hfTHpL3JKTM7BlgyJ.1WZZCIE12QZw9DwbdYdkjRlFS9sRrve EXnwqXA1Zvwq5hZmXUJ.dR_HOLo2wPLpWpDjf4Ycx6YUDSHdwU3YYIR9XouycjgB8truzdDhf6Fj 117EqtGs_qgqYoqCoPbBG.nQTUQPZrvJjMC9vp2alq0mslJ9uLHtq4S5j.aBxKDQz46l44hrEMcR nFmm.G_65VGWZgkgN1u4gY1uxTDhdGFPOnIjoE4w1y_PXvs_MFX8v94bIXcpqrALRWW_2hsgEscU L6I7.V_VCRvgQ0hFLkhUqMwCPB5Oaj9Fv3OI8kQrPrVdzHhPdlUDBiW73EWcW22dZJOpcVrB9KHv AmK.8AXIsc37egRiiHpyQhkd67sgojCza16JxGDgxWvduB.aOGAzvb2RQNqqbLdhXEdstuEqrbR6 SanoPoineibW9RXrHYf7oF15rgH8mpMai1pTuFYWjy_e5IlKIsE8y6P8Ei3yc1eZD_2LCalS90E2 I5QMj34OCQrg6FKy.i_LntDCvSYeWLN7wgmJkCHMHbMSlZq.O8G6Nj4v_WkGVPXhuLk3MO0JKOjs s5OMv9V3P0.HP_A_mpAgtd3IkENi2TWQOe3eQmm3j4MpstcDUsIoKJss7cD6jNNFug61gchB70d. 6.PfVF8YblRsyUplm2qe5.FF3qSf7PuZvl9V3I0Bvo1QKWfJYXo.aSey1fhtJmk3f8aFkTsVB6z1 du5qPvFOiw7eLMgygXRf3cXm3_UV7LW.g_lyDquZsLQnLnrc699ei7WW5li8azU6vDKFhCqEvUEB SrS68ul4yAIC_LiYTrApdIPRqvpZGMz9z2E4eXLta3ocp3mGiTDJuTr8C8Ie32u6Ze8T1W96lmSS 0JeRshAwOxcMQ5Gi3tWs6rBXcu1teYjOEk_G5BuKOwyvmTro3HGe3T_CQtVxb5N_Zi_4Cn.hxK76 FXrWQD74l4Wjnzs9GxMANsSLgLkTkKmQdUtSYFe8LsajsC4ZYLXHSucdypc5avisJdiV4VLaQDGv pYgOGllJdntffyjMtDo3gljIa6f3jZu4UlXTUjabMDggnDtWIk.Ol0WEeRzM5hpjnu7NpGPr1_QN uR_GJEIyufdxCK2Zwbs3OiDLlGr7TsxtKXiRa38jE2tr109JTmJs4AB7JWHjpIGhzDe5BE9YTRxH 6mLefQoAiq0dTYJq5k8gDk7EUn3sTVjydnEXq_.JBx5JwGVSPvZ5tTIEOo5.CPvM6D9Jy5P5ZXaM iboAAUCph996eSIexpWqFvIsW2JPBFLLan7hafhaCxAOE6Z15id8PpC3R3SEmhbdIfrwDPCbNuJ8 SRoiDxj8sPzGp3zd58Wzngb5ShZIwxS_rVHkOmBlzoUrGcESTN8x9Xx_Mimt_glCPsdlVWmbzPz. DBQ3axy3ZiYaeKora8swL7FJhU4dabIIEB6QnmPOlz_wyLmb.sukfPp4ySUYZuRS.O3FfXSHRqrF KDl7P7QVYpsJGi6dPZnF3nrv_fdocCAYDwtNBD1fgDfkMnjis1yBLckCVIoY9MZZHqx3nrnMg_AK fJVSzyI5DSN.wIgM30C_FDUfVfru6zHsiI7GO5JvGpPe17Br.arKxB.eCD_lF4_5PgD4qxfw0UxO NLw7ukEbHCA73rIPROPmN7roQ7K.fX31DouCkMKi4VtTHPiip.SF6ZQgYKzSh9q3wTVQvffHnuL8 Vj6jJrkrBzdiQ7_hDTP9lXGru3tRKe0ch_5tOxTHqbm9tUQUmQg0sqv2ma7UTn1qWH5tNTzDjru1 660bUcYXfQhdg._hJy.zh6yQXZNRl773LG9vwsgtTw9zQjUnP7aFLaEzuA0J40BGtOmPTZ6hPPua WKsgY4k5J8Q3yixkJICYz7asnFOStWm4TJGmtSoEEPqOkTjmFirmSQ5WcXDwVHvF9MoXTKkxxqFQ DDc3vkRbl5mrePpxydUZ5hccKb1dZHV_kUGHB6sm.na12TEidYJp24umQAbfKsVGruppZJRUof2a MwTT55_sP4cIUZRk70wj7bQoK8S5mJi6R.mB4e.mFROkoT662dV8OFhrd8l8PHcCUV5IA4bz6M.o RDBRgggf59nvgKhfiRg7sRtJqRSaVWZVlyGWF_dziBDcG8Fw3YmIuJ_KoHCPbDVcLS6mt0QKCFu. wUB15dP86V5hDUrKGWFcw9UOcw3qnqfNZJvsKs0hLFGUhu9wJuhuYoAZxWyfAWQGyEm2NIfj0wcO ONpBCFL6e_xoU8.TPEEI3KkdlTtk9FWF91GYxPQV07w.0q2.O2YsS9VLxNTjoJDJ8eLEcmok5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Mon, 1 Feb 2021 16:33:36 +0000 Received: by smtp413.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4c2c77a52d47be85fe7d7a881b3b33d9; Mon, 01 Feb 2021 16:33:30 +0000 (UTC) User-Agent: Microsoft-MacOutlook/16.44.20121301 Date: Mon, 01 Feb 2021 11:33:29 -0500 From: Reshad Rahman To: Kent Watsen CC: "netconf@ietf.org" , "draft-ietf-netconf-https-notif@ietf.org" Message-ID: Thread-Topic: [netconf] WGLC: draft-ietf-netconf-https-notif-06 References: <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6.ref@yahoo.com> <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6@yahoo.com> <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-000000@email.amazonses.com> In-Reply-To: <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-000000@email.amazonses.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3695024010_96058648" X-Mailer: WebService/1.1.17648 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 16:33:39 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3695024010_96058648 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Good with me. =20 Regards, Reshad. =20 From: Kent Watsen Date: Sunday, January 31, 2021 at 7:54 AM To: Reshad Rahman Cc: "netconf@ietf.org" , "draft-ietf-netconf-https-notif@= ietf.org" Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 =20 =20 I've reviewed this document and I think the document will be ready once the= changes planned by the authors (regarding notification-messages) are made. =20 Thanks, but a couple more problems: =20 1) the URLs are bad. Specifically, the example in the =E2=80=9CLearning Receiver= Capabilities=E2=80=9D section uses a nonsensical URL (=E2=80=98/=E2=80=98). The authors pro= pose to instead use a sub-resource to the user-configured =E2=80=9Cpath=E2=80=9D (e.g., = GET /some/path/capabilities) and move the POST URL to another sub-resource (= e.g., /some/path/relay-notification). [see below for more on this] =20 2) the media-types are bad: =E2=80=9Capplication/yang-data+[xml/json]=E2=80=9D is used = for notifications, which is wrong since they are not YANG-defined, and the c= ustom media-types for capabilities (application/ietf-https-notif-cap+[xml/js= on]) is a way overkill. The authors propose to use =E2=80=9Capplication/[xml/json= ]=E2=80=9D for both cases. =20 I have a question on the following YANG description. Section 4.1 mentions '= path-absolute' for the URI but the description below says "Relative URI...".= Should this description be clarified/corrected or am I missing something? augment "transport/tls/tls/http-client-parameters" { leaf path { type string; description "Relative URI to the target resource."; } description "Augmentation to add a path to the target resource."; } =20 Agreed. How about this? =20 leaf path { type string; mandatory true; description "URI prefix to the target resources. Under this path the receiver must support both the 'capabilities' and 'relay-notification' resource targets, as described in RFC XXXX."; } So, if path=3D=3D=E2=80=9C/som/path=E2=80=9D, capability-discovery would be to "/some/path/= capabilities=E2=80=9D and notifications would be sent to =E2=80=9C/some/path/relay-notif= ication=E2=80=9D. =20 Thoughts? =20 =20 Formatting nit: Trust anchors (i.e. CA certs) that are used to authenticat\ e =20 Fixed, but the other example cannot be fixed because the =E2=80=9Cxmlns=E2=80=9D string= s alone are too long, and XML doesn=E2=80=99t internally support folding, and the = =E2=80=9Cstring=E2=80=9D type doesn=E2=80=99t allows for whitespace (include =E2=80=98\n=E2=80=99) both at= the beginning and end of strings (recall my request for rfc6991-bis to defi= ne a =E2=80=9Ctoken=E2=80=9D type that would enable the parser to discard any found, so = our examples could more often be manually-folded). =20 K. =20 =20 --B_3695024010_96058648 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Good with me.=

 

Re= gards,

Reshad.

 

From: Kent Watsen <kent+ietf@watsen.net>
Date: Sunday, Januar= y 31, 2021 at 7:54 AM
To: Reshad Rahman <reshad@yahoo.com>Cc: "netconf@ietf.org" <netconf@ietf.org>, "dr= aft-ietf-netconf-https-notif@ietf.org" <draft-ietf-netconf-https-not= if@ietf.org>
Subject: Re: [netconf] WGLC: draft-ietf-netconf-ht= tps-notif-06

 <= /o:p>

 

I've reviewed this document and I think the document will be ready once= the changes planned by the authors (regarding notification-messages) are ma= de.

&nbs= p;

Thanks, but a couple more problems= :

 

1) the URLs are bad.  Specifically, the example in= the =E2=80=9CLearning Receiver Capabilities=E2=80=9D section uses a nonsensical URL (=E2=80= =98/=E2=80=98).   The authors propose to instead use a sub-resource to the user= -configured =E2=80=9Cpath=E2=80=9D (e.g., GET /some/path/capabilities) and move the POST= URL to another sub-resource (e.g., /some/path/relay-notification).  [s= ee below for more on this]

=  

2) the media-types are bad: =E2=80= =9Capplication/yang-data+[xml/json]=E2=80=9D is used for notifications, which is wro= ng since they are not YANG-defined, and the custom media-types for capabilit= ies (application/ietf-https-notif-cap+[xml/json]) is a way overkill.  T= he authors propose to use =E2=80=9Capplication= /[xml/json]=E2=80=9D for both cases.

 



<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

I have a question on the following YANG description. Section 4.1 me= ntions 'path-absolute' for the URI but the description below says "Rela= tive URI...". Should this description be clarified/corrected or am I mi= ssing something?

        &nbs= p;   augment "transport/tls/tls/http-client-parameters&q= uot; {
           =    leaf path {
       &= nbsp;        type string;
 &= nbsp;            = ;  description
        =           "Relative U= RI to the target resource.";
      &nb= sp;       }
    &n= bsp;         description
&nb= sp;            &= nbsp;  "Augmentation to add a path to the target resource.&qu= ot;;
           &n= bsp;}

&n= bsp;

Agreed.  How about this?

 

       &nb= sp;leaf path {
          type&nbs= p;string;
          mandatory true;          description
     =       "URI prefix to the target resources. &n= bsp;Under this
             path = the receiver must support both the 'capabilities'
    &nbs= p;        and 'relay-notification' resource targets, as&= nbsp;described
             in RFC XXX= X.";
        }

So, if path=3D=3D=E2=80=9C/som/path=E2=80=9D, capability-discovery would be = to "/some/path/capabilities=E2=80=9D and notificati= ons would be sent to =E2=80=9C/some/path/relay-notification=E2=80=9D.

 

Thoughts?

&nbs= p;

 

Formatting nit:
         =   Trust anchors (i.e. CA certs) that are used to authenticat\
&= nbsp;e

&= nbsp;

Fixed, but the other example ca= nnot be fixed because the =E2=80=9Cxmlns=E2=80=9D strings alone are too long, and XML do= esn=E2=80=99t internally support folding, and the =E2=80=9Cstring=E2=80=9D type doesn=E2=80=99t allo= ws for whitespace (include =E2=80=98\n=E2=80=99) both at the beginning and end of string= s (recall my request for rfc6991-bis to define a =E2=80=9Ctoken=E2=80=9D type that would= enable the parser to discard any found, so our examples could more often be= manually-folded).

 <= /o:p>

K.

 

 

=
--B_3695024010_96058648-- From nobody Tue Feb 2 14:22:45 2021 Return-Path: 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 79B683A0C6A; Tue, 2 Feb 2021 14:22:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <161230456345.20070.17776740163539556284@ietfa.amsl.com> Date: Tue, 02 Feb 2021 14:22:43 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-https-notif-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 22:22:43 -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 : An HTTPS-based Transport for Configured Subscriptions Authors : Mahesh Jethanandani Kent Watsen Filename : draft-ietf-netconf-https-notif-07.txt Pages : 27 Date : 2021-02-02 Abstract: This document defines both a protocol for sending notifications over HTTPS as well as extensions to the data model for configured subscriptions defined in RFC 8639. It also presents an example module for configuration without using the data model defined in RFC 8639. This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is a server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-07 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 Feb 2 14:33:51 2021 Return-Path: <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-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 A30B03A09E9 for ; Tue, 2 Feb 2021 14:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 RTXMoJcp7gTL for ; Tue, 2 Feb 2021 14:33:47 -0800 (PST) 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 A731B3A09E1 for ; Tue, 2 Feb 2021 14:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1612305226; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=MxtLv/fIk8L2Czu9dukZVGq1umzyqTPHOVdq3ye5OZA=; b=PgYUQJBI+xK3sC4FuflBfVliAr1d7/JiDl6/rZ0V7MmK0ROKf7d0rHQ49W2vBicc OVKTroypK+HKg1o+LxtsPyoUV15RnrUEes5qiEzuHLI73Gbfc98KWnQoP5rXezaq2Nb RL6hqXciAzo1Fc0abc9VmtePqGiDKsDpJP2u9sIo= From: Kent Watsen Message-ID: <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FD2780A2-98AC-4407-86D3-AC6F8DCA3751" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 2 Feb 2021 22:33:46 +0000 In-Reply-To: To: "netconf@ietf.org" References: <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6.ref@yahoo.com> <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6@yahoo.com> <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.02-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 22:33:50 -0000 --Apple-Mail=_FD2780A2-98AC-4407-86D3-AC6F8DCA3751 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 NETCONF, The just posted -07 addresses issues raised thus far. https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07 = Henning, Eric, Reshad, Please re-review as your comments are important to us. Everyone else, The hasn=E2=80=99t been many reviews as yet. Please review this version, as it is significantly better (ready for publication?) than the prevision version. K. > On Feb 1, 2021, at 11:33 AM, Reshad Rahman wrote: >=20 > Good with me. > =20 > Regards, > Reshad. > =20 > From: Kent Watsen > Date: Sunday, January 31, 2021 at 7:54 AM > To: Reshad Rahman > Cc: "netconf@ietf.org" , = "draft-ietf-netconf-https-notif@ietf.org" = > Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 > =20 > =20 >> I've reviewed this document and I think the document will be ready = once the changes planned by the authors (regarding = notification-messages) are made. > =20 > Thanks, but a couple more problems: > =20 > 1) the URLs are bad. Specifically, the example in the =E2=80=9CLearning= Receiver Capabilities=E2=80=9D section uses a nonsensical URL = (=E2=80=98/=E2=80=98). The authors propose to instead use a = sub-resource to the user-configured =E2=80=9Cpath=E2=80=9D (e.g., GET = /some/path/capabilities) and move the POST URL to another sub-resource = (e.g., /some/path/relay-notification). [see below for more on this] > =20 > 2) the media-types are bad: =E2=80=9Capplication/yang-data+[xml/json]=E2= =80=9D is used for notifications, which is wrong since they are not = YANG-defined, and the custom media-types for capabilities = (application/ietf-https-notif-cap+[xml/json]) is a way overkill. The = authors propose to use =E2=80=9Capplication/[xml/json]=E2=80=9D for both = cases. > =20 >=20 >=20 >> I have a question on the following YANG description. Section 4.1 = mentions 'path-absolute' for the URI but the description below says = "Relative URI...". Should this description be clarified/corrected or am = I missing something? >>=20 >> augment "transport/tls/tls/http-client-parameters" { >> leaf path { >> type string; >> description >> "Relative URI to the target resource."; >> } >> description >> "Augmentation to add a path to the target resource."; >> } > =20 > Agreed. How about this? > =20 > leaf path { > type string; > mandatory true; > description > "URI prefix to the target resources. Under this > path the receiver must support both the 'capabilities' > and 'relay-notification' resource targets, as described > in RFC XXXX."; > } >=20 > So, if path=3D=3D=E2=80=9C/som/path=E2=80=9D, capability-discovery = would be to "/some/path/capabilities=E2=80=9D and notifications would be = sent to =E2=80=9C/some/path/relay-notification=E2=80=9D. > =20 > Thoughts? > =20 > =20 >> Formatting nit: >> Trust anchors (i.e. CA certs) that are used to = authenticat\ >> e > =20 > Fixed, but the other example cannot be fixed because the =E2=80=9Cxmlns=E2= =80=9D strings alone are too long, and XML doesn=E2=80=99t internally = support folding, and the =E2=80=9Cstring=E2=80=9D type doesn=E2=80=99t = allows for whitespace (include =E2=80=98\n=E2=80=99) both at the = beginning and end of strings (recall my request for rfc6991-bis to = define a =E2=80=9Ctoken=E2=80=9D type that would enable the parser to = discard any found, so our examples could more often be manually-folded). > =20 > K. --Apple-Mail=_FD2780A2-98AC-4407-86D3-AC6F8DCA3751 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 NETCONF,

      The just posted -07 addresses issues = raised thus far.
      https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07

Henning, Eric, Reshad,

      Please = re-review as your comments are important to us.

Everyone else,

      The hasn=E2=80=99t = been many reviews as yet.  Please review this
      version, as it is significantly better = (ready for publication?)
      than = the prevision version.




On Feb 1, 2021, at 11:33 AM, Reshad Rahman = <reshad@yahoo.com> wrote:

Good with me.
 
Regards,
Reshad.
 
From: Kent Watsen <kent+ietf@watsen.net>
Date: Sunday, January 31, = 2021 at 7:54 AM
To: Reshad Rahman <reshad@yahoo.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>, = "draft-ietf-netconf-https-notif@ietf.org" <draft-ietf-netconf-https-notif@ietf.org>
Subject: Re: [netconf] WGLC: = draft-ietf-netconf-https-notif-06
 
 
I've = reviewed this document and I think the document will be ready once the = changes planned by the authors (regarding notification-messages) are = made.
 
Thanks, but a couple more problems:
 
1) = the URLs are bad.  Specifically, the example in the =E2=80=9CLearning= Receiver Capabilities=E2=80=9D section uses a nonsensical URL = (=E2=80=98/=E2=80=98).   The authors propose to instead use a = sub-resource to the user-configured =E2=80=9Cpath=E2=80=9D (e.g., GET = /some/path/capabilities) and move the POST URL to another sub-resource = (e.g., /some/path/relay-notification).  [see below for more on = this]
 
2) the media-types are bad: = =E2=80=9Capplication/yang-data+[xml/json]=E2=80=9D is used for = notifications, which is wrong since they are not YANG-defined, and the = custom media-types for capabilities = (application/ietf-https-notif-cap+[xml/json]) is a way overkill. =  The authors propose to = use =E2=80=9Capplication/[xml/json]=E2=80=9D for both = cases.
 


I have a question on the following YANG = description. Section 4.1 mentions 'path-absolute' for the URI but the = description below says "Relative URI...". Should this description be = clarified/corrected or am I missing something?

          &nb= sp; augment "transport/tls/tls/http-client-parameters" {
          &nb= sp;   leaf path {
          &nb= sp;     type string;
          &nb= sp;     description
          &nb= sp;       "Relative URI to the target = resource.";
          &nb= sp;   }
          &nb= sp;   description
          &nb= sp;     "Augmentation to add a path to the = target resource.";
          &nb= sp; }
 
Agreed.  How about this?
 

        leaf path {
          type string;
        =   mandatory true;
      =     description
        =     "URI prefix to the target = resources.  Under this
      =        path the receiver must support both = the 'capabilities'
          =    and 'relay-notification' resource targets, = as described
          =    in RFC XXXX.";
      =   }

So, if path=3D=3D=E2=80=9C/som/path=E2=80=9D, = capability-discovery would be to "/some/path/capabilities=E2=80=9D and notifications would be sent = to =E2=80=9C/some/path/relay-notification=E2=80=9D.
 
Thoughts?
 
 
Formatting nit:
          &nb= sp;Trust anchors (i.e. CA certs) that are used to authenticat\
 e
 
Fixed, but the other example cannot be = fixed because the =E2=80=9Cxmlns=E2=80=9D strings alone are too long, = and XML doesn=E2=80=99t internally support folding, and the =E2=80=9Cstrin= g=E2=80=9D type doesn=E2=80=99t allows for whitespace (include =E2=80=98\n= =E2=80=99) both at the beginning and end of strings (recall my request = for rfc6991-bis to define a =E2=80=9Ctoken=E2=80=9D type that would = enable the parser to discard any found, so our examples could more often = be manually-folded).
 
K.

= --Apple-Mail=_FD2780A2-98AC-4407-86D3-AC6F8DCA3751-- From nobody Wed Feb 3 03:14:52 2021 Return-Path: <01000177679a1bd4-8b1dd0c5-325a-400e-bda3-ae6e594c7fca-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 63EF33A09B7 for ; Wed, 3 Feb 2021 03:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 VwUXoPqPa4gy for ; Wed, 3 Feb 2021 03:14:50 -0800 (PST) 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 5212E3A09B5 for ; Wed, 3 Feb 2021 03:14:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1612350889; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=oJIhtJh7lXRsXMJ8XEszDeNYgfVNqAOl0Vj/2gPow3Q=; b=jFn5jthtgSo9CFtAwUM7kLCVxnO60diRnXHF8zwdagdO24AdcapbjGTBjlQYynLw MW01TXDlDyG5MfHd9M9+IrngjxnKQvpfwB3q1aZ+VFHm/ZvHXli9H95hXIKtF0wvniL m7XRCmvWK7blBdIfJ/xzISAIONsbWzbKquRQ/350= From: Kent Watsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 3 Feb 2021 11:14:49 +0000 References: <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6.ref@yahoo.com> <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6@yahoo.com> <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-000000@email.amazonses.com> <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com> Message-ID: <01000177679a1bd4-8b1dd0c5-325a-400e-bda3-ae6e594c7fca-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.03-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 11:14:51 -0000 Should we abandon legacy RFC 5277 protocol? Specifically, change the API to something that can be modeled by YANG? = This is desirable to receivers that are themselves an NC/RC "server=E2=80=9D= . For instance: rpc relay-notification { input { anydata notification; } } OLD: POST /some/path/relay-notification HTTP/1.1 Host: example.com Content-Type: application/xml = ... NEW: (diffs: URL, Content-Type, , and xmlns) /restconf/operations/ietf-notif-receiver-https:relay-notification = HTTP/1.1 Host: example.com Content-Type: application/yang+data+xml ... Not shown, but it also normalizes the JSON-encoding to have a = YANG-modeled prefix (not a pseudo prefix, e.g., =E2=80=9Cietf-restconf:=E2= =80=9D) Thoughts? K. From nobody Wed Feb 3 04:21:03 2021 Return-Path: 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 389A83A0A27 for ; Wed, 3 Feb 2021 04:21:02 -0800 (PST) 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 3aClOtwUrn8R for ; Wed, 3 Feb 2021 04:21:00 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F273A0A02 for ; Wed, 3 Feb 2021 04:21:00 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id h7so33009242lfc.6 for ; Wed, 03 Feb 2021 04:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=C3pJOEp0xeB9FRT/IVPmOiaY8W9zqfOdmOe7xgaNoN8=; b=OFs9TSYi4MZWzyD/BCMxrsu7A8xm5sdVpaCfylbW+IWrBKp932oiDnOXS1Od3WXkfV LSs5mTxqUBwAYpRAm7M/Wc6REAyQvgzaJs/0/CPbGStelk7Dqebct8/HVNYt28Oy0gJm nSgJD7WmTkCsYTfvaWJCzIUN6QHdAl/3MBCI1KIgvTQE3AfY7pyRxsmwHLY/avqc3HQt XRb+MMT6zydrbOTqedqQ+hw5Fq5S7wuo3jqEsJbZRPwoK81Oq7926QVQLEB9WimZ1e7n JFrIsfmZjTg/dj7DuzbdIrkLw6RPWIPPsTRTxGsQqwRQuz04TGHsmehfm2228xWU3WAZ G2Ew== 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=C3pJOEp0xeB9FRT/IVPmOiaY8W9zqfOdmOe7xgaNoN8=; b=oCYXL6lrstGjPpicZwdLvCxG59lFIqddEEkoRRYNgamzp57ZAxKV15q/3EoCzsZysP 6Po6LV9iQ+K5Sck3+GQicX59Bel4C1daJ5I7uxVGXJK+y/xXg9uz7XVS4SXNoDT2VqIJ v4OelPLDs1HIeI2+xRv+RJ8WuH9QOb3xfl82PWklaRIYFDQdBIWSXQRp4l3hxJjGH7l3 ya/KP92FcoIM/bF1lASY+wYITwJBsHq5wa3hqOwmXNr0XyAgrnr4fKrSkthwAvK0tRa8 5HYPJ2WSlRDuM2RgAKQvyaUN9TUjUEeA5EuwN61aZd9m8NRX+N8NTONbcORdrb5w2U8K Zrwg== X-Gm-Message-State: AOAM533UxzVVnGoRa+YsA7SwofDKLMgPT+cmWb/vtys7uhfiK0SUP5We GtI4ocar3/n1hp+qTeg81+lY2ET4eKLQawxxBlxYkmYNvXk= X-Google-Smtp-Source: ABdhPJwyWlGX4Yj3NIJx7JOqRHmexC1Jfb+H8KK5f7cUtILMSfwunPTYpLcSb2PXDTTTeux0kv9SGGBoc0FQqA+UOsc= X-Received: by 2002:ac2:43b0:: with SMTP id t16mr1562897lfl.582.1612354858170; Wed, 03 Feb 2021 04:20:58 -0800 (PST) MIME-Version: 1.0 References: <161230456345.20070.17776740163539556284@ietfa.amsl.com> In-Reply-To: <161230456345.20070.17776740163539556284@ietfa.amsl.com> From: Henning Rogge Date: Wed, 3 Feb 2021 13:20:32 +0100 Message-ID: To: Netconf Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 12:21:02 -0000 Re-sending the POST request for every pipelined notification resolves the issues I had with the pipelining. Also the compacted example illustration is easier to understand in my opinion. Henning Rogge From nobody Wed Feb 3 23:28:43 2021 Return-Path: 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 677F33A1373 for ; Wed, 3 Feb 2021 23:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 acrBTmvQrgNA for ; Wed, 3 Feb 2021 23:28:40 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57733A1372 for ; Wed, 3 Feb 2021 23:28:39 -0800 (PST) Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DWVP42rXXz67kkV for ; Thu, 4 Feb 2021 15:22:16 +0800 (CST) Received: from dggeme719-chm.china.huawei.com (10.1.199.115) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Thu, 4 Feb 2021 08:28:31 +0100 Received: from dggeme770-chm.china.huawei.com (10.3.19.116) by dggeme719-chm.china.huawei.com (10.1.199.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Thu, 4 Feb 2021 15:28:30 +0800 Received: from dggeme770-chm.china.huawei.com ([10.8.68.58]) by dggeme770-chm.china.huawei.com ([10.8.68.58]) with mapi id 15.01.2106.006; Thu, 4 Feb 2021 15:28:30 +0800 From: "maqiufang (A)" To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] WGLC: draft-ietf-netconf-https-notif-06 Thread-Index: AQHW91XvRUspf6oo7ECvf5qPey2iLapBK5iAgAHPkYCAAfb+AIACqp3Q Date: Thu, 4 Feb 2021 07:28:30 +0000 Message-ID: References: <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6.ref@yahoo.com> <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6@yahoo.com> <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-000000@email.amazonses.com> <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com> In-Reply-To: <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.100.25] Content-Type: multipart/alternative; boundary="_000_cb57b46caf25410dacb1e37b6ce91393huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 07:28:43 -0000 --_000_cb57b46caf25410dacb1e37b6ce91393huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEtlbnQ6DQoNCkkgaGF2ZSByZWFkIHRoZSBsYXRlc3QgdmVyc2lvbiBhbmQgZmluZCBpdCBt b3JlIGZsZXhpYmxlLg0KSGVyZSBjb21lcyBhIGZldyBzdWdnZXN0aW9uczoNCg0KMeOAgSBZb3Ug aGF2ZSBnb3QgYSB3cm9uZyBsaW5rIGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiAxLjEuIEl0IHN1cHBv c2VkIHRvIGJlIEFwcGVuZGl4IEEuMiwgcmF0aGVyIHRoYW4gU2VjdGlvbiA4LjIuDQoNCjLjgIEg SXQgc2VlbXMgdGhhdCB5b3UgYXJlIG1peC11c2luZyBIVFRQIGFuZCBIVFRQUyBzb21ld2hlcmUs IGZvciBleGFtcGxlLCAgIlRoZSBwcm90b2NvbCBjb25zaXN0cyBvZiB0d28gSFRUUC1iYXNlZCB0 YXJnZXQgcmVzb3VyY2VzIHByZXNlbnRlZCBieSB0aGUgcmVjZWl2ZXIiKFNob3VsZCBiZSDigJxI VFRQUy1iYXNlZOKAnSwgSSB0aGluaykuDQoNCjPjgIEgU2VjdGlvbiAzLjMvNC4yOiBXaWxsIHRo ZSByZWNlaXZlciByZXR1cm4gYSBIVFRQIDIwMC8yMDQgZGVmaW5pdGVseT8gU2hvdWxkIHdlIGNv bnNpZGVyIHNvbWUgb3RoZXIgZXh0cmVtZSBzaXR1YXRpb25zKCBlLmcuLCBub3Qgc3VwcG9ydGVk L2ltcGxlbWVudGVkKSA/IEp1c3QgbXkgaW5kaXZpZHVhbCBvcGluaW9uLjopDQoNCjTjgIEgU2Vj dGlvbiA0LjM6IFlvdSBzaG91bGQgcmVwbGFjZSAiPGV2ZW50LWNsYXNzPmZhdWx0PC9mYXVsdD4i IHdpdGggIjxldmVudC1jbGFzcz5mYXVsdDwvZXZlbnQtY2xhc3M+Ii4NCg0KUWl1ZmFuZyBNYQ0K DQpGcm9tOiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgS2VudCBXYXRzZW4NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMywgMjAyMSA2OjM0 IEFNDQpUbzogbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBXR0xDOiBk cmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDYNCg0KTkVUQ09ORiwNCg0KICAgICAgVGhl IGp1c3QgcG9zdGVkIC0wNyBhZGRyZXNzZXMgaXNzdWVzIHJhaXNlZCB0aHVzIGZhci4NCiAgICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90 aWYtMDcNCg0KSGVubmluZywgRXJpYywgUmVzaGFkLA0KDQoNCiAgICAgIFBsZWFzZSByZS1yZXZp ZXcgYXMgeW91ciBjb21tZW50cyBhcmUgaW1wb3J0YW50IHRvIHVzLg0KDQpFdmVyeW9uZSBlbHNl LA0KDQogICAgICBUaGUgaGFzbuKAmXQgYmVlbiBtYW55IHJldmlld3MgYXMgeWV0LiAgUGxlYXNl IHJldmlldyB0aGlzDQogICAgICB2ZXJzaW9uLCBhcyBpdCBpcyBzaWduaWZpY2FudGx5IGJldHRl ciAocmVhZHkgZm9yIHB1YmxpY2F0aW9uPykNCiAgICAgIHRoYW4gdGhlIHByZXZpc2lvbiB2ZXJz aW9uLg0KDQpLLg0KDQoNCg0KDQpPbiBGZWIgMSwgMjAyMSwgYXQgMTE6MzMgQU0sIFJlc2hhZCBS YWhtYW4gPHJlc2hhZEB5YWhvby5jb208bWFpbHRvOnJlc2hhZEB5YWhvby5jb20+PiB3cm90ZToN Cg0KR29vZCB3aXRoIG1lLg0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KDQpGcm9tOiBLZW50IFdhdHNl biA8a2VudCtpZXRmQHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnQraWV0ZkB3YXRzZW4ubmV0Pj4NCkRh dGU6IFN1bmRheSwgSmFudWFyeSAzMSwgMjAyMSBhdCA3OjU0IEFNDQpUbzogUmVzaGFkIFJhaG1h biA8cmVzaGFkQHlhaG9vLmNvbTxtYWlsdG86cmVzaGFkQHlhaG9vLmNvbT4+DQpDYzogIm5ldGNv bmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+IiA8bmV0Y29uZkBpZXRmLm9yZzxt YWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+LCAiZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlm QGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWZAaWV0Zi5vcmc+ IiA8ZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmQGlldGYub3JnPG1haWx0bzpkcmFmdC1p ZXRmLW5ldGNvbmYtaHR0cHMtbm90aWZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtuZXRjb25m XSBXR0xDOiBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDYNCg0KDQpJJ3ZlIHJldmll d2VkIHRoaXMgZG9jdW1lbnQgYW5kIEkgdGhpbmsgdGhlIGRvY3VtZW50IHdpbGwgYmUgcmVhZHkg b25jZSB0aGUgY2hhbmdlcyBwbGFubmVkIGJ5IHRoZSBhdXRob3JzIChyZWdhcmRpbmcgbm90aWZp Y2F0aW9uLW1lc3NhZ2VzKSBhcmUgbWFkZS4NCg0KVGhhbmtzLCBidXQgYSBjb3VwbGUgbW9yZSBw cm9ibGVtczoNCg0KMSkgdGhlIFVSTHMgYXJlIGJhZC4gIFNwZWNpZmljYWxseSwgdGhlIGV4YW1w bGUgaW4gdGhlIOKAnExlYXJuaW5nIFJlY2VpdmVyIENhcGFiaWxpdGllc+KAnSBzZWN0aW9uIHVz ZXMgYSBub25zZW5zaWNhbCBVUkwgKOKAmC/igJgpLiAgIFRoZSBhdXRob3JzIHByb3Bvc2UgdG8g aW5zdGVhZCB1c2UgYSBzdWItcmVzb3VyY2UgdG8gdGhlIHVzZXItY29uZmlndXJlZCDigJxwYXRo 4oCdIChlLmcuLCBHRVQgL3NvbWUvcGF0aC9jYXBhYmlsaXRpZXMpIGFuZCBtb3ZlIHRoZSBQT1NU IFVSTCB0byBhbm90aGVyIHN1Yi1yZXNvdXJjZSAoZS5nLiwgL3NvbWUvcGF0aC9yZWxheS1ub3Rp ZmljYXRpb24pLiAgW3NlZSBiZWxvdyBmb3IgbW9yZSBvbiB0aGlzXQ0KDQoyKSB0aGUgbWVkaWEt dHlwZXMgYXJlIGJhZDog4oCcYXBwbGljYXRpb24veWFuZy1kYXRhK1t4bWwvanNvbl3igJ0gaXMg dXNlZCBmb3Igbm90aWZpY2F0aW9ucywgd2hpY2ggaXMgd3Jvbmcgc2luY2UgdGhleSBhcmUgbm90 IFlBTkctZGVmaW5lZCwgYW5kIHRoZSBjdXN0b20gbWVkaWEtdHlwZXMgZm9yIGNhcGFiaWxpdGll cyAoYXBwbGljYXRpb24vaWV0Zi1odHRwcy1ub3RpZi1jYXArW3htbC9qc29uXSkgaXMgYSB3YXkg b3ZlcmtpbGwuICBUaGUgYXV0aG9ycyBwcm9wb3NlIHRvIHVzZSDigJxhcHBsaWNhdGlvbi9beG1s L2pzb25d4oCdIGZvciBib3RoIGNhc2VzLg0KDQoNCg0KDQpJIGhhdmUgYSBxdWVzdGlvbiBvbiB0 aGUgZm9sbG93aW5nIFlBTkcgZGVzY3JpcHRpb24uIFNlY3Rpb24gNC4xIG1lbnRpb25zICdwYXRo LWFic29sdXRlJyBmb3IgdGhlIFVSSSBidXQgdGhlIGRlc2NyaXB0aW9uIGJlbG93IHNheXMgIlJl bGF0aXZlIFVSSS4uLiIuIFNob3VsZCB0aGlzIGRlc2NyaXB0aW9uIGJlIGNsYXJpZmllZC9jb3Jy ZWN0ZWQgb3IgYW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KICAgICAgICAgICAgYXVnbWVudCAi dHJhbnNwb3J0L3Rscy90bHMvaHR0cC1jbGllbnQtcGFyYW1ldGVycyIgew0KICAgICAgICAgICAg ICBsZWFmIHBhdGggew0KICAgICAgICAgICAgICAgIHR5cGUgc3RyaW5nOw0KICAgICAgICAgICAg ICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICAgICAiUmVsYXRpdmUgVVJJIHRvIHRoZSB0 YXJnZXQgcmVzb3VyY2UuIjsNCiAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICBkZXNjcmlw dGlvbg0KICAgICAgICAgICAgICAgICJBdWdtZW50YXRpb24gdG8gYWRkIGEgcGF0aCB0byB0aGUg dGFyZ2V0IHJlc291cmNlLiI7DQogICAgICAgICAgICB9DQoNCkFncmVlZC4gIEhvdyBhYm91dCB0 aGlzPw0KDQogICAgICAgIGxlYWYgcGF0aCB7DQogICAgICAgICAgdHlwZSBzdHJpbmc7DQogICAg ICAgICAgbWFuZGF0b3J5IHRydWU7DQogICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAg ICJVUkkgcHJlZml4IHRvIHRoZSB0YXJnZXQgcmVzb3VyY2VzLiAgVW5kZXIgdGhpcw0KICAgICAg ICAgICAgIHBhdGggdGhlIHJlY2VpdmVyIG11c3Qgc3VwcG9ydCBib3RoIHRoZSAnY2FwYWJpbGl0 aWVzJw0KICAgICAgICAgICAgIGFuZCAncmVsYXktbm90aWZpY2F0aW9uJyByZXNvdXJjZSB0YXJn ZXRzLCBhcyBkZXNjcmliZWQNCiAgICAgICAgICAgICBpbiBSRkMgWFhYWC4iOw0KICAgICAgICB9 DQpTbywgaWYgcGF0aD094oCcL3NvbS9wYXRo4oCdLCBjYXBhYmlsaXR5LWRpc2NvdmVyeSB3b3Vs ZCBiZSB0byAiL3NvbWUvcGF0aC9jYXBhYmlsaXRpZXPigJ0gYW5kIG5vdGlmaWNhdGlvbnMgd291 bGQgYmUgc2VudCB0byDigJwvc29tZS9wYXRoL3JlbGF5LW5vdGlmaWNhdGlvbuKAnS4NCg0KVGhv dWdodHM/DQoNCg0KRm9ybWF0dGluZyBuaXQ6DQogICAgICAgICAgIFRydXN0IGFuY2hvcnMgKGku ZS4gQ0EgY2VydHMpIHRoYXQgYXJlIHVzZWQgdG8gYXV0aGVudGljYXRcDQogZQ0KDQpGaXhlZCwg YnV0IHRoZSBvdGhlciBleGFtcGxlIGNhbm5vdCBiZSBmaXhlZCBiZWNhdXNlIHRoZSDigJx4bWxu c+KAnSBzdHJpbmdzIGFsb25lIGFyZSB0b28gbG9uZywgYW5kIFhNTCBkb2VzbuKAmXQgaW50ZXJu YWxseSBzdXBwb3J0IGZvbGRpbmcsIGFuZCB0aGUg4oCcc3RyaW5n4oCdIHR5cGUgZG9lc27igJl0 IGFsbG93cyBmb3Igd2hpdGVzcGFjZSAoaW5jbHVkZSDigJhcbuKAmSkgYm90aCBhdCB0aGUgYmVn aW5uaW5nIGFuZCBlbmQgb2Ygc3RyaW5ncyAocmVjYWxsIG15IHJlcXVlc3QgZm9yIHJmYzY5OTEt YmlzIHRvIGRlZmluZSBhIOKAnHRva2Vu4oCdIHR5cGUgdGhhdCB3b3VsZCBlbmFibGUgdGhlIHBh cnNlciB0byBkaXNjYXJkIGFueSBmb3VuZCwgc28gb3VyIGV4YW1wbGVzIGNvdWxkIG1vcmUgb2Z0 ZW4gYmUgbWFudWFsbHktZm9sZGVkKS4NCg0KSy4NCg0K --_000_cb57b46caf25410dacb1e37b6ce91393huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0K CW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYu MHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4w cHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTY3Mzk0NTgzMTsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NDE2MDcwMjAw IDYyNjU4ODU3OCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2 NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXRleHQ6JTHjgIE7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLCBLZW50OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIHJlYWQgdGhlIGxhdGVz dCB2ZXJzaW9uIGFuZCBmaW5kIGl0IG1vcmUgZmxleGlibGUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhl cmUgY29tZXMgYSBmZXcgc3VnZ2VzdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MeOAgTxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPllvdSBoYXZl IGdvdCBhIHdyb25nIGxpbmsgYXQgdGhlIGVuZCBvZiBzZWN0aW9uIDEuMS4gSXQgc3VwcG9zZWQg dG8gYmUgQXBwZW5kaXggQS4yLCByYXRoZXIgdGhhbiBTZWN0aW9uIDguMi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4y44CBPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4NCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SXQgc2VlbXMgdGhhdCB5b3UgYXJlIG1peC11c2luZyBIVFRQIGFuZCBIVFRQUyBz b21ld2hlcmUsIGZvciBleGFtcGxlLCAmbmJzcDsmcXVvdDtUaGUgcHJvdG9jb2wgY29uc2lzdHMg b2YgdHdvIEhUVFAtYmFzZWQgdGFyZ2V0IHJlc291cmNlcyBwcmVzZW50ZWQgYnkgdGhlIHJlY2Vp dmVyJnF1b3Q7KFNob3VsZA0KIGJlIOKAnEhUVFBTLWJhc2Vk4oCdLCBJIHRoaW5rKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4z44CBPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4NCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiAzLjMvNC4yOiBXaWxsIHRoZSByZWNlaXZlciByZXR1cm4g YSBIVFRQIDIwMC8yMDQgZGVmaW5pdGVseT8gU2hvdWxkIHdlIGNvbnNpZGVyIHNvbWUgb3RoZXIg ZXh0cmVtZSBzaXR1YXRpb25zKCBlLmcuLCBub3Qgc3VwcG9ydGVkL2ltcGxlbWVudGVkKQ0KID8g SnVzdCBteSBpbmRpdmlkdWFsIG9waW5pb24uOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4044CBPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4NCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2VjdGlv biA0LjM6IFlvdSBzaG91bGQgcmVwbGFjZSAmcXVvdDsmbHQ7ZXZlbnQtY2xhc3MmZ3Q7ZmF1bHQm bHQ7L2ZhdWx0Jmd0OyZxdW90OyB3aXRoICZxdW90OyZsdDtldmVudC1jbGFzcyZndDtmYXVsdCZs dDsvZXZlbnQtY2xhc3MmZ3Q7JnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+UWl1ZmFuZyBNYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+S2VudCBXYXRzZW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBG ZWJydWFyeSAzLCAyMDIxIDY6MzQgQU08YnI+DQo8Yj5Ubzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBXR0xDOiBkcmFmdC1pZXRmLW5ldGNv bmYtaHR0cHMtbm90aWYtMDY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ORVRDT05GLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlIGp1c3QgcG9zdGVkIC0wNyBhZGRyZXNzZXMg aXNzdWVzIHJhaXNlZCB0aHVzIGZhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0w NyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1u b3RpZi0wNzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IZW5uaW5nLCBFcmljLCBSZXNoYWQs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyBQbGVhc2UgcmUtcmV2aWV3IGFzIHlvdXIgY29tbWVudHMgYXJlIGltcG9ydGFudCB0 byB1cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RXZlcnlvbmUgZWxzZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlIGhhc27igJl0IGJlZW4gbWFu eSByZXZpZXdzIGFzIHlldC4gJm5ic3A7UGxlYXNlIHJldmlldyB0aGlzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyB2ZXJzaW9uLCBhcyBpdCBpcyBzaWduaWZpY2FudGx5IGJldHRlciAocmVhZHkgZm9yIHB1Ymxp Y2F0aW9uPyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoYW4gdGhlIHByZXZpc2lvbiB2ZXJzaW9uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Sy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEZlYiAxLCAyMDIxLCBhdCAxMTozMyBBTSwgUmVzaGFkIFJhaG1hbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJlc2hhZEB5YWhvby5jb20iPnJlc2hhZEB5YWhvby5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+R29vZCB3aXRoIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVzaGFkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5L ZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldCI+ a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0PC9hPiZndDs8YnI+DQo8Yj5EYXRlOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+U3VuZGF5LCBKYW51YXJ5 IDMxLCAyMDIxIGF0IDc6NTQgQU08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJlc2hhZCBSYWhtYW4gJmx0OzxhIGhyZWY9Im1h aWx0bzpyZXNoYWRAeWFob28uY29tIj5yZXNoYWRAeWFob28uY29tPC9hPiZndDs8YnI+DQo8Yj5D Yzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPiZx dW90OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0 Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbmV0Y29uZi1o dHRwcy1ub3RpZkBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmQGlldGYu b3JnPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1uZXRjb25mLWh0 dHBzLW5vdGlmQGlldGYub3JnIj5kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWZAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW25ldGNvbmZdIFdHTEM6IGRyYWZ0LWlldGYtbmV0 Y29uZi1odHRwcy1ub3RpZi0wNjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5JJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYW5kIEkgdGhpbmsgdGhlIGRvY3VtZW50 IHdpbGwgYmUgcmVhZHkgb25jZSB0aGUgY2hhbmdlcyBwbGFubmVkIGJ5IHRoZSBhdXRob3JzIChy ZWdhcmRpbmcgbm90aWZpY2F0aW9uLW1lc3NhZ2VzKSBhcmUgbWFkZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MsIGJ1dCBhIGNvdXBsZSBtb3JlIHByb2Js ZW1zOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4xKSB0aGUgVVJMcyBhcmUgYmFkLiAmbmJzcDtTcGVjaWZp Y2FsbHksIHRoZSBleGFtcGxlIGluIHRoZSDigJxMZWFybmluZyBSZWNlaXZlciBDYXBhYmlsaXRp ZXPigJ0gc2VjdGlvbiB1c2VzIGEgbm9uc2Vuc2ljYWwgVVJMICjigJgv4oCYKS4gJm5ic3A7IFRo ZSBhdXRob3JzIHByb3Bvc2UgdG8gaW5zdGVhZCB1c2UgYSBzdWItcmVzb3VyY2UNCiB0byB0aGUg dXNlci1jb25maWd1cmVkIOKAnHBhdGjigJ0gKGUuZy4sIEdFVCAvc29tZS9wYXRoL2NhcGFiaWxp dGllcykgYW5kIG1vdmUgdGhlIFBPU1QgVVJMIHRvIGFub3RoZXIgc3ViLXJlc291cmNlIChlLmcu LCAvc29tZS9wYXRoL3JlbGF5LW5vdGlmaWNhdGlvbikuICZuYnNwO1tzZWUgYmVsb3cgZm9yIG1v cmUgb24gdGhpc108bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MikgdGhlIG1lZGlhLXR5cGVzIGFyZSBiYWQ6 IOKAnGFwcGxpY2F0aW9uL3lhbmctZGF0YSYjNDM7W3htbC9qc29uXeKAnSBpcyB1c2VkIGZvciBu b3RpZmljYXRpb25zLCB3aGljaCBpcyB3cm9uZyBzaW5jZSB0aGV5IGFyZSBub3QgWUFORy1kZWZp bmVkLCBhbmQgdGhlIGN1c3RvbSBtZWRpYS10eXBlcyBmb3IgY2FwYWJpbGl0aWVzDQogKGFwcGxp Y2F0aW9uL2lldGYtaHR0cHMtbm90aWYtY2FwJiM0MztbeG1sL2pzb25dKSBpcyBhIHdheSBvdmVy a2lsbC4gJm5ic3A7VGhlJm5ic3A7YXV0aG9ycyBwcm9wb3NlIHRvIHVzZSZuYnNwO+KAnGFwcGxp Y2F0aW9uL1t4bWwvanNvbl3igJ0gZm9yIGJvdGggY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBoYXZlIGEgcXVl c3Rpb24gb24gdGhlIGZvbGxvd2luZyBZQU5HIGRlc2NyaXB0aW9uLiBTZWN0aW9uIDQuMSBtZW50 aW9ucyAncGF0aC1hYnNvbHV0ZScgZm9yIHRoZSBVUkkgYnV0IHRoZSBkZXNjcmlwdGlvbiBiZWxv dyBzYXlzICZxdW90O1JlbGF0aXZlIFVSSS4uLiZxdW90Oy4gU2hvdWxkIHRoaXMgZGVzY3JpcHRp b24NCiBiZSBjbGFyaWZpZWQvY29ycmVjdGVkIG9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmc/PGJy Pg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YXVnbWVudCAmcXVvdDt0cmFuc3BvcnQvdGxzL3Rscy9o dHRwLWNsaWVudC1wYXJhbWV0ZXJzJnF1b3Q7IHs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtsZWFmIHBhdGggezxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3R5cGUgc3RyaW5nOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO2Rlc2NyaXB0aW9uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7UmVsYXRpdmUgVVJJIHRvIHRoZSB0YXJnZXQgcmVzb3VyY2Uu JnF1b3Q7Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtkZXNjcmlwdGlvbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZxdW90O0F1Z21lbnRhdGlvbiB0byBhZGQgYSBwYXRoIHRvIHRoZSB0 YXJnZXQgcmVzb3VyY2UuJnF1b3Q7Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BZ3JlZWQuICZuYnNwO0hvdyBhYm91dCB0aGlz PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jm5ic3A7bGVhZiZuYnNwO3BhdGgmbmJzcDt7PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO3R5cGUmbmJzcDtzdHJpbmc7PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO21hbmRhdG9yeSZuYnNwO3RydWU7PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO2Rlc2NyaXB0aW9uPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmcXVvdDtV UkkgcHJlZml4IHRvIHRoZSB0YXJnZXQgcmVzb3VyY2VzLiZuYnNwOyZuYnNwO1VuZGVyJm5ic3A7 dGhpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3BhdGggdGhlIHJlY2VpdmVyIG11c3Qgc3VwcG9ydCBib3RoIHRoZSZuYnNwOydjYXBhYmlsaXRp ZXMnPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 YW5kICdyZWxheS1ub3RpZmljYXRpb24nIHJlc291cmNlIHRhcmdldHMsIGFzJm5ic3A7ZGVzY3Jp YmVkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 aW4gUkZDIFhYWFguJnF1b3Q7Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNw O308bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TbywgaWYgcGF0aD094oCcL3NvbS9wYXRo4oCd LCBjYXBhYmlsaXR5LWRpc2NvdmVyeSB3b3VsZCBiZSB0byAmcXVvdDsvc29tZS9wYXRoL2NhcGFi aWxpdGllc+KAnSBhbmQgbm90aWZpY2F0aW9ucyB3b3VsZCBiZSBzZW50IHRvJm5ic3A74oCcL3Nv bWUvcGF0aC9yZWxheS1ub3RpZmljYXRpb27igJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRob3VnaHRz PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZvcm1hdHRpbmcgbml0Ojxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RydXN0IGFuY2hvcnMg KGkuZS4gQ0EgY2VydHMpIHRoYXQgYXJlIHVzZWQgdG8gYXV0aGVudGljYXRcPGJyPg0KJm5ic3A7 ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZpeGVkLCBidXQgdGhl IG90aGVyIGV4YW1wbGUgY2Fubm90IGJlIGZpeGVkIGJlY2F1c2UgdGhlIOKAnHhtbG5z4oCdIHN0 cmluZ3MgYWxvbmUgYXJlIHRvbyBsb25nLCBhbmQgWE1MIGRvZXNu4oCZdCBpbnRlcm5hbGx5IHN1 cHBvcnQgZm9sZGluZywgYW5kIHRoZSDigJxzdHJpbmfigJ0gdHlwZSBkb2VzbuKAmXQgYWxsb3dz DQogZm9yIHdoaXRlc3BhY2UgKGluY2x1ZGUg4oCYXG7igJkpIGJvdGggYXQgdGhlIGJlZ2lubmlu ZyBhbmQgZW5kIG9mIHN0cmluZ3MgKHJlY2FsbCBteSByZXF1ZXN0IGZvciByZmM2OTkxLWJpcyB0 byBkZWZpbmUgYSDigJx0b2tlbuKAnSB0eXBlIHRoYXQgd291bGQgZW5hYmxlIHRoZSBwYXJzZXIg dG8gZGlzY2FyZCBhbnkgZm91bmQsIHNvIG91ciBleGFtcGxlcyBjb3VsZCBtb3JlIG9mdGVuIGJl IG1hbnVhbGx5LWZvbGRlZCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Sy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_cb57b46caf25410dacb1e37b6ce91393huaweicom_-- From nobody Thu Feb 4 11:39:50 2021 Return-Path: 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 0A5883A1777 for ; Thu, 4 Feb 2021 11:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.123 X-Spam-Level: X-Spam-Status: No, score=-0.123 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, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=Vf5/tHQq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HbkoGrMM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esqS78JfDEeO for ; Thu, 4 Feb 2021 11:39:47 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABFC3A1776 for ; Thu, 4 Feb 2021 11:39:47 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A71E75C0129; Thu, 4 Feb 2021 14:39:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 04 Feb 2021 14:39:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm1; bh= uutfq1P0OlNgPdfsaR7G0jvLMPbZDyftgsPM1D4CZM8=; b=Vf5/tHQq3H0rIDWr Q/asBWik8iDUAqjH1hYetOzJCJfSyU6Bsz8BIy5NnNGD649DibESK4BFMyqziacY 8LM+ZDGInTH8i1OBWiVo0fE0RioZ2mZ9wz7Zj3NVmb+nKycdEhqrUdEfblnFgpQO DOYY+0DNI2HWUZ1AXpBuZ6gebSVSUEruRf548ZAslkyN8Gnsh/tq+HXfwJxl+CIE 6knNOT9+dmeuVCbl1WYDgfLQhuykweVCYyqyh/9lvJ/3+csNZQmScylHhsgptPEp oFfeVRm1DlN0S4tMtGpeGxLQVHhic+dp/SicTcTv46Lda6uQifXxrkl+r1wjaoDU dL22Gg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=uutfq1P0OlNgPdfsaR7G0jvLMPbZDyftgsPM1D4CZ M8=; b=HbkoGrMM4krArDcAClnEdIToZCtDWwWcxgnNtFFKHdcNnjpbnJVH5Xf9I +M3TDKHAzskRu4iM0hT/da+h210yYVv3Ps7sFj671tnVgf0cfbSrwwWTKL1vgjgh xFZ1N5IQ0ZdskgpvI4Qjn9kpXzVn3YH7vSQdEvYGj9i0ROiboZ3KdjEqo9zF84gW zA7sFbSHLPvn24RdmkGhdEBHAxvjfDgXlKX7hM9DGeRpLF+kKMEe8xWRRzHT2j1s 4Y00KnxJDbCIgBqv46iGGYFCxgZCUWdUPNN3jw18iC0kwlE4VRk6Tl2goT1f9L/M IlpC9saI5h9rhv4NIluEv0JVpAkvw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgeeggdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepfeehkefgudekfeehieehhf ekgedvffehteevgfeffeeghfdvfeeuleduvddvgfehnecuffhomhgrihhnpehivghtfhdr ohhrghenucfkphepudehkedrudejgedrgedrvdduheenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id F12FF1080064; Thu, 4 Feb 2021 14:39:45 -0500 (EST) Date: Thu, 04 Feb 2021 20:39:44 +0100 (CET) Message-Id: <20210204.203944.1533922869570231478.id@4668.se> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com> References: <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-000000@email.amazonses.com> <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 19:39:49 -0000 SGksDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50ICgtMDcpLCBhbmQgSSBqdXN0IGhh dmUgc29tZSBtaW5vcg0KY29tbWVudHMuICBUaGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuIGFu ZCBlYXN5IHRvIHVuZGVyc3RhbmQuDQoNCg0KbyAgQWJzdHJhY3QNCg0KICAgWy4uLl0gSXQgYWxz byBwcmVzZW50cyBhbiBleGFtcGxlDQogICBtb2R1bGUgZm9yIGNvbmZpZ3VyYXRpb24gd2l0aG91 dCB1c2luZyB0aGUgZGF0YSBtb2RlbCBkZWZpbmVkIGluIFJGQw0KICAgODYzOS4NCg0KICBJcyB0 aGlzIHN1Y2ggYW4gaW1wb3J0YW50IGV4YW1wbGUgdGhhdCBpdCBzaG91bGQgYmUgbWVudGlvbmVk IGluIHRoZQ0KICBhYnN0cmFjdD8gIERvZXMgdGhpcyBtZWFuIHRoYXQgdGhlIE5FVENPTkYgV0cg ZG9lc24ndCB0aGluayB0aGF0IHRoZQ0KICBkYXRhIG1vZGVsIGRlZmluZWQgaW4gUkZDIDg2Mzkg aXMgdXNlZnVsIGFueW1vcmU/ICBXaHkgaXMgYQ0KICAic2ltcGxlciIgbW9kdWxlIG5lZWRlZD8N Cg0KDQpvICAzLjEuICBBcHBsaWNhYmlsaXR5DQoNCiAgIEZvciBwdWJsaXNoZXJzIHVzaW5nIFN1 YnNjcmlwdGlvbiB0byBZQU5HIE5vdGlmaWNhdGlvbnMgW1JGQzg2MzldLA0KICAgZHluYW1pYyBk aXNjb3Zlcnkgb2YgYSByZWNlaXZlcidzIHN1cHBvcnRlZCBlbmNvZGluZyBpcyBuZWNlc3NhcnkN CiAgIG9ubHkgd2hlbiB0aGUgIi9zdWJzY3JpcHRpb25zL3N1YnNjcmlwdGlvbi9lbmNvZGluZyIg bGVhZiBpcyBub3QNCiAgIGNvbmZpZ3VyZWQsIHBlciB0aGUgImVuY29kaW5nIiBsZWFmJ3MgZGVz Y3JpcHRpb24gc3RhdGVtZW50IGluIHRoZQ0KICAgImlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRp b24iIG1vZHVsZS4gIEZJWE1FOiBkbyB0aGV5IG5lZWQgdG8NCiAgIGRpc2NvdmVyICphbnkqIGNh cGFiaWxpdGllcz8NCg0KICBOb3RlIHRoYXQgdGhlICJlbmNvZGluZyIgbGVhZiBoYXMgYSB3aGVu IGV4cHJlc3Npb24gYW5kIGlzDQogIHByZXNlbnQgb25seSBpZiB0aGUgY2hvc2VuIHRyYW5zcG9y dCBpcyBkZXJpdmVkIGZyb20NCiAgc246Y29uZmlndXJhYmxlLWVuY29kaW5nLiAgVGhlICJodHRw cyIgdHJhbnNwb3J0IGlkZW50aXR5IGlzIG5vdA0KICBkZXJpdmVkIGZyb20gc246Y29uZmlndXJh YmxlLWVuY29kaW5nLCBzbyB0aGUgImVuY29kaW5nIiBsZWFmIHdpbGwNCiAgbmV2ZXIgYmUgcHJl c2VudC4NCg0KDQozLjIuICBSZXF1ZXN0DQoNCiAgIFRvIGxlYXJuIHRoZSBjYXBhYmlsaXRpZXMg b2YgYSByZWNlaXZlciwgYSBwdWJsaXNoZXIgY2FuIGlzc3VlIGFuDQogICBIVFRQUyBHRVQgcmVx dWVzdCB0byB0aGUgImNhcGFiaWxpdGllcyIgcmVzb3VyY2UgdW5kZXIgYSBrbm93biBwYXRoDQog ICBvbiB0aGUgcmVjZWl2ZXINCg0KICBJIHRoaW5rIHlvdSBzaG91bGQgbWVudGlvbiB3aGF0IHRo aXMgImtub3duIHBhdGgiIGlzLiAgQWZ0ZXIgcmVhZGluZw0KICB0aGUgZGF0YSBtb2RlbCBpbiBk ZXRhaWwgSSB1bmRlcnN0YW5kIGhvdyBpdCB3b3JrcywgYnV0IGl0IHdvdWxkIGJlDQogIGdvb2Qg d2l0aCBhbiBlYXJseSBleHBsYW5hdGlvbiAodGhlIHBhdGggaXMgY29uZmlndXJlZCBwZXINCiAg cmVjZWl2ZXIpLg0KDQoNCm8gIDMuMw0KDQogICAgIGxlYWYtbGlzdCByZWNlaXZlci1jYXBhYmls aXR5IHsNCiAgICAgICB0eXBlIHN0cmluZyB7DQogICAgICAgICBwYXR0ZXJuICJ1cm46aWV0Zjpj YXBhYmlsaXR5Omh0dHBzLW5vdGlmLXJlY2VpdmVyOioiOw0KICAgICAgIH0NCg0KICBXaGF0J3Mg dGhlIHBvaW50IG9mIHRoZSAidXJuOi4uLiIgcHJlZml4IGlmIGl0IGlzIHJlcXVpcmVkPyAgSXQN CiAgd291bGQgYmUgc2ltcGxlciB0byBqdXN0IGhhdmUgdGhlICIqIi1wYXJ0IGluIHRoZSByZWdp c3RyeS4NCg0KICBCdXQgSSB0aGluayBhIGJldHRlciBzb2x1dGlvbiB3b3VsZCBiZQ0KDQogICAg IGxlYWYtbGlzdCByZWNlaXZlci1jYXBhYmlsaXR5IHsNCiAgICAgICB0eXBlIGluZXQ6dXJpOw0K ICAgICB9DQoNCiAgVGhpcyB3b3VsZCBiZSBtb3JlIGV4dGVuc2libGUuDQoNCg0KbyAgMy40LiAg RXhhbXBsZQ0KDQogICBUaGUgcHVibGlzaGVyIGNhbiBzZW5kIHRoZSBmb2xsb3dpbmcgcmVxdWVz dCB0byBsZWFybiB0aGUgcmVjZWl2ZXINCiAgIGNhcGFiaWxpdGllcy4gIEluIHRoaXMgZXhhbXBs ZSwgdGhlICJBY2NlcHQiIHN0YXRlcyB0aGF0IHRoZSByZWNlaXZlcg0KICAgd2FudHMgdG8gcmVj ZWl2ZSBub3RpZmljYXRpb25zIGluIFhNTCBidXQsIGlmIG5vdCBzdXBwb3J0ZWQsIHRvIHVzZQ0K ICAgSlNPTiBlbmNvZGluZy4NCg0KICBDb3B5JnBhc3RlIGVycm9yPyAgVGhlICJBY2NlcHQiIGhl YWRlciBzdGF0ZXMgdGhhdCB0aGUgY2xpZW50IHdhbnRzDQogIHRvIGdldCB0aGUgY2FwYWJpbGl0 aWVzIGFzIHhtbCwganNvbi4NCg0KDQpvICA1LjINCg0KICAgPENPREUgQkVHSU5TPiBmaWxlICJp ZXRmLXN1YnNjcmliZWQtbm90aWYtcmVjZWl2ZXJzQDIwMjEtMDItMDIueWFuZyINCiAgIFtub3Rl OiAnXCcgbGluZSB3cmFwcGluZyBmb3IgZm9ybWF0dGluZyBvbmx5XQ0KDQogICBtb2R1bGUgaWV0 Zi1zdWJzY3JpYmVkLW5vdGlmLXJlY2VpdmVycyB7DQoNCiAgUmVtb3ZlIHRoZSAibm90ZSIgbGlu ZSAobm8gIlwiIGlzIHVzZWQsIGFuZCB0aGlzIGxpbmUgc2hvdWxkIG5vdCBiZQ0KICBwYXJ0IG9m IHRoZSA8Q09ERSBCRUdJTlM+KS4NCg0KbyAgNi4yDQoNCiAgQXMgYWJvdmUsIGJ1dCBhbHNvIHJl bW92ZSB0aGUgICJcIiBpbiB0aGUgbW9kdWxlOyB0aGV5IGFyZSBub3QNCiAgbmVlZGVkLg0KDQoN Cm8gNi4yDQoNCiAgZmVhdHVyZSByZWNlaXZlci1pZGVudGl0eSB7DQogICAgZGVzY3JpcHRpb24N CiAgICAgICJJbmRpY2F0ZXMgaWYgdGhlIHNlcnZlciBzdXBwb3J0cyBmaWx0ZXJpbmcgbm90aWZp Y2F0aW9ucw0KDQogIHMvaWYvdGhhdC8NCg0KDQoNCm8gIEFwcGVuZGl4DQoNCiAgVGhlIGV4YW1w bGVzIHdvdWxkIGJlIGVhc2llciB0byByZWFkIGlmIHRoZSAiXCItbGluZSB3cmFwcGluZw0KICBj b252ZW50aW9uIHdhcyB1c2VkIG9ubHkgd2hlbiBhYnNvbHV0ZWx5IG5lZWRlZC4gIEZvciBleGFt cGxlLCB0aGlzDQogIGRvZXNuJ3QgbG9vayByaWdodDoNCg0KICAgICAgICAgICAgICAgICAgPGNs ZWFydGV4dC1wYXNzd29yZD5teS1wYXNzd29yZDwvY2xlYXJ0ZXh0LXBhc3N3b3JkXA0KPg0KDQog IEFuZCB0aGlzOg0KDQogIDxzdWJzY3JpcHRpb25zIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1s Om5zOnlhbmc6aWV0Zi1zdWJzY3JpYmVkLW5cDQpvdGlmaWNhdGlvbnMiPg0KDQogIHdvdWxkIGJl IGVhc2llciBvbiB0aGUgZXllIGFzOg0KDQogIDxzdWJzY3JpcHRpb25zDQogICAgeG1sbnM9InVy bjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyI+ DQoNCg0KDQoNCg0KL21hcnRpbg0KDQoNCg0KDQpLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNl bi5uZXQ+IHdyb3RlOg0KPiBORVRDT05GLA0KPiANCj4gICAgICAgVGhlIGp1c3QgcG9zdGVkIC0w NyBhZGRyZXNzZXMgaXNzdWVzIHJhaXNlZCB0aHVzIGZhci4NCj4gICAgICAgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0wNyA8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0wNz4N Cj4gDQo+IEhlbm5pbmcsIEVyaWMsIFJlc2hhZCwNCj4gDQo+ICAgICAgIFBsZWFzZSByZS1yZXZp ZXcgYXMgeW91ciBjb21tZW50cyBhcmUgaW1wb3J0YW50IHRvIHVzLg0KPiANCj4gRXZlcnlvbmUg ZWxzZSwNCj4gDQo+ICAgICAgIFRoZSBoYXNu4oCZdCBiZWVuIG1hbnkgcmV2aWV3cyBhcyB5ZXQu ICBQbGVhc2UgcmV2aWV3IHRoaXMNCj4gICAgICAgdmVyc2lvbiwgYXMgaXQgaXMgc2lnbmlmaWNh bnRseSBiZXR0ZXIgKHJlYWR5IGZvciBwdWJsaWNhdGlvbj8pDQo+ICAgICAgIHRoYW4gdGhlIHBy ZXZpc2lvbiB2ZXJzaW9uLg0KPiANCj4gSy4NCj4gDQo+IA0KPiANCj4gPiBPbiBGZWIgMSwgMjAy MSwgYXQgMTE6MzMgQU0sIFJlc2hhZCBSYWhtYW4gPHJlc2hhZEB5YWhvby5jb20+IHdyb3RlOg0K PiA+IA0KPiA+IEdvb2Qgd2l0aCBtZS4NCj4gPiAgDQo+ID4gUmVnYXJkcywNCj4gPiBSZXNoYWQu DQo+ID4gIA0KPiA+IEZyb206IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4NCj4g PiBEYXRlOiBTdW5kYXksIEphbnVhcnkgMzEsIDIwMjEgYXQgNzo1NCBBTQ0KPiA+IFRvOiBSZXNo YWQgUmFobWFuIDxyZXNoYWRAeWFob28uY29tPg0KPiA+IENjOiAibmV0Y29uZkBpZXRmLm9yZyIg PG5ldGNvbmZAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmQGlldGYu b3JnIiA8ZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmQGlldGYub3JnPg0KPiA+IFN1Ympl Y3Q6IFJlOiBbbmV0Y29uZl0gV0dMQzogZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmLTA2 DQo+ID4gIA0KPiA+ICANCj4gPj4gSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBJIHRo aW5rIHRoZSBkb2N1bWVudCB3aWxsIGJlIHJlYWR5IG9uY2UgdGhlIGNoYW5nZXMgcGxhbm5lZCBi eSB0aGUgYXV0aG9ycyAocmVnYXJkaW5nIG5vdGlmaWNhdGlvbi1tZXNzYWdlcykgYXJlIG1hZGUu DQo+ID4gIA0KPiA+IFRoYW5rcywgYnV0IGEgY291cGxlIG1vcmUgcHJvYmxlbXM6DQo+ID4gIA0K PiA+IDEpIHRoZSBVUkxzIGFyZSBiYWQuICBTcGVjaWZpY2FsbHksIHRoZSBleGFtcGxlIGluIHRo ZSDigJxMZWFybmluZyBSZWNlaXZlciBDYXBhYmlsaXRpZXPigJ0gc2VjdGlvbiB1c2VzIGEgbm9u c2Vuc2ljYWwgVVJMICjigJgv4oCYKS4gICBUaGUgYXV0aG9ycyBwcm9wb3NlIHRvIGluc3RlYWQg dXNlIGEgc3ViLXJlc291cmNlIHRvIHRoZSB1c2VyLWNvbmZpZ3VyZWQg4oCccGF0aOKAnSAoZS5n LiwgR0VUIC9zb21lL3BhdGgvY2FwYWJpbGl0aWVzKSBhbmQgbW92ZSB0aGUgUE9TVCBVUkwgdG8g YW5vdGhlciBzdWItcmVzb3VyY2UgKGUuZy4sIC9zb21lL3BhdGgvcmVsYXktbm90aWZpY2F0aW9u KS4gIFtzZWUgYmVsb3cgZm9yIG1vcmUgb24gdGhpc10NCj4gPiAgDQo+ID4gMikgdGhlIG1lZGlh LXR5cGVzIGFyZSBiYWQ6IOKAnGFwcGxpY2F0aW9uL3lhbmctZGF0YStbeG1sL2pzb25d4oCdIGlz IHVzZWQgZm9yIG5vdGlmaWNhdGlvbnMsIHdoaWNoIGlzIHdyb25nIHNpbmNlIHRoZXkgYXJlIG5v dCBZQU5HLWRlZmluZWQsIGFuZCB0aGUgY3VzdG9tIG1lZGlhLXR5cGVzIGZvciBjYXBhYmlsaXRp ZXMgKGFwcGxpY2F0aW9uL2lldGYtaHR0cHMtbm90aWYtY2FwK1t4bWwvanNvbl0pIGlzIGEgd2F5 IG92ZXJraWxsLiAgVGhlIGF1dGhvcnMgcHJvcG9zZSB0byB1c2Ug4oCcYXBwbGljYXRpb24vW3ht bC9qc29uXeKAnSBmb3IgYm90aCBjYXNlcy4NCj4gPiAgDQo+ID4gDQo+ID4gDQo+ID4+IEkgaGF2 ZSBhIHF1ZXN0aW9uIG9uIHRoZSBmb2xsb3dpbmcgWUFORyBkZXNjcmlwdGlvbi4gU2VjdGlvbiA0 LjEgbWVudGlvbnMgJ3BhdGgtYWJzb2x1dGUnIGZvciB0aGUgVVJJIGJ1dCB0aGUgZGVzY3JpcHRp b24gYmVsb3cgc2F5cyAiUmVsYXRpdmUgVVJJLi4uIi4gU2hvdWxkIHRoaXMgZGVzY3JpcHRpb24g YmUgY2xhcmlmaWVkL2NvcnJlY3RlZCBvciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KPiA+PiAN Cj4gPj4gICAgICAgICAgICAgYXVnbWVudCAidHJhbnNwb3J0L3Rscy90bHMvaHR0cC1jbGllbnQt cGFyYW1ldGVycyIgew0KPiA+PiAgICAgICAgICAgICAgIGxlYWYgcGF0aCB7DQo+ID4+ICAgICAg ICAgICAgICAgICB0eXBlIHN0cmluZzsNCj4gPj4gICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9u DQo+ID4+ICAgICAgICAgICAgICAgICAgICJSZWxhdGl2ZSBVUkkgdG8gdGhlIHRhcmdldCByZXNv dXJjZS4iOw0KPiA+PiAgICAgICAgICAgICAgIH0NCj4gPj4gICAgICAgICAgICAgICBkZXNjcmlw dGlvbg0KPiA+PiAgICAgICAgICAgICAgICAgIkF1Z21lbnRhdGlvbiB0byBhZGQgYSBwYXRoIHRv IHRoZSB0YXJnZXQgcmVzb3VyY2UuIjsNCj4gPj4gICAgICAgICAgICAgfQ0KPiA+ICANCj4gPiBB Z3JlZWQuICBIb3cgYWJvdXQgdGhpcz8NCj4gPiAgDQo+ID4gICAgICAgICBsZWFmIHBhdGggew0K PiA+ICAgICAgICAgICB0eXBlIHN0cmluZzsNCj4gPiAgICAgICAgICAgbWFuZGF0b3J5IHRydWU7 DQo+ID4gICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ID4gICAgICAgICAgICAgIlVSSSBwcmVmaXgg dG8gdGhlIHRhcmdldCByZXNvdXJjZXMuICBVbmRlciB0aGlzDQo+ID4gICAgICAgICAgICAgIHBh dGggdGhlIHJlY2VpdmVyIG11c3Qgc3VwcG9ydCBib3RoIHRoZSAnY2FwYWJpbGl0aWVzJw0KPiA+ ICAgICAgICAgICAgICBhbmQgJ3JlbGF5LW5vdGlmaWNhdGlvbicgcmVzb3VyY2UgdGFyZ2V0cywg YXMgZGVzY3JpYmVkDQo+ID4gICAgICAgICAgICAgIGluIFJGQyBYWFhYLiI7DQo+ID4gICAgICAg ICB9DQo+ID4gDQo+ID4gU28sIGlmIHBhdGg9PeKAnC9zb20vcGF0aOKAnSwgY2FwYWJpbGl0eS1k aXNjb3Zlcnkgd291bGQgYmUgdG8gIi9zb21lL3BhdGgvY2FwYWJpbGl0aWVz4oCdIGFuZCBub3Rp ZmljYXRpb25zIHdvdWxkIGJlIHNlbnQgdG8g4oCcL3NvbWUvcGF0aC9yZWxheS1ub3RpZmljYXRp b27igJ0uDQo+ID4gIA0KPiA+IFRob3VnaHRzPw0KPiA+ICANCj4gPiAgDQo+ID4+IEZvcm1hdHRp bmcgbml0Og0KPiA+PiAgICAgICAgICAgIFRydXN0IGFuY2hvcnMgKGkuZS4gQ0EgY2VydHMpIHRo YXQgYXJlIHVzZWQgdG8gYXV0aGVudGljYXRcDQo+ID4+ICBlDQo+ID4gIA0KPiA+IEZpeGVkLCBi dXQgdGhlIG90aGVyIGV4YW1wbGUgY2Fubm90IGJlIGZpeGVkIGJlY2F1c2UgdGhlIOKAnHhtbG5z 4oCdIHN0cmluZ3MgYWxvbmUgYXJlIHRvbyBsb25nLCBhbmQgWE1MIGRvZXNu4oCZdCBpbnRlcm5h bGx5IHN1cHBvcnQgZm9sZGluZywgYW5kIHRoZSDigJxzdHJpbmfigJ0gdHlwZSBkb2VzbuKAmXQg YWxsb3dzIGZvciB3aGl0ZXNwYWNlIChpbmNsdWRlIOKAmFxu4oCZKSBib3RoIGF0IHRoZSBiZWdp bm5pbmcgYW5kIGVuZCBvZiBzdHJpbmdzIChyZWNhbGwgbXkgcmVxdWVzdCBmb3IgcmZjNjk5MS1i aXMgdG8gZGVmaW5lIGEg4oCcdG9rZW7igJ0gdHlwZSB0aGF0IHdvdWxkIGVuYWJsZSB0aGUgcGFy c2VyIHRvIGRpc2NhcmQgYW55IGZvdW5kLCBzbyBvdXIgZXhhbXBsZXMgY291bGQgbW9yZSBvZnRl biBiZSBtYW51YWxseS1mb2xkZWQpLg0KPiA+ICANCj4gPiBLLg0KPiANCg== From nobody Fri Feb 5 00:07:16 2021 Return-Path: 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 3EC553A1D59 for ; Fri, 5 Feb 2021 00:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34C4SJL6pInP for ; Fri, 5 Feb 2021 00:07:12 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C3A8F3A1D58 for ; Fri, 5 Feb 2021 00:07:12 -0800 (PST) Received: from [10.61.207.210] (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id 3A88A1AE02AA; Fri, 5 Feb 2021 09:07:10 +0100 (CET) From: Jan Lindblad Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C761E30A-7D68-46A9-8F54-F1DBC6D324BB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 5 Feb 2021 09:07:09 +0100 In-Reply-To: <20210204.203944.1533922869570231478.id@4668.se> Cc: Netconf To: Kent Watsen , =?utf-8?Q?Martin_Bj=C3=B6rklund?= References: <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-000000@email.amazonses.com> <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com> <20210204.203944.1533922869570231478.id@4668.se> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 08:07:14 -0000 --Apple-Mail=_C761E30A-7D68-46A9-8F54-F1DBC6D324BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > o 3.3 >=20 > leaf-list receiver-capability { > type string { > pattern "urn:ietf:capability:https-notif-receiver:*"; > } >=20 > What's the point of the "urn:..." prefix if it is required? It > would be simpler to just have the "*"-part in the registry. >=20 > But I think a better solution would be >=20 > leaf-list receiver-capability { > type inet:uri; > } >=20 > This would be more extensible. +1 What's worse is that the pattern = "urn:ietf:capability:https-notif-receiver:*" above is actually not = matching strings like urn:ietf:capability:https-notif-receiver:encoding:json since YANG patterns are regexes, and not filename globbings. The pattern = above only matches the urn string followed by zero or more colon = characters. /jan --Apple-Mail=_C761E30A-7D68-46A9-8F54-F1DBC6D324BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
o  3.3

=     leaf-list receiver-capability {
=       type string {
=         pattern = "urn:ietf:capability:https-notif-receiver:*";
=       }

=  What's the point of the "urn:..." prefix if it is required? =  It
 would be simpler to just have the "*"-part = in the registry.

 But I think a = better solution would be

=     leaf-list receiver-capability {
=       type inet:uri;
=     }

 This would = be more extensible.

+1


What's worse is that the pattern = "urn:ietf:capability:https-notif-receiver:*" above is actually not = matching strings like

urn:ietf:capability:https-notif-receiver:encoding:json

since YANG patterns are = regexes, and not filename globbings. The pattern above only matches the = urn string followed by zero or more colon characters.

/jan

= --Apple-Mail=_C761E30A-7D68-46A9-8F54-F1DBC6D324BB-- From nobody Fri Feb 5 12:52:20 2021 Return-Path: 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 CC0663A0855 for ; Fri, 5 Feb 2021 12:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziqhjtOGzGkg for ; Fri, 5 Feb 2021 12:52:16 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6BB3A084D for ; Fri, 5 Feb 2021 12:52:16 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id m22so9390867ljj.4 for ; Fri, 05 Feb 2021 12:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cEYhKvPaxEypLRAtkV3h8qrjjeQHHSek6RAntrxxZHQ=; b=vbu5YtopTfQ/w9UEIg9GAg7VTSCT5S6VbaTIROgtQkGCScp5fsHSjopXLypekp27up p4seaKuvAnqD9iU7QXSVLoZotTrd27ATFzsfUqBPB7CKxo90NWfTHWRzfVIO6rMGUxsP g1LpTLtGs9/2EffL/pUKAkqQd7DlL6cvRbQDBqCCn0IKZWcubhv+cVmKAUbrvznW3Krx Z3nNlcHghw9w2Q/xV/xJ7R+RRACWzpSfJu1Vcb93t87KacMnDoudj+D4Ms5MWRFV+Wfv u8rj+STJQw4LNvjJSqjLpYcEu+kx0TidCy68OzxJyk+waCDKUEEI5xp3SPu+P8sPVeBf 1QJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cEYhKvPaxEypLRAtkV3h8qrjjeQHHSek6RAntrxxZHQ=; b=C6+aQaHphMOnu21mfG5qRU2yyG6bijAxM/+Cb521CbDBlK/0EMOfWcl+luyIV9MfgR n7+WfjkBBiEjruaN5Op6OShukudNhyzeJ+zfl1NTb1XYKahGWcCaenbdrMgvqEC4JgSp by/09cAGMpFQhtCAoWyVAg1bIrMMC7DIlqfRxZkvcuKx6d6l0/pErs+nQn2tdjb1Pdcg PMCEmFl5FPMK/HLJDs30tfqhWCgd4BxnCXvJTvTVhY4QS91dZyYl74cezzUhm2QUkiAg eHBtFT6/CtqlsV+9L75JkbYYo9eXplzrhnqvb1ro6MTL49lUwVNYFhUigf8uwBUv7/Jo KAVQ== X-Gm-Message-State: AOAM531Sx0yArQHmO4tEyoocD+GK2cDTn/FoIS8qJP6x99+QSuMFNe1i 8viz5KDOayohHDDUVIIcWtkJnumAuk5i2CqP+nLBLQ== X-Google-Smtp-Source: ABdhPJyQcipu/X3uQ9Cg6vUSaH8JiPiCONW5n/JZLgMMChp/RvwpuWwYswEMSqqBeeAEjX3DCH3YKY/C/3q68ANhyhg= X-Received: by 2002:a2e:a590:: with SMTP id m16mr3924291ljp.325.1612558334159; Fri, 05 Feb 2021 12:52:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Fri, 5 Feb 2021 12:52:03 -0800 Message-ID: To: "Rob Wilton (rwilton)" Cc: "netconf@ietf.org" , "draft-ietf-netconf-https-notif@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b002f705ba9cfe1b" Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2021 20:52:19 -0000 --000000000000b002f705ba9cfe1b Content-Type: text/plain; charset="UTF-8" Hi, I reviewed draft-07 that was just published. It seems too much of the language is limited to XML or JSON encoding. The media type extensibility should be well-defined so this draft does not have unintended limitations later on. There is a significant architectural change made without any real mention (sec. 4) In NETCONF and RESTCONF, a notification is a one-way message, meaning there is no application layer response whatsoever. That is not the case here. Instead, the publisher sends an HTTPS POST for every notification and expects a "204 No Content" response for each one. The draft should explain the reasons for this change. HTTP client implementations tend to wait for a response to a POST. That is probably not what is intended here, but no text explains the details. Sec. 4 does not mention what the publisher is supposed to do if the receiver does not send a response or sends something other than 204. It seems like this redundant ACK adds complexity and network traffic for no benefit. Andy On Thu, Jan 14, 2021 at 5:12 AM Rob Wilton (rwilton) wrote: > This message begins a two-week WGLC for draft-ietf-netconf-https-notif-06 > ending on Jan 28. Here is a direct link to the HTML version of the draft: > > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-06 > > Positive comments, e.g., "I've reviewed this document and believe it is > ready for publication", are welcome! This is useful and important, even > from authors. Objections, concerns, and suggestions are also welcomed at > this time. > > Please note, the reason that I am making this request rather than the > WG chairs is because both chairs are listed as authors on this document. > > Thank you, > Rob Wilton, OPS AD > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000b002f705ba9cfe1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I reviewed draft-07 that was just p= ublished.

It seems too much of the language is lim= ited to XML or JSON encoding.
The media type extensibility should= be well-defined so this draft
does not have unintended limitatio= ns later on.

There is a significant architectural = change made without any real mention (sec. 4)
In NETCONF and REST= CONF, a notification is a one-way message, meaning there
is no ap= plication layer response whatsoever.

That is not t= he case here. Instead, the publisher sends an HTTPS POST for every notifica= tion
and expects a "204 No Content" response for each o= ne.
The draft should explain the reasons for this change.
HTTP client implementations tend to wait for a response to a POST.
=
That is probably not what is intended here, but no text explains the d= etails.

Sec. 4 does not mention what the publisher= is supposed to do if the receiver does not
send a response or se= nds something other than 204.=C2=A0 It seems like this redundant ACK
<= div>adds complexity and network traffic for no benefit.


Andy


On Thu, Jan 14, 2021 at 5:12 = AM Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:
This message begins a two-week WGLC for = draft-ietf-netconf-https-notif-06 ending on Jan 28.=C2=A0 Here is a direct = link to the HTML version of the draft:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://too= ls.ietf.org/html/draft-ietf-netconf-https-notif-06

Positive comments, e.g., "I've reviewed this document and believe = it is ready for publication", are welcome!=C2=A0 This is useful and im= portant, even from authors.=C2=A0 Objections, concerns, and suggestions are= also welcomed at this time.

Please note, the reason that I am making this request rather than the
WG chairs is because both chairs are listed as authors on this document.
Thank you,
Rob Wilton, OPS AD

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000b002f705ba9cfe1b-- From nobody Sat Feb 6 04:51:14 2021 Return-Path: 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 27EC63A1234; Sat, 6 Feb 2021 04:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 93SCjsKEWFUb; Sat, 6 Feb 2021 04:51:11 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C613A1233; Sat, 6 Feb 2021 04:51:11 -0800 (PST) Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DXsV52Gknz67jHs; Sat, 6 Feb 2021 20:46:21 +0800 (CST) Received: from fraeml701-chm.china.huawei.com (10.206.15.50) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Sat, 6 Feb 2021 13:51:07 +0100 Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.2106.2 via Frontend Transport; Sat, 6 Feb 2021 13:51:07 +0100 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.15]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0509.000; Sat, 6 Feb 2021 20:51:05 +0800 From: Qin Wu To: "netconf@ietf.org" , "draft-ietf-netconf-https-notif@ietf.org" Thread-Topic: WGLC: draft-ietf-netconf-https-notif-06 Thread-Index: Adb8hrXL1/zYo+imSqywerXloeit7g== Date: Sat, 6 Feb 2021 12:51:04 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.101.103] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2021 12:51:13 -0000 SGksIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmDQpJIGhhdmUgcmVh ZCB0aGUgdi0wNyB0aGF0IGhhcyBqdXN0IGJlZW4gcG9zdGVkIGFuZCBoYXZlIHRoZSBmb2xsb3dp bmcgY29tbWVudHM6DQoxLiBTZWN0aW9uIDEgc2FpZDoNCiJmdXR1cmUgZWZmb3J0cyBtYXkgZGVm aW5lIHN1cHBvcnQgZm9yIG90aGVyIGVuY29kaW5ncyAoZS5nLiwgYmluYXJ5KS4iDQpXaHkgQ2Jv ciBjYW4gbm90IGJlIHN1cHBvcnRlZCBhcyBvbmUgb2YgZXhhbXBsZSBiaW5hcnkgZW5jb2Rpbmc/ IElzbid0IENPQlIgSUVURiBwdWJsaXNoZWQgc3RhbmRhcmQgd29yaz8NCg0KMi4gU2VjdGlvbiAx ICxsYXN0IHBhcmFncmFwaCBzYWlkOg0KIg0KICAgQ29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGVu YWJsZSBhIHNlcnZlciwgYWN0aW5nIGFzIGEgcHVibGlzaGVyIG9mDQogICBub3RpZmljYXRpb25z LCB0byBwcm9hY3RpdmVseSBwdXNoIG5vdGlmaWNhdGlvbnMgdG8gZXh0ZXJuYWwNCiAgIHJlY2Vp dmVycyB3aXRob3V0IHRoZSByZWNlaXZlcnMgbmVlZGluZyB0byBmaXJzdCBjb25uZWN0IHRvIHRo ZQ0KICAgc2VydmVyLCBhcyBpcyB0aGUgY2FzZSB3aXRoIGR5bmFtaWMgc3Vic2NyaXB0aW9ucy4N CiINCkkgd2FudCB0byBtYWtlIHN1cmUgdHdvIHRoaW5ncyB0aGlzIHBhcmFncmFwaCB3YW50IHRv IGNvbnZleToNCjEuCVNvIGNhbGwgaG9tZSBpcyBub3QgbmVlZGVkIGluIHRoaXMgY2FzZSB0byBl c3RhYmxpc2ggc2VydmljZSBpbml0aWF0ZWQgUkVTVENPTkYgY29ubmVjdGlvbg0KMi4gICBUaGUg Y29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBzZXJ2ZXIgYW5kIHRoZSByZWNpdmVyIGlzIHNob3J0IGxp dmUgY29ubmVjdGlvbiByYXRoZXIgdGhhbiBsb25nIGxpdmUgY29ubmVjdGlvbj8gQ29ycmVjdD8N Cg0KMy4gU2VjdGlvbiAyIHNhaWQ6DQoiDQogICBUaGUgcHJvdG9jb2wgY29uc2lzdHMgb2YgdHdv IEhUVFAtYmFzZWQgdGFyZ2V0IHJlc291cmNlcyBwcmVzZW50ZWQgYnkNCiAgIHRoZSByZWNlaXZl cjoNCiINCklzIHRhcmdldCByZXNvdXJjZSB0YXJnZXQgVVJJPyBDYW4geW91IHByb3ZpZGUgYSBy ZWZlcmVuY2UgZm9yIHRhcmdldCByZXNvdXJjZT8NCg0KNC4gU2VjdGlvbiAyIHNlY29uZCBidWxs ZXQgc2FpZDoNCiINCmEgZnV0dXJlIGVmZm9ydCBNQVkgZXh0ZW5kIHRoZSBwcm90b2NvbCB0byBz ZW5kIG11bHRpcGxlIG5vdGlmaWNhdGlvbnMgcGVyIG1lc3NhZ2UuDQoiDQpXaGF0IGRvIHlvdSBp bmRpY2F0ZSBmb3Igc2VuZGluZyBtdWx0aXBsZSBub3RpZmljYXRpb24gcGVyIG1lc3NhZ2U/IFNo b3VsZCB5b3UgYWRkIHJlZmVyZW5jZSB0byBtZXNzYWdlIGhlYWRlciBhbmQgYnVuZGxlIGRyYWZ0 LGkuZS4sIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXM/DQoNCjUuIFNl Y3Rpb24gNC4xIHNhaWQ6DQoiDQogICBUaGUgcHVibGlzaGVyIHNlbmRzIGFuIEhUVFBTIFBPU1Qg cmVxdWVzdCB0byB0aGUgInJlbGF5LQ0KICAgbm90aWZpY2F0aW9ucyIgIHJlc291cmNlIHVuZGVy IGEga25vd24gcGF0aCBvbiB0aGUgcmVjZWl2ZXINCiINCldoZXJlIHJlbGF5LSBub3RpZmljYXRp b25zIiByZXNvdXJjZSBpcyBkZWZpbmVkPyBJbiB3aGljaCBSRkM/IENhbiB5b3UgcHJvdmlkZSBh IHJlZmVyZW5jZSB0byBpdC4gSXQgaXMgYSBzdXJwcmlzZSB0byBzZWUgobByZWxheS1ub3RpZmlj YXRpb26hsSBhcHBlYXJlZCB3aXRob3V0IGFueSBjb250ZXh0IGluZm9ybWF0aW9uIA0KdG8gYmUg bGFpZCBvdXQgZm9yIHRoaXM/IEUuZy4sIHdoeSByZWxheS1ub3RpZmljYXRpb24gaXMgcGlja2Vk PyBJcyB0aGVyZSBhbnkgb3RoZXIgY2hvaWNlPw0KDQo2LiBTZWN0aW9uIDQuMSBzYWlkOg0KIg0K SW5zdGVhZCBvZiBzYXlpbmcgdGhhdCwgZm9yIEpTT04tZW5jb2RpbmcgcHVycG9zZXMsIHRoZSBt b2R1bGUNCm5hbWUgZm9yIHRoZSAibm90aWZpY2F0aW9uIiBlbGVtZW50IGlzICJpZXRmLXJlc3Rj b25mLCB0aGUgbW9kdWxlDQpuYW1lIHdpbGwgaW5zdGVhZCBieSAiaWV0Zi1odHRwcy1ub3RpZiIu DQoiDQpzL3RoZSBtb2R1bGUgbmFtZSB3aWxsIGluc3RlYWQgYnkvdGhlIG1vZHVsZSBuYW1lIHdp bGwgYmUgaW5zdGVhZCBieQ0KDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogbmV0 Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBSb2IgV2lsdG9uIChy d2lsdG9uKQ0Kt6LLzcqxvOQ6IDIwMjHE6jHUwjE0yNUgMjE6MTINCsrVvP7IyzogbmV0Y29uZkBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmQGlldGYub3JnDQrW98ziOiBb bmV0Y29uZl0gV0dMQzogZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmLTA2DQoNClRoaXMg bWVzc2FnZSBiZWdpbnMgYSB0d28td2VlayBXR0xDIGZvciBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0 cHMtbm90aWYtMDYgZW5kaW5nIG9uIEphbiAyOC4gIEhlcmUgaXMgYSBkaXJlY3QgbGluayB0byB0 aGUgSFRNTCB2ZXJzaW9uIG9mIHRoZSBkcmFmdDoNCg0KCWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDYNCg0KUG9zaXRpdmUgY29tbWVu dHMsIGUuZy4sICJJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYW5kIGJlbGlldmUgaXQgaXMg cmVhZHkgZm9yIHB1YmxpY2F0aW9uIiwgYXJlIHdlbGNvbWUhICBUaGlzIGlzIHVzZWZ1bCBhbmQg aW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy4gIE9iamVjdGlvbnMsIGNvbmNlcm5zLCBhbmQg c3VnZ2VzdGlvbnMgYXJlIGFsc28gd2VsY29tZWQgYXQgdGhpcyB0aW1lLg0KDQpQbGVhc2Ugbm90 ZSwgdGhlIHJlYXNvbiB0aGF0IEkgYW0gbWFraW5nIHRoaXMgcmVxdWVzdCByYXRoZXIgdGhhbiB0 aGUgV0cgY2hhaXJzIGlzIGJlY2F1c2UgYm90aCBjaGFpcnMgYXJlIGxpc3RlZCBhcyBhdXRob3Jz IG9uIHRoaXMgZG9jdW1lbnQuDQoNClRoYW5rIHlvdSwNClJvYiBXaWx0b24sIE9QUyBBRA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0Y29uZiBt YWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Mon Feb 8 20:27:12 2021 Return-Path: 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 4980A3A18D5; Mon, 8 Feb 2021 20:27:05 -0800 (PST) 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 hT0td8yn_JdN; Mon, 8 Feb 2021 20:27:02 -0800 (PST) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 14CD63A18DA; Mon, 8 Feb 2021 20:26:58 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id my11so869211pjb.1; Mon, 08 Feb 2021 20:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OVOUtULNLl2QWPqSgPYp4Q9vKtyUjmbFyyZlBlBQgLY=; b=fwCKcPZNsr0QXnqNsPvRjK47MD3OEmqhp1Wx4s31/OcBgVLzc+rxaAt8LtQD4a2T9x YHlVN5xc3n9AqIv4lr6nwgPtA5HjlP3pHYz4iDQgE9atJe3HZp2POvgvDV0v7seyil9d oKXcGkIbTpffz63WyXHe1t70BRprJDTxdGk2gja21ht+SezZi+6YTKMeOPSM36Tb1+zH zhnL0EwS6CPmTakqLFft8TCVOsQDw12JUQSYA6tR6RGmyaKqfS6DgrWGSH9+Mi8Vykjh 3BTfqBJ8NTvUkgFCqgeUqGhktTAWJrmcD5V4cM0yVDuSifwwfeRxfWCpLMVOr8Qdr3zD NWyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OVOUtULNLl2QWPqSgPYp4Q9vKtyUjmbFyyZlBlBQgLY=; b=ot3QTS+PGrSgYwU8hu5zi0Bz1hc3uyG4hE7eVs+3scmmGob68Ceqmz/4i824BDKQXp YM3T/+lF2FK/dp8JTwyg1Ya1A1IDiY5UmKPsLvpmhsc7deKRcgwF6QeTMCXS4q4JNRCn 4oRr2ACT56jel+JI71FlUxriEXDKs2oWL75cBKSRdNwrLx6U4ZBz6hn2oqZC6UnT0Day cab1DJbheGtCehMJMO/Xhzf8GWHC6YgjHQZlsoqYxELkc8wAhukxWxGdbo9cp6r452oO XKP+m7G7Wr1kHjm2kOiat9SFk3NDBAXvwKgaoTzAOuYvQ5yCmSvWT0YB0EbBWWzUo0MV gZkg== X-Gm-Message-State: AOAM532BCGdIRouzwwaLuk/2LdqO56ufRTlzRwBeiXhDixcn7XuGGi0b DOYwFy81jqYBimlV0cvOXtc= X-Google-Smtp-Source: ABdhPJw4f6x6dH8HnDrTYxG3Co47/1ECszb39TZaJUcaHi+Xbdh4ydf0VCwq4EtPJ9N4Pl/QuATyTw== X-Received: by 2002:a17:902:7c11:b029:e1:8692:9137 with SMTP id x17-20020a1709027c11b02900e186929137mr19869673pll.50.1612844818276; Mon, 08 Feb 2021 20:26:58 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:a506:3d59:a640:5116? ([2601:647:5600:5020:a506:3d59:a640:5116]) by smtp.gmail.com with ESMTPSA id h15sm16860260pfo.193.2021.02.08.20.26.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2021 20:26:57 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4B7053B2-CE3A-4C68-87ED-47E84A1402F2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 8 Feb 2021 20:26:56 -0800 In-Reply-To: <161176691048.5494.2373231790931856179@ietfa.amsl.com> Cc: yang-doctors@ietf.org, draft-ietf-netconf-https-notif.all@ietf.org, last-call@ietf.org, netconf@ietf.org To: Acee Lindem References: <161176691048.5494.2373231790931856179@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 04:27:05 -0000 --Apple-Mail=_4B7053B2-CE3A-4C68-87ED-47E84A1402F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Acee, Thank you first of all for the review of the document. You reviewed -06, = and we have since submitted -07. I will in my responses reflect the = changes in -07 that might affect the comments you have provided. > On Jan 27, 2021, at 9:01 AM, Acee Lindem via Datatracker = wrote: >=20 > Reviewer: Acee Lindem > Review result: Almost Ready >=20 > The document is almost ready for WG Last Call. I have the following = comments: >=20 > Model ietf-sub-notif-recv-list: >=20 > Seems odd to have a model that adds a choice statement without any > valid options. I realize you expect other transports in the future = but > having a separate module the one defined in the same draft seems = like a > profligate design choice. The draft contains two models as you have noted. While the = ietf-sub-notif-recv-list adds a choice statement, the second model goes = on to adding a case statement for that choice statement. We could have = hard coded the two models together, but believe that by separating them, = we offer the flexibility to implementations that may choose not to = implement both the models. Also, other transports can augment = "receiver-instances", without including the entire http transport model. If it helps, we can add a comment to that effect in the model to explain = our motivation. >=20 > Model ietf-sub-notif-recv-list: > 1. The prefix "hn" seems inconsistent to lose the context. I'd use > "snrlhn". This wouldn't be an issue if you combined the = modules. The updated model in -07 now carries the prefix =E2=80=9Chnt=E2=80=9D. > 2. This comment is incomprehensible: >=20 > // create the logical impossibility of enabling "tcp" > // transport Would it help if we expanded the comment to say: // The "http-client-stack-grouping=E2=80=9D supports both HTTP and HTTPS = stacks by default. This draft, however supports HTTPS only. The = following=20 // if-feature statement makes it logically impossible to configure HTTP = transport. >=20 > In the IANA section, the security considerations for the media types > point to this draft's security considerations. However, they don't > include the referenced information. It seems these IANA references > should point to other RFCs. The updated IANA section no longer carries the media-types. >=20 > It should be noted that ietf-subscribed-notifications has a number of = YANG > errors and warnings. >=20 > I also have the following editorial comments: > Acee-Lindems-iMac-2:Desktop acee$ diff -c > draft-ietf-netconf-https-notif-06.txt.orig > draft-ietf-netconf-https-notif-06.txt *** > draft-ietf-netconf-https-notif-06.txt.orig 2021-01-27 = 10:06:29.000000000 -0500 > --- draft-ietf-netconf-https-notif-06.txt 2021-01-27 = 11:57:13.000000000 > -0500 > *************** > *** 17,23 **** > This document defines a YANG data module for configuring HTTPS = based > configured subscription, as defined in RFC 8639. The use of HTTPS > maximizes transport-level interoperability, while allowing for > ! encoding selection from text, e.g. XML or JSON, to binary. >=20 > Status of This Memo >=20 > --- 17,23 ---- > This document defines a YANG data module for configuring HTTPS = based > configured subscription, as defined in RFC 8639. The use of HTTPS > maximizes transport-level interoperability, while allowing for > ! encoding selection from text, e.g., XML or JSON, to binary. The abstract section has been updated. >=20 > Status of This Memo >=20 > *************** > *** 103,109 **** > documents. This document defines two YANG 1.1 [RFC7950] data > modules, one for augmenting the Subscription to YANG Notifications > [RFC8639] to add a transport type, and another for configuring and > ! managing HTTPS based receivers for the notifications. >=20 > --- 103,109 ---- > documents. This document defines two YANG 1.1 [RFC7950] data > modules, one for augmenting the Subscription to YANG Notifications > [RFC8639] to add a transport type, and another for configuring and > ! managing HTTPS-based receivers for the notifications. Fixed. >=20 > *************** > *** 118,124 **** > the same receiver instance. The second module describes how to > enable the transmission of YANG modeled notifications, in the > configured encoding (i.e., XML, JSON) over HTTPS. Notifications = are > ! delivered in the form of a HTTPS POST. The use of HTTPS = maximizes > transport-level interoperability, while the encoding selection = pivots > between implementation simplicity (XML, JSON) and throughput (text > versus binary). > --- 118,124 ---- > the same receiver instance. The second module describes how to > enable the transmission of YANG modeled notifications, in the > configured encoding (i.e., XML, JSON) over HTTPS. Notifications = are > ! delivered in the form of an HTTPS POST. The use of HTTPS = maximizes > transport-level interoperability, while the encoding selection = pivots > between implementation simplicity (XML, JSON) and throughput (text > versus binary). > *************** Fixed. > *** 196,202 **** >=20 > In the case of "pipelining", the flow of messages would look > something like this. This example shows the flow assuming that > ! Subscribed Notifications is used and therefore a started> notification is sent before sending the first = notification. > The example would be the same for when Subscribed Notification is = not > used by removing the first POST message for = . > --- 196,202 ---- >=20 > In the case of "pipelining", the flow of messages would look > something like this. This example shows the flow assuming that > ! Subscribed Notification is used and therefore a started> notification is sent before sending the first = notification. > The example would be the same for when Subscribed Notification is = not > used by removing the first POST message for = . > *************** This section has been rewritten. > *** 342,350 **** >=20 > 2.1. Introduction >=20 > ! To learn the capabilities of the receiver, the publisher can = issue a > HTTPS GET request with Accept-Type set to application/ietf-https- > ! notif-cap+xml or application/ietf-https-notif-cap+json, with = latter > as the mandatory to implement, and the default in case the type is > not specified. If the receiver supports capabilities such as = binary > encoding of data, it can return that as a capability in a = response. > --- 342,350 ---- >=20 > 2.1. Introduction >=20 > ! To learn the capabilities of the receiver, the publisher can = issue an > HTTPS GET request with Accept-Type set to application/ietf-https- > ! notif-cap+xml or application/ietf-https-notif-cap+json, with the = latter > as the mandatory to implement, and the default in case the type is > not specified. If the receiver supports capabilities such as = binary > encoding of data, it can return that as a capability in a = response. > *************** Fixed. > *** 450,456 **** > Internet-Draft HTTPS Configured Subscription November = 2020 >=20 > ! Copyright (c) 2018 IETF Trust and the persons identified as > the document authors. All rights reserved. > Redistribution and use in source and binary forms, with or > without modification, is permitted pursuant to, and subject > --- 450,456 ---- > Internet-Draft HTTPS Configured Subscription November = 2020 >=20 > ! Copyright (c) 2021 IETF Trust and the persons identified as > the document authors. All rights reserved. > Redistribution and use in source and binary forms, with or > without modification, is permitted pursuant to, and subject > *************** Fixed. > *** 536,545 **** >=20 > This YANG module is a definition of a set of receivers that are > interested in the notifications published by the publisher. The > ! module contains the TCP, TLS and HTTPS parameters that are needed = to > communicate with the receiver. The module augments the ietf-sub- > notif-recv-list module to define a transport specific receiver. = As > ! mentioned earlier, it uses POST method to deliver the = notification. > The attribute 'path' defines the path for the resource on the > receiver, as defined by 'path-absolute' in URI Generic Syntax > [RFC3986]. The user-id used by Network Configuration Access = Control > --- 536,545 ---- >=20 > This YANG module is a definition of a set of receivers that are > interested in the notifications published by the publisher. The > ! module contains the TCP, TLS, and HTTPS parameters that are = needed to > communicate with the receiver. The module augments the ietf-sub- > notif-recv-list module to define a transport specific receiver. = As > ! mentioned earlier, it uses the POST method to deliver the = notification. > The attribute 'path' defines the path for the resource on the > receiver, as defined by 'path-absolute' in URI Generic Syntax > [RFC3986]. The user-id used by Network Configuration Access = Control > *************** This section of the module has been rewritten. > *** 639,645 **** > description > "YANG module for configuring HTTPS base configuration. >=20 > ! Copyright (c) 2018 IETF Trust and the persons identified as > the document authors. All rights reserved. > Redistribution and use in source and binary forms, with or > without modification, is permitted pursuant to, and subject > --- 639,645 ---- > description > "YANG module for configuring HTTPS base configuration. >=20 > ! Copyright (c) 2021 IETF Trust and the persons identified as > the document authors. All rights reserved. > Redistribution and use in source and binary forms, with or > without modification, is permitted pursuant to, and subject > *************** Fixed. > *** 704,710 **** >=20 > container receiver-identity { > description > ! "Specifies mechanism for identifying the receiver. > The publisher MUST NOT include any content in a > notification that the user is not authorized to = view."; >=20 > --- 704,710 ---- >=20 > container receiver-identity { > description > ! "Specifies the mechanism for identifying the = receiver. > The publisher MUST NOT include any content in a > notification that the user is not authorized to = view."; >=20 > *************** This description statement has been updated. > *** 791,801 **** >=20 > 6. Receiving Event Notifications >=20 > ! Encoding notifications for the HTTPS notifications is the same as = the > encoding notifications as defined in RESTCONF [RFC8040] Section = 6.4, > with the following changes. Instead of saying that for = JSON-encoding > purposes, the module name for "notification" element will be = "ietf- > ! restconf, it will say that for JSON-encoding purposes, the module > name for "notification" element will be "ietf-https-notif". >=20 > With those changes, the SSE event notification encoded JSON = example > --- 791,801 ---- >=20 > 6. Receiving Event Notifications >=20 > ! Encoding notifications for the HTTPS notifications is the same as = for > encoding notifications as defined in RESTCONF [RFC8040] Section = 6.4, > with the following changes. Instead of saying that for = JSON-encoding > purposes, the module name for "notification" element will be = "ietf- > ! restconf", it will say that for JSON-encoding purposes, the = module > name for "notification" element will be "ietf-https-notif". >=20 > With those changes, the SSE event notification encoded JSON = example > *************** This and all the following sections have been updated.=20 Thanks. > *** 815,826 **** >=20 > 7. IANA Considerations >=20 > ! This document registers two URI, two YANG module and two Media = Types. >=20 > 7.1. URI Registration >=20 > in the IETF XML registry [RFC3688]. Following the format in RFC > ! 3688, the following registration is requested to be made: >=20 > URI: urn:ietf:params:xml:ns:yang:ietf-http-notif > URI: urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list > --- 815,826 ---- >=20 > 7. IANA Considerations >=20 > ! This document registers two URIs, two YANG modules, and two Media = Types. >=20 > 7.1. URI Registration >=20 > in the IETF XML registry [RFC3688]. Following the format in RFC > ! 3688, the following registrations are requested to be made: >=20 > URI: urn:ietf:params:xml:ns:yang:ietf-http-notif > URI: urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list > *************** > *** 854,860 **** >=20 > 7.3. Media Types >=20 > ! 7.3.1. Media Type "application/ietf-https-notif-cap+xml >=20 > Type name: application >=20 > --- 854,860 ---- >=20 > 7.3. Media Types >=20 > ! 7.3.1. Media Type "application/ietf-https-notif-cap+xml" >=20 > Type name: application >=20 > *************** > *** 917,923 **** >=20 > Provisional registration? (standards tree only): no >=20 > ! 7.3.2. Media Type "application/ietf-https-notif-cap+json >=20 > Type name: application >=20 > --- 917,923 ---- >=20 > Provisional registration? (standards tree only): no >=20 > ! 7.3.2. Media Type "application/ietf-https-notif-cap+json" >=20 > Type name: application >=20 > *************** > *** 1106,1112 **** > >=20 > ! 8.2. Non Subscribed Notification based Configuration >=20 > In the case that it is desired to use HTTPS notif outside of > Subscribed Notifications, there would have to be a module to = define > --- 1106,1112 ---- > >=20 > ! 8.2. Non-Subscribed Notification based Configuration >=20 > In the case that it is desired to use HTTPS notif outside of > Subscribed Notifications, there would have to be a module to = define >=20 > Thanks, > Acee >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_4B7053B2-CE3A-4C68-87ED-47E84A1402F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Acee,

Thank you = first of all for the review of the document. You reviewed -06, and we = have since submitted -07. I will in my responses reflect the changes in = -07 that might affect the comments you have provided.

On Jan 27, 2021, at 9:01 AM, Acee Lindem via Datatracker = <noreply@ietf.org> wrote:

Reviewer: Acee Lindem
Review result: Almost = Ready

The document is almost ready for WG = Last Call. I have the following comments:

Model ietf-sub-notif-recv-list:

=    Seems odd to have a model that adds a choice statement = without any
   valid options. I realize = you expect other transports in the future but
=    having a separate module the one defined in the same = draft seems like a
   profligate design = choice.

The draft contains two models as you have noted. While = the ietf-sub-notif-recv-list adds a choice statement, the second model = goes on to adding a case statement for that choice statement. We could = have hard coded the two models together, but believe that by separating = them, we offer the flexibility to implementations that may choose not to = implement both the models. Also, other transports can augment = "receiver-instances", without including the entire http transport = model.

If it helps, we can add a = comment to that effect in the model to explain our = motivation.


Model = ietf-sub-notif-recv-list:
   1. The prefix = "hn" seems inconsistent to lose the context. I'd use
=        "snrlhn".  This wouldn't = be an issue if you combined the modules.

The = updated model in -07 now carries the prefix =E2=80=9Chnt=E2=80=9D.

   2. This comment is = incomprehensible:

=             &n= bsp; // create the logical impossibility of enabling "tcp"
=             &n= bsp; // transport

Would it help if we expanded the comment to = say:

// The = "http-client-stack-grouping=E2=80=9D supports both HTTP and HTTPS stacks = by default. This draft, however supports HTTPS only. The = following 
// if-feature statement makes it logically = impossible to configure HTTP transport.


In the IANA section, the security = considerations for the media types
point to this draft's = security considerations. However, they don't
include the = referenced information. It seems these IANA references
should point to other RFCs.

The = updated IANA section no longer carries the media-types.


It should be noted that = ietf-subscribed-notifications has a number of YANG
errors = and warnings.

I also have the following = editorial comments:
Acee-Lindems-iMac-2:Desktop acee$ diff -c
draft-ietf-netconf-https-notif-06.txt.orig
draft-ietf-netconf-https-notif-06.txt ***
draft-ietf-netconf-https-notif-06.txt.orig  2021-01-27 = 10:06:29.000000000 -0500
--- = draft-ietf-netconf-https-notif-06.txt =       2021-01-27 11:57:13.000000000
-0500
***************
*** 17,23 = ****
    This document defines a YANG = data module for configuring HTTPS based
=     configured subscription, as defined in RFC 8639. =  The use of HTTPS
    maximizes = transport-level interoperability, while allowing for
! =    encoding selection from text, e.g.  XML or JSON, = to binary.

 Status of This Memo

--- 17,23 ----
=     This document defines a YANG data module for = configuring HTTPS based
=     configured subscription, as defined in RFC 8639. =  The use of HTTPS
    maximizes = transport-level interoperability, while allowing for
! =    encoding selection from text, e.g.,  XML or JSON, = to binary.

The abstract section has been updated.


 Status of This Memo

***************
*** 103,109 ****
=     documents.  This document defines two YANG = 1.1 [RFC7950] data
    modules, one = for augmenting the Subscription to YANG Notifications
=     [RFC8639] to add a transport type, and another = for configuring and
!    managing HTTPS = based receivers for the notifications.

--- = 103,109 ----
    documents. =  This document defines two YANG 1.1 [RFC7950] data
=     modules, one for augmenting the Subscription to = YANG Notifications
    [RFC8639] to = add a transport type, and another for configuring and
! =    managing HTTPS-based receivers for the = notifications.

Fixed.


***************
*** 118,124 ****
=     the same receiver instance.  The second = module describes how to
    enable = the transmission of YANG modeled notifications, in the
=     configured encoding (i.e., XML, JSON) over = HTTPS.  Notifications are
! =    delivered in the form of a HTTPS POST.  The use = of HTTPS maximizes
=     transport-level interoperability, while the = encoding selection pivots
    between = implementation simplicity (XML, JSON) and throughput (text
=     versus binary).
--- 118,124 = ----
    the same receiver instance. =  The second module describes how to
=     enable the transmission of YANG modeled = notifications, in the
    configured = encoding (i.e., XML, JSON) over HTTPS.  Notifications are
!    delivered in the form of an HTTPS POST. =  The use of HTTPS maximizes
=     transport-level interoperability, while the = encoding selection pivots
    between = implementation simplicity (XML, JSON) and throughput (text
=     versus binary).
***************

Fixed.

*** 196,202 ****

    In the case of = "pipelining", the flow of messages would look
=     something like this.  This example shows = the flow assuming that
!    Subscribed = Notifications is used and therefore a <subscription-
=     started> notification is sent before sending = the first notification.
    The = example would be the same for when Subscribed Notification is not
    used by removing the first POST = message for <susbscription-started>.
--- 196,202 = ----

    In the case = of "pipelining", the flow of messages would look
=     something like this.  This example shows = the flow assuming that
!    Subscribed = Notification is used and therefore a <subscription-
=     started> notification is sent before sending = the first notification.
    The = example would be the same for when Subscribed Notification is not
    used by removing the first POST = message for <susbscription-started>.
***************
This section has been rewritten.

*** 342,350 ****

 2.1. =  Introduction

!    To = learn the capabilities of the receiver, the publisher can issue a
    HTTPS GET request with Accept-Type = set to application/ietf-https-
! =    notif-cap+xml or = application/ietf-https-notif-cap+json, with latter
=     as the mandatory to implement, and the default = in case the type is
    not = specified.  If the receiver supports capabilities such as binary
    encoding of data, it can return that = as a capability in a response.
--- 342,350 ----

 2.1.  Introduction
!    To learn the capabilities of the = receiver, the publisher can issue an
=     HTTPS GET request with Accept-Type set to = application/ietf-https-
!    notif-cap+xml = or application/ietf-https-notif-cap+json, with the latter
=     as the mandatory to implement, and the default = in case the type is
    not = specified.  If the receiver supports capabilities such as binary
    encoding of data, it can return that = as a capability in a response.
***************

Fixed.

*** 450,456 ****
 Internet-Draft =        HTTPS Configured Subscription =        November 2020

!      Copyright (c) 2018 IETF Trust = and the persons identified as
=       the document authors.  All = rights reserved.
=       Redistribution and use in source and = binary forms, with or
=       without modification, is permitted = pursuant to, and subject
--- 450,456 ----
=  Internet-Draft        HTTPS = Configured Subscription =        November 2020

!      Copyright (c) 2021 IETF Trust = and the persons identified as
=       the document authors.  All = rights reserved.
=       Redistribution and use in source and = binary forms, with or
=       without modification, is permitted = pursuant to, and subject
***************

Fixed.

*** 536,545 ****

    This YANG module is a = definition of a set of receivers that are
=     interested in the notifications published by the = publisher.  The
!    module contains = the TCP, TLS and HTTPS parameters that are needed to
=     communicate with the receiver.  The module = augments the ietf-sub-
=     notif-recv-list module to define a transport = specific receiver.  As
!    mentioned = earlier, it uses POST method to deliver the notification.
=     The attribute 'path' defines the path for the = resource on the
    receiver, as = defined by 'path-absolute' in URI Generic Syntax
=     [RFC3986].  The user-id used by Network = Configuration Access Control
--- 536,545 ----

    This YANG module is a = definition of a set of receivers that are
=     interested in the notifications published by the = publisher.  The
!    module contains = the TCP, TLS, and HTTPS parameters that are needed to
=     communicate with the receiver.  The module = augments the ietf-sub-
=     notif-recv-list module to define a transport = specific receiver.  As
!    mentioned = earlier, it uses the POST method to deliver the notification.
    The attribute 'path' defines the = path for the resource on the
=     receiver, as defined by 'path-absolute' in URI = Generic Syntax
    [RFC3986]. =  The user-id used by Network Configuration Access Control
***************
This section of the module has been = rewritten.

*** 639,645 ****
=       description
=         "YANG module for = configuring HTTPS base configuration.

! =         Copyright (c) 2018 IETF = Trust and the persons identified as
=          the document = authors.  All rights reserved.
=          Redistribution and = use in source and binary forms, with or
=          without = modification, is permitted pursuant to, and subject
--- = 639,645 ----
=       description
=         "YANG module for = configuring HTTPS base configuration.

! =         Copyright (c) 2021 IETF = Trust and the persons identified as
=          the document = authors.  All rights reserved.
=          Redistribution and = use in source and binary forms, with or
=          without = modification, is permitted pursuant to, and subject
***************
Fixed.

*** 704,710 = ****

=             co= ntainer receiver-identity {
=             &n= bsp; description
! =             &n= bsp;  "Specifies mechanism for identifying the receiver.
=             &n= bsp;    The publisher MUST NOT include any content = in a
=             &n= bsp;    notification that the user is not authorized = to view.";

--- 704,710 ----
=             co= ntainer receiver-identity {
=             &n= bsp; description
! =             &n= bsp;  "Specifies the mechanism for identifying the = receiver.
=             &n= bsp;    The publisher MUST NOT include any content = in a
=             &n= bsp;    notification that the user is not authorized = to view.";

***************

This = description statement has been updated.

*** 791,801 ****

 6. =  Receiving Event Notifications

! =    Encoding notifications for the HTTPS notifications is = the same as the
    encoding = notifications as defined in RESTCONF [RFC8040] Section 6.4,
=     with the following changes.  Instead of = saying that for JSON-encoding
=     purposes, the module name for "notification" = element will be "ietf-
!    restconf, it = will say that for JSON-encoding purposes, the module
=     name for "notification" element will be = "ietf-https-notif".

=     With those changes, the SSE event notification = encoded JSON example
--- 791,801 ----

 6.  Receiving Event Notifications
!    Encoding notifications for the HTTPS = notifications is the same as for
=     encoding notifications as defined in RESTCONF = [RFC8040] Section 6.4,
    with the = following changes.  Instead of saying that for JSON-encoding
    purposes, the module name for = "notification" element will be "ietf-
! =    restconf", it will say that for JSON-encoding = purposes, the module
    name for = "notification" element will be "ietf-https-notif".

    With those changes, the SSE event = notification encoded JSON example
***************

This and = all the following sections have been updated. 

Thanks.

*** 815,826 = ****

 7.  IANA Considerations

!    This document registers = two URI, two YANG module and two Media Types.

 7.1.  URI Registration

    in the IETF XML registry [RFC3688]. =  Following the format in RFC
! =    3688, the following registration is requested to be = made:

    URI: = urn:ietf:params:xml:ns:yang:ietf-http-notif
=     URI: = urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list
--- = 815,826 ----

 7.  IANA = Considerations

!    This = document registers two URIs, two YANG modules, and two Media Types.

 7.1.  URI Registration

    in the IETF XML = registry [RFC3688].  Following the format in RFC
! =    3688, the following registrations are requested to be = made:

    URI: = urn:ietf:params:xml:ns:yang:ietf-http-notif
=     URI: = urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list
***************
*** 854,860 ****

 7.3.  Media Types

! 7.3.1.  Media Type = "application/ietf-https-notif-cap+xml

=  Type name: application

--- 854,860 = ----

 7.3.  Media Types

! 7.3.1.  Media Type = "application/ietf-https-notif-cap+xml"

=  Type name: application

***************
*** 917,923 ****

 Provisional registration? (standards = tree only): no

! 7.3.2.  Media Type = "application/ietf-https-notif-cap+json

=  Type name: application

--- 917,923 = ----

 Provisional registration? = (standards tree only): no

! 7.3.2. =  Media Type "application/ietf-https-notif-cap+json"
 Type name: application

***************
*** 1106,1112 ****
=  </config>

! 8.2.  Non = Subscribed Notification based Configuration

=     In the case that it is desired to use HTTPS = notif outside of
    Subscribed = Notifications, there would have to be a module to define
---= 1106,1112 ----
 </config>

! 8.2.  Non-Subscribed Notification based = Configuration

    In = the case that it is desired to use HTTPS notif outside of
=     Subscribed Notifications, there would have to be = a module to define

Thanks,
Acee



Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_4B7053B2-CE3A-4C68-87ED-47E84A1402F2-- From nobody Wed Feb 10 11:04:00 2021 Return-Path: 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 54CDA3A13DA; Wed, 10 Feb 2021 11:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=Jn7oUXjw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=uT+csbSv Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37gjMu2dw6F0; Wed, 10 Feb 2021 11:03:55 -0800 (PST) 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 C397B3A13D5; Wed, 10 Feb 2021 11:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=62303; q=dns/txt; s=iport; t=1612983834; x=1614193434; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vPDxAuZahBcn9mZJ9ra9eTVZabrlKgwXtMDPP0bj9uo=; b=Jn7oUXjwDSH6rXCLvLqG2EplkFs7ShMz0aQd5+Cq4YyjsYaWALQNOgQk x67Xn+ia+o3ytBt8F/UreHk7NqBgTPATfd7TkGSuWcKNNY9Cob60nM1mG Nq/iSeKu0yA6gZ7/JuFe0v5texgLcy+V3tqQtHRU8c6gdb5u4YnjzgGJi 4=; X-IPAS-Result: =?us-ascii?q?A0AxAwAvLCRgkIkNJK1ZCRwBAQEBAQEHAQESAQEEBAEBg?= =?us-ascii?q?X4EAQELAYEiMCklA31aEiQxCgGENoNIA44QA4ofhHeKBoFCgREDVAsBAQENA?= =?us-ascii?q?QEtAgQBAYRLAheBbAIlNwYOAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBh?= =?us-ascii?q?jgNhkMBAQEBAxoJHQEBJRIBDwIBCA4DAwECDhMBBgMCAgIfERQJCAIEDgWCJ?= =?us-ascii?q?UsBgX5XAy4BS6QnAooldoEygwQBAQaFCg0LghIJgTgBgnWEBAGBC4U3JhuCA?= =?us-ascii?q?IERJxyCVj6CG4FmEUMJFoJgNIIJIoIVL1IYAQMyEQgHARQMQR4CAQMvLwUVF?= =?us-ascii?q?QEYBxMGGpAUJIJeQIc/LYwbkG5bCoJ6ll4EhSUDH4Mvn3mWPowkjkw+CQGEN?= =?us-ascii?q?wIEAgQFAg4BAQaBJEcigVlwFTsqAYI+UBcCDVZEjQUag1eKWXM3AgYBCQEBA?= =?us-ascii?q?wl8iggBgQ4BAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3A4U3nSxJk3lzBY0p9gdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKk/g1rAXIGd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkdQEcf6IVbVpy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D=?= =?us-ascii?q?3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,169,1610409600"; d="scan'208,217";a="684859853" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Feb 2021 19:03:53 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 11AJ3rEE010230 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Feb 2021 19:03:53 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 10 Feb 2021 13:03:53 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 10 Feb 2021 14:03:51 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 10 Feb 2021 13:03:51 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QS9NcKuft3h8QQpfM74F/feX1s96GA7k26hTjToA1HQq74pDp/i/w8fOMqngaU1KXucCCwraOfDMS6cZZIv+5MvozXALPWQRk9NlFU+eN8dYcFh+srzfBUXn+OaeU0R+OwU8Wkt6ctRtqI3sK5n2+c7rAGUI6Ywk/2izWAM3g/qIUJcewJIPUeOHCEngKQjGU2/xBkrGmv+6oY8JjUuKbu8eLQ/4SMuFAZZjsf2L8Bxq6g3DVC29rKEe94PQev/reGvgRLrX/HD0pMEJiZScSdFtUCQx1NhPfqTHKM6AEZFmuakTy+Fe2i57LzGTlK+JTWDeBelEB5bTSgYTQGD6Ww== 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=vPDxAuZahBcn9mZJ9ra9eTVZabrlKgwXtMDPP0bj9uo=; b=k8Q3hP7zpYZ2e3QluXGYG1NMWl8fCNW4pyXU0wC4RMX6WPRimbbYvYzLprR0uZPWy4lvDLA9CBoydkngv2ISeZoU1SaG5xw+apjb81SR5zOVB39ghJEUyDhIX9Oseleky2EyCgoBHK2coxXyezLR6TMJZb/1HXcaiKeoWVJErcLyJ1xDqj5fP3aWM/7jw2k/g70iHpxyFHemX+b+kG8zMq01EZaICuRMLKxfxsyS4zlR2czvqB1JrnMB30gz5ohbVm1H7IaHAmVgDaUXKE8K1g2yKhMFqKkt5PwAjWvC7ME0ob33MnTqLMHxjfVwMWW49LoARWUXegQ3IdafgG5llQ== 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=vPDxAuZahBcn9mZJ9ra9eTVZabrlKgwXtMDPP0bj9uo=; b=uT+csbSvYEihn2JGsvfRgUesr2OL+GDM0b2F6ewcpa7i/xnSI0MNFCcg3UZvqVXfwMFPb5r2sTplojgMZ2AXloHWAG1er+jjoduu3T5zdZzax2N3C/CkoTqQMDHlvTWr1MKn+qD/0RaEKSyOmxxDhLtuyVgiFushv/LMczDrL4g= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3431.namprd11.prod.outlook.com (2603:10b6:a03:8d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.30; Wed, 10 Feb 2021 19:03:49 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::a053:fad0:cf70:98b6]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::a053:fad0:cf70:98b6%4]) with mapi id 15.20.3846.026; Wed, 10 Feb 2021 19:03:49 +0000 From: "Acee Lindem (acee)" To: Mahesh Jethanandani CC: "yang-doctors@ietf.org" , "draft-ietf-netconf-https-notif.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" , tom petch Thread-Topic: Yangdoctors last call review of draft-ietf-netconf-https-notif-06 Thread-Index: AQHW/pvUHccHf7i4HUisNl1RTJhKSqpRbeAA Date: Wed, 10 Feb 2021 19:03:49 +0000 Message-ID: References: <161176691048.5494.2373231790931856179@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bc4a3ff9-2819-438b-4f29-08d8cdf699a5 x-ms-traffictypediagnostic: BYAPR11MB3431: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QXtXE87WAZSr3uhPuiCkc6zOpbWJQnh95gH+6yPwKe9oVlKEiDBtLHeBfp7eqMUlEeRV/iZ4ex3QfMk7li51JojVKUn6ovdR1pcP5NOl1PbJauezt9L+aslDY/VYdoCW/3qHJn+qX5WbeI0XXhjErDuhTfZtPuj7waxiOu76hwJFOBQdlaYVbEVX5Hh4h/KjN4fbdpIg/YKc7+iAUaau6jOUXSaW2WBoJdnUgxziao5ejU5Zu5crtlNZ2RGrvwfZwqydCMZ27kNtcqDLe7bm5oBkB0He7+sWGXtn4tw/sEnpJz/UjWxdHaahsWvhTr6LDNHb40aP4b7i2Tw+W0jflAMgVpyqsq51THJfeyPurU4kPqUoxXykAExHrj5bbd0vsCXpKo3rEuZa5TwOY+KInja6rDpTeHy+xfLtxJ0a3LYm+1f+xgPYNaaR/Cg53rCNAKN00AInBYvr0JO0dHD4ZdUlnVaWrhSulqBcuurA/hh7LXq78eiTmWlAQ7AIimF0VrTz0zHC+DvwwuRvd6TLyaeCEvGaDTuCinCpvywaVqD3iDnNrP1e0+9JK+/Um+JrYoVETW+Ki+doNMMdOJI5Rw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(376002)(346002)(136003)(396003)(6486002)(6916009)(66476007)(53546011)(66574015)(478600001)(4326008)(54906003)(36756003)(316002)(6512007)(8676002)(5660300002)(2616005)(9326002)(26005)(30864003)(33656002)(86362001)(186003)(71200400001)(76116006)(66946007)(8936002)(83380400001)(66556008)(64756008)(66446008)(6506007)(2906002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?RVdlNkVmZ3hwWlBXejBWWk1iNU8zUmNRTU5JYkUvTXpsV2xPMHhhRVdhb1dP?= =?utf-8?B?bUtYZjRkQkpGUVVrRWNad0RZZEMxSnFEb0xwbW1mSVVqdVBqT2svczVTWUFm?= =?utf-8?B?NzR6anJkakcwSTJVb09lbDlNNUhGV0YrY0YxU0lrY08wQktsOHZ4cmIzNHpI?= =?utf-8?B?d1Y0MnFYblQ0UWZiMVAvWTl4TmFhZG51R09HK3BvaHZnbFNwdTJLS3plQzl4?= =?utf-8?B?cVpWem5rdVdNeDhJTktIUmdkMDdDcG5TYmVLWnhCdVZtS1VYaVVKUG03RVJo?= =?utf-8?B?cmhxWm4xWkdpdVJwUFY1VGNyUTc1N2FpNlAzWUs3cU1zL0wzeEc1OVA2ZWFG?= =?utf-8?B?UHIrVlJwQzNyUEp3YlVRNkVhQUNWc0EzajIrR0ZuMG9oVWR1L1NkdnNWRjhu?= =?utf-8?B?ZU5XeUZCKzJhWTBEQXFUL09SL01IeS9sbXkyZ2RsTktXOUZNQ25uYkR2cXJ6?= =?utf-8?B?TTZDazEvOXowVng0S1JTYjVyNWVOVW1UNGVYWDV5V29tRHZpRjYwSUZqNith?= =?utf-8?B?eCt0aG9CTFNSTUhzNXZDcHRwRGpXeDVtZXg1d1EvSFh3dW9XdFNnbDYyTm13?= =?utf-8?B?cExVbE1keEVNV3JzVHp2enZsM3llTlFScXJBdzA1cVBiZWw3c2J5SjQ3bzhm?= =?utf-8?B?WjFHb1pMUEltaGY5NXhVWCs4akVCYWdhNEZabnl5aEVoaGNtMm1yTTFMN3Fu?= =?utf-8?B?ZlJpRVpwTlptNU5EN2hvM1hsTnlLeFA5OUowWDY5UmtQeEFWaUNtZGt0KzBu?= =?utf-8?B?cWVvY0FxTnNJbDZHNy9SeEkwSkdOV2RkQUl1NG12TmhQQjUvNENqTHpMSmtp?= =?utf-8?B?dW9VZEU0UVc1N0QwSFZ2bFBDWVRieGZpNjAyK1QzOFZKZlZiNGNTMkxtK1ll?= =?utf-8?B?cldoU3Z2U1BvUWkybkhSSWcwM0ZIdHF4TEQrV0ZJYjhISjFJN2xYUnAvcGNz?= =?utf-8?B?Z1I4bnRyRFlOa3hYWktTTk5ON1cyN3hJWStDc3VnUEFPR2JpMUtZaFpqaG1k?= =?utf-8?B?cVFwYVFLSTYrNFk5a1o2ZW94eEpiZW5kTnczTWhucGhHTGxkWmxBSVIzcEIr?= =?utf-8?B?aWg1bG5CTXZESm1zUFBveWczUTRocTZlQ3JmMzJhS2ExbENUdGZuQUR6OGtY?= =?utf-8?B?N0hlc1NJMENaZ0xTVUNtZGJ5UlBaVHZvR2ppNm5NSGVIVWF2VGd4V1ZVeTBQ?= =?utf-8?B?WE52c0gxNDhJR0Yxd1BwYlJXais0R1RnR1J0OEFSbkJOSEdOZ0l0ay9CNlhL?= =?utf-8?B?TTFBdlc5RzlkV2dEbmtTZXJGTzdHZytVbURCYVkvRTRsZEJ6OG1VUzdUWk82?= =?utf-8?B?YithZnVKbVhVekd3dEZzVTQ1QUFaNU9kR0ZTMVpxRXAvRkZaMERkdHZxUHg4?= =?utf-8?B?YlN1Unl5T0Q4RWEyRUxvUm1Qdm9FSnArU0dRM3R5cVR4eGpqOVpPdVpRQVhw?= =?utf-8?B?K0xxYVZYVG5mcmhaMVBjaDdzQzdtTmJobEpOdXV0RXF4alFsQlVmaER1L3FU?= =?utf-8?B?SWIyeVgxUlhkQ1lraWJ6MjRYcGRkYmNiQnJjeml3K0pzNE5sUWRqa3d1Ynl2?= =?utf-8?B?RU9pdm1RZGdRbkp2dlp1SUd4OGh1S2RKNDdWS3Z5bjJlVHBPSElNYnpkRWt3?= =?utf-8?B?UWpFUk16NzBmKzVmSVpBcVAwbTVzZm1BL3FsUElIN1AzQlg2L2VPUEh6UHp2?= =?utf-8?B?THZiWEk5dVl4RFFLcU9qZ295NkMydFZIdEs0ajZUYWxaM21iRVFFWjc4ak9a?= =?utf-8?Q?GtPjDPgCh9yi0PvGEYPLC0DXxbLwwyvJDLoMhZb?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_D9F4C4E1224E41FC876A81274FF6256Eciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bc4a3ff9-2819-438b-4f29-08d8cdf699a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2021 19:03:49.5222 (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: 0oMC+Nk4L++uaNPUvQmn4pF1cF7xZ235Dwlpwj0yuLKFJU5IAqtoLM69tUyyDahj X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3431 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 19:03:58 -0000 --_000_D9F4C4E1224E41FC876A81274FF6256Eciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KDQpUaGFua3MgZm9yIHRoZSB1cGRhdGUuIFNlZSBzb21lIGlubGluZXMuDQoN CkZyb206IE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KRGF0 ZTogTW9uZGF5LCBGZWJydWFyeSA4LCAyMDIxIGF0IDExOjI3IFBNDQpUbzogQWNlZSBMaW5kZW0g PGFjZWVAY2lzY28uY29tPg0KQ2M6IFlBTkcgRG9jdG9ycyA8eWFuZy1kb2N0b3JzQGlldGYub3Jn PiwgImRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi5hbGxAaWV0Zi5vcmciIDxkcmFmdC1p ZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYuYWxsQGlldGYub3JnPiwgImxhc3QtY2FsbEBpZXRmLm9y ZyIgPGxhc3QtY2FsbEBpZXRmLm9yZz4sICJuZXRjb25mQGlldGYub3JnIiA8bmV0Y29uZkBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBZYW5nZG9jdG9ycyBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0wNg0KDQpIaSBBY2VlLA0KDQpUaGFuayB5b3UgZmly c3Qgb2YgYWxsIGZvciB0aGUgcmV2aWV3IG9mIHRoZSBkb2N1bWVudC4gWW91IHJldmlld2VkIC0w NiwgYW5kIHdlIGhhdmUgc2luY2Ugc3VibWl0dGVkIC0wNy4gSSB3aWxsIGluIG15IHJlc3BvbnNl cyByZWZsZWN0IHRoZSBjaGFuZ2VzIGluIC0wNyB0aGF0IG1pZ2h0IGFmZmVjdCB0aGUgY29tbWVu dHMgeW91IGhhdmUgcHJvdmlkZWQuDQoNCg0KT24gSmFuIDI3LCAyMDIxLCBhdCA5OjAxIEFNLCBB Y2VlIExpbmRlbSB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc8bWFpbHRvOm5vcmVw bHlAaWV0Zi5vcmc+PiB3cm90ZToNCg0KUmV2aWV3ZXI6IEFjZWUgTGluZGVtDQpSZXZpZXcgcmVz dWx0OiBBbG1vc3QgUmVhZHkNCg0KVGhlIGRvY3VtZW50IGlzIGFsbW9zdCByZWFkeSBmb3IgV0cg TGFzdCBDYWxsLiBJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50czoNCg0KTW9kZWwgaWV0Zi1z dWItbm90aWYtcmVjdi1saXN0Og0KDQogICBTZWVtcyBvZGQgdG8gaGF2ZSBhIG1vZGVsIHRoYXQg YWRkcyBhIGNob2ljZSBzdGF0ZW1lbnQgd2l0aG91dCBhbnkNCiAgIHZhbGlkIG9wdGlvbnMuIEkg cmVhbGl6ZSB5b3UgZXhwZWN0IG90aGVyIHRyYW5zcG9ydHMgaW4gdGhlIGZ1dHVyZSBidXQNCiAg IGhhdmluZyBhIHNlcGFyYXRlIG1vZHVsZSB0aGUgb25lIGRlZmluZWQgaW4gdGhlIHNhbWUgZHJh ZnQgc2VlbXMgbGlrZSBhDQogICBwcm9mbGlnYXRlIGRlc2lnbiBjaG9pY2UuDQoNClRoZSBkcmFm dCBjb250YWlucyB0d28gbW9kZWxzIGFzIHlvdSBoYXZlIG5vdGVkLiBXaGlsZSB0aGUgaWV0Zi1z dWItbm90aWYtcmVjdi1saXN0IGFkZHMgYSBjaG9pY2Ugc3RhdGVtZW50LCB0aGUgc2Vjb25kIG1v ZGVsIGdvZXMgb24gdG8gYWRkaW5nIGEgY2FzZSBzdGF0ZW1lbnQgZm9yIHRoYXQgY2hvaWNlIHN0 YXRlbWVudC4gV2UgY291bGQgaGF2ZSBoYXJkIGNvZGVkIHRoZSB0d28gbW9kZWxzIHRvZ2V0aGVy LCBidXQgYmVsaWV2ZSB0aGF0IGJ5IHNlcGFyYXRpbmcgdGhlbSwgd2Ugb2ZmZXIgdGhlIGZsZXhp YmlsaXR5IHRvIGltcGxlbWVudGF0aW9ucyB0aGF0IG1heSBjaG9vc2Ugbm90IHRvIGltcGxlbWVu dCBib3RoIHRoZSBtb2RlbHMuIEFsc28sIG90aGVyIHRyYW5zcG9ydHMgY2FuIGF1Z21lbnQgInJl Y2VpdmVyLWluc3RhbmNlcyIsIHdpdGhvdXQgaW5jbHVkaW5nIHRoZSBlbnRpcmUgaHR0cCB0cmFu c3BvcnQgbW9kZWwuDQoNCldlbGwsIHJpZ2h0IG5vdywgdGhlcmUgaXMgb25seSBvbmUgY2hvaWNl IGZvciB0cmFuc3BvcnQuDQoNCklmIGl0IGhlbHBzLCB3ZSBjYW4gYWRkIGEgY29tbWVudCB0byB0 aGF0IGVmZmVjdCBpbiB0aGUgbW9kZWwgdG8gZXhwbGFpbiBvdXIgbW90aXZhdGlvbi4NCg0KVGhh dCB3b3VsZCBiZSBnb29kIGFsdGhvdWdoIEkgdW5kZXJzdG9vZCB0aGUgbW90aXZhdGlvbi4gSSBn dWVzcyB0aGlzIGlzIG9uZSB3YXkgdG8gbWFrZSBpdCBvcHRpb25hbCBidXQgY3VycmVudGx5IHRo ZSBvbmx5IG9wdGlvbiBpcyBib3RoIG1vZGVscyBvciBuZWl0aGVyLg0KDQoNCg0KTW9kZWwgaWV0 Zi1zdWItbm90aWYtcmVjdi1saXN0Og0KICAgMS4gVGhlIHByZWZpeCAiaG4iIHNlZW1zIGluY29u c2lzdGVudCB0byBsb3NlIHRoZSBjb250ZXh0LiBJJ2QgdXNlDQogICAgICAgInNucmxobiIuICBU aGlzIHdvdWxkbid0IGJlIGFuIGlzc3VlIGlmIHlvdSBjb21iaW5lZCB0aGUgbW9kdWxlcy4NCg0K VGhlIHVwZGF0ZWQgbW9kZWwgaW4gLTA3IG5vdyBjYXJyaWVzIHRoZSBwcmVmaXgg4oCcaG504oCd Lg0KDQpUaGF0IGlzIGFuIGltcHJvdmVtZW50IGJ1dCBzaW5jZSB0aGlzIGF1Z21lbnRzIGEgbW9k ZWwgd2l0aCDigJxzbnLigJ0gYXMgdGhlIHByZWZpeCwgaXQgc2VlbXMgdGhhdCBzaG91bGQgYmUg cGFydCBvZiB0aGUgcHJlZml4LiBJZiB5b3UgZGlkbuKAmXQgaGF2ZSBhIHNlcGFyYXRlIG1vZGVs LCBpdCB3b3VsZG7igJl0IGJlIGFuIGlzc3VlLiA7XikgSG93ZXZlciwgSeKAmW0gbGVhdmUgaXQg dG8gVG9tIChjb3BpZWQpIGZvciBmdXJ0aGVyIGRlYmF0ZS4NCg0KDQogICAyLiBUaGlzIGNvbW1l bnQgaXMgaW5jb21wcmVoZW5zaWJsZToNCg0KICAgICAgICAgICAgICAvLyBjcmVhdGUgdGhlIGxv Z2ljYWwgaW1wb3NzaWJpbGl0eSBvZiBlbmFibGluZyAidGNwIg0KICAgICAgICAgICAgICAvLyB0 cmFuc3BvcnQNCg0KV291bGQgaXQgaGVscCBpZiB3ZSBleHBhbmRlZCB0aGUgY29tbWVudCB0byBz YXk6DQoNCi8vIFRoZSAiaHR0cC1jbGllbnQtc3RhY2stZ3JvdXBpbmfigJ0gc3VwcG9ydHMgYm90 aCBIVFRQIGFuZCBIVFRQUyBzdGFja3MgYnkgZGVmYXVsdC4gVGhpcyBkcmFmdCwgaG93ZXZlciBz dXBwb3J0cyBIVFRQUyBvbmx5LiBUaGUgZm9sbG93aW5nDQovLyBpZi1mZWF0dXJlIHN0YXRlbWVu dCBtYWtlcyBpdCBsb2dpY2FsbHkgaW1wb3NzaWJsZSB0byBjb25maWd1cmUgSFRUUCB0cmFuc3Bv cnQuDQoNClllcy4NCg0KDQoNCkluIHRoZSBJQU5BIHNlY3Rpb24sIHRoZSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBmb3IgdGhlIG1lZGlhIHR5cGVzDQpwb2ludCB0byB0aGlzIGRyYWZ0J3Mgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMuIEhvd2V2ZXIsIHRoZXkgZG9uJ3QNCmluY2x1ZGUgdGhlIHJl ZmVyZW5jZWQgaW5mb3JtYXRpb24uIEl0IHNlZW1zIHRoZXNlIElBTkEgcmVmZXJlbmNlcw0Kc2hv dWxkIHBvaW50IHRvIG90aGVyIFJGQ3MuDQoNClRoZSB1cGRhdGVkIElBTkEgc2VjdGlvbiBubyBs b25nZXIgY2FycmllcyB0aGUgbWVkaWEtdHlwZXMuDQoNClRoYXTigJlzIGJldHRlci4NCg0KVGhh bmtzLA0KQWNlZQ0KDQoNCg0KSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgaWV0Zi1zdWJzY3JpYmVk LW5vdGlmaWNhdGlvbnMgaGFzIGEgbnVtYmVyIG9mIFlBTkcNCmVycm9ycyBhbmQgd2FybmluZ3Mu DQoNCkkgYWxzbyBoYXZlIHRoZSBmb2xsb3dpbmcgZWRpdG9yaWFsIGNvbW1lbnRzOg0KQWNlZS1M aW5kZW1zLWlNYWMtMjpEZXNrdG9wIGFjZWUkIGRpZmYgLWMNCmRyYWZ0LWlldGYtbmV0Y29uZi1o dHRwcy1ub3RpZi0wNi50eHQub3JpZw0KZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmLTA2 LnR4dCAqKioNCmRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0wNi50eHQub3JpZyAgMjAy MS0wMS0yNyAxMDowNjoyOS4wMDAwMDAwMDAgLTA1MDANCi0tLSBkcmFmdC1pZXRmLW5ldGNvbmYt aHR0cHMtbm90aWYtMDYudHh0ICAgICAgIDIwMjEtMDEtMjcgMTE6NTc6MTMuMDAwMDAwMDAwDQot MDUwMA0KKioqKioqKioqKioqKioqDQoqKiogMTcsMjMgKioqKg0KICAgIFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2R1bGUgZm9yIGNvbmZpZ3VyaW5nIEhUVFBTIGJhc2VkDQog ICAgY29uZmlndXJlZCBzdWJzY3JpcHRpb24sIGFzIGRlZmluZWQgaW4gUkZDIDg2MzkuICBUaGUg dXNlIG9mIEhUVFBTDQogICAgbWF4aW1pemVzIHRyYW5zcG9ydC1sZXZlbCBpbnRlcm9wZXJhYmls aXR5LCB3aGlsZSBhbGxvd2luZyBmb3INCiEgICAgZW5jb2Rpbmcgc2VsZWN0aW9uIGZyb20gdGV4 dCwgZS5nLiAgWE1MIG9yIEpTT04sIHRvIGJpbmFyeS4NCg0KIFN0YXR1cyBvZiBUaGlzIE1lbW8N Cg0KLS0tIDE3LDIzIC0tLS0NCiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEg bW9kdWxlIGZvciBjb25maWd1cmluZyBIVFRQUyBiYXNlZA0KICAgIGNvbmZpZ3VyZWQgc3Vic2Ny aXB0aW9uLCBhcyBkZWZpbmVkIGluIFJGQyA4NjM5LiAgVGhlIHVzZSBvZiBIVFRQUw0KICAgIG1h eGltaXplcyB0cmFuc3BvcnQtbGV2ZWwgaW50ZXJvcGVyYWJpbGl0eSwgd2hpbGUgYWxsb3dpbmcg Zm9yDQohICAgIGVuY29kaW5nIHNlbGVjdGlvbiBmcm9tIHRleHQsIGUuZy4sICBYTUwgb3IgSlNP TiwgdG8gYmluYXJ5Lg0KDQpUaGUgYWJzdHJhY3Qgc2VjdGlvbiBoYXMgYmVlbiB1cGRhdGVkLg0K DQoNCg0KIFN0YXR1cyBvZiBUaGlzIE1lbW8NCg0KKioqKioqKioqKioqKioqDQoqKiogMTAzLDEw OSAqKioqDQogICAgZG9jdW1lbnRzLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBZQU5HIDEu MSBbUkZDNzk1MF0gZGF0YQ0KICAgIG1vZHVsZXMsIG9uZSBmb3IgYXVnbWVudGluZyB0aGUgU3Vi c2NyaXB0aW9uIHRvIFlBTkcgTm90aWZpY2F0aW9ucw0KICAgIFtSRkM4NjM5XSB0byBhZGQgYSB0 cmFuc3BvcnQgdHlwZSwgYW5kIGFub3RoZXIgZm9yIGNvbmZpZ3VyaW5nIGFuZA0KISAgICBtYW5h Z2luZyBIVFRQUyBiYXNlZCByZWNlaXZlcnMgZm9yIHRoZSBub3RpZmljYXRpb25zLg0KDQotLS0g MTAzLDEwOSAtLS0tDQogICAgZG9jdW1lbnRzLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBZ QU5HIDEuMSBbUkZDNzk1MF0gZGF0YQ0KICAgIG1vZHVsZXMsIG9uZSBmb3IgYXVnbWVudGluZyB0 aGUgU3Vic2NyaXB0aW9uIHRvIFlBTkcgTm90aWZpY2F0aW9ucw0KICAgIFtSRkM4NjM5XSB0byBh ZGQgYSB0cmFuc3BvcnQgdHlwZSwgYW5kIGFub3RoZXIgZm9yIGNvbmZpZ3VyaW5nIGFuZA0KISAg ICBtYW5hZ2luZyBIVFRQUy1iYXNlZCByZWNlaXZlcnMgZm9yIHRoZSBub3RpZmljYXRpb25zLg0K DQpGaXhlZC4NCg0KDQoNCioqKioqKioqKioqKioqKg0KKioqIDExOCwxMjQgKioqKg0KICAgIHRo ZSBzYW1lIHJlY2VpdmVyIGluc3RhbmNlLiAgVGhlIHNlY29uZCBtb2R1bGUgZGVzY3JpYmVzIGhv dyB0bw0KICAgIGVuYWJsZSB0aGUgdHJhbnNtaXNzaW9uIG9mIFlBTkcgbW9kZWxlZCBub3RpZmlj YXRpb25zLCBpbiB0aGUNCiAgICBjb25maWd1cmVkIGVuY29kaW5nIChpLmUuLCBYTUwsIEpTT04p IG92ZXIgSFRUUFMuICBOb3RpZmljYXRpb25zIGFyZQ0KISAgICBkZWxpdmVyZWQgaW4gdGhlIGZv cm0gb2YgYSBIVFRQUyBQT1NULiAgVGhlIHVzZSBvZiBIVFRQUyBtYXhpbWl6ZXMNCiAgICB0cmFu c3BvcnQtbGV2ZWwgaW50ZXJvcGVyYWJpbGl0eSwgd2hpbGUgdGhlIGVuY29kaW5nIHNlbGVjdGlv biBwaXZvdHMNCiAgICBiZXR3ZWVuIGltcGxlbWVudGF0aW9uIHNpbXBsaWNpdHkgKFhNTCwgSlNP TikgYW5kIHRocm91Z2hwdXQgKHRleHQNCiAgICB2ZXJzdXMgYmluYXJ5KS4NCi0tLSAxMTgsMTI0 IC0tLS0NCiAgICB0aGUgc2FtZSByZWNlaXZlciBpbnN0YW5jZS4gIFRoZSBzZWNvbmQgbW9kdWxl IGRlc2NyaWJlcyBob3cgdG8NCiAgICBlbmFibGUgdGhlIHRyYW5zbWlzc2lvbiBvZiBZQU5HIG1v ZGVsZWQgbm90aWZpY2F0aW9ucywgaW4gdGhlDQogICAgY29uZmlndXJlZCBlbmNvZGluZyAoaS5l LiwgWE1MLCBKU09OKSBvdmVyIEhUVFBTLiAgTm90aWZpY2F0aW9ucyBhcmUNCiEgICAgZGVsaXZl cmVkIGluIHRoZSBmb3JtIG9mIGFuIEhUVFBTIFBPU1QuICBUaGUgdXNlIG9mIEhUVFBTIG1heGlt aXplcw0KICAgIHRyYW5zcG9ydC1sZXZlbCBpbnRlcm9wZXJhYmlsaXR5LCB3aGlsZSB0aGUgZW5j b2Rpbmcgc2VsZWN0aW9uIHBpdm90cw0KICAgIGJldHdlZW4gaW1wbGVtZW50YXRpb24gc2ltcGxp Y2l0eSAoWE1MLCBKU09OKSBhbmQgdGhyb3VnaHB1dCAodGV4dA0KICAgIHZlcnN1cyBiaW5hcnkp Lg0KKioqKioqKioqKioqKioqDQoNCkZpeGVkLg0KDQoNCioqKiAxOTYsMjAyICoqKioNCg0KICAg IEluIHRoZSBjYXNlIG9mICJwaXBlbGluaW5nIiwgdGhlIGZsb3cgb2YgbWVzc2FnZXMgd291bGQg bG9vaw0KICAgIHNvbWV0aGluZyBsaWtlIHRoaXMuICBUaGlzIGV4YW1wbGUgc2hvd3MgdGhlIGZs b3cgYXNzdW1pbmcgdGhhdA0KISAgICBTdWJzY3JpYmVkIE5vdGlmaWNhdGlvbnMgaXMgdXNlZCBh bmQgdGhlcmVmb3JlIGEgPHN1YnNjcmlwdGlvbi0NCiAgICBzdGFydGVkPiBub3RpZmljYXRpb24g aXMgc2VudCBiZWZvcmUgc2VuZGluZyB0aGUgZmlyc3Qgbm90aWZpY2F0aW9uLg0KICAgIFRoZSBl eGFtcGxlIHdvdWxkIGJlIHRoZSBzYW1lIGZvciB3aGVuIFN1YnNjcmliZWQgTm90aWZpY2F0aW9u IGlzIG5vdA0KICAgIHVzZWQgYnkgcmVtb3ZpbmcgdGhlIGZpcnN0IFBPU1QgbWVzc2FnZSBmb3Ig PHN1c2JzY3JpcHRpb24tc3RhcnRlZD4uDQotLS0gMTk2LDIwMiAtLS0tDQoNCiAgICBJbiB0aGUg Y2FzZSBvZiAicGlwZWxpbmluZyIsIHRoZSBmbG93IG9mIG1lc3NhZ2VzIHdvdWxkIGxvb2sNCiAg ICBzb21ldGhpbmcgbGlrZSB0aGlzLiAgVGhpcyBleGFtcGxlIHNob3dzIHRoZSBmbG93IGFzc3Vt aW5nIHRoYXQNCiEgICAgU3Vic2NyaWJlZCBOb3RpZmljYXRpb24gaXMgdXNlZCBhbmQgdGhlcmVm b3JlIGEgPHN1YnNjcmlwdGlvbi0NCiAgICBzdGFydGVkPiBub3RpZmljYXRpb24gaXMgc2VudCBi ZWZvcmUgc2VuZGluZyB0aGUgZmlyc3Qgbm90aWZpY2F0aW9uLg0KICAgIFRoZSBleGFtcGxlIHdv dWxkIGJlIHRoZSBzYW1lIGZvciB3aGVuIFN1YnNjcmliZWQgTm90aWZpY2F0aW9uIGlzIG5vdA0K ICAgIHVzZWQgYnkgcmVtb3ZpbmcgdGhlIGZpcnN0IFBPU1QgbWVzc2FnZSBmb3IgPHN1c2JzY3Jp cHRpb24tc3RhcnRlZD4uDQoqKioqKioqKioqKioqKioNCg0KVGhpcyBzZWN0aW9uIGhhcyBiZWVu IHJld3JpdHRlbi4NCg0KDQoqKiogMzQyLDM1MCAqKioqDQoNCiAyLjEuICBJbnRyb2R1Y3Rpb24N Cg0KISAgICBUbyBsZWFybiB0aGUgY2FwYWJpbGl0aWVzIG9mIHRoZSByZWNlaXZlciwgdGhlIHB1 Ymxpc2hlciBjYW4gaXNzdWUgYQ0KICAgIEhUVFBTIEdFVCByZXF1ZXN0IHdpdGggQWNjZXB0LVR5 cGUgc2V0IHRvIGFwcGxpY2F0aW9uL2lldGYtaHR0cHMtDQohICAgIG5vdGlmLWNhcCt4bWwgb3Ig YXBwbGljYXRpb24vaWV0Zi1odHRwcy1ub3RpZi1jYXAranNvbiwgd2l0aCBsYXR0ZXINCiAgICBh cyB0aGUgbWFuZGF0b3J5IHRvIGltcGxlbWVudCwgYW5kIHRoZSBkZWZhdWx0IGluIGNhc2UgdGhl IHR5cGUgaXMNCiAgICBub3Qgc3BlY2lmaWVkLiAgSWYgdGhlIHJlY2VpdmVyIHN1cHBvcnRzIGNh cGFiaWxpdGllcyBzdWNoIGFzIGJpbmFyeQ0KICAgIGVuY29kaW5nIG9mIGRhdGEsIGl0IGNhbiBy ZXR1cm4gdGhhdCBhcyBhIGNhcGFiaWxpdHkgaW4gYSByZXNwb25zZS4NCi0tLSAzNDIsMzUwIC0t LS0NCg0KIDIuMS4gIEludHJvZHVjdGlvbg0KDQohICAgIFRvIGxlYXJuIHRoZSBjYXBhYmlsaXRp ZXMgb2YgdGhlIHJlY2VpdmVyLCB0aGUgcHVibGlzaGVyIGNhbiBpc3N1ZSBhbg0KICAgIEhUVFBT IEdFVCByZXF1ZXN0IHdpdGggQWNjZXB0LVR5cGUgc2V0IHRvIGFwcGxpY2F0aW9uL2lldGYtaHR0 cHMtDQohICAgIG5vdGlmLWNhcCt4bWwgb3IgYXBwbGljYXRpb24vaWV0Zi1odHRwcy1ub3RpZi1j YXAranNvbiwgd2l0aCB0aGUgbGF0dGVyDQogICAgYXMgdGhlIG1hbmRhdG9yeSB0byBpbXBsZW1l bnQsIGFuZCB0aGUgZGVmYXVsdCBpbiBjYXNlIHRoZSB0eXBlIGlzDQogICAgbm90IHNwZWNpZmll ZC4gIElmIHRoZSByZWNlaXZlciBzdXBwb3J0cyBjYXBhYmlsaXRpZXMgc3VjaCBhcyBiaW5hcnkN CiAgICBlbmNvZGluZyBvZiBkYXRhLCBpdCBjYW4gcmV0dXJuIHRoYXQgYXMgYSBjYXBhYmlsaXR5 IGluIGEgcmVzcG9uc2UuDQoqKioqKioqKioqKioqKioNCg0KRml4ZWQuDQoNCg0KKioqIDQ1MCw0 NTYgKioqKg0KIEludGVybmV0LURyYWZ0ICAgICAgICBIVFRQUyBDb25maWd1cmVkIFN1YnNjcmlw dGlvbiAgICAgICAgTm92ZW1iZXIgMjAyMA0KDQohICAgICAgQ29weXJpZ2h0IChjKSAyMDE4IElF VEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMNCiAgICAgIHRoZSBkb2N1bWVu dCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiAgICAgIFJlZGlzdHJpYnV0aW9uIGFu ZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3INCiAgICAgIHdpdGhvdXQg bW9kaWZpY2F0aW9uLCBpcyBwZXJtaXR0ZWQgcHVyc3VhbnQgdG8sIGFuZCBzdWJqZWN0DQotLS0g NDUwLDQ1NiAtLS0tDQogSW50ZXJuZXQtRHJhZnQgICAgICAgIEhUVFBTIENvbmZpZ3VyZWQgU3Vi c2NyaXB0aW9uICAgICAgICBOb3ZlbWJlciAyMDIwDQoNCiEgICAgICBDb3B5cmlnaHQgKGMpIDIw MjEgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcw0KICAgICAgdGhlIGRv Y3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KICAgICAgUmVkaXN0cmlidXRp b24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvcg0KICAgICAgd2l0 aG91dCBtb2RpZmljYXRpb24sIGlzIHBlcm1pdHRlZCBwdXJzdWFudCB0bywgYW5kIHN1YmplY3QN CioqKioqKioqKioqKioqKg0KDQpGaXhlZC4NCg0KDQoqKiogNTM2LDU0NSAqKioqDQoNCiAgICBU aGlzIFlBTkcgbW9kdWxlIGlzIGEgZGVmaW5pdGlvbiBvZiBhIHNldCBvZiByZWNlaXZlcnMgdGhh dCBhcmUNCiAgICBpbnRlcmVzdGVkIGluIHRoZSBub3RpZmljYXRpb25zIHB1Ymxpc2hlZCBieSB0 aGUgcHVibGlzaGVyLiAgVGhlDQohICAgIG1vZHVsZSBjb250YWlucyB0aGUgVENQLCBUTFMgYW5k IEhUVFBTIHBhcmFtZXRlcnMgdGhhdCBhcmUgbmVlZGVkIHRvDQogICAgY29tbXVuaWNhdGUgd2l0 aCB0aGUgcmVjZWl2ZXIuICBUaGUgbW9kdWxlIGF1Z21lbnRzIHRoZSBpZXRmLXN1Yi0NCiAgICBu b3RpZi1yZWN2LWxpc3QgbW9kdWxlIHRvIGRlZmluZSBhIHRyYW5zcG9ydCBzcGVjaWZpYyByZWNl aXZlci4gIEFzDQohICAgIG1lbnRpb25lZCBlYXJsaWVyLCBpdCB1c2VzIFBPU1QgbWV0aG9kIHRv IGRlbGl2ZXIgdGhlIG5vdGlmaWNhdGlvbi4NCiAgICBUaGUgYXR0cmlidXRlICdwYXRoJyBkZWZp bmVzIHRoZSBwYXRoIGZvciB0aGUgcmVzb3VyY2Ugb24gdGhlDQogICAgcmVjZWl2ZXIsIGFzIGRl ZmluZWQgYnkgJ3BhdGgtYWJzb2x1dGUnIGluIFVSSSBHZW5lcmljIFN5bnRheA0KICAgIFtSRkMz OTg2XS4gIFRoZSB1c2VyLWlkIHVzZWQgYnkgTmV0d29yayBDb25maWd1cmF0aW9uIEFjY2VzcyBD b250cm9sDQotLS0gNTM2LDU0NSAtLS0tDQoNCiAgICBUaGlzIFlBTkcgbW9kdWxlIGlzIGEgZGVm aW5pdGlvbiBvZiBhIHNldCBvZiByZWNlaXZlcnMgdGhhdCBhcmUNCiAgICBpbnRlcmVzdGVkIGlu IHRoZSBub3RpZmljYXRpb25zIHB1Ymxpc2hlZCBieSB0aGUgcHVibGlzaGVyLiAgVGhlDQohICAg IG1vZHVsZSBjb250YWlucyB0aGUgVENQLCBUTFMsIGFuZCBIVFRQUyBwYXJhbWV0ZXJzIHRoYXQg YXJlIG5lZWRlZCB0bw0KICAgIGNvbW11bmljYXRlIHdpdGggdGhlIHJlY2VpdmVyLiAgVGhlIG1v ZHVsZSBhdWdtZW50cyB0aGUgaWV0Zi1zdWItDQogICAgbm90aWYtcmVjdi1saXN0IG1vZHVsZSB0 byBkZWZpbmUgYSB0cmFuc3BvcnQgc3BlY2lmaWMgcmVjZWl2ZXIuICBBcw0KISAgICBtZW50aW9u ZWQgZWFybGllciwgaXQgdXNlcyB0aGUgUE9TVCBtZXRob2QgdG8gZGVsaXZlciB0aGUgbm90aWZp Y2F0aW9uLg0KICAgIFRoZSBhdHRyaWJ1dGUgJ3BhdGgnIGRlZmluZXMgdGhlIHBhdGggZm9yIHRo ZSByZXNvdXJjZSBvbiB0aGUNCiAgICByZWNlaXZlciwgYXMgZGVmaW5lZCBieSAncGF0aC1hYnNv bHV0ZScgaW4gVVJJIEdlbmVyaWMgU3ludGF4DQogICAgW1JGQzM5ODZdLiAgVGhlIHVzZXItaWQg dXNlZCBieSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gQWNjZXNzIENvbnRyb2wNCioqKioqKioqKioq KioqKg0KDQpUaGlzIHNlY3Rpb24gb2YgdGhlIG1vZHVsZSBoYXMgYmVlbiByZXdyaXR0ZW4uDQoN Cg0KKioqIDYzOSw2NDUgKioqKg0KICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgIllBTkcgbW9k dWxlIGZvciBjb25maWd1cmluZyBIVFRQUyBiYXNlIGNvbmZpZ3VyYXRpb24uDQoNCiEgICAgICAg ICBDb3B5cmlnaHQgKGMpIDIwMTggSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmll ZCBhcw0KICAgICAgICAgdGhlIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVk Lg0KICAgICAgICAgUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBm b3Jtcywgd2l0aCBvcg0KICAgICAgICAgd2l0aG91dCBtb2RpZmljYXRpb24sIGlzIHBlcm1pdHRl ZCBwdXJzdWFudCB0bywgYW5kIHN1YmplY3QNCi0tLSA2MzksNjQ1IC0tLS0NCiAgICAgIGRlc2Ny aXB0aW9uDQogICAgICAgICJZQU5HIG1vZHVsZSBmb3IgY29uZmlndXJpbmcgSFRUUFMgYmFzZSBj b25maWd1cmF0aW9uLg0KDQohICAgICAgICAgQ29weXJpZ2h0IChjKSAyMDIxIElFVEYgVHJ1c3Qg YW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMNCiAgICAgICAgIHRoZSBkb2N1bWVudCBhdXRo b3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiAgICAgICAgIFJlZGlzdHJpYnV0aW9uIGFuZCB1 c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3INCiAgICAgICAgIHdpdGhvdXQg bW9kaWZpY2F0aW9uLCBpcyBwZXJtaXR0ZWQgcHVyc3VhbnQgdG8sIGFuZCBzdWJqZWN0DQoqKioq KioqKioqKioqKioNCg0KRml4ZWQuDQoNCg0KKioqIDcwNCw3MTAgKioqKg0KDQogICAgICAgICAg ICBjb250YWluZXIgcmVjZWl2ZXItaWRlbnRpdHkgew0KICAgICAgICAgICAgICBkZXNjcmlwdGlv bg0KISAgICAgICAgICAgICAgICAiU3BlY2lmaWVzIG1lY2hhbmlzbSBmb3IgaWRlbnRpZnlpbmcg dGhlIHJlY2VpdmVyLg0KICAgICAgICAgICAgICAgICBUaGUgcHVibGlzaGVyIE1VU1QgTk9UIGlu Y2x1ZGUgYW55IGNvbnRlbnQgaW4gYQ0KICAgICAgICAgICAgICAgICBub3RpZmljYXRpb24gdGhh dCB0aGUgdXNlciBpcyBub3QgYXV0aG9yaXplZCB0byB2aWV3LiI7DQoNCi0tLSA3MDQsNzEwIC0t LS0NCg0KICAgICAgICAgICAgY29udGFpbmVyIHJlY2VpdmVyLWlkZW50aXR5IHsNCiAgICAgICAg ICAgICAgZGVzY3JpcHRpb24NCiEgICAgICAgICAgICAgICAgIlNwZWNpZmllcyB0aGUgbWVjaGFu aXNtIGZvciBpZGVudGlmeWluZyB0aGUgcmVjZWl2ZXIuDQogICAgICAgICAgICAgICAgIFRoZSBw dWJsaXNoZXIgTVVTVCBOT1QgaW5jbHVkZSBhbnkgY29udGVudCBpbiBhDQogICAgICAgICAgICAg ICAgIG5vdGlmaWNhdGlvbiB0aGF0IHRoZSB1c2VyIGlzIG5vdCBhdXRob3JpemVkIHRvIHZpZXcu IjsNCg0KKioqKioqKioqKioqKioqDQoNClRoaXMgZGVzY3JpcHRpb24gc3RhdGVtZW50IGhhcyBi ZWVuIHVwZGF0ZWQuDQoNCg0KKioqIDc5MSw4MDEgKioqKg0KDQogNi4gIFJlY2VpdmluZyBFdmVu dCBOb3RpZmljYXRpb25zDQoNCiEgICAgRW5jb2Rpbmcgbm90aWZpY2F0aW9ucyBmb3IgdGhlIEhU VFBTIG5vdGlmaWNhdGlvbnMgaXMgdGhlIHNhbWUgYXMgdGhlDQogICAgZW5jb2Rpbmcgbm90aWZp Y2F0aW9ucyBhcyBkZWZpbmVkIGluIFJFU1RDT05GIFtSRkM4MDQwXSBTZWN0aW9uIDYuNCwNCiAg ICB3aXRoIHRoZSBmb2xsb3dpbmcgY2hhbmdlcy4gIEluc3RlYWQgb2Ygc2F5aW5nIHRoYXQgZm9y IEpTT04tZW5jb2RpbmcNCiAgICBwdXJwb3NlcywgdGhlIG1vZHVsZSBuYW1lIGZvciAibm90aWZp Y2F0aW9uIiBlbGVtZW50IHdpbGwgYmUgImlldGYtDQohICAgIHJlc3Rjb25mLCBpdCB3aWxsIHNh eSB0aGF0IGZvciBKU09OLWVuY29kaW5nIHB1cnBvc2VzLCB0aGUgbW9kdWxlDQogICAgbmFtZSBm b3IgIm5vdGlmaWNhdGlvbiIgZWxlbWVudCB3aWxsIGJlICJpZXRmLWh0dHBzLW5vdGlmIi4NCg0K ICAgIFdpdGggdGhvc2UgY2hhbmdlcywgdGhlIFNTRSBldmVudCBub3RpZmljYXRpb24gZW5jb2Rl ZCBKU09OIGV4YW1wbGUNCi0tLSA3OTEsODAxIC0tLS0NCg0KIDYuICBSZWNlaXZpbmcgRXZlbnQg Tm90aWZpY2F0aW9ucw0KDQohICAgIEVuY29kaW5nIG5vdGlmaWNhdGlvbnMgZm9yIHRoZSBIVFRQ UyBub3RpZmljYXRpb25zIGlzIHRoZSBzYW1lIGFzIGZvcg0KICAgIGVuY29kaW5nIG5vdGlmaWNh dGlvbnMgYXMgZGVmaW5lZCBpbiBSRVNUQ09ORiBbUkZDODA0MF0gU2VjdGlvbiA2LjQsDQogICAg d2l0aCB0aGUgZm9sbG93aW5nIGNoYW5nZXMuICBJbnN0ZWFkIG9mIHNheWluZyB0aGF0IGZvciBK U09OLWVuY29kaW5nDQogICAgcHVycG9zZXMsIHRoZSBtb2R1bGUgbmFtZSBmb3IgIm5vdGlmaWNh dGlvbiIgZWxlbWVudCB3aWxsIGJlICJpZXRmLQ0KISAgICByZXN0Y29uZiIsIGl0IHdpbGwgc2F5 IHRoYXQgZm9yIEpTT04tZW5jb2RpbmcgcHVycG9zZXMsIHRoZSBtb2R1bGUNCiAgICBuYW1lIGZv ciAibm90aWZpY2F0aW9uIiBlbGVtZW50IHdpbGwgYmUgImlldGYtaHR0cHMtbm90aWYiLg0KDQog ICAgV2l0aCB0aG9zZSBjaGFuZ2VzLCB0aGUgU1NFIGV2ZW50IG5vdGlmaWNhdGlvbiBlbmNvZGVk IEpTT04gZXhhbXBsZQ0KKioqKioqKioqKioqKioqDQoNClRoaXMgYW5kIGFsbCB0aGUgZm9sbG93 aW5nIHNlY3Rpb25zIGhhdmUgYmVlbiB1cGRhdGVkLg0KDQpUaGFua3MuDQoNCg0KKioqIDgxNSw4 MjYgKioqKg0KDQogNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KISAgICBUaGlzIGRvY3VtZW50 IHJlZ2lzdGVycyB0d28gVVJJLCB0d28gWUFORyBtb2R1bGUgYW5kIHR3byBNZWRpYSBUeXBlcy4N Cg0KIDcuMS4gIFVSSSBSZWdpc3RyYXRpb24NCg0KICAgIGluIHRoZSBJRVRGIFhNTCByZWdpc3Ry eSBbUkZDMzY4OF0uICBGb2xsb3dpbmcgdGhlIGZvcm1hdCBpbiBSRkMNCiEgICAgMzY4OCwgdGhl IGZvbGxvd2luZyByZWdpc3RyYXRpb24gaXMgcmVxdWVzdGVkIHRvIGJlIG1hZGU6DQoNCiAgICBV Ukk6IHVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWh0dHAtbm90aWYNCiAgICBVUkk6 IHVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXN1Yi1ub3RpZi1yZWN2LWxpc3QNCi0t LSA4MTUsODI2IC0tLS0NCg0KIDcuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiEgICAgVGhpcyBk b2N1bWVudCByZWdpc3RlcnMgdHdvIFVSSXMsIHR3byBZQU5HIG1vZHVsZXMsIGFuZCB0d28gTWVk aWEgVHlwZXMuDQoNCiA3LjEuICBVUkkgUmVnaXN0cmF0aW9uDQoNCiAgICBpbiB0aGUgSUVURiBY TUwgcmVnaXN0cnkgW1JGQzM2ODhdLiAgRm9sbG93aW5nIHRoZSBmb3JtYXQgaW4gUkZDDQohICAg IDM2ODgsIHRoZSBmb2xsb3dpbmcgcmVnaXN0cmF0aW9ucyBhcmUgcmVxdWVzdGVkIHRvIGJlIG1h ZGU6DQoNCiAgICBVUkk6IHVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWh0dHAtbm90 aWYNCiAgICBVUkk6IHVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXN1Yi1ub3RpZi1y ZWN2LWxpc3QNCioqKioqKioqKioqKioqKg0KKioqIDg1NCw4NjAgKioqKg0KDQogNy4zLiAgTWVk aWEgVHlwZXMNCg0KISA3LjMuMS4gIE1lZGlhIFR5cGUgImFwcGxpY2F0aW9uL2lldGYtaHR0cHMt bm90aWYtY2FwK3htbA0KDQogVHlwZSBuYW1lOiBhcHBsaWNhdGlvbg0KDQotLS0gODU0LDg2MCAt LS0tDQoNCiA3LjMuICBNZWRpYSBUeXBlcw0KDQohIDcuMy4xLiAgTWVkaWEgVHlwZSAiYXBwbGlj YXRpb24vaWV0Zi1odHRwcy1ub3RpZi1jYXAreG1sIg0KDQogVHlwZSBuYW1lOiBhcHBsaWNhdGlv bg0KDQoqKioqKioqKioqKioqKioNCioqKiA5MTcsOTIzICoqKioNCg0KIFByb3Zpc2lvbmFsIHJl Z2lzdHJhdGlvbj8gKHN0YW5kYXJkcyB0cmVlIG9ubHkpOiBubw0KDQohIDcuMy4yLiAgTWVkaWEg VHlwZSAiYXBwbGljYXRpb24vaWV0Zi1odHRwcy1ub3RpZi1jYXAranNvbg0KDQogVHlwZSBuYW1l OiBhcHBsaWNhdGlvbg0KDQotLS0gOTE3LDkyMyAtLS0tDQoNCiBQcm92aXNpb25hbCByZWdpc3Ry YXRpb24/IChzdGFuZGFyZHMgdHJlZSBvbmx5KTogbm8NCg0KISA3LjMuMi4gIE1lZGlhIFR5cGUg ImFwcGxpY2F0aW9uL2lldGYtaHR0cHMtbm90aWYtY2FwK2pzb24iDQoNCiBUeXBlIG5hbWU6IGFw cGxpY2F0aW9uDQoNCioqKioqKioqKioqKioqKg0KKioqIDExMDYsMTExMiAqKioqDQogPC9jb25m aWc+DQoNCiEgOC4yLiAgTm9uIFN1YnNjcmliZWQgTm90aWZpY2F0aW9uIGJhc2VkIENvbmZpZ3Vy YXRpb24NCg0KICAgIEluIHRoZSBjYXNlIHRoYXQgaXQgaXMgZGVzaXJlZCB0byB1c2UgSFRUUFMg bm90aWYgb3V0c2lkZSBvZg0KICAgIFN1YnNjcmliZWQgTm90aWZpY2F0aW9ucywgdGhlcmUgd291 bGQgaGF2ZSB0byBiZSBhIG1vZHVsZSB0byBkZWZpbmUNCi0tLSAxMTA2LDExMTIgLS0tLQ0KIDwv Y29uZmlnPg0KDQohIDguMi4gIE5vbi1TdWJzY3JpYmVkIE5vdGlmaWNhdGlvbiBiYXNlZCBDb25m aWd1cmF0aW9uDQoNCiAgICBJbiB0aGUgY2FzZSB0aGF0IGl0IGlzIGRlc2lyZWQgdG8gdXNlIEhU VFBTIG5vdGlmIG91dHNpZGUgb2YNCiAgICBTdWJzY3JpYmVkIE5vdGlmaWNhdGlvbnMsIHRoZXJl IHdvdWxkIGhhdmUgdG8gYmUgYSBtb2R1bGUgdG8gZGVmaW5lDQoNClRoYW5rcywNCkFjZWUNCg0K DQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpl dGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0KDQoNCg== --_000_D9F4C4E1224E41FC876A81274FF6256Eciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpIE1haGVzaCwgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rcyBmb3IgdGhlIHVwZGF0ZS4gU2VlIHNvbWUgaW5saW5lcy4gPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk1haGVz aCBKZXRoYW5hbmRhbmkgJmx0O21qZXRoYW5hbmRhbmlAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5Nb25kYXksIEZlYnJ1YXJ5IDgsIDIwMjEgYXQgMTE6MjcgUE08YnI+DQo8Yj5Ubzog PC9iPkFjZWUgTGluZGVtICZsdDthY2VlQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPllB TkcgRG9jdG9ycyAmbHQ7eWFuZy1kb2N0b3JzQGlldGYub3JnJmd0OywgJnF1b3Q7ZHJhZnQtaWV0 Zi1uZXRjb25mLWh0dHBzLW5vdGlmLmFsbEBpZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQtaWV0Zi1u ZXRjb25mLWh0dHBzLW5vdGlmLmFsbEBpZXRmLm9yZyZndDssICZxdW90O2xhc3QtY2FsbEBpZXRm Lm9yZyZxdW90OyAmbHQ7bGFzdC1jYWxsQGlldGYub3JnJmd0OywgJnF1b3Q7bmV0Y29uZkBpZXRm Lm9yZyZxdW90OyAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IFlhbmdkb2N0b3JzIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLWh0 dHBzLW5vdGlmLTA2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+SGkgQWNlZSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhhbmsg eW91IGZpcnN0IG9mIGFsbCBmb3IgdGhlIHJldmlldyBvZiB0aGUgZG9jdW1lbnQuIFlvdSByZXZp ZXdlZCAtMDYsIGFuZCB3ZSBoYXZlIHNpbmNlIHN1Ym1pdHRlZCAtMDcuIEkgd2lsbCBpbiBteSBy ZXNwb25zZXMgcmVmbGVjdCB0aGUgY2hhbmdlcyBpbiAtMDcgdGhhdCBtaWdodCBhZmZlY3QgdGhl IGNvbW1lbnRzIHlvdSBoYXZlIHByb3ZpZGVkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5PbiBKYW4gMjcsIDIwMjEsIGF0IDk6MDEgQU0sIEFjZWUgTGluZGVtIHZpYSBE YXRhdHJhY2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmciPm5vcmVwbHlA aWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+UmV2aWV3ZXI6IEFjZWUgTGluZGVtPGJyPg0KUmV2aWV3IHJlc3VsdDogQWxtb3N0IFJl YWR5PGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50IGlzIGFsbW9zdCByZWFkeSBmb3IgV0cgTGFzdCBD YWxsLiBJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50czo8YnI+DQo8YnI+DQpNb2RlbCBpZXRm LXN1Yi1ub3RpZi1yZWN2LWxpc3Q6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7U2VlbXMg b2RkIHRvIGhhdmUgYSBtb2RlbCB0aGF0IGFkZHMgYSBjaG9pY2Ugc3RhdGVtZW50IHdpdGhvdXQg YW55PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7dmFsaWQgb3B0aW9ucy4gSSByZWFsaXplIHlvdSBl eHBlY3Qgb3RoZXIgdHJhbnNwb3J0cyBpbiB0aGUgZnV0dXJlIGJ1dDxicj4NCiZuYnNwOyZuYnNw OyZuYnNwO2hhdmluZyBhIHNlcGFyYXRlIG1vZHVsZSB0aGUgb25lIGRlZmluZWQgaW4gdGhlIHNh bWUgZHJhZnQgc2VlbXMgbGlrZSBhPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7cHJvZmxpZ2F0ZSBk ZXNpZ24gY2hvaWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5UaGUgZHJhZnQgY29udGFpbnMgdHdvIG1vZGVscyBhcyB5b3Ug aGF2ZSBub3RlZC4gV2hpbGUgdGhlIGlldGYtc3ViLW5vdGlmLXJlY3YtbGlzdCBhZGRzIGEgY2hv aWNlIHN0YXRlbWVudCwgdGhlIHNlY29uZCBtb2RlbCBnb2VzIG9uIHRvIGFkZGluZyBhIGNhc2Ug c3RhdGVtZW50IGZvciB0aGF0IGNob2ljZSBzdGF0ZW1lbnQuIFdlIGNvdWxkIGhhdmUgaGFyZCBj b2RlZA0KIHRoZSB0d28gbW9kZWxzIHRvZ2V0aGVyLCBidXQgYmVsaWV2ZSB0aGF0IGJ5IHNlcGFy YXRpbmcgdGhlbSwgd2Ugb2ZmZXIgdGhlIGZsZXhpYmlsaXR5IHRvIGltcGxlbWVudGF0aW9ucyB0 aGF0IG1heSBjaG9vc2Ugbm90IHRvIGltcGxlbWVudCBib3RoIHRoZSBtb2RlbHMuIEFsc28sIG90 aGVyIHRyYW5zcG9ydHMgY2FuIGF1Z21lbnQgJnF1b3Q7cmVjZWl2ZXItaW5zdGFuY2VzJnF1b3Q7 LCB3aXRob3V0IGluY2x1ZGluZyB0aGUgZW50aXJlIGh0dHAgdHJhbnNwb3J0DQogbW9kZWwuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlbGwsIHJpZ2h0IG5vdywgdGhlcmUgaXMgb25seSBvbmUg Y2hvaWNlIGZvciB0cmFuc3BvcnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+SWYgaXQgaGVscHMsIHdlIGNhbiBhZGQgYSBjb21tZW50IHRvIHRoYXQgZWZm ZWN0IGluIHRoZSBtb2RlbCB0byBleHBsYWluIG91ciBtb3RpdmF0aW9uLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGF0IHdvdWxkIGJlIGdvb2QgYWx0aG91Z2ggSSB1bmRlcnN0b29kIHRoZSBt b3RpdmF0aW9uLiBJIGd1ZXNzIHRoaXMgaXMgb25lIHdheSB0byBtYWtlIGl0IG9wdGlvbmFsIGJ1 dCBjdXJyZW50bHkgdGhlIG9ubHkgb3B0aW9uIGlzIGJvdGggbW9kZWxzIG9yIG5laXRoZXIuICZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48YnI+DQpNb2RlbCBpZXRmLXN1Yi1ub3RpZi1yZWN2LWxpc3Q6PGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7MS4gVGhlIHByZWZpeCAmcXVvdDtobiZxdW90OyBzZWVtcyBpbmNvbnNpc3RlbnQgdG8g bG9zZSB0aGUgY29udGV4dC4gSSdkIHVzZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZxdW90O3NucmxobiZxdW90Oy4gJm5ic3A7VGhpcyB3b3VsZG4ndCBi ZSBhbiBpc3N1ZSBpZiB5b3UgY29tYmluZWQgdGhlIG1vZHVsZXMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSB1cGRhdGVk IG1vZGVsIGluIC0wNyBub3cgY2FycmllcyB0aGUgcHJlZml4IOKAnGhudOKAnS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhdCBpcyBhbiBpbXByb3ZlbWVudCBidXQgc2luY2UgdGhpcyBhdWdt ZW50cyBhIG1vZGVsIHdpdGgg4oCcc25y4oCdIGFzIHRoZSBwcmVmaXgsIGl0IHNlZW1zIHRoYXQg c2hvdWxkIGJlIHBhcnQgb2YgdGhlIHByZWZpeC4gSWYgeW91IGRpZG7igJl0IGhhdmUgYSBzZXBh cmF0ZSBtb2RlbCwgaXQgd291bGRu4oCZdCBiZSBhbiBpc3N1ZS4gO14pIEhvd2V2ZXIsIEnigJlt IGxlYXZlIGl0IHRvIFRvbSAoY29waWVkKSBmb3IgZnVydGhlcg0KIGRlYmF0ZS4gPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNw OyZuYnNwOzIuIFRoaXMgY29tbWVudCBpcyBpbmNvbXByZWhlbnNpYmxlOjxicj4NCjxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy8vIGNyZWF0ZSB0aGUgbG9naWNhbCBpbXBvc3NpYmls aXR5IG9mIGVuYWJsaW5nICZxdW90O3RjcCZxdW90Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOy8vIHRyYW5zcG9ydDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Xb3VsZCBpdCBoZWxwIGlmIHdlIGV4cGFuZGVkIHRo ZSBjb21tZW50IHRvIHNheTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4vLyBUaGUgJnF1b3Q7aHR0cC1jbGllbnQtc3RhY2stZ3JvdXBpbmfigJ0gc3VwcG9y dHMgYm90aCBIVFRQIGFuZCBIVFRQUyBzdGFja3MgYnkgZGVmYXVsdC4gVGhpcyBkcmFmdCwgaG93 ZXZlciBzdXBwb3J0cyBIVFRQUyBvbmx5LiBUaGUgZm9sbG93aW5nJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Ly8gaWYtZmVhdHVyZSBzdGF0ZW1lbnQgbWFrZXMgaXQgbG9naWNhbGx5IGltcG9z c2libGUgdG8gY29uZmlndXJlIEhUVFAgdHJhbnNwb3J0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5ZZXMuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48YnI+DQpJbiB0aGUgSUFOQSBzZWN0aW9uLCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgZm9yIHRoZSBtZWRpYSB0eXBlczxicj4NCnBvaW50IHRvIHRoaXMgZHJhZnQncyBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucy4gSG93ZXZlciwgdGhleSBkb24ndDxicj4NCmluY2x1ZGUgdGhlIHJl ZmVyZW5jZWQgaW5mb3JtYXRpb24uIEl0IHNlZW1zIHRoZXNlIElBTkEgcmVmZXJlbmNlczxicj4N CnNob3VsZCBwb2ludCB0byBvdGhlciBSRkNzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgdXBkYXRlZCBJQU5BIHNlY3Rp b24gbm8gbG9uZ2VyIGNhcnJpZXMgdGhlIG1lZGlhLXR5cGVzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGF04oCZcyBiZXR0ZXIuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPGJy Pg0KQWNlZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48YnI+DQpJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBpZXRmLXN1YnNjcmliZWQtbm90aWZp Y2F0aW9ucyBoYXMgYSBudW1iZXIgb2YgWUFORzxicj4NCmVycm9ycyBhbmQgd2FybmluZ3MuPGJy Pg0KPGJyPg0KSSBhbHNvIGhhdmUgdGhlIGZvbGxvd2luZyBlZGl0b3JpYWwgY29tbWVudHM6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5BY2VlLUxpbmRlbXMtaU1hYy0yOkRlc2t0b3AgYWNlZSQgZGlmZiAtYzxicj4NCmRy YWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0wNi50eHQub3JpZzxicj4NCmRyYWZ0LWlldGYt bmV0Y29uZi1odHRwcy1ub3RpZi0wNi50eHQgKioqPGJyPg0KZHJhZnQtaWV0Zi1uZXRjb25mLWh0 dHBzLW5vdGlmLTA2LnR4dC5vcmlnICZuYnNwOzIwMjEtMDEtMjcgMTA6MDY6MjkuMDAwMDAwMDAw IC0wNTAwPGJyPg0KLS0tIGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0wNi50eHQgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7MjAyMS0wMS0yNyAxMTo1NzoxMy4wMDAw MDAwMDA8YnI+DQotMDUwMDxicj4NCioqKioqKioqKioqKioqKjxicj4NCioqKiAxNywyMyAqKioq PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFO RyBkYXRhIG1vZHVsZSBmb3IgY29uZmlndXJpbmcgSFRUUFMgYmFzZWQ8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtjb25maWd1cmVkIHN1YnNjcmlwdGlvbiwgYXMgZGVmaW5lZCBpbiBSRkMg ODYzOS4gJm5ic3A7VGhlIHVzZSBvZiBIVFRQUzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O21heGltaXplcyB0cmFuc3BvcnQtbGV2ZWwgaW50ZXJvcGVyYWJpbGl0eSwgd2hpbGUgYWxsb3dp bmcgZm9yPGJyPg0KISAmbmJzcDsmbmJzcDsmbmJzcDtlbmNvZGluZyBzZWxlY3Rpb24gZnJvbSB0 ZXh0LCBlLmcuICZuYnNwO1hNTCBvciBKU09OLCB0byBiaW5hcnkuPGJyPg0KPGJyPg0KJm5ic3A7 U3RhdHVzIG9mIFRoaXMgTWVtbzxicj4NCjxicj4NCi0tLSAxNywyMyAtLS0tPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZHVs ZSBmb3IgY29uZmlndXJpbmcgSFRUUFMgYmFzZWQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtjb25maWd1cmVkIHN1YnNjcmlwdGlvbiwgYXMgZGVmaW5lZCBpbiBSRkMgODYzOS4gJm5ic3A7 VGhlIHVzZSBvZiBIVFRQUzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO21heGltaXplcyB0 cmFuc3BvcnQtbGV2ZWwgaW50ZXJvcGVyYWJpbGl0eSwgd2hpbGUgYWxsb3dpbmcgZm9yPGJyPg0K ISAmbmJzcDsmbmJzcDsmbmJzcDtlbmNvZGluZyBzZWxlY3Rpb24gZnJvbSB0ZXh0LCBlLmcuLCAm bmJzcDtYTUwgb3IgSlNPTiwgdG8gYmluYXJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGUgYWJzdHJhY3Qgc2VjdGlvbiBo YXMgYmVlbiB1cGRhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48YnI+DQombmJzcDtTdGF0dXMgb2YgVGhpcyBNZW1vPGJyPg0KPGJyPg0K KioqKioqKioqKioqKioqPGJyPg0KKioqIDEwMywxMDkgKioqKjxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2RvY3VtZW50cy4gJm5ic3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBZQU5H IDEuMSBbUkZDNzk1MF0gZGF0YTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO21vZHVsZXMs IG9uZSBmb3IgYXVnbWVudGluZyB0aGUgU3Vic2NyaXB0aW9uIHRvIFlBTkcgTm90aWZpY2F0aW9u czxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1tSRkM4NjM5XSB0byBhZGQgYSB0cmFuc3Bv cnQgdHlwZSwgYW5kIGFub3RoZXIgZm9yIGNvbmZpZ3VyaW5nIGFuZDxicj4NCiEgJm5ic3A7Jm5i c3A7Jm5ic3A7bWFuYWdpbmcgSFRUUFMgYmFzZWQgcmVjZWl2ZXJzIGZvciB0aGUgbm90aWZpY2F0 aW9ucy48YnI+DQo8YnI+DQotLS0gMTAzLDEwOSAtLS0tPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ZG9jdW1lbnRzLiAmbmJzcDtUaGlzIGRvY3VtZW50IGRlZmluZXMgdHdvIFlBTkcgMS4x IFtSRkM3OTUwXSBkYXRhPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bW9kdWxlcywgb25l IGZvciBhdWdtZW50aW5nIHRoZSBTdWJzY3JpcHRpb24gdG8gWUFORyBOb3RpZmljYXRpb25zPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7W1JGQzg2MzldIHRvIGFkZCBhIHRyYW5zcG9ydCB0 eXBlLCBhbmQgYW5vdGhlciBmb3IgY29uZmlndXJpbmcgYW5kPGJyPg0KISAmbmJzcDsmbmJzcDsm bmJzcDttYW5hZ2luZyBIVFRQUy1iYXNlZCByZWNlaXZlcnMgZm9yIHRoZSBub3RpZmljYXRpb25z LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5GaXhlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PGJyPg0KKioqKioqKioqKioqKioqPGJyPg0KKioqIDExOCwxMjQgKioqKjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBzYW1lIHJlY2VpdmVyIGluc3RhbmNlLiAm bmJzcDtUaGUgc2Vjb25kIG1vZHVsZSBkZXNjcmliZXMgaG93IHRvPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ZW5hYmxlIHRoZSB0cmFuc21pc3Npb24gb2YgWUFORyBtb2RlbGVkIG5vdGlm aWNhdGlvbnMsIGluIHRoZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NvbmZpZ3VyZWQg ZW5jb2RpbmcgKGkuZS4sIFhNTCwgSlNPTikgb3ZlciBIVFRQUy4gJm5ic3A7Tm90aWZpY2F0aW9u cyBhcmU8YnI+DQohICZuYnNwOyZuYnNwOyZuYnNwO2RlbGl2ZXJlZCBpbiB0aGUgZm9ybSBvZiBh IEhUVFBTIFBPU1QuICZuYnNwO1RoZSB1c2Ugb2YgSFRUUFMgbWF4aW1pemVzPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7dHJhbnNwb3J0LWxldmVsIGludGVyb3BlcmFiaWxpdHksIHdoaWxl IHRoZSBlbmNvZGluZyBzZWxlY3Rpb24gcGl2b3RzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7YmV0d2VlbiBpbXBsZW1lbnRhdGlvbiBzaW1wbGljaXR5IChYTUwsIEpTT04pIGFuZCB0aHJv dWdocHV0ICh0ZXh0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dmVyc3VzIGJpbmFyeSku PGJyPg0KLS0tIDExOCwxMjQgLS0tLTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBz YW1lIHJlY2VpdmVyIGluc3RhbmNlLiAmbmJzcDtUaGUgc2Vjb25kIG1vZHVsZSBkZXNjcmliZXMg aG93IHRvPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZW5hYmxlIHRoZSB0cmFuc21pc3Np b24gb2YgWUFORyBtb2RlbGVkIG5vdGlmaWNhdGlvbnMsIGluIHRoZTxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO2NvbmZpZ3VyZWQgZW5jb2RpbmcgKGkuZS4sIFhNTCwgSlNPTikgb3ZlciBI VFRQUy4gJm5ic3A7Tm90aWZpY2F0aW9ucyBhcmU8YnI+DQohICZuYnNwOyZuYnNwOyZuYnNwO2Rl bGl2ZXJlZCBpbiB0aGUgZm9ybSBvZiBhbiBIVFRQUyBQT1NULiAmbmJzcDtUaGUgdXNlIG9mIEhU VFBTIG1heGltaXplczxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RyYW5zcG9ydC1sZXZl bCBpbnRlcm9wZXJhYmlsaXR5LCB3aGlsZSB0aGUgZW5jb2Rpbmcgc2VsZWN0aW9uIHBpdm90czxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2JldHdlZW4gaW1wbGVtZW50YXRpb24gc2ltcGxp Y2l0eSAoWE1MLCBKU09OKSBhbmQgdGhyb3VnaHB1dCAodGV4dDxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO3ZlcnN1cyBiaW5hcnkpLjxicj4NCioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5GaXhl ZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ KioqIDE5NiwyMDIgKioqKjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0luIHRo ZSBjYXNlIG9mICZxdW90O3BpcGVsaW5pbmcmcXVvdDssIHRoZSBmbG93IG9mIG1lc3NhZ2VzIHdv dWxkIGxvb2s8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzb21ldGhpbmcgbGlrZSB0aGlz LiAmbmJzcDtUaGlzIGV4YW1wbGUgc2hvd3MgdGhlIGZsb3cgYXNzdW1pbmcgdGhhdDxicj4NCiEg Jm5ic3A7Jm5ic3A7Jm5ic3A7U3Vic2NyaWJlZCBOb3RpZmljYXRpb25zIGlzIHVzZWQgYW5kIHRo ZXJlZm9yZSBhICZsdDtzdWJzY3JpcHRpb24tPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 c3RhcnRlZCZndDsgbm90aWZpY2F0aW9uIGlzIHNlbnQgYmVmb3JlIHNlbmRpbmcgdGhlIGZpcnN0 IG5vdGlmaWNhdGlvbi48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgZXhhbXBsZSB3 b3VsZCBiZSB0aGUgc2FtZSBmb3Igd2hlbiBTdWJzY3JpYmVkIE5vdGlmaWNhdGlvbiBpcyBub3Q8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1c2VkIGJ5IHJlbW92aW5nIHRoZSBmaXJzdCBQ T1NUIG1lc3NhZ2UgZm9yICZsdDtzdXNic2NyaXB0aW9uLXN0YXJ0ZWQmZ3Q7Ljxicj4NCi0tLSAx OTYsMjAyIC0tLS08YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJbiB0aGUgY2Fz ZSBvZiAmcXVvdDtwaXBlbGluaW5nJnF1b3Q7LCB0aGUgZmxvdyBvZiBtZXNzYWdlcyB3b3VsZCBs b29rPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c29tZXRoaW5nIGxpa2UgdGhpcy4gJm5i c3A7VGhpcyBleGFtcGxlIHNob3dzIHRoZSBmbG93IGFzc3VtaW5nIHRoYXQ8YnI+DQohICZuYnNw OyZuYnNwOyZuYnNwO1N1YnNjcmliZWQgTm90aWZpY2F0aW9uIGlzIHVzZWQgYW5kIHRoZXJlZm9y ZSBhICZsdDtzdWJzY3JpcHRpb24tPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3RhcnRl ZCZndDsgbm90aWZpY2F0aW9uIGlzIHNlbnQgYmVmb3JlIHNlbmRpbmcgdGhlIGZpcnN0IG5vdGlm aWNhdGlvbi48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgZXhhbXBsZSB3b3VsZCBi ZSB0aGUgc2FtZSBmb3Igd2hlbiBTdWJzY3JpYmVkIE5vdGlmaWNhdGlvbiBpcyBub3Q8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1c2VkIGJ5IHJlbW92aW5nIHRoZSBmaXJzdCBQT1NUIG1l c3NhZ2UgZm9yICZsdDtzdXNic2NyaXB0aW9uLXN0YXJ0ZWQmZ3Q7Ljxicj4NCioqKioqKioqKioq KioqKjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5UaGlzIHNlY3Rpb24gaGFzIGJlZW4gcmV3cml0dGVuLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4qKiogMzQyLDM1MCAqKioq PGJyPg0KPGJyPg0KJm5ic3A7Mi4xLiAmbmJzcDtJbnRyb2R1Y3Rpb248YnI+DQo8YnI+DQohICZu YnNwOyZuYnNwOyZuYnNwO1RvIGxlYXJuIHRoZSBjYXBhYmlsaXRpZXMgb2YgdGhlIHJlY2VpdmVy LCB0aGUgcHVibGlzaGVyIGNhbiBpc3N1ZSBhPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 SFRUUFMgR0VUIHJlcXVlc3Qgd2l0aCBBY2NlcHQtVHlwZSBzZXQgdG8gYXBwbGljYXRpb24vaWV0 Zi1odHRwcy08YnI+DQohICZuYnNwOyZuYnNwOyZuYnNwO25vdGlmLWNhcCt4bWwgb3IgYXBwbGlj YXRpb24vaWV0Zi1odHRwcy1ub3RpZi1jYXAranNvbiwgd2l0aCBsYXR0ZXI8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDthcyB0aGUgbWFuZGF0b3J5IHRvIGltcGxlbWVudCwgYW5kIHRoZSBk ZWZhdWx0IGluIGNhc2UgdGhlIHR5cGUgaXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtu b3Qgc3BlY2lmaWVkLiAmbmJzcDtJZiB0aGUgcmVjZWl2ZXIgc3VwcG9ydHMgY2FwYWJpbGl0aWVz IHN1Y2ggYXMgYmluYXJ5PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZW5jb2Rpbmcgb2Yg ZGF0YSwgaXQgY2FuIHJldHVybiB0aGF0IGFzIGEgY2FwYWJpbGl0eSBpbiBhIHJlc3BvbnNlLjxi cj4NCi0tLSAzNDIsMzUwIC0tLS08YnI+DQo8YnI+DQombmJzcDsyLjEuICZuYnNwO0ludHJvZHVj dGlvbjxicj4NCjxicj4NCiEgJm5ic3A7Jm5ic3A7Jm5ic3A7VG8gbGVhcm4gdGhlIGNhcGFiaWxp dGllcyBvZiB0aGUgcmVjZWl2ZXIsIHRoZSBwdWJsaXNoZXIgY2FuIGlzc3VlIGFuPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SFRUUFMgR0VUIHJlcXVlc3Qgd2l0aCBBY2NlcHQtVHlwZSBz ZXQgdG8gYXBwbGljYXRpb24vaWV0Zi1odHRwcy08YnI+DQohICZuYnNwOyZuYnNwOyZuYnNwO25v dGlmLWNhcCt4bWwgb3IgYXBwbGljYXRpb24vaWV0Zi1odHRwcy1ub3RpZi1jYXAranNvbiwgd2l0 aCB0aGUgbGF0dGVyPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YXMgdGhlIG1hbmRhdG9y eSB0byBpbXBsZW1lbnQsIGFuZCB0aGUgZGVmYXVsdCBpbiBjYXNlIHRoZSB0eXBlIGlzPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bm90IHNwZWNpZmllZC4gJm5ic3A7SWYgdGhlIHJlY2Vp dmVyIHN1cHBvcnRzIGNhcGFiaWxpdGllcyBzdWNoIGFzIGJpbmFyeTxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO2VuY29kaW5nIG9mIGRhdGEsIGl0IGNhbiByZXR1cm4gdGhhdCBhcyBhIGNh cGFiaWxpdHkgaW4gYSByZXNwb25zZS48YnI+DQoqKioqKioqKioqKioqKio8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Rml4ZWQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPioq KiA0NTAsNDU2ICoqKio8YnI+DQombmJzcDtJbnRlcm5ldC1EcmFmdCAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtIVFRQUyBDb25maWd1cmVkIFN1YnNjcmlwdGlvbiAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtOb3ZlbWJlciAyMDIwPGJy Pg0KPGJyPg0KISAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDb3B5cmlnaHQgKGMpIDIw MTggSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhczxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBkb2N1bWVudCBhdXRob3JzLiAmbmJzcDtB bGwgcmlnaHRzIHJlc2VydmVkLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO1JlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdp dGggb3I8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt3aXRob3V0IG1v ZGlmaWNhdGlvbiwgaXMgcGVybWl0dGVkIHB1cnN1YW50IHRvLCBhbmQgc3ViamVjdDxicj4NCi0t LSA0NTAsNDU2IC0tLS08YnI+DQombmJzcDtJbnRlcm5ldC1EcmFmdCAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtIVFRQUyBDb25maWd1cmVkIFN1YnNjcmlwdGlvbiAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtOb3ZlbWJlciAyMDIwPGJy Pg0KPGJyPg0KISAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDb3B5cmlnaHQgKGMpIDIw MjEgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhczxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZSBkb2N1bWVudCBhdXRob3JzLiAmbmJzcDtB bGwgcmlnaHRzIHJlc2VydmVkLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO1JlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdp dGggb3I8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt3aXRob3V0IG1v ZGlmaWNhdGlvbiwgaXMgcGVybWl0dGVkIHB1cnN1YW50IHRvLCBhbmQgc3ViamVjdDxicj4NCioq KioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5GaXhlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KioqIDUzNiw1NDUgKioqKjxicj4NCjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgWUFORyBtb2R1bGUgaXMgYSBkZWZpbml0aW9uIG9mIGEg c2V0IG9mIHJlY2VpdmVycyB0aGF0IGFyZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2lu dGVyZXN0ZWQgaW4gdGhlIG5vdGlmaWNhdGlvbnMgcHVibGlzaGVkIGJ5IHRoZSBwdWJsaXNoZXIu ICZuYnNwO1RoZTxicj4NCiEgJm5ic3A7Jm5ic3A7Jm5ic3A7bW9kdWxlIGNvbnRhaW5zIHRoZSBU Q1AsIFRMUyBhbmQgSFRUUFMgcGFyYW1ldGVycyB0aGF0IGFyZSBuZWVkZWQgdG88YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtjb21tdW5pY2F0ZSB3aXRoIHRoZSByZWNlaXZlci4gJm5ic3A7 VGhlIG1vZHVsZSBhdWdtZW50cyB0aGUgaWV0Zi1zdWItPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7bm90aWYtcmVjdi1saXN0IG1vZHVsZSB0byBkZWZpbmUgYSB0cmFuc3BvcnQgc3BlY2lm aWMgcmVjZWl2ZXIuICZuYnNwO0FzPGJyPg0KISAmbmJzcDsmbmJzcDsmbmJzcDttZW50aW9uZWQg ZWFybGllciwgaXQgdXNlcyBQT1NUIG1ldGhvZCB0byBkZWxpdmVyIHRoZSBub3RpZmljYXRpb24u PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIGF0dHJpYnV0ZSAncGF0aCcgZGVmaW5l cyB0aGUgcGF0aCBmb3IgdGhlIHJlc291cmNlIG9uIHRoZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3JlY2VpdmVyLCBhcyBkZWZpbmVkIGJ5ICdwYXRoLWFic29sdXRlJyBpbiBVUkkgR2Vu ZXJpYyBTeW50YXg8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtbUkZDMzk4Nl0uICZuYnNw O1RoZSB1c2VyLWlkIHVzZWQgYnkgTmV0d29yayBDb25maWd1cmF0aW9uIEFjY2VzcyBDb250cm9s PGJyPg0KLS0tIDUzNiw1NDUgLS0tLTxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O1RoaXMgWUFORyBtb2R1bGUgaXMgYSBkZWZpbml0aW9uIG9mIGEgc2V0IG9mIHJlY2VpdmVycyB0 aGF0IGFyZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2ludGVyZXN0ZWQgaW4gdGhlIG5v dGlmaWNhdGlvbnMgcHVibGlzaGVkIGJ5IHRoZSBwdWJsaXNoZXIuICZuYnNwO1RoZTxicj4NCiEg Jm5ic3A7Jm5ic3A7Jm5ic3A7bW9kdWxlIGNvbnRhaW5zIHRoZSBUQ1AsIFRMUywgYW5kIEhUVFBT IHBhcmFtZXRlcnMgdGhhdCBhcmUgbmVlZGVkIHRvPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Y29tbXVuaWNhdGUgd2l0aCB0aGUgcmVjZWl2ZXIuICZuYnNwO1RoZSBtb2R1bGUgYXVnbWVu dHMgdGhlIGlldGYtc3ViLTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO25vdGlmLXJlY3Yt bGlzdCBtb2R1bGUgdG8gZGVmaW5lIGEgdHJhbnNwb3J0IHNwZWNpZmljIHJlY2VpdmVyLiAmbmJz cDtBczxicj4NCiEgJm5ic3A7Jm5ic3A7Jm5ic3A7bWVudGlvbmVkIGVhcmxpZXIsIGl0IHVzZXMg dGhlIFBPU1QgbWV0aG9kIHRvIGRlbGl2ZXIgdGhlIG5vdGlmaWNhdGlvbi48YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtUaGUgYXR0cmlidXRlICdwYXRoJyBkZWZpbmVzIHRoZSBwYXRoIGZv ciB0aGUgcmVzb3VyY2Ugb24gdGhlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVjZWl2 ZXIsIGFzIGRlZmluZWQgYnkgJ3BhdGgtYWJzb2x1dGUnIGluIFVSSSBHZW5lcmljIFN5bnRheDxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1tSRkMzOTg2XS4gJm5ic3A7VGhlIHVzZXItaWQg dXNlZCBieSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gQWNjZXNzIENvbnRyb2w8YnI+DQoqKioqKioq KioqKioqKio8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+VGhpcyBzZWN0aW9uIG9mIHRoZSBtb2R1bGUgaGFzIGJlZW4gcmV3cml0 dGVuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4qKiogNjM5LDY0NSAqKioqPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ZGVzY3JpcHRpb248YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmcXVvdDtZQU5HIG1vZHVsZSBmb3IgY29uZmlndXJpbmcgSFRUUFMgYmFzZSBj b25maWd1cmF0aW9uLjxicj4NCjxicj4NCiEgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Q29weXJpZ2h0IChjKSAyMDE4IElFVEYgVHJ1c3QgYW5kIHRoZSBw ZXJzb25zIGlkZW50aWZpZWQgYXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgZG9jdW1lbnQgYXV0aG9ycy4gJm5ic3A7QWxsIHJp Z2h0cyByZXNlcnZlZC48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmlu YXJ5IGZvcm1zLCB3aXRoIG9yPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7d2l0aG91dCBtb2RpZmljYXRpb24sIGlzIHBlcm1pdHRlZCBw dXJzdWFudCB0bywgYW5kIHN1YmplY3Q8YnI+DQotLS0gNjM5LDY0NSAtLS0tPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGVzY3JpcHRpb248YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtZQU5HIG1vZHVsZSBm b3IgY29uZmlndXJpbmcgSFRUUFMgYmFzZSBjb25maWd1cmF0aW9uLjxicj4NCjxicj4NCiEgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q29weXJpZ2h0IChj KSAyMDIxIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXM8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgZG9j dW1lbnQgYXV0aG9ycy4gJm5ic3A7QWxsIHJpZ2h0cyByZXNlcnZlZC48YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSZWRpc3RyaWJ1dGlv biBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7d2l0aG91dCBt b2RpZmljYXRpb24sIGlzIHBlcm1pdHRlZCBwdXJzdWFudCB0bywgYW5kIHN1YmplY3Q8YnI+DQoq KioqKioqKioqKioqKio8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Rml4ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPioqKiA3MDQsNzEwICoqKio8YnI+DQo8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtjb250YWluZXIgcmVjZWl2ZXItaWRlbnRpdHkgezxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO2Rlc2NyaXB0aW9uPGJyPg0KISAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmcXVvdDtTcGVjaWZpZXMgbWVjaGFuaXNtIGZvciBpZGVudGlmeWluZyB0aGUg cmVjZWl2ZXIuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7VGhlIHB1Ymxpc2hlciBNVVNUIE5PVCBpbmNsdWRlIGFueSBjb250ZW50IGluIGE8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtub3RpZmljYXRpb24g dGhhdCB0aGUgdXNlciBpcyBub3QgYXV0aG9yaXplZCB0byB2aWV3LiZxdW90Ozs8YnI+DQo8YnI+ DQotLS0gNzA0LDcxMCAtLS0tPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y29udGFpbmVyIHJl Y2VpdmVyLWlkZW50aXR5IHs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtkZXNjcmlw dGlvbjxicj4NCiEgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7U3BlY2lm aWVzIHRoZSBtZWNoYW5pc20gZm9yIGlkZW50aWZ5aW5nIHRoZSByZWNlaXZlci48YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgcHVibGlzaGVyIE1V U1QgTk9UIGluY2x1ZGUgYW55IGNvbnRlbnQgaW4gYTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO25vdGlmaWNhdGlvbiB0aGF0IHRoZSB1c2VyIGlzIG5v dCBhdXRob3JpemVkIHRvIHZpZXcuJnF1b3Q7Ozxicj4NCjxicj4NCioqKioqKioqKioqKioqKjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5UaGlzIGRlc2NyaXB0aW9uIHN0YXRlbWVudCBoYXMgYmVlbiB1cGRhdGVkLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4qKiogNzkxLDgw MSAqKioqPGJyPg0KPGJyPg0KJm5ic3A7Ni4gJm5ic3A7UmVjZWl2aW5nIEV2ZW50IE5vdGlmaWNh dGlvbnM8YnI+DQo8YnI+DQohICZuYnNwOyZuYnNwOyZuYnNwO0VuY29kaW5nIG5vdGlmaWNhdGlv bnMgZm9yIHRoZSBIVFRQUyBub3RpZmljYXRpb25zIGlzIHRoZSBzYW1lIGFzIHRoZTxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2VuY29kaW5nIG5vdGlmaWNhdGlvbnMgYXMgZGVmaW5lZCBp biBSRVNUQ09ORiBbUkZDODA0MF0gU2VjdGlvbiA2LjQsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7d2l0aCB0aGUgZm9sbG93aW5nIGNoYW5nZXMuICZuYnNwO0luc3RlYWQgb2Ygc2F5aW5n IHRoYXQgZm9yIEpTT04tZW5jb2Rpbmc8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwdXJw b3NlcywgdGhlIG1vZHVsZSBuYW1lIGZvciAmcXVvdDtub3RpZmljYXRpb24mcXVvdDsgZWxlbWVu dCB3aWxsIGJlICZxdW90O2lldGYtPGJyPg0KISAmbmJzcDsmbmJzcDsmbmJzcDtyZXN0Y29uZiwg aXQgd2lsbCBzYXkgdGhhdCBmb3IgSlNPTi1lbmNvZGluZyBwdXJwb3NlcywgdGhlIG1vZHVsZTxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO25hbWUgZm9yICZxdW90O25vdGlmaWNhdGlvbiZx dW90OyBlbGVtZW50IHdpbGwgYmUgJnF1b3Q7aWV0Zi1odHRwcy1ub3RpZiZxdW90Oy48YnI+DQo8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtXaXRoIHRob3NlIGNoYW5nZXMsIHRoZSBTU0Ug ZXZlbnQgbm90aWZpY2F0aW9uIGVuY29kZWQgSlNPTiBleGFtcGxlPGJyPg0KLS0tIDc5MSw4MDEg LS0tLTxicj4NCjxicj4NCiZuYnNwOzYuICZuYnNwO1JlY2VpdmluZyBFdmVudCBOb3RpZmljYXRp b25zPGJyPg0KPGJyPg0KISAmbmJzcDsmbmJzcDsmbmJzcDtFbmNvZGluZyBub3RpZmljYXRpb25z IGZvciB0aGUgSFRUUFMgbm90aWZpY2F0aW9ucyBpcyB0aGUgc2FtZSBhcyBmb3I8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtlbmNvZGluZyBub3RpZmljYXRpb25zIGFzIGRlZmluZWQgaW4g UkVTVENPTkYgW1JGQzgwNDBdIFNlY3Rpb24gNi40LDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3dpdGggdGhlIGZvbGxvd2luZyBjaGFuZ2VzLiAmbmJzcDtJbnN0ZWFkIG9mIHNheWluZyB0 aGF0IGZvciBKU09OLWVuY29kaW5nPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cHVycG9z ZXMsIHRoZSBtb2R1bGUgbmFtZSBmb3IgJnF1b3Q7bm90aWZpY2F0aW9uJnF1b3Q7IGVsZW1lbnQg d2lsbCBiZSAmcXVvdDtpZXRmLTxicj4NCiEgJm5ic3A7Jm5ic3A7Jm5ic3A7cmVzdGNvbmYmcXVv dDssIGl0IHdpbGwgc2F5IHRoYXQgZm9yIEpTT04tZW5jb2RpbmcgcHVycG9zZXMsIHRoZSBtb2R1 bGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtuYW1lIGZvciAmcXVvdDtub3RpZmljYXRp b24mcXVvdDsgZWxlbWVudCB3aWxsIGJlICZxdW90O2lldGYtaHR0cHMtbm90aWYmcXVvdDsuPGJy Pg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2l0aCB0aG9zZSBjaGFuZ2VzLCB0aGUg U1NFIGV2ZW50IG5vdGlmaWNhdGlvbiBlbmNvZGVkIEpTT04gZXhhbXBsZTxicj4NCioqKioqKioq KioqKioqKjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5UaGlzIGFuZCBhbGwgdGhlIGZvbGxvd2luZyBzZWN0aW9ucyBoYXZlIGJl ZW4gdXBkYXRlZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5UaGFua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDtt YXJnaW4tbGVmdDouNWluIj4NCioqKiA4MTUsODI2ICoqKio8YnI+DQo8YnI+DQombmJzcDs3LiAm bmJzcDtJQU5BIENvbnNpZGVyYXRpb25zPGJyPg0KPGJyPg0KISAmbmJzcDsmbmJzcDsmbmJzcDtU aGlzIGRvY3VtZW50IHJlZ2lzdGVycyB0d28gVVJJLCB0d28gWUFORyBtb2R1bGUgYW5kIHR3byBN ZWRpYSBUeXBlcy48YnI+DQo8YnI+DQombmJzcDs3LjEuICZuYnNwO1VSSSBSZWdpc3RyYXRpb248 YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpbiB0aGUgSUVURiBYTUwgcmVnaXN0 cnkgW1JGQzM2ODhdLiAmbmJzcDtGb2xsb3dpbmcgdGhlIGZvcm1hdCBpbiBSRkM8YnI+DQohICZu YnNwOyZuYnNwOyZuYnNwOzM2ODgsIHRoZSBmb2xsb3dpbmcgcmVnaXN0cmF0aW9uIGlzIHJlcXVl c3RlZCB0byBiZSBtYWRlOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1VSSTog dXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtaHR0cC1ub3RpZjxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1VSSTogdXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtc3Vi LW5vdGlmLXJlY3YtbGlzdDxicj4NCi0tLSA4MTUsODI2IC0tLS08YnI+DQo8YnI+DQombmJzcDs3 LiAmbmJzcDtJQU5BIENvbnNpZGVyYXRpb25zPGJyPg0KPGJyPg0KISAmbmJzcDsmbmJzcDsmbmJz cDtUaGlzIGRvY3VtZW50IHJlZ2lzdGVycyB0d28gVVJJcywgdHdvIFlBTkcgbW9kdWxlcywgYW5k IHR3byBNZWRpYSBUeXBlcy48YnI+DQo8YnI+DQombmJzcDs3LjEuICZuYnNwO1VSSSBSZWdpc3Ry YXRpb248YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpbiB0aGUgSUVURiBYTUwg cmVnaXN0cnkgW1JGQzM2ODhdLiAmbmJzcDtGb2xsb3dpbmcgdGhlIGZvcm1hdCBpbiBSRkM8YnI+ DQohICZuYnNwOyZuYnNwOyZuYnNwOzM2ODgsIHRoZSBmb2xsb3dpbmcgcmVnaXN0cmF0aW9ucyBh cmUgcmVxdWVzdGVkIHRvIGJlIG1hZGU6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7VVJJOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1odHRwLW5vdGlmPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VVJJOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6 aWV0Zi1zdWItbm90aWYtcmVjdi1saXN0PGJyPg0KKioqKioqKioqKioqKioqPGJyPg0KKioqIDg1 NCw4NjAgKioqKjxicj4NCjxicj4NCiZuYnNwOzcuMy4gJm5ic3A7TWVkaWEgVHlwZXM8YnI+DQo8 YnI+DQohIDcuMy4xLiAmbmJzcDtNZWRpYSBUeXBlICZxdW90O2FwcGxpY2F0aW9uL2lldGYtaHR0 cHMtbm90aWYtY2FwK3htbDxicj4NCjxicj4NCiZuYnNwO1R5cGUgbmFtZTogYXBwbGljYXRpb248 YnI+DQo8YnI+DQotLS0gODU0LDg2MCAtLS0tPGJyPg0KPGJyPg0KJm5ic3A7Ny4zLiAmbmJzcDtN ZWRpYSBUeXBlczxicj4NCjxicj4NCiEgNy4zLjEuICZuYnNwO01lZGlhIFR5cGUgJnF1b3Q7YXBw bGljYXRpb24vaWV0Zi1odHRwcy1ub3RpZi1jYXAreG1sJnF1b3Q7PGJyPg0KPGJyPg0KJm5ic3A7 VHlwZSBuYW1lOiBhcHBsaWNhdGlvbjxicj4NCjxicj4NCioqKioqKioqKioqKioqKjxicj4NCioq KiA5MTcsOTIzICoqKio8YnI+DQo8YnI+DQombmJzcDtQcm92aXNpb25hbCByZWdpc3RyYXRpb24/ IChzdGFuZGFyZHMgdHJlZSBvbmx5KTogbm88YnI+DQo8YnI+DQohIDcuMy4yLiAmbmJzcDtNZWRp YSBUeXBlICZxdW90O2FwcGxpY2F0aW9uL2lldGYtaHR0cHMtbm90aWYtY2FwK2pzb248YnI+DQo8 YnI+DQombmJzcDtUeXBlIG5hbWU6IGFwcGxpY2F0aW9uPGJyPg0KPGJyPg0KLS0tIDkxNyw5MjMg LS0tLTxicj4NCjxicj4NCiZuYnNwO1Byb3Zpc2lvbmFsIHJlZ2lzdHJhdGlvbj8gKHN0YW5kYXJk cyB0cmVlIG9ubHkpOiBubzxicj4NCjxicj4NCiEgNy4zLjIuICZuYnNwO01lZGlhIFR5cGUgJnF1 b3Q7YXBwbGljYXRpb24vaWV0Zi1odHRwcy1ub3RpZi1jYXAranNvbiZxdW90Ozxicj4NCjxicj4N CiZuYnNwO1R5cGUgbmFtZTogYXBwbGljYXRpb248YnI+DQo8YnI+DQoqKioqKioqKioqKioqKio8 YnI+DQoqKiogMTEwNiwxMTEyICoqKio8YnI+DQombmJzcDsmbHQ7L2NvbmZpZyZndDs8YnI+DQo8 YnI+DQohIDguMi4gJm5ic3A7Tm9uIFN1YnNjcmliZWQgTm90aWZpY2F0aW9uIGJhc2VkIENvbmZp Z3VyYXRpb248YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJbiB0aGUgY2FzZSB0 aGF0IGl0IGlzIGRlc2lyZWQgdG8gdXNlIEhUVFBTIG5vdGlmIG91dHNpZGUgb2Y8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtTdWJzY3JpYmVkIE5vdGlmaWNhdGlvbnMsIHRoZXJlIHdvdWxk IGhhdmUgdG8gYmUgYSBtb2R1bGUgdG8gZGVmaW5lPGJyPg0KLS0tIDExMDYsMTExMiAtLS0tPGJy Pg0KJm5ic3A7Jmx0Oy9jb25maWcmZ3Q7PGJyPg0KPGJyPg0KISA4LjIuICZuYnNwO05vbi1TdWJz Y3JpYmVkIE5vdGlmaWNhdGlvbiBiYXNlZCBDb25maWd1cmF0aW9uPGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7SW4gdGhlIGNhc2UgdGhhdCBpdCBpcyBkZXNpcmVkIHRvIHVzZSBI VFRQUyBub3RpZiBvdXRzaWRlIG9mPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U3Vic2Ny aWJlZCBOb3RpZmljYXRpb25zLCB0aGVyZSB3b3VsZCBoYXZlIHRvIGJlIGEgbW9kdWxlIHRvIGRl ZmluZTxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpBY2VlPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TWFoZXNoIEpldGhhbmFu ZGFuaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBn bWFpbC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_D9F4C4E1224E41FC876A81274FF6256Eciscocom_-- From nobody Wed Feb 10 15:54:58 2021 Return-Path: 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 EB1F23A0E1F; Wed, 10 Feb 2021 15:54:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <161300129188.29461.3458075948704758224@ietfa.amsl.com> Date: Wed, 10 Feb 2021 15:54:51 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-crypto-types-19.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 23:54:52 -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 Data Types and Groupings for Cryptography Author : Kent Watsen Filename : draft-ietf-netconf-crypto-types-19.txt Pages : 61 Date : 2021-02-10 Abstract: This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-crypto-types-19.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 10 15:56:01 2021 Return-Path: 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 95C3A3A0E49; Wed, 10 Feb 2021 15:55:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <161300135657.9121.10640743135929525107@ietfa.amsl.com> Date: Wed, 10 Feb 2021 15:55:56 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-14.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 23:55:57 -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 : A YANG Data Model for a Truststore Author : Kent Watsen Filename : draft-ietf-netconf-trust-anchors-14.txt Pages : 39 Date : 2021-02-10 Abstract: This document defines a YANG module for configuring bags of certificates and bags of public keys that can be referenced by other data models for trust. Notifications are sent when certificates are about to expire. 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: * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "BBBB" --> 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: * "2021-02-10" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-trust-anchors-14.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-trust-anchors-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 10 15:57:58 2021 Return-Path: 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 8ADFD3A0E25; Wed, 10 Feb 2021 15:57:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <161300147752.22323.5388154332625339919@ietfa.amsl.com> Date: Wed, 10 Feb 2021 15:57:57 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-23.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 23:57:58 -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 SSH Clients and SSH Servers Author : Kent Watsen Filename : draft-ietf-netconf-ssh-client-server-23.txt Pages : 62 Date : 2021-02-10 Abstract: This document defines three YANG modules: the first defines groupings for a generic SSH client, the second defines groupings for a generic SSH server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the SSH protocol. 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: * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors * "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore * "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server * "EEEE" --> 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: * "2021-02-10" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-ssh-client-server-23.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 10 15:59:16 2021 Return-Path: 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 D42F13A0E27; Wed, 10 Feb 2021 15:59:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <161300155083.26372.11314837489898276501@ietfa.amsl.com> Date: Wed, 10 Feb 2021 15:59:10 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-23.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 23:59: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 TLS Clients and TLS Servers Author : Kent Watsen Filename : draft-ietf-netconf-tls-client-server-23.txt Pages : 59 Date : 2021-02-10 Abstract: This document defines three YANG modules: the first defines groupings for a generic TLS client, the second defines groupings for a generic TLS server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the TLS protocol. 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: * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors * "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore * "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server * "FFFF" --> 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: * "2021-02-10" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-tls-client-server-23.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 10 16:00:04 2021 Return-Path: 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 F28E63A0EC6; Wed, 10 Feb 2021 15:59:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <161300159796.14660.5559687234338088781@ietfa.amsl.com> Date: Wed, 10 Feb 2021 15:59:57 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-http-client-server-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 00:00:04 -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 HTTP Clients and HTTP Servers Author : Kent Watsen Filename : draft-ietf-netconf-http-client-server-06.txt Pages : 31 Date : 2021-02-10 Abstract: This document defines two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). 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 (note: not all may be present): * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors * "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore * "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server * "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- client-server * "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- client-server * "GGGG" --> 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: * "2021-02-10" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-http-client-server/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-http-client-server-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-http-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 Wed Feb 10 16:01:02 2021 Return-Path: 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 2D6583A1163; Wed, 10 Feb 2021 16:00:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <161300165114.20714.975156061192590891@ietfa.amsl.com> Date: Wed, 10 Feb 2021 16:00:51 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-client-server-22.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 00:00:57 -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 : NETCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-netconf-client-server-22.txt Pages : 58 Date : 2021-02-10 Abstract: This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. 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 (note: not all may be present): * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors * "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore * "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server * "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- client-server * "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- client-server * "GGGG" --> the assigned RFC value for draft-ietf-netconf-http- client-server * "HHHH" --> 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: * "2021-02-10" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-netconf-client-server-22.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-client-server-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 10 16:02:03 2021 Return-Path: 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 211873A10C7; Wed, 10 Feb 2021 16:01:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <161300171101.545.6068348103148030674@ietfa.amsl.com> Date: Wed, 10 Feb 2021 16:01:51 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-restconf-client-server-22.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 00:01:58 -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 : RESTCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-restconf-client-server-22.txt Pages : 55 Date : 2021-02-10 Abstract: This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. 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 (note: not all may be present): * "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types * "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors * "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore * "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server * "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- client-server * "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- client-server * "GGGG" --> the assigned RFC value for draft-ietf-netconf-http- client-server * "HHHH" --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * "IIII" --> 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: * "2021-02-10" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix B. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-restconf-client-server-22.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-client-server-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 10 16:04:42 2021 Return-Path: <010001778e67638b-53d8c33f-82f6-4bda-881a-3cf881c06c95-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 4F5243A0E2D; Wed, 10 Feb 2021 16:04:41 -0800 (PST) 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 iN-zuaQ3c4Pk; Wed, 10 Feb 2021 16:04:38 -0800 (PST) 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 0CF783A0E2A; Wed, 10 Feb 2021 16:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1613001876; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=mhc1bnW/VzsfhzFXwjKRmx/eIgc/XtPgGhGjACaPmec=; b=PdqR5UNJfpMw8YijPWo3ABr3VRKWuP3npOU4b3/jjKGofWYdaHSBADD3KVswL5Gu xEdWRJWX0fz+pBdzDAdL+0mwicKIN5cpK2HarByRtPlIs9vidrEIyireVXC9nAXrXb4 lCjnVoTFnpWVTnAXl8sq/tmC+7w2o41oBR+q2mRw= From: Kent Watsen Message-ID: <010001778e67638b-53d8c33f-82f6-4bda-881a-3cf881c06c95-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8BF13DB0-EAF9-41C4-AF3A-52CB3DBBE330" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 11 Feb 2021 00:04:36 +0000 In-Reply-To: <161045360252.14510.16755799701987783827@ietfa.amsl.com> Cc: "netconf@ietf.org" , YANG Doctors To: Juergen Schoenwaelder References: <161045360252.14510.16755799701987783827@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.11-54.240.48.95 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-crypto-types-18 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 00:04:41 -0000 --Apple-Mail=_8BF13DB0-EAF9-41C4-AF3A-52CB3DBBE330 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you for your review, Juergen! Below are responses to your comments. PS: this response took longer because I had to triage with Security = Experts on a couple points. Kent > Reviewer: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder > Review result: Ready with Issues >=20 > The crypto modules aim at providing a flexible reusable infrastructure > of groupings for modeling cryptographic keys and related concepts. The > flexibility of the definitions provided of course comes with a certain > amount of complexity. >=20 >> =46rom a YANG perspective, draft-ietf-netconf-crypto-types-18.txt is = in > a good and close to publish state (a couple of minor issues left). I > also tried to understand what is being modeled here and hence I also > have some questions concerning the concepts modeled and I hope these > are easy to answer/resolve as well. >=20 > - I have compiled the YANG modules using yanglint 0.16.105. >=20 > - s/ietf-crypt-types/ietf-crypto-types/ Fixed. > - Does it make sense to have a new notation like >=20 > | The diagram above uses syntax that is similar to but not > | defined in [RFC8340]. >=20 > or shall this simply become regular text? I find using tree-diagram like notation for features, identities, and = typedefs helpful, especially in showing the =E2=80=9Cif-feature=E2=80=9D = constraints and hierarchical relationships between items. I recommend = adding these enhancements to RFC 8340. It would be helpful if someone = could whip up an I-D so these documents could reference the I-D instead = of having the "The diagram above uses syntax that is similar to but not = defined in [RFC8340]=E2=80=9D language. That said, I also used a "rfc8340-like" diagram to list all the = groupings in a module. It seems like the consistent thing to do, but I = can=E2=80=99t imagine the RFC 8340 being updated to support that output, = so I replaced that diagram, with a normal "xml2rfc" list, in the entire = suite of drafts. > - "Identities use to specify uncommon formats are enabled [...]" is > this correct or should it be "used to specify=E2=80=9D? Fixed. > - Second bullet 2.1.4.1: >=20 > Perhaps change >=20 > [...] specified by the "format" identity Section 2.1.2 associated = [...] >=20 > to >=20 > [...] specified by the "format" identity (see Section 2.1.2) = associated [=E2=80=A6] Fixed, but see below... > What is 'encoded in the format specified by the "format" identity' I > assume this refers to the key value that is encrypted and stored in > encrypted-value, no? Not only was the solution unclear, but it was rather upside-down in = terms of how to encode encrypted values. Please see the =E2=80=9Cdiffs=E2= =80=9D to get a sense for how the solution was changed. > - Same bullet in 2.1.4.1: >=20 > The "encrypted-value" node is the key, encrypted by the key > referenced by the "encrypted-by" node, encoded in the format > specified by the "format" identity Section 2.1.2 associated with > the ancestor node using this grouping. >=20 > Do I understand correctly that the encrypted-value always holds an > encrypted key? No. Encryption was initially for just keys, but since expanded to = support passwords. > ...If so, a better name for the leaf would perhaps have > been encrypted-key and for the grouping encrypted-key-grouping. I > assume you did not pick this name since you wanted to use > encrypted-key for other purposes? Correct. > This makes sense and may have led > to encrypted-key-value-grouping, in the sense of an encrypted > 'key-value=E2=80=99? For the definition of the grouping, does it = actually > matter that the value encrypted is a key? Or would it make sense to > rename the grouping to encrypted-value-grouping and then the second > bullet becomes: >=20 > The "encrypted-value" node holds the value, encrypted by the key > referenced by the "encrypted-by" node, encoded in the format > specified by the "format" identity (see Section 2.1.2) associated = with > the ancestor node using this grouping. Yes, especially since the original definition the WG added support for = encrypted passwords=E2=80=A6so the grouping name = =E2=80=9Cencrypted-key-value-grouping=E2=80=9D is now a misnomer. I = just s/encrypted-key-value-grouping/encrypted-value-grouping/g to = resolve this naming issue. This better aligns the naming, as you say, = as now the "encrypted-value-grouping=E2=80=9D contains a node called = "encrypted-value=E2=80=9D. > Looking at the definition of encrypted-key-value-grouping, it seems > that the name encrypted-value-grouping would actually be more > appropriate, there is nothing in the definition that says that the > value must be a key for something. +1 > And is it "the" ancestor node or "an" ancestor node? Perhaps the > possible confusion here is that ancestor node may mean different > things, schema tree versus data tree. What about this? >=20 > The "encrypted-value" node holds the value, encrypted by the key > referenced by the "encrypted-by" node, encoded in the format > specified by the "format" identity (see Section 2.1.2) associated = with > the ancestor data node of the data node using this grouping. You=E2=80=99re correct but, looking at the updated text (see diffs), the = word =E2=80=9Cancestor=E2=80=9D was removed, so no action to take now. > Hm. Did I reverse engineer this correctly? You did well, but it was unfortunate that the draft wasn=E2=80=99t = clearer. I do hope the current version is better. > - In 2.1.4.2 last item, where do I see that the encrypted-password > node is encoded using the CMS EnvelopedData structure? There is no > "format" identity here, so this is hard coded to always have the CMS > EnvelopedData structure (or is it CMS EncryptedData structure, see > below)? OK, if I lookup the definition, it seems to use a hardcoded > format Yes, the format for encrypted passwords was hardcoded (which was not a = great solution). =20 The new solution resolves this by treating encrypted passwords just like = any other encrypted value. Specifically: case encrypted-password { if-feature password-encryption; container encrypted-password { description "A container for the encrypted password value."; uses encrypted-value-grouping; } } > .- Always use cleartext instead plain-text? I understand that some > people make a distinction between plain text, plaintext, and > cleartext. Does this document do that? I do not think so, and if so, > we may reduce confusion by picking just one term. On the other hand, > if there is a distinction made, then the document should perhaps be > explicit about it somewhere and define how these terms are used. Yes, always =E2=80=9Ccleartext=E2=80=9D. I just replaced = =E2=80=9Cplaintext=E2=80=9D with =E2=80=9Ccleartext=E2=80=9D everywhere. > - The example in section 2.2 is helpful and much appreciated. I now even more so as its been extended to show a cleartext/encrypted = password as well. :) > - s/confugration/configuration/ Fixed. > - The encrypted-password description says that it uses a" CMS > EnvelopedData structure, per Section 8 in RFC 5652, encoded using > ASN.1 distinguished encoding rules (DER)". However, section 8 of RFC > 5652 defined EncryptedData and not EnvelopedData. So what is the > intention here? Yeah, this part was a mess. Please see the latest. > - Following up on the previous point, it seems that the EncryptedData > format does not introduce a salt, i.e., if the same password is used > multiple times and they are all protected by the same key, then this > is visible since the encrypted formats will all be the same as well. > Is this something to be concerned about? Well, this is not really > a yang-doctor question... This is not an issue, as follows: 1) When the encrypting key is symmetric, a random IV should be used, = thus identical inputs will produce different outputs. 2) When the encrypting key is asymmetric, a random symmetric key is = generated, thus identical inputs will produce different outputs. > - The encrypted-one-symmetric-key-format again refers to the > EnvelopedData per Section 8 in RFC 5652 but section 8 only defines > EncryptedData. So either the type name is wrong or the reference is > wrong. This text was mostly rewritten in, hopefully, a more exact manner=E2=80=A6= > - The encrypted-password container description refers to the > EnvelopedData and either the reference to section 8 is wrong or it > should be EncryptedData (see above). Is it OK to have a fixed > encrypted password format? Perhaps it is, I am just checking. (The > password leaf in RFC 7317 uses the ianach:crypt-hash format, i.e., > it is somewhat extensible but then this module may target different > use cases as it deals with encrypted passwords instead of hashed > passwords.) Again, new text abounds. To point, there are no more hardcoded formats, = all formats are identity-based now. > - I wonder why this is a SHOULD and not a MUST: >=20 > "Identifies the symmetric key's format. Implementations > SHOULD ensure that the incoming symmetric key value is > encoded in the specified format."; >=20 > This statement shows up several times when the key-format identities > are used. I wonder what this means to an implementer. If I receive a > key format (say one-symmetric-key-format) and a corresponding blob > of data, do I have to decode this to see whether the format works > out? If later the key-format is changed to something else (lets say > octet-string-key-format), do I reject such a change or is it OK as > long as the binary data I have would be a valid value given the new > format? Perhaps this is implementation specific? Well, since we deal > with keys, ... It currently a "SHOULD=E2=80=9D because some implementations may assume = that clients always configure perfect values, and so it becomes squishy = as to if they MUST. If a server fails to validate the base64 contents = (which are outside YANG validation) as they=E2=80=99re being applied, = then the server may run into nasty exceptions when needing to use the = value at runtime. A nice system will decode the base64 values and = verify that they contain valid values during the commit process. Make sense? - leave as SHOULD okay? > - The definitions of the features symmetric-key-encryption and > private-key-encryption have copy and paste text from the definition > of the feature password-encryption. I think they need to be changed > to: >=20 > feature symmetric-key-encryption { > description > "Indicates that the server supports encryption of > symmetric keys."; > } >=20 > feature private-key-encryption { > description > "Indicates that the server supports encryption of > private keys."; > } Fixed! > - If I have a 'octet-string-key-format' key and I use it to create an > encrypted key. How do I know which crypto algorithm is used? I have > not digged into it, but do the various CMS structures provide this > information somewhere? In the case of asymmetric keys, the format > gives a hint whether I am dealing with RSA keys or EC keys. For > symmetric keys, I am not sure in all cases how the algorithm is > determined. Exactly right, the OctetString is not bound to an algorithm (because the = algorithm-identifier effort collapsed), which is now plainly stated in = the identity=E2=80=99s =E2=80=9Cdescription=E2=80=9D statement: How the associated algorithm is known is outside the scope of this module. This statement also applies when the octet string has been encrypted."; That said, when the octet string is used to create an EncryptedData = structure, the structure encodes an algorithm identifier (e.g., = aes128-cbc). The =E2=80=9Caes128=E2=80=9D part is unimportant, as = already there is the =E2=80=9Cencrytped-by=E2=80=9D node that points to = the octet string that, per above, the application needs to know is an = AES-128 key. The important part, though, is the identification of the = blocking mode (e.g., =E2=80=9Ccbc=E2=80=9D) and/or padding (e.g., = pkcs5). If applications have issue with limitations that come with the = OctetString type, they are welcomed to use the OneSymmetricKey = structure, which self-identifies the keys algorithm. > - The asymmetric-key-pair-with-certs-grouping descriptions talk about > 'IDevID' and 'LDevID' and 'TPM-protected asymmetric keys'. This > seems to call for additional references to explain what these are. True, but I instead removed the anecdotal comments altogether. >=20 > - s/is was unclear/it was unclear/ Fixed! > - RFC 8407 suggests that the XML registry Registrant Contact is: >=20 > Registrant Contact: The IESG. >=20 > This does not seem to be handled in a consistent manner if I look at > recent RFCs but I think the idea was to give the responsibility to > the IESG, assuming the IESG is a more stable entity than WGs. Fixed, in the entire suite of drafts. Thank you again for your review! Kent --Apple-Mail=_8BF13DB0-EAF9-41C4-AF3A-52CB3DBBE330 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank= you for your review, Juergen!

Below are responses to your comments.

PS: this response took longer because I = had to triage with Security Experts on a couple points.

Kent


Reviewer: J=C3=BCrgen = Sch=C3=B6nw=C3=A4lder
Review result: Ready with Issues

The crypto modules aim at providing a flexible = reusable infrastructure
of groupings for modeling = cryptographic keys and related concepts. The
flexibility = of the definitions provided of course comes with a certain
amount of complexity.

=46rom a YANG perspective, = draft-ietf-netconf-crypto-types-18.txt is in
a = good and close to publish state (a couple of minor issues left). =  I
also tried to understand what is being modeled = here and hence I also
have some questions concerning the = concepts modeled and I hope these
are easy to = answer/resolve as well.

- I have compiled = the YANG modules using yanglint 0.16.105.

- = s/ietf-crypt-types/ietf-crypto-types/

Fixed.


- Does it make sense to have = a new notation like

=      |  The diagram above uses syntax that = is similar to but not
     |  defined in = [RFC8340].

 or shall this simply = become regular text?

I find using tree-diagram like notation for = features, identities, and typedefs helpful, especially in showing the = =E2=80=9Cif-feature=E2=80=9D constraints and hierarchical relationships = between items.  I recommend adding these enhancements to RFC 8340. =  It would be helpful if someone could whip up an I-D so these = documents could reference the I-D instead of having the "The diagram = above uses syntax that is similar to but not defined in [RFC8340]=E2=80=9D= language.

That said, I also used a = "rfc8340-like" diagram to list all the groupings in a module.  It = seems like the consistent thing to do, but I can=E2=80=99t imagine the = RFC 8340 being updated to support that output, so I replaced that = diagram, with a normal "xml2rfc" list, in the entire suite of = drafts.


- "Identities use to specify uncommon formats = are enabled [...]" is
 this correct or should it be = "used to specify=E2=80=9D?

Fixed.


- Second bullet 2.1.4.1:

=  Perhaps change

 [...] specified = by the "format" identity Section 2.1.2 associated [...]

 to

 [...] specified = by the "format" identity (see Section 2.1.2) associated [=E2=80=A6]

Fixed, but see = below...


 What is = 'encoded in the format specified by the "format" identity' I
 assume this refers to the key value that is encrypted = and stored in
 encrypted-value, no?

Not = only was the solution unclear, but it was rather upside-down in terms of = how to encode encrypted values.  Please see the =E2=80=9Cdiffs=E2=80=9D= to get a sense for how the solution was = changed.


- Same bullet in 2.1.4.1:

=      The "encrypted-value" node is the key, = encrypted by the key
=      referenced by the "encrypted-by" node, = encoded in the format
=      specified by the "format" identity Section = 2.1.2 associated with
     the = ancestor node using this grouping.

=  Do I understand correctly that the encrypted-value always holds = an
 encrypted key?

No.  Encryption was initially for just keys, but = since expanded to support passwords.


 ...If so, a better name for the leaf would perhaps = have
 been encrypted-key and for the grouping = encrypted-key-grouping. I
 assume you did not pick = this name since you wanted to use
 encrypted-key for = other purposes?

Correct.


This makes sense and may have led
 to = encrypted-key-value-grouping, in the sense of an encrypted
=  'key-value=E2=80=99?  For the definition of the grouping, = does it actually
 matter that the value = encrypted is a key? Or would it make sense to
=  rename the grouping to encrypted-value-grouping and then the = second
 bullet becomes:

=      The "encrypted-value" node holds the = value, encrypted by the key
=      referenced by the "encrypted-by" node, = encoded in the format
=      specified by the "format" identity (see = Section 2.1.2) associated with
=      the ancestor node using this grouping.

Yes, = especially since the original definition the WG added support for = encrypted passwords=E2=80=A6so the grouping name = =E2=80=9Cencrypted-key-value-grouping=E2=80=9D is now a misnomer. =  I just s/encrypted-key-value-grouping/encrypted-value-grouping/g = to resolve this naming issue.  This better aligns the naming, as = you say, as now the "encrypted-value-grouping=E2=80=9D contains a node called = "encrypted-value=E2=80=9D.


 Looking at the definition of = encrypted-key-value-grouping, it seems
 that the = name encrypted-value-grouping would actually be more
=  appropriate, there is nothing in the definition that says that = the
 value must be a key for something.

+1


 And is = it "the" ancestor node or "an" ancestor node? Perhaps the
=  possible confusion here is that ancestor node may mean = different
 things, schema tree versus data tree. = What about this?

=      The "encrypted-value" node holds the = value, encrypted by the key
=      referenced by the "encrypted-by" node, = encoded in the format
=      specified by the "format" identity (see = Section 2.1.2) associated with
=      the ancestor data node of the data node = using this grouping.

You=E2=80=99re correct but, looking at = the updated text (see diffs), the word =E2=80=9Cancestor=E2=80=9D was = removed, so no action to take now.


 Hm. Did I reverse = engineer this correctly?

You did well, but it was = unfortunate that the draft wasn=E2=80=99t clearer.  I do hope the = current version is better.


- In 2.1.4.2 last item, where do I see that the = encrypted-password
 node is encoded using the CMS = EnvelopedData structure? There is no
 "format" = identity here, so this is hard coded to always have the CMS
=  EnvelopedData structure (or is it CMS EncryptedData structure, = see
 below)? OK, if I lookup the definition, it = seems to use a hardcoded
=  format

Yes, the format for encrypted passwords = was hardcoded (which was not a great = solution).  

The new solution resolves this by = treating encrypted passwords just like any other encrypted value. =  Specifically:

    =   case encrypted-password {
  =       if-feature password-encryption;
      =   container encrypted-password {
  =         description
    =         "A container for the encrypted password = value.";
        =   uses encrypted-value-grouping;
  =       }
      }





.- Always use cleartext instead plain-text? I = understand that some
 people make a distinction = between plain text, plaintext, and
 cleartext. Does = this document do that? I do not think so, and if so,
=  we may reduce confusion by picking just one term. On the other = hand,
 if there is a distinction made, then the = document should perhaps be
 explicit about it = somewhere and define how these terms are used.

Yes, always =E2=80=9Ccleartext=E2=80=9D. =   I just replaced =E2=80=9Cplaintext=E2=80=9D with =E2=80=9Ccleartext= =E2=80=9D everywhere.


- The example in section 2.2 is helpful and much = appreciated.

I now even more so as its been extended = to show a cleartext/encrypted password as well.  :)


- = s/confugration/configuration/

Fixed.


- The encrypted-password description says = that it uses a" CMS
 EnvelopedData structure, per = Section 8 in RFC 5652, encoded using
 ASN.1 = distinguished encoding rules (DER)". However, section 8 of RFC
 5652 defined EncryptedData and not EnvelopedData. So = what is the
 intention here?

Yeah, this part was a mess. =  Please see the latest.


- Following up on the previous point, it = seems that the EncryptedData
 format does not = introduce a salt, i.e., if the same password is used
=  multiple times and they are all protected by the same key, then = this
 is visible since the encrypted formats will = all be the same as well.
 Is this something to be = concerned about? Well, this is not really
 a = yang-doctor question...

This is not an issue, as = follows:

1) = When the encrypting key is symmetric, a random IV should be used, = thus identical inputs will produce different = outputs.
2) When = the encrypting key is asymmetric, a random symmetric key is = generated, thus identical inputs will = produce different outputs.


- The encrypted-one-symmetric-key-format again refers to = the
 EnvelopedData per Section 8 in RFC 5652 but = section 8 only defines
 EncryptedData. So either the = type name is wrong or the reference is
 wrong.

This text was mostly rewritten in, = hopefully, a more exact manner=E2=80=A6


- The encrypted-password container = description refers to the
 EnvelopedData and either = the reference to section 8 is wrong or it
 should be = EncryptedData (see above). Is it OK to have a fixed
=  encrypted password format? Perhaps it is, I am just checking. = (The
 password leaf in RFC 7317 uses the = ianach:crypt-hash format, i.e.,
 it is somewhat = extensible but then this module may target different
=  use cases as it deals with encrypted passwords instead of = hashed
 passwords.)

Again, new text abounds.  To = point, there are no more hardcoded formats, all formats are = identity-based now.


- I wonder why this is a SHOULD and not a = MUST:

=           "Identifies = the symmetric key's format.  Implementations
=            SHOULD = ensure that the incoming symmetric key value is
=            encoded = in the specified format.";

 This = statement shows up several times when the key-format identities
 are used. I wonder what this means to an implementer. = If I receive a
 key format (say = one-symmetric-key-format) and a corresponding blob
=  of data, do I have to decode this to see whether the format = works
 out? If later the key-format is changed to = something else (lets say
 octet-string-key-format), = do I reject such a change or is it OK as
 long as = the binary data I have would be a valid value given the new
=  format? Perhaps this is implementation specific? Well, since we = deal
 with keys, ...

It currently a "SHOULD=E2=80=9D because = some implementations may assume that clients always configure perfect = values, and so it becomes squishy as to if they MUST.   If a server = fails to validate the base64 contents (which are outside YANG = validation) as they=E2=80=99re being applied, then the server may run = into nasty exceptions when needing to use the value at runtime.  A = nice system will decode the base64 values and verify that they contain = valid values during the commit process.

Make sense?  - leave as SHOULD = okay?


- The = definitions of the features symmetric-key-encryption and
=  private-key-encryption have copy and paste text from the = definition
 of the feature password-encryption. I = think they need to be changed
 to:

    feature symmetric-key-encryption = {
      description
        "Indicates = that the server supports encryption of
=          symmetric = keys.";
    }

    feature private-key-encryption {
      description
=         "Indicates that the = server supports encryption of
=  private keys.";
    }

Fixed!


- If I have a = 'octet-string-key-format' key and I use it to create an
=  encrypted key. How do I know which crypto algorithm is used? I = have
 not digged into it, but do the various CMS = structures provide this
 information somewhere? In = the case of asymmetric keys, the format
 gives a = hint whether I am dealing with RSA keys or EC keys. For
=  symmetric keys, I am not sure in all cases how the algorithm is
 determined.

Exactly right, the = OctetString is not bound to an algorithm (because the = algorithm-identifier effort collapsed), which is now plainly stated in = the identity=E2=80=99s =E2=80=9Cdescription=E2=80=9D = statement:

       How the associated algorithm is = known is outside the
       scope of this module.  This = statement also applies when
       the octet string has been = encrypted.";

That said, when the octet string is used to = create an EncryptedData structure, the structure encodes an = algorithm identifier (e.g., aes128-cbc).  The =E2=80=9Caes128=E2=80=9D= part is unimportant, as already there is the =E2=80=9Cencrytped-by=E2=80=9D= node that points to the octet string that, per above, the application = needs to know is an AES-128 key.  The important part, though, is = the identification of the blocking mode (e.g., =E2=80=9Ccbc=E2=80=9D) = and/or padding (e.g., pkcs5).

If applications have issue with = limitations that come with the OctetString type, they are welcomed to = use the OneSymmetricKey structure, which self-identifies the keys = algorithm.


- The asymmetric-key-pair-with-certs-grouping descriptions = talk about
 'IDevID' and 'LDevID' and 'TPM-protected = asymmetric keys'. This
 seems to call for additional = references to explain what these are.

True, but I instead removed the = anecdotal comments altogether.



- s/is was unclear/it was = unclear/

Fixed!


- RFC 8407 suggests that the XML registry = Registrant Contact is:

 Registrant = Contact: The IESG.

 This does not = seem to be handled in a consistent manner if I look at
=  recent RFCs but I think the idea was to give the responsibility = to
 the IESG, assuming the IESG is a more stable = entity than WGs.

Fixed, in the entire suite of = drafts.



Thank you again for your review!

Kent


= --Apple-Mail=_8BF13DB0-EAF9-41C4-AF3A-52CB3DBBE330-- From nobody Wed Feb 10 16:05:09 2021 Return-Path: <010001778e67c4e0-c179290b-6eba-46df-b17f-ec474c44783c-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 6BA9B3A0E2A; Wed, 10 Feb 2021 16:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 JGHFxUz5nkEC; Wed, 10 Feb 2021 16:05:02 -0800 (PST) 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 9529A3A0E2D; Wed, 10 Feb 2021 16:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1613001901; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=hRrp7mQBRUN6JwnV4O1586ZPUnyORcAo2QD6gHRAzpg=; b=aWL8pi8645hA6b/o3UVHY7SizX2EQO0+4Ca1eeagdar4fkyehy89YxG+4h6TUUBu CjIB8sm8vS9XfDqVgsyBTt8nd+wbvxi8b+ScwO8qLEiTPVx4gt9URGVUj/Bf+d/Ywbk 48Lc5CV3qN/YHTFPeFftFiZsueHDiXBBG0UFUO3w= From: Kent Watsen Message-ID: <010001778e67c4e0-c179290b-6eba-46df-b17f-ec474c44783c-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C6CA3C6E-F7C0-4386-87E2-4C3A33389958" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 11 Feb 2021 00:05:01 +0000 In-Reply-To: <161047687248.13931.17900123352005904827@ietfa.amsl.com> Cc: YANG Doctors , "netconf@ietf.org" To: Juergen Schoenwaelder References: <161047687248.13931.17900123352005904827@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.11-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Last-Call] Yangdoctors last call review of draft-ietf-netconf-trust-anchors-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 00:05:06 -0000 --Apple-Mail=_C6CA3C6E-F7C0-4386-87E2-4C3A33389958 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you for your review, Juergen! Below are responses to your comments. PS: this response took longer because I had to triage with Security = Experts on a couple points on the =E2=80=9Ccrypto-types=E2=80=9D draft. Kent > On Jan 12, 2021, at 1:41 PM, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder via = Datatracker wrote: >=20 > Reviewer: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder > Review result: Ready with Issues >=20 > The crypto modules aim at providing a flexible reusable infrastructure > of groupings for modeling cryptographic keys and related concepts. The > flexibility of the definitions provided of course comes with a certain > amount of complexity. >=20 >> =46rom a YANG perspective, draft-ietf-netconf-trust-anchors-13.txt is = in > a good and close to publish state (a couple of minor issues left). I > also tried to understand what is being modeled here and hence I also > have some questions concerning the concepts modeled and I hope these > are easy to answer/resolve as well. >=20 > - I have compiled the YANG modules using yanglint 0.16.105. >=20 > - The prefix 'ts' is rather short, the set of two letter prefixes is > rather small limited. This comment also applies to the other > documents, crypto-types uses 'ct. Perhaps this is not a problem > since collisions can be handled but if we go for rather short > prefixes, we will have to exercise the collision resolution. (I see > that 'ct' has already been used by ietf-complex-types, RFC 6095.) A > possible alternative could be to use sec-ct, sec-ts, sec-ks, ...). Ugh (me, whenever a naming-discussion comes up ;) I don=E2=80=99t know why prefixes are registered, as the prefix is = defined at the top of each module. The only value I see is not = syntactic but rather for consistency, to aid human readability across = disconnected sets of modules. Prefixing the prefix with =E2=80=9Csec-=E2=80=9C may work for trio of = drafts you just reviewed, but it seems undesirable when getting to the = client-server drafts, as they're more *protocol* oriented. If =E2=80=9Cks= =E2=80=9D and =E2=80=9Cts=E2=80=9D aren=E2=80=99t taken, then maybe we = claim =E2=80=9Cfirst mover=E2=80=9D advantage? If not, then maybe = =E2=80=9Ckstore=E2=80=9D and =E2=80=9Ctstore=E2=80=9D might be = meaningful fallbacks? Assuming we claim =E2=80=9Cfirst mover=E2=80=9D = advantage for =E2=80=9Cks=E2=80=9D and =E2=80=9Cts=E2=80=9D, then we = just need to handle =E2=80=9Cct=E2=80=9D, which maybe could be = =E2=80=9Cctypes=E2=80=9D or =E2=80=9Ccryptypes=E2=80=9D or =E2=80=9Cct2=E2= =80=9D? So, 1) prefix the trio or 2) claim first-mover advantage on two = and figure out something for =E2=80=9Cct=E2=80=9D? =E2=80=A6or maybe 3) = keep =E2=80=9Cct=E2=80=9D also noting that a) =E2=80=9CSHOULD NOT=E2=80=9D= is not a =E2=80=9CMUST NOT=E2=80=9D (in the text below), b) my = =E2=80=9Crant=E2=80=9D might have some merit, and c) short and terse is = nice (per your next comment). > RFC 8407 provides the following guidelines (Section 4.2): >=20 > Prefix values SHOULD be short but are also likely to be unique. > Prefix values SHOULD NOT conflict with known modules that have been > previously published. >=20 > Well, having short and terse prefixes is actually nice and enhancing > programmer readability. :) > - s/is defines a truststore/defines a truststore/ Fixed. > - s/to be grouped referenced/to be grouped and referenced/ Fixed. > - In 2.2.1, I was not sure what CA certificates are and what EE > certificates are. I then tried to guess EE =3D end entity cert, but > this does not explain CA since the term used in crypto types is > trust anchor cert. The description in the XML clarified that my > guess was kind of correct. Perhaps explain upfront what these > acronyms mean? Or perhaps the acronyms can be avoided by simply > spelling things out? They do not appear to be used frequently. Good point, I expanded to using "trust anchor=E2=80=9D and =E2=80=9Cend = entity=E2=80=9D (but then had to 's/certificates/certs/' to keep the = diagram from overrunning) > - s/ the assigned RFC value for draft-ietf-netconf-crypto- types * "CCCC" --> 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: * "2021-02-10" --> the publication date of this draft The following Appendix section is to be removed prior to publication: * Appendix A. Change Log The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-keystore-21.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 10 16:52:33 2021 Return-Path: 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 3757C3A0D3F; Wed, 10 Feb 2021 16:52:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <161300473717.6429.11653445688133356160@ietfa.amsl.com> Date: Wed, 10 Feb 2021 16:52:17 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 00:52:17 -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-09.txt Pages : 32 Date : 2021-02-10 Abstract: This document defines three YANG 1.1 [RFC7950] modules to support the configuration of TCP clients and TCP servers, either as standalone or in conjunction with a stack protocol layer specific configurations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-tcp-client-server-09.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tcp-client-server-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 10 16:57:01 2021 Return-Path: <010001778e975419-ae0fec48-c491-4c4d-b7e4-fb303e7e9748-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 6D0E33A0D31 for ; Wed, 10 Feb 2021 16:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 s_iA8N7MLUMg for ; Wed, 10 Feb 2021 16:56:59 -0800 (PST) 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 63EEB3A0D2E for ; Wed, 10 Feb 2021 16:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1613005018; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=ivUz2rubPiuyl+Ms0WfytWOKqpW0D2rRDu8VXPqOVtw=; b=FSoDnYWNVP5NC0lZOmEEKBh/jXHx6i51GvOPQG+3FKnfcTFCJXVoTHzPF4iE2fx4 1q19juSQI+gXKZ7TVPaZjaSFc8S2vuRJMfQz1UUCu5hM9v0h2Xyx0ZaGAmwK3IIie7D fRtiNnBMnr4rKMVogrcuHGBqJ+1SIN5+5AqagH8E= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <010001778e975419-ae0fec48-c491-4c4d-b7e4-fb303e7e9748-000000@email.amazonses.com> Date: Thu, 11 Feb 2021 00:56:58 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.11-54.240.48.95 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Draft updates X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 00:57:00 -0000 Updated all drafts, but only the 1st three (ct, ts, and ks) have notable = updates: Crypto-types: * Added a "Unconstrained Public Key Usage" Security Consideration to address concern raised by SecDir of the 'truststore' draft. * Added a "Unconstrained Private Key Usage" Security Consideration to address concern raised by SecDir of the 'truststore' draft. * Changed the encryption strategy, after conferring with Russ Housley. * Added a "password-grouping" example to the "crypto-types-usage" example. * Added an "Encrypting Passwords" section to Security Consideration. * Addressed other comments raised by YANG Doctor. Truststore: * Added an "Unconstrained Public Key Usage" Security Consideration to address concern raised by SecDir. * Addressed comments raised by YANG Doctor. Keystore: * Added a "Unconstrained Private Key Usage" Security Consideration to address concern raised by SecDir. * Addressed comments raised by YANG Doctor. K. From nobody Thu Feb 11 13:23:44 2021 Return-Path: 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 75BB93A03EE; Thu, 11 Feb 2021 13:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.621 X-Spam-Level: X-Spam-Status: No, score=-9.621 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=hV9E5Gye; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=sJWBUHf8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoKjxBJjDlUv; Thu, 11 Feb 2021 13:23:40 -0800 (PST) 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 53CEC3A03C9; Thu, 11 Feb 2021 13:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9464; q=dns/txt; s=iport; t=1613078620; x=1614288220; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uEHc3RxFwlE8TzygwrL+iCFLtONCJ8WDEeW98ojW8Sc=; b=hV9E5GyeDqu5Mf9TKIJZv5ywy+p9sGOoVuEy+lHAMA14/Kr8ibAOXFDC 1O92iB3EKAv6iOqb+L45nNwXrHyZx1bei5eMEB5J/J8etTagGRe/L1Lug 8hCzJ8wPi1d1+ZwhqaPjWXVxnCRC7H6LuiRfSLsodx97wRvjgr3+55mrN g=; X-Files: smime.p7s : 3975 X-IPAS-Result: =?us-ascii?q?A0AnAAABnyVgmIcNJK1YCh0BAQEBCQESAQUFAUCBOwgBC?= =?us-ascii?q?wGBUikofSwuNjEKAYd+A4RZiTsDjxaKBoEuFIERA1QEBwEBAQoDAQEYDQgCB?= =?us-ascii?q?AEBhAdEAoIHAiU0CQ4CAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2A?= =?us-ascii?q?QyGQwEBAQMBAQE+AQErAQsBBAcEAgEIEQQBAQ4hAiULHQgBAQQOBQgGghdLA?= =?us-ascii?q?YF+VwMOEQ8BDgOmIAKKJXSBNIMEAQEGgTMBAwKDXhiCCwcDBoE4AYFSgSOKS?= =?us-ascii?q?CYbgUFBgRFDgVh+PoJdAQEDgS8THAUzgxCCK4JKPhsLBCIhDgEBUAsYDgEWN?= =?us-ascii?q?BcwnTKKf5FJCoJ6gRmDS4JqgWmSdYMxikeVNJQ4iyyReRMJhDkCBAIEBQIOA?= =?us-ascii?q?QEGgVU4gVlwFTuCaVAXAg2OHxqDV4UUhUVzNwIGCgEBAwl8iggBgQ4BAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3A3KzaIROUIf3xN4ealjol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw33l7EQYud7OhL2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YklYBMi4YEfd8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,171,1610409600"; d="p7s'?scan'208";a="662230375" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Feb 2021 21:23:39 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 11BLNdou025364 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2021 21:23:39 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 11 Feb 2021 15:23:38 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 11 Feb 2021 15:23:38 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 11 Feb 2021 15:23:38 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SAHxCwhIY3Go5Jl/Yd4hfeOH41xTsgcPLNPjRfPgmb5cOHdlZvsVLEySvcOnYQvrycSV3spI4ZJiVlwGvKxwTlPHgYOb//YlEoabUnzxl4sWLnLyJiw9h5WuZDuLjgRfbWo5T2j4cw6Wa4uDflZrlb0OJ5pj3Dy4+Osua3D0AsPcRZNTjm4osqL669PN3nQsaAbBSg9vAUmOCQ+rX9pbZlf01Au/1yuk0peUrfB6+zdGVLVxfbH2x5blytNiioMhVmcDGhDTe3IBE4LffLIp4yIHiOy8LVYIJjOZrYc7KimpF4mqPKlX817QGtU4Cm/nid5XIi7JNe7yMIrsJdJgqw== 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=aV5hVauURRmOmXnG2WjMj+Q/chPyFIv7V9Ch5919Q7g=; b=E4f8pNGfvM4yAxkCCYICabw1pGuasj+ZgksIO75AtpFvy6V2ijUU8Hd2gKRlvbBtJvsabpNzX5vC4kGfyQJIYd5RLZD7RrjP5DEXKOScg91Eqm3ogqT03dW02/Ho47vfnmiejONdU51/UiYyQC5WJWQQt33v+ptdtCX7IaGzQ15aDF3Dg0WKYljfH7gQ9Fj0eI6ymOw++Ns8nXccB4urQateSe/RXn/zzIDlZQBA9ykp93lZLiE0RNU/TSx1/XH/caaSze89R4NZ5Qsy8C2OV2ljYV9+sjkXniBE2F+OBqE4+asfnt7KrXUENoxSQKmpp9rDIKQm5xZsRDei55ZIgQ== 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=aV5hVauURRmOmXnG2WjMj+Q/chPyFIv7V9Ch5919Q7g=; b=sJWBUHf8sG/IcLCgdJniHn36D32MiYDRemKgYQGHPO4KATrfE28235VWrzcka0eJjUyvW4udDnFauTUPFXQ3zK9FkRSAf3g/tOWQ0mLlfV0PI/gnV70l6LLR6xPwHOQrhvS/fowKa2qa1yWy4Nhb2mY11vJCMzhTWoPiC51xjAs= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3522.namprd11.prod.outlook.com (2603:10b6:208:7f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.27; Thu, 11 Feb 2021 21:23:35 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::88f5:c7e1:3338:cecf]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::88f5:c7e1:3338:cecf%3]) with mapi id 15.20.3846.029; Thu, 11 Feb 2021 21:23:35 +0000 From: "Eric Voit (evoit)" To: "draft-ietf-netconf-https-notif@ietf.org" CC: "netconf@ietf.org" Thread-Topic: WGLC: draft-ietf-netconf-https-notif-06 Thread-Index: AdbqdYOgUz15Gs1wTZ6RgVXH+iq7RQGk0X5QA+xnatA= Date: Thu, 11 Feb 2021 21:23:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [108.18.141.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ab5fc868-8066-4d0c-ba7a-08d8ced34a90 x-ms-traffictypediagnostic: BL0PR11MB3522: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tcPD4N01gMLbtAtVCpgzX7BLUrJZjdvNKR7RIZNRRpLADmMTTmk3cpkyjIZGOn+8xzYkVisFjmn9aSyfrH9YG4JpQ9YdvB9c4vaOhVQ0+R0GLI7WtzUIr/4cR0i0Z0Lu6npok/QOd9+1YPnLzM7edvmXUD5z60/7AinHzjoxzRlRXrL59qAgiQBxVFCI5rFNxxXY/Enf+rD2Y/UNlWUGw5QVHSIKvKNz83WbxwfwKbNuhlPB82Eoal6abrRBoqrif6s9uvhKD670hd0+pjPNCQ7HrF2nK9+PFsrz5+NXAZmV/Ad6OEp3vQPR5OnSKu0lwTQDWhlvQz7p3Kgd2eA+OR3MDA67CnWNNxC8hrKafJb2XwFkr+q8JnqPI/tOjyq0h3oejGifBC+oQ78u4eckrh5hcJoZNXtOtnyTUGphn1tvHvKVOqdXpGZpTkXeyTnAPzMNP/Rl7zZNGv1FrU1qVH4bLu5g7Xf7nlVIDi9c/6iZPtTdB9u8qJ9HkGDPrmo6GThh4TrQizlwOXU12YEfwmZDe2adV4/F5fSdg3cVnwWgwTPTTrFVZOmOM+uhDWi4hQuqtaW7gXndghI//awCQsk8kpWfCvjA7wJBLGZw2G0= 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; SFS:(346002)(366004)(136003)(376002)(396003)(39860400002)(99936003)(53546011)(8676002)(478600001)(4326008)(7696005)(8936002)(186003)(52536014)(76116006)(66616009)(66556008)(26005)(83380400001)(6916009)(316002)(86362001)(66476007)(5660300002)(64756008)(66446008)(66946007)(450100002)(33656002)(6506007)(2906002)(9686003)(71200400001)(966005)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?U7cqJdSZfA2P3+8KcCbbn4i2RPiJYvzY7idzB1Xioe51sli4VN1gbUbQEAmm?= =?us-ascii?Q?mKWFsDdpbxbP7/JS3Agic92KWYR4CB206q44D4Ikw/P80C3Wxs+W6m2VXPFX?= =?us-ascii?Q?cWCnBvPUNTCedHDxnAb15DMoZhOSSVIy5WZ76FJUrERKuQSg/6/disMf51V6?= =?us-ascii?Q?aoOKwLF0x41x8bmXQUa0k8gvwgoRc4e54uC5s/V7+FUPz5JXMPsQIbh9MoiA?= =?us-ascii?Q?zRc0DBHRXNR++zJSVptbFbbfhgg+vw5SNhZlETfZ6OrrHnmH+osiMx8Ezqqc?= =?us-ascii?Q?eUH2E5OUr2mcZdKJ4FCNqnxA44+COqx7E+MaGZZDMBX6VFKR11v6fVigXUPk?= =?us-ascii?Q?hH/JHvph7EssrMDGqm2rdvODogfnSFNgUsSydpXzM32RJqWjJ1dQ8bfhkcb1?= =?us-ascii?Q?mvqzttc2xFyhecMwFW5FLQICTJif4m7ZhpzfwjTlxd19NJaOCcJA2a9OSgls?= =?us-ascii?Q?C/j49jvJ9461fkqNijx156BetwlNBWElO4RUJTS0nrW4LvwggZ3+5xz4/qNT?= =?us-ascii?Q?s24eBS4knSCL+6YU3BbAtXWTzLJ5Qv+RFAd9a9SOi4bndCfPCVVcotRtJJX8?= =?us-ascii?Q?yBqXijyFjJfTP4MHNRnA5MVtUEYCQUk9GJF/eJ7EkcK/E7kfbTeXBxEktsWk?= =?us-ascii?Q?hdkeQHWSWXu2WBiZfQx7+gG4SdLr0iJ9EsFn7tEZkUiw7YTREh3/hkYuWCH6?= =?us-ascii?Q?w9EyC0Jkoab2R88GV1IzFxsMqMuYfgfir8ZGsq9GYelIgJxesmXhZULKY2/s?= =?us-ascii?Q?bVAGRkEEJlen17ud73duE7I8r15eHUn5Cl0MLaAEEnPrRpoHQNL11ONpo/1U?= =?us-ascii?Q?gQ/QIbZiSUFWyaMGKkzPaI+09aIcMwptlcDbxpIr7m9rPdzuppZCOHYwmTpI?= =?us-ascii?Q?dZluLL+ANjrfIFuz6mMaCUk8L/llIUDmM7RchNumiTwp69ldjPejd7HD656t?= =?us-ascii?Q?BrVbyNDvTZ/MeByDwbraHkXzI44wTqj+wg3sKzu7fTfHvIV+t2ryZwNvt+XP?= =?us-ascii?Q?jKXrXVdGuAxBCKwub4yEtJSrr2CVECpM6OVrevOkAufTIChDtG9O0XjbAX1X?= =?us-ascii?Q?Rcz9JfW8+jlRccCCfDEgO3KQmT6wPo3ex7Hpj4q87FhZnBiMEaDRdwUoJCsi?= =?us-ascii?Q?GngPtyBwifX4+p0pHftenpUSC+lrJjdqHb1KTkJe6SqGIzx+BJt5KePqRMPo?= =?us-ascii?Q?RoXuTE2tq+x281pBWJ94RgzbG+IxmmXYIY9s0BJM+XZU8IQKWlx+VvrtKIDs?= =?us-ascii?Q?08VlMXsojyUO/UDaGfrKt0lmMnVZKPse5hHUMo5PxXMmdTRNxSDBw9+WSkCH?= =?us-ascii?Q?k/e0HgHSfR7j6v3HRUQ8w0np?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_007A_01D70092.3CA6AB60" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ab5fc868-8066-4d0c-ba7a-08d8ced34a90 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2021 21:23:35.6076 (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: 2TGWa5GFcpXDy370mO4rzIMWAN7mZokYACwjra44ez8p2mZrhVb2WLaAYI20Qqow X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3522 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 21:23:43 -0000 ------=_NextPart_000_007A_01D70092.3CA6AB60 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Some updates for my comments for -07 based on the requests for -06. > -----Original Message----- > From: netconf On Behalf Of Eric Voit (evoit) > Sent: Monday, January 25, 2021 9:36 AM > To: draft-ietf-netconf-https-notif@ietf.org > Cc: netconf@ietf.org > Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 > > I have reviewed this document. I believe it close to being ready. I do have three > comments: > > (1) Section 1.1 > There was an interaction in July 2020 about describes why subscription state > change notifications are not included within the draft. > https://mailarchive.ietf.org/arch/msg/netconf/K0jnMW3GZknxihnNjKL4UlFTfoY > / > https://mailarchive.ietf.org/arch/msg/netconf/CYOosxZy_- > tKKsrCCoLmQeFvEuI/ > Actually, we are talking only about a subset of the subscription state change > notifications, as is include within examples of this > document. > > Per Alex and my earlier requests, it would be good to include which state change > notifications are included, and why, so that others have this context. This > would allow receivers to understand that the control plane messages which > identify the current state of the subscription on the subscriber are not available. > Perhaps it might even drive others who might want this functionality to add this > upon the current http-notif. This might be worth including in Section 1.1, > Applicability Statement. The majority of examples showing have been removed. The last place where they are discussed in -07 is the end of Section 2. I still feel that describing the coverage or non-coverage of the set of subscription state change notifications within a stream of event provides a useful context. > (2) Section 2.1 > Learning Receiver Capabilities is critical, as Configured Subscriptions can DOS a > receiver if adequate protections are not on the publisher. It would be useful to > list this here so that the topic is not missed in an implementation. Alternatively > this could be addressed in Section 5. Thank you for including this as a new section. > (3) > In Sections 1.5 and 8.3 there is a reference to I-D.ietf-netconf-notification- > messages. I am not sure how this impacts the eventual completion of this draft, > but defer to others who know the IETF process better. Thanks for the changes here. Eric > Thanks, > Eric > > > -----Original Message----- > > From: netconf On Behalf Of Rob Wilton > > (rwilton) > > Sent: Thursday, January 14, 2021 8:12 AM > > To: netconf@ietf.org; draft-ietf-netconf-https-notif@ietf.org > > Subject: [netconf] WGLC: draft-ietf-netconf-https-notif-06 > > > > This message begins a two-week WGLC for > > draft-ietf-netconf-https-notif-06 ending on Jan 28. Here is a direct link to the > HTML version of the draft: > > > > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-06 > > > > Positive comments, e.g., "I've reviewed this document and believe it > > is > ready for > > publication", are welcome! This is useful and important, even from > authors. > > Objections, concerns, and suggestions are also welcomed at this time. > > > > Please note, the reason that I am making this request rather than the > > WG > chairs > > is because both chairs are listed as authors on this document. > > > > Thank you, > > Rob Wilton, OPS AD > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_007A_01D70092.3CA6AB60 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjExMjEyMzMxWjAjBgkqhkiG 9w0BCQQxFgQUKvibXI+zPgYbpERRcDY7ZPx9bxkwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQB9no4DMWjee+Oc841GXmMrg95c6AxJG65iK+qFxoFlM4XkZrhSThLxGANFKHMOgXM9 HvbKh46P3ygiB7k9f5AF5oOD82vPEsI8pWooZVekCz8iCgfei8wcjYwvzFTZBIKHpqzH8jDTUTVR 0pr39OT/5pSmuAamX1yn0HHSrF18aManm65px3eI57e7CpXLU/EyA2iOpisu4iNwbbKm1MXXIAiV EZha3RahXBnmKs9/4tMBI9WkQf5z+nxDEVVYqfSKxk7i3mHjlWk41zZ/d6auhGxo5UVqadDxoawl ZLIxqtijkkHFfkNi994N6h6yo/M2R1M+xtXyU7GzBg3FhoU0AAAAAAAA ------=_NextPart_000_007A_01D70092.3CA6AB60-- From nobody Fri Feb 12 16:33:27 2021 Return-Path: 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 AAE8A3A1165; Fri, 12 Feb 2021 16:33:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: netconf@ietf.org, rwilton@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317639668.31337.7091018198058676615@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:16 -0800 Archived-At: Subject: [netconf] netconf - Requested session has been scheduled for IETF 110 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:33:17 -0000 Dear Mahesh Jethanandani, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. netconf Session 1 (2:00 requested) Monday, 8 March 2021, Session I 1300-1500 Room Name: Room 4 size: 504 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/netconf.ics Request Information: --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Mahesh Jethanandani Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 65 Conflicts to Avoid: Chair Conflict: netmod tcpm idr Technology Overlap: opsarea opsawg People who must be present: Kent Watsen Mahesh Jethanandani Robert Wilton Resources Requested: Special Requests: Afternoon sessions are preferred. --------------------------------------------------------- From nobody Mon Feb 15 03:31:21 2021 Return-Path: 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 BDA313A119A for ; Mon, 15 Feb 2021 03:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=NK11Lpea; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ojZ4VYEQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLOl4fdGtqDw for ; Mon, 15 Feb 2021 03:31:17 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7553A1196 for ; Mon, 15 Feb 2021 03:31:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=796; q=dns/txt; s=iport; t=1613388677; x=1614598277; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=9lRo8FYowoYVwcHFyWNESv8eordC5TQglAziu0xM4eQ=; b=NK11LpeaoeoOsohOe/wTBZ2VdlmOLEUCJynnZp/WXWok3yE9ik5J6iG+ Uj7g1zV28bz8FVT2yoekhkWgFiCH15G/4lRkKWdB54ss/JrR9xdO+fpLt SfMUjgVJGh07KATVIEr0BjZsESiYzBSsdWipVOLEWOa7bH32Zq7k7M0vm I=; X-IPAS-Result: =?us-ascii?q?A0BaBAD5WSpgkIENJK1iHgEBCxIMQIFEC4FTUYFXNjEKh?= =?us-ascii?q?38DjgeZIIJTA1QLAQEBDQEBMgIEAQGETQKCCAIlNwYOAgMBAQEDAgMBAQEBB?= =?us-ascii?q?QEBAQIBBgQUAQEBAQEBhjgNhwUGAQE3AREBPkImAQQODYJoglYDLgEDpCkCi?= =?us-ascii?q?iV0gTSDBAEBBoUbGIISCYE4gnaJLYFFHIFBQYERQ4c7GoNIgiuCTGIEMoF6O?= =?us-ascii?q?WK5GQqCegScKKMttjUCBAIEBQIOAQEGgWsigVlwFYMkUBcCDY4fGh2DOopZc?= =?us-ascii?q?zcCBgoBAQMJfIoIAYEOAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AlhXxAhYYdIOTwXMb1iBGDvn/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-AV: E=Sophos;i="5.81,180,1610409600"; d="scan'208";a="647086547" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Feb 2021 11:31:16 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 11FBVGU7026716 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Feb 2021 11:31:16 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Feb 2021 05:31:15 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Feb 2021 06:31:15 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 15 Feb 2021 05:31:14 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EIanIXjV76EiMb+HGbWoLCMjXD9T6KdcUN0j4WegvJ+szlG5deYMjQ40G+9NvDNnjor8nupRcboxx1ld+9/4KaNeTjnYDuk4zPvjI4D7sGF0OXN4H4c3nmKLmfI5zkQHoUufQ4z26cQorboU3TQZfYiNHD2Ng9YPDe1Jv1n8wtISmQ+BmE5LjgUegXnMcB0qVPTSf0jAOhB3ElnvEMXovPLz/CanUX2sksFH9MLeMXH//8rXYy0faLExHIb4vZ+E0AgwUa2IgF4ANnvW3u82DaLDWYL8rOD+rDGz8AoT2Ph6GDw/UFy7tplw1f30h2IwbsoBKxeY6F17J2Y5YkohkQ== 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=MV5sab+RH0ktSxRkQXsZqtLrfDw0rcJ6SQUO8brDI+A=; b=SRnO4xFvnM5Md4EmAr0s3bd13MgLyMsSxALrdWnqtCo+1cLGJoSntvMf4ZXXgqsV8eXv1EjNX0+Wau2IjgtB4pEeW9pijbUpU4ISzZU7uUaNNm6jVi29yo+s6O761G61rV80KJvfyIQPu/WSRTYupENKjdDEPYxGBH2VuCBr1/j2HApzVqwPZr9w19lwmQa6ym8WK6sCvQjiGFVmppnV8vXjZit+eFrayoXrU1teKx+fVBRi/HfL1n+LyECZasLniECvGtSvuZ3NfqED8H/cuzW7iGK+F5qdbXIb6Z6AMfwY8DnjRTv6KsuRx6llFPfnpYKIpgSJMQf/ngOn0gMRzg== 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=MV5sab+RH0ktSxRkQXsZqtLrfDw0rcJ6SQUO8brDI+A=; b=ojZ4VYEQssdnH3b9lrWbtILfExTEYyE7czCAPGf3R9wjzLT440cgkWZfhe1bcHlv37Tf2qHBEGQgUfMdGML7VPPXjpo0aF9JK/5FLHfdqjNlQWqZW99sRN438x7+ee3MVueWSH1QFctGp/X5RivKfRmNBGHDZALeMth8lMLhtIY= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3347.namprd11.prod.outlook.com (2603:10b6:208:2f::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.34; Mon, 15 Feb 2021 11:31:14 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.3846.039; Mon, 15 Feb 2021 11:31:14 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: Does draft-ietf-lwig-curve-representations-19 have any bearing on the NETCONF crypto drafts Thread-Index: AdcDjfRlhVxUQpCYSc+DsE0nwDprjw== Date: Mon, 15 Feb 2021 11:31:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US 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=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aaecdab7-81fa-4a92-a1d4-08d8d1a533b4 x-ms-traffictypediagnostic: BL0PR11MB3347: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IKPbMBGpI8wTkbi3zeeZXRsxUzmhBGEqpAFajb+fDj9iUzQiAD/KsVT4Kxl3FEc+qf/wGqiEkY4zrHGkH2l6WWIWQ9I84twr2G+FyZJu8a2DA5Mv5wnaLLO1FOatAxFuFVgP4ejZjMEGP605vIReRA3S0UiF/OooFeHTX1KII/p/UoaUzMltcgdnuk7rK5B0r4WngBmlfNm5GmPVEnvs/IbN7dWBEE55DZ7ApRW6YbDjm3xlvxAbOf6QXRU6X4eSjLN0P2673JrSMT7wUU4Du3Glccdy1+RdG9611k/J1eMlLTtB57I6rqlZC59DBIB3JIHKKM9KmLMfIgyoSZLEIWW782qj5aeBvOmthKB7IVzH2xtHOmpdmZ/QzlmdYGKXujZQwX1G6uvD8OL3f0ZNOPJfZVxJXG7/4JK3r3wrIrWjIndd4lS52jycqZzWgFQqaC8LOj8uWEyUmx8BPs5/2zjnJk38kY8P++G7mSCA9gbHy0dPQVb8XvBJx+9aQ8kzyxZZrTDh8ijDR3VMNEcLoA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(136003)(376002)(346002)(39860400002)(5660300002)(55016002)(33656002)(52536014)(71200400001)(6506007)(26005)(2906002)(186003)(316002)(66476007)(66556008)(64756008)(66446008)(86362001)(66946007)(76116006)(7696005)(4326008)(8676002)(8936002)(9686003)(4744005)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?oFuV9IExP9fwB1IwCinJp0WE/E0+5z2gZ8EPoxglBZAsxxIXMB0UrY1983Kb?= =?us-ascii?Q?H2x67v6y8a+Iqd8+bZKsr6g7IpaZhTR97jQzD97pcvPEVP7XweRXnXQQFm5+?= =?us-ascii?Q?TKtukRXPmnjqVpDgNF7kqy/oMrxEYVAHlVOgItxg3CeXubRDkIqXFVCyQhtW?= =?us-ascii?Q?9i5HJgo+oSTeT9enk395iYq4/McMN3wdNoey2Jz5J6+mJd2ihFsiycmrZ7BM?= =?us-ascii?Q?yRU39tUBGvCIk7X5965olHMjhWmk/0DeSSAlnBqH6soqgxpynnQQzILi9e6n?= =?us-ascii?Q?OVSJtvRwNrJppquoQf+3zpAFX4lMZ1B5RF6Sd3FMWfucWo1uyaicGbgJgj76?= =?us-ascii?Q?J10i+3gaX1juK3PmHYDcA/4jPXBvrpCo1IILDoJYQd/cEhDFYlzQ4EGQTwlN?= =?us-ascii?Q?iqvCSUJggdMwd03P9WfjKyZWyakfxrV6eQarWTffGhkJl2l1S0SjBpqUzhGQ?= =?us-ascii?Q?W922q31sNJX1nW1UX97LetN2x6MtwHohqGYg4OO3PS87jctYjvll75QSEqi3?= =?us-ascii?Q?ukQn4jBq1XgOrJ6R+wBtAFmAmj26VKT2tey+VmjTQoeo4YWdhsuBlYkbYX7R?= =?us-ascii?Q?nq3vkItLhXGTypeugLpT9NB0KnChwwFvhn1IxxKYsCfsYsSiY6slL2tR+Ptj?= =?us-ascii?Q?nNSUw6H80eGz8PXsM1zCCjG/6jdtV42in5Bxs+7OWk9CXAlP8353GCjMKEQk?= =?us-ascii?Q?XCjJaFTriq78EAgieR4Kufqd9ANg6RWlmc2kbYQzDhuukYnxFAedx53aHjjG?= =?us-ascii?Q?PuCV06rgaQzCmS2dzhCm03fZbz+zLEE0plgL6lDOi1ZmT9S+EC6vorGQqAxK?= =?us-ascii?Q?f9J0Yz/tZ21oSspnN22xdkfMkcFf2zB2UwCTSkmY6SGrDXYLwwRfASOXTa0I?= =?us-ascii?Q?hpWDiBCvAHnL5RY/oUxS+sH+e9LGoQKGGIeceIWue6ynj28nCcGAfvQLpslC?= =?us-ascii?Q?OGSPr60fydigDhWjNs43Zq/JiY7zUWvDOrUKSZjpR/ogdEy1s35M3g4HnPoK?= =?us-ascii?Q?x7ulbaW2rAyXA/AQJe8b8pqrwSnvf44OD5xEZCGXFZcNcf/exlPdMwQ3nDc3?= =?us-ascii?Q?U5UDfmiMCLcGxk6qgo0m15KEgKAzsXJ7+rnC5w12AJSquJclQEviqSwUGrst?= =?us-ascii?Q?pyOxpSWvHSO5SvgfRoDGL/+zDBSMFNBpcq3gN4QHNDdfLBLJOTdIrBCowdEI?= =?us-ascii?Q?cwzroidcXzG8D7YtpaVtHSsdnYplFVo6Xrav/O3xfzoRLqWK5AnHfn2JocJM?= =?us-ascii?Q?AEgdxks026vL1hbWT1P4qbRpEdwwTPAv6GD1+8958v/T1RnS3I5bvuHdeJmg?= =?us-ascii?Q?KMRr3tpagKBlUOd2N0SS+FlR?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: aaecdab7-81fa-4a92-a1d4-08d8d1a533b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2021 11:31:13.9490 (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: gY5pnWPChpkxVTVOGUJr6AJlyKGL524CVpVs/Cot2Kb+ZGTqSftnbuzWJn9uaSNktiZW0Wy73vLjQD+JgFkbpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3347 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: [netconf] Does draft-ietf-lwig-curve-representations-19 have any bearing on the NETCONF crypto drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 11:31:19 -0000 Hi Kent, draft-ietf-lwig-curve-representations-19 is in IESG review, the abstract st= ates: This document specifies how to represent Montgomery curves and (twisted) Edwards curves as curves in short-Weierstrass form and illustrates how this can be used to carry out elliptic curve computations using existing implementations of, e.g., ECDSA and ECDH using NIST prime curves. We also provide extensive background material that may be useful for implementers of elliptic curve cryptography. I just wanted to check whether this draft is relevant to the crypto types w= ork in NETCONF at all (e.g., draft-ietf-netconf-ssh-client-server). From a= quick look, I didn't think that it would have any impact, but thought that= I should check. Regards, Rob From nobody Mon Feb 15 06:44:50 2021 Return-Path: <01000177a6268889-efcce6ef-fef0-4308-9dd8-6f3b9ee72955-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 90D2B3A0C49 for ; Mon, 15 Feb 2021 06:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.006 X-Spam-Level: X-Spam-Status: No, score=0.006 tagged_above=-999 required=5 tests=[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 iaSqAEM5Gds9 for ; Mon, 15 Feb 2021 06:44:42 -0800 (PST) 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 6F8313A0C06 for ; Mon, 15 Feb 2021 06:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1613400279; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=qN79tP1Oq5jPdH/UkUQy9uSoe9QrbGub07XnS0VMXEA=; b=kP8a9U4FyqC3eCrR5MMHBzu/RQEVRuc3AjFsWWh5sEvxNk9d5uDcn9HNCa+cLZid ADOFUkBYdHFbfYJQU3MPQnG/JsQ5Erjd28ST/r29TDu6E8BbaA9vi5CYA+T2WC43z+6 Go3SkLOgoIiRADa+2pjgOxF+a0AeVBLDCKIQfSFA= From: Kent Watsen Message-ID: <01000177a6268889-efcce6ef-fef0-4308-9dd8-6f3b9ee72955-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_94E1F70A-6E27-4D9A-9208-BDE32E925790" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Mon, 15 Feb 2021 14:44:39 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: "Rob Wilton (rwilton)" References: X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.02.15-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Does draft-ietf-lwig-curve-representations-19 have any bearing on the NETCONF crypto drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 14:44:49 -0000 --Apple-Mail=_94E1F70A-6E27-4D9A-9208-BDE32E925790 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Rob, The closest our work comes is in the "crypt-types" draft itself, where = we have "public-key-format" and "private-key-format". Presumably (after = skimming the draft) the same "ECPrivateKey" and "SubjectPublicKeyInfo" = ASN.1 structures are used to persist the key. If so, then no impact, = otherwise there may be a need to define other identities from our base = "private-ket-format" and/or "public-key-format" identities, which could = be done as a future effort (i.e., no need to block current publication). K. > On Feb 15, 2021, at 6:31 AM, Rob Wilton (rwilton) = wrote: >=20 > Hi Kent, >=20 > draft-ietf-lwig-curve-representations-19 is in IESG review, the = abstract states: >=20 > This document specifies how to represent Montgomery curves and > (twisted) Edwards curves as curves in short-Weierstrass form and > illustrates how this can be used to carry out elliptic curve > computations using existing implementations of, e.g., ECDSA and ECDH > using NIST prime curves. We also provide extensive background > material that may be useful for implementers of elliptic curve > cryptography. >=20 > I just wanted to check whether this draft is relevant to the crypto = types work in NETCONF at all (e.g., = draft-ietf-netconf-ssh-client-server). =46rom a quick look, I didn't = think that it would have any impact, but thought that I should check. >=20 > Regards, > Rob >=20 --Apple-Mail=_94E1F70A-6E27-4D9A-9208-BDE32E925790 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Rob,

The closest our work comes is in the "crypt-types" draft = itself, where we have "public-key-format" and "private-key-format". =  Presumably (after skimming the draft) the same "ECPrivateKey" and = "SubjectPublicKeyInfo" ASN.1 structures are used to persist the key. =  If so, then no impact, otherwise there may be a need to define = other identities from our base "private-ket-format" and/or = "public-key-format" identities, which could be done as a future effort = (i.e., no need to block current publication).

K.


On Feb 15, 2021, at 6:31 AM, Rob Wilton = (rwilton) <rwilton@cisco.com> wrote:

Hi = Kent,

draft-ietf-lwig-curve-representations-19 is in IESG review, = the abstract states:

  This = document specifies how to represent Montgomery curves and
=   (twisted) Edwards curves as curves in short-Weierstrass form = and
  illustrates how this can be used to carry = out elliptic curve
  computations using = existing implementations of, e.g., ECDSA and ECDH
=   using NIST prime curves.  We also provide extensive = background
  material that may be useful for = implementers of elliptic curve
=   cryptography.

I just wanted to = check whether this draft is relevant to the crypto types work in NETCONF = at all (e.g., draft-ietf-netconf-ssh-client-server).  =46rom a = quick look, I didn't think that it would have any impact, but thought = that I should check.

Regards,
Rob


= --Apple-Mail=_94E1F70A-6E27-4D9A-9208-BDE32E925790-- From nobody Mon Feb 15 07:28:45 2021 Return-Path: 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 F2F7C3A0C61 for ; Mon, 15 Feb 2021 07:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.697 X-Spam-Level: X-Spam-Status: No, score=-7.697 tagged_above=-999 required=5 tests=[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=AUQxMR4d; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PYojDtsO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxIsHRJE9Cwv for ; Mon, 15 Feb 2021 07:28:41 -0800 (PST) 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 C62253A0C59 for ; Mon, 15 Feb 2021 07:28:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7471; q=dns/txt; s=iport; t=1613402920; x=1614612520; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YeTasS+/kykn6skyN5qKYFGp1tPT/g6bujhRVrGJdDM=; b=AUQxMR4dmXcL8FeOdkfoLVhugzgJMPmrWLDBp64yAliNgQgB74zr81CC KYED/94AaMIUxKThVFdY4cyhhN5Ib6ZeYF9iZuFehrQp3VwDx9p6JwZhe nBRqHrhSrtUYoLKrAPgnIBQE09bQbBwLtb0t4vBoYydTSMMHF1moMwOq7 A=; X-IPAS-Result: =?us-ascii?q?A0DSAgAlkSpgkIENJK1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+BIzBRfVo2MQqHfwOOCAOUKoRzglMDVAsBAQENAQEyAgQBAYRNAoIJAiU4E?= =?us-ascii?q?wIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAYY4DYZEAQEBBC0TAQE3AQ8CA?= =?us-ascii?q?QgRBAEBKAcyFAkIAQEEDgUIgmgBgX5XAy4BA6QqAooldIE0gwQBAQaFFRiCE?= =?us-ascii?q?gmBOIJ2hAWFKIEfJhyBQUGBEUOCVz6EJho0gxSCK4IrISAcJgQygXo5YpsGj?= =?us-ascii?q?EqRSQqCepwsoy22NQIEAgQFAg4BAQaBbCGBWXAVgyRQFwINjh8aHYM6illzN?= =?us-ascii?q?wIGCgEBAwl8iggBgQ4BAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AAVcVjxCpTeSe8xGDzIjFUyQJPHJ1sqjoPgMT9p?= =?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-AV: E=Sophos;i="5.81,180,1610409600"; d="scan'208,217";a="687778849" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Feb 2021 15:28:39 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 11FFSdm7024862 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Feb 2021 15:28:39 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Feb 2021 09:28:39 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Feb 2021 09:28:38 -0600 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; Mon, 15 Feb 2021 10:28:38 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZIiHvwYrnqJjziCV5O3YFaRhQiez3rfqvh6tkcdnPlBMoHTOx1N0qjVYp2PHCog6K+r4CzgGEY4fRmQuApWkkWC/+21+9N22Gm3dGkFn7ZaZKBRLsC82nCkiy0Y04dUHUhMqaoWxsOps/mnUj/k57n0uMezCDhnxDajU9+nUJmqYfHgiGtZ0Vi8H2WIWAxpoNjFLuB92IuUp9aUZEMSyX8sy70dEgtn4xG/9cFl1LgEloOLE5pWyWsdXUWk5b7XTNBs4+SfsiAZW1hYjzyUUQafbhwHspyLgySdXJ0mCIzpnaas6Z4Cf4uUgchOy9OJ17BbMEuP3hZzWlz1zWuxU3w== 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=eCbYsaNpTKjRkjROpDMQmkkykY67PicAiL8Q8uSAy3Y=; b=Wt22+ohdMUvjfPRET64M4qa9sa2BMoBOoCrmgVC90Zk/34IGmS3oB1NQSwbYk0/U0VaxLh7XZu7hFxgItXb/shkEW8/uxhurtpWAt/mk6s4gnuWhHI+jmeXeqMpw+vL6fCt9IGQkZriZN6Ib+PgvANU8bocgFvjiUk5ZJOMuqarm9+1uJpQXlbaKtbVdDY1E4gaqd5ciRnys47UPeFciIPYYeoRiOYfjrFr70DbRRqEcR4QbIhjbEDcQxEvSbFCORcD+fTqgnyXxzw1KX1W3BCs7g0RFs29A/EAgtZUxICHoTp7TrxG0s2SBWtB62hUasl9yibHiqbOr+TrlOa6GYw== 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=eCbYsaNpTKjRkjROpDMQmkkykY67PicAiL8Q8uSAy3Y=; b=PYojDtsOZbLvyP9QkI5QEDkEdt5uJKp+t+DJOBq2dPtIWKS2JxZkxQHQLCqwB/5dflbCVtB58QO/197CDc8x1feIcFmrbTc1igRQlHkmjtDd6iI+BKBhdf98MFVF7smhwlgCl+ynkBFkeCKGuAltAGuRWX7/Jx4EptPdA4M/fAE= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3105.namprd11.prod.outlook.com (2603:10b6:208:33::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.31; Mon, 15 Feb 2021 15:28:37 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.3846.039; Mon, 15 Feb 2021 15:28:37 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: Does draft-ietf-lwig-curve-representations-19 have any bearing on the NETCONF crypto drafts Thread-Index: AdcDjfRlhVxUQpCYSc+DsE0nwDprjwAGyHyAAAGGveA= Date: Mon, 15 Feb 2021 15:28:37 +0000 Message-ID: References: <01000177a6268889-efcce6ef-fef0-4308-9dd8-6f3b9ee72955-000000@email.amazonses.com> In-Reply-To: <01000177a6268889-efcce6ef-fef0-4308-9dd8-6f3b9ee72955-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US 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=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 68aca66c-ff01-4ab8-2079-08d8d1c65d6e x-ms-traffictypediagnostic: BL0PR11MB3105: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QFLiVYONCoxKhBLhCai8sDlzfBOeIrSGEpPfXEy09cu1yyoiA4HuCOGKZjwMiZ1mZ+xQ7S7AiqQl0e5ccZHxgDUEoq5DAEWogTr6ESze67Oaf6PRZ2v3s0WycjHQxkAvoPVKKwxWiCygzEElwPkbOXqOGn3xZbT7juZdjxvTYqHzUcJSdBDR/iDDQAE0W9ZzV+uybSy9J+vWHpI/5FhJzW71imzWnTZGhu4IUHJ4AFW20Aa4udTLhp2pVJxF/gN7B5wg98CQoNr8u0/R+ok8CarnGh7al9FFw97ptkaHyioBI+IH2qXe1KjgNRGyWuVoZZTevb0R+bfS+35ZMrHgDkHPNpfs/c/MpBXhfjbfcGSziTQOYyMr0am4wLEL0ztpHdETi68Gk7SORJI1VBC2J333Jb9W/kvNU4U/H4gl/utDzDtF7QqdHYvBr/jLW5KqcScwgx9kd/8k9FEWCx3ZIQD3U9ZF5zOReS3DxvkQPB7rWia0hSeztrV9BCqYoK6b4U0iqFKZfeaim0vKqsncRA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(346002)(39860400002)(366004)(376002)(55016002)(4326008)(9686003)(316002)(9326002)(8936002)(8676002)(86362001)(76116006)(5660300002)(52536014)(83380400001)(64756008)(53546011)(71200400001)(7696005)(66446008)(2906002)(66476007)(66946007)(66556008)(186003)(33656002)(478600001)(26005)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?TKgc+1O0S/zX4KihDUnesatBJRmLVjPTDBZKFtG/4JFV+9zlNY9t4kNXE+5h?= =?us-ascii?Q?VqK+SVLN5e70upYXORuRm1+X4HJchw9GFwVI/eVyb9U7sx1W9Gs7jt1ugm4V?= =?us-ascii?Q?RQHNuy6bMQU+/aufpgmG0vcqYQ/gzA4NnNT5ZfCL6YbBJ4RR+0wRGikDFDL8?= =?us-ascii?Q?qCNSqeHZLHFRjFmL4BkJg7tDvgiQmTYoWx+5tYLEwy3tq8qf2AK2bevEwDYQ?= =?us-ascii?Q?7eKKoxjK+xh1rKZvuB4riPQ0vO+b2trLuk6O7HfrhaLJ5hIFLjZx7ZZSbz1z?= =?us-ascii?Q?Ll9oxGh0okmg8XNyE+uF43tJofARScbJ/5C+jr/NTgCKtgdRy3bvdfcuBBKP?= =?us-ascii?Q?Vx+ANK98v7cict2DvIMkVwm99ss4xF2KFnqS9nRM5gp0ozc+uLYh87zq7Y4g?= =?us-ascii?Q?5mXIC+o6QEOEdwxE9ae7hgZYcS5tI/OUEr/ik2Q/YYUpDR+chlSs1rvZiaLw?= =?us-ascii?Q?urY9Lfum7U1+H1jQs7t73KQsz++/XDPS9llvZt4PPJqx8urvQC0IGTtyIE/D?= =?us-ascii?Q?tmaOVatgyxaJmrq5PQJmW+lAWUJWYmEX35avyBicbkta3scUspzlPGzxsN9m?= =?us-ascii?Q?DD0dqPETKLlL03cSJevIcjHHM5pfdE1p5ZrrXtrn7V8uPl43eG1NGQ3sK0kA?= =?us-ascii?Q?U3LD4GisTfKnjNrHsQRyRJAfnHV+xwZZnkS3fPa1avYiKKBSGRu21Pjd+Vyj?= =?us-ascii?Q?kAwRNSeoYRa6HYMOomr7IVulXWBcXd+QINfhrBXaB4PzZhe7cNoK69MUME5k?= =?us-ascii?Q?JgsimDmAKp4Xff7A5i1D49K4m88nu6+pSBg5cvCMSN3bb2SNtgZECD65dw87?= =?us-ascii?Q?fwcXAmEEjHQ/Igh51dZ8fkpz9UvDQdyjABzSDkAqvUyPax3wm6VnswduPVK7?= =?us-ascii?Q?xAESfgR5RgUqEwA22016gPP2VyMDEyJGeHyeVDHj/c20f4O/7hXlL1euPZdh?= =?us-ascii?Q?fl2WYjltJqApGYzdng1/FLTI9sq09xiRgeQr63LjNW8y/qcc2H4SCGDjFC2n?= =?us-ascii?Q?cIMR1eXBFog/D2gMSpcWPOTIfVNxdKm0dLb9oXxybyVpwRIUTF/1Jk/8NU5W?= =?us-ascii?Q?+97z1mFvifLkHHH0nzNqD8D7iT7qm9LKu3b3JWWq8dSdlF4PB4N9kRjGdnkP?= =?us-ascii?Q?Yp3aRkqCHXYssFBO2HFJBtU4me1mu+Ytg8bvTdpIhBMI3Wep0K6gQ1eJ6qs0?= =?us-ascii?Q?+sQY1FYoqcFddPSM0xCQ7gxe3n3v32N7D93rPjp/cMYLP7Mlt7dUTX9UAU4a?= =?us-ascii?Q?1rB0n/4VSMYwxNMgjYO2VQqB54a7xRZW8k6mmb3tfe2LR2dVFTvTC10lbjQL?= =?us-ascii?Q?/PMASNhZKCKiGH2o+2+DnAhL?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43668AE47038B41E231BA41FB5889MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 68aca66c-ff01-4ab8-2079-08d8d1c65d6e X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2021 15:28:37.3093 (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: r/lr7MekXMMmTyANICSgB1FLsu0dhstP07LuZFTHdAzTvBKYvKtq8dczm4wiUGpPIyh6cmxYYGRS92dGbFkaEg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3105 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [netconf] Does draft-ietf-lwig-curve-representations-19 have any bearing on the NETCONF crypto drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2021 15:28:44 -0000 --_000_MN2PR11MB43668AE47038B41E231BA41FB5889MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, Thanks for confirming. Rob From: Kent Watsen Sent: 15 February 2021 14:45 To: Rob Wilton (rwilton) Cc: netconf@ietf.org Subject: Re: Does draft-ietf-lwig-curve-representations-19 have any bearing= on the NETCONF crypto drafts Hi Rob, The closest our work comes is in the "crypt-types" draft itself, where we h= ave "public-key-format" and "private-key-format". Presumably (after skimmi= ng the draft) the same "ECPrivateKey" and "SubjectPublicKeyInfo" ASN.1 stru= ctures are used to persist the key. If so, then no impact, otherwise there= may be a need to define other identities from our base "private-ket-format= " and/or "public-key-format" identities, which could be done as a future ef= fort (i.e., no need to block current publication). K. On Feb 15, 2021, at 6:31 AM, Rob Wilton (rwilton) > wrote: Hi Kent, draft-ietf-lwig-curve-representations-19 is in IESG review, the abstract st= ates: This document specifies how to represent Montgomery curves and (twisted) Edwards curves as curves in short-Weierstrass form and illustrates how this can be used to carry out elliptic curve computations using existing implementations of, e.g., ECDSA and ECDH using NIST prime curves. We also provide extensive background material that may be useful for implementers of elliptic curve cryptography. I just wanted to check whether this draft is relevant to the crypto types w= ork in NETCONF at all (e.g., draft-ietf-netconf-ssh-client-server). From a= quick look, I didn't think that it would have any impact, but thought that= I should check. Regards, Rob --_000_MN2PR11MB43668AE47038B41E231BA41FB5889MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,<= o:p>

&nbs= p;

Thanks fo= r confirming.

&nbs= p;

Rob<= /o:p>

&nbs= p;

&nbs= p;

From: Kent Watsen <kent+ietf@watsen.net>
Sent: 15 February 2021 14:45
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: netconf@ietf.org
Subject: Re: Does draft-ietf-lwig-curve-representations-19 have any = bearing on the NETCONF crypto drafts

 

Hi Rob,

 

The closest our work comes is in the "crypt-typ= es" draft itself, where we have "public-key-format" and &quo= t;private-key-format".  Presumably (after skimming the draft) the= same "ECPrivateKey" and "SubjectPublicKeyInfo" ASN.1 s= tructures are used to persist the key.  If so, then no impact, otherwise there may = be a need to define other identities from our base "private-ket-format= " and/or "public-key-format" identities, which could be done= as a future effort (i.e., no need to block current publication).

 

K.

 



On Feb 15, 2021, at 6:31 AM, Rob Wilton (rwilton) &l= t;rwilton@cisco.com> wrote:

 

Hi Kent,

draft-ietf-lwig-curve-representations-19 is in IESG review, the abstract st= ates:

  This document specifies how to represent Montgomery curves and<= br>   (twisted) Edwards curves as curves in short-Weierstrass form an= d
  illustrates how this can be used to carry out elliptic curve   computations using existing implementations of, e.g., ECDSA and= ECDH
  using NIST prime curves.  We also provide extensive backgr= ound
  material that may be useful for implementers of elliptic curve<= br>   cryptography.

I just wanted to check whether this draft is relevant to the crypto types w= ork in NETCONF at all (e.g., draft-ietf-netconf-ssh-client-server).  F= rom a quick look, I didn't think that it would have any impact, but thought= that I should check.

Regards,
Rob

 

--_000_MN2PR11MB43668AE47038B41E231BA41FB5889MN2PR11MB4366namp_-- From nobody Tue Feb 16 10:30:34 2021 Return-Path: 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 C8FBE3A0BD3; Tue, 16 Feb 2021 10:30:22 -0800 (PST) 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 34fnuWqeJdfS; Tue, 16 Feb 2021 10:30:19 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D233A0E00; Tue, 16 Feb 2021 10:30:19 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id a24so5946963plm.11; Tue, 16 Feb 2021 10:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/Ojy3IUYPM6rpdnaK6qp0Ry3AyUFdTqTT4Ps/hjKxYw=; b=tNGXQ+2tZ6HKIytrJuiMWBQ3LpSQMa9CW2LyyINcDu55oluGsnSR/pUe1xmbXTh64O AeG1O0crTOLi4BiBOyb8Hhg7z9XxUHGfU4jS9SyIirZUH7CEsK14A56eNDp6FiSp75Pc KvlO5Yl+w8haPpHFABRpms3C6ZDM7c09oti9wn/4za2ory8ImaJk86aBE6yVc4Wb5uql kqSeBkMyeqGQw86pVryO671bwMeogxwftBOqRMW9jFQyh8qB+q3NPUs64mLo5lkpTeWf JGK6IjQjmQizDbt5Jyyhf3D//rbIBuYffjlHmedFGDD4NF8JHjnHq5gIg2ZIowl2hjxL FC7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/Ojy3IUYPM6rpdnaK6qp0Ry3AyUFdTqTT4Ps/hjKxYw=; b=X8IDc7EwgxVIzPLdg8vrFGfwbO2ljXGrOcqOzUFEgoaC/ldVlz5ghZucOQhuI5067e m15WXxPirShbORZelSHxAL3ZX5mBa7fkM+txs3HU8JCrJDbi4Hw5VXZao5T11S7oKJdZ Em3xrwzEL84NqtnsKBGm7YY0tnaVj3Zr86ZMbI135ljYQgU17XcecS6HHxZt7Zyfgv/i zaDd2kDqlrejH2xFlNEzcsjdvqKicef5UFHFZXeUDZmhKErB2jIFtpgftmQOGURzEAoN rK4th0F48Dnj+fyZMRlB+KTStr55VlQrMlMWIwJwwYXtQKsolvLqpXpA37MAvoH1WTqP 9GqA== X-Gm-Message-State: AOAM530C5RtryXhrAG2cUkYjQI6Q6gNeZS4O4EYVfVn8d/zEUFUV0LA7 AlCIN/v0tC8rNTQyCnqQk18gtSGCrFdnXQ== X-Google-Smtp-Source: ABdhPJwaAGFXZZ/tudT4WppjeG9FAnVOsJ/ekhgyOIjgogt+VTzoI+2COi+4FU9sl3cX4HQFMlMLNQ== X-Received: by 2002:a17:902:9b91:b029:e3:2c9e:f511 with SMTP id y17-20020a1709029b91b02900e32c9ef511mr18494285plp.74.1613500218481; Tue, 16 Feb 2021 10:30:18 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:f520:e2e5:d323:243b? ([2601:647:5600:5020:f520:e2e5:d323:243b]) by smtp.gmail.com with ESMTPSA id g3sm22845215pfq.42.2021.02.16.10.30.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Feb 2021 10:30:18 -0800 (PST) From: Mahesh Jethanandani Message-Id: <383BE000-68C0-45E0-9456-D1A397935C91@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C07B6F8E-8A25-4D1D-BEAC-56F9301FD96B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 16 Feb 2021 10:30:16 -0800 In-Reply-To: Cc: "yang-doctors@ietf.org" , "draft-ietf-netconf-https-notif.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" , tom petch To: "Acee Lindem (acee)" References: <161176691048.5494.2373231790931856179@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 18:30:23 -0000 --Apple-Mail=_C07B6F8E-8A25-4D1D-BEAC-56F9301FD96B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Acee, See inline with [mj] > On Feb 10, 2021, at 11:03 AM, Acee Lindem (acee) = wrote: >=20 > Hi Mahesh,=20 > =20 > Thanks for the update. See some inlines.=20 > =20 > From: Mahesh Jethanandani > > Date: Monday, February 8, 2021 at 11:27 PM > To: Acee Lindem > > Cc: YANG Doctors >, = "draft-ietf-netconf-https-notif.all@ietf.org = " = >, = "last-call@ietf.org " >, "netconf@ietf.org = " > > Subject: Re: Yangdoctors last call review of = draft-ietf-netconf-https-notif-06 > =20 > Hi Acee, > =20 > Thank you first of all for the review of the document. You reviewed = -06, and we have since submitted -07. I will in my responses reflect the = changes in -07 that might affect the comments you have provided. >=20 >=20 >> On Jan 27, 2021, at 9:01 AM, Acee Lindem via Datatracker = > wrote: >> =20 >> Reviewer: Acee Lindem >> Review result: Almost Ready >>=20 >> The document is almost ready for WG Last Call. I have the following = comments: >>=20 >> Model ietf-sub-notif-recv-list: >>=20 >> Seems odd to have a model that adds a choice statement without any >> valid options. I realize you expect other transports in the future = but >> having a separate module the one defined in the same draft seems = like a >> profligate design choice. > =20 > The draft contains two models as you have noted. While the = ietf-sub-notif-recv-list adds a choice statement, the second model goes = on to adding a case statement for that choice statement. We could have = hard coded the two models together, but believe that by separating them, = we offer the flexibility to implementations that may choose not to = implement both the models. Also, other transports can augment = "receiver-instances", without including the entire http transport model. > =20 > Well, right now, there is only one choice for transport. > =20 > If it helps, we can add a comment to that effect in the model to = explain our motivation. > =20 > That would be good although I understood the motivation. I guess this = is one way to make it optional but currently the only option is both = models or neither. =20 [mj] True if you want to use https as the transport. There is another WG = draft, the UDP transport draft that will use the = ietf-sub-notif-recv-list module to add a case statement for udp = transport. If this draft proposes one model, the UDP transport would = have to import all the models https transport draft imports, just to = resolve all the dependencies. Ideally, this model should have been part of RFC 8639. But that train = has already left the station. We were surprised that no one suggested = that the model be spun into a draft of its own, although that draft = would be very small. Thanks. >=20 >=20 >>=20 >> Model ietf-sub-notif-recv-list: >> 1. The prefix "hn" seems inconsistent to lose the context. I'd use >> "snrlhn". This wouldn't be an issue if you combined the = modules. > =20 > The updated model in -07 now carries the prefix =E2=80=9Chnt=E2=80=9D. > =20 > That is an improvement but since this augments a model with =E2=80=9Csnr= =E2=80=9D as the prefix, it seems that should be part of the prefix. If = you didn=E2=80=99t have a separate model, it wouldn=E2=80=99t be an = issue. ;^) However, I=E2=80=99m leave it to Tom (copied) for further = debate.=20 >=20 >=20 >> 2. This comment is incomprehensible: >>=20 >> // create the logical impossibility of enabling "tcp" >> // transport > =20 > Would it help if we expanded the comment to say: > =20 > // The "http-client-stack-grouping=E2=80=9D supports both HTTP and = HTTPS stacks by default. This draft, however supports HTTPS only. The = following=20 > // if-feature statement makes it logically impossible to configure = HTTP transport. > =20 > Yes.=20 >=20 >=20 >>=20 >> In the IANA section, the security considerations for the media types >> point to this draft's security considerations. However, they don't >> include the referenced information. It seems these IANA references >> should point to other RFCs. > =20 > The updated IANA section no longer carries the media-types. > =20 > That=E2=80=99s better.=20 > =20 > Thanks, > Acee >=20 >=20 >>=20 >> It should be noted that ietf-subscribed-notifications has a number of = YANG >> errors and warnings. >>=20 >> I also have the following editorial comments: >=20 >> Acee-Lindems-iMac-2:Desktop acee$ diff -c >> draft-ietf-netconf-https-notif-06.txt.orig >> draft-ietf-netconf-https-notif-06.txt *** >> draft-ietf-netconf-https-notif-06.txt.orig 2021-01-27 = 10:06:29.000000000 -0500 >> --- draft-ietf-netconf-https-notif-06.txt 2021-01-27 = 11:57:13.000000000 >> -0500 >> *************** >> *** 17,23 **** >> This document defines a YANG data module for configuring HTTPS = based >> configured subscription, as defined in RFC 8639. The use of = HTTPS >> maximizes transport-level interoperability, while allowing for >> ! encoding selection from text, e.g. XML or JSON, to binary. >>=20 >> Status of This Memo >>=20 >> --- 17,23 ---- >> This document defines a YANG data module for configuring HTTPS = based >> configured subscription, as defined in RFC 8639. The use of = HTTPS >> maximizes transport-level interoperability, while allowing for >> ! encoding selection from text, e.g., XML or JSON, to binary. > =20 > The abstract section has been updated. >=20 >=20 >>=20 >> Status of This Memo >>=20 >> *************** >> *** 103,109 **** >> documents. This document defines two YANG 1.1 [RFC7950] data >> modules, one for augmenting the Subscription to YANG = Notifications >> [RFC8639] to add a transport type, and another for configuring = and >> ! managing HTTPS based receivers for the notifications. >>=20 >> --- 103,109 ---- >> documents. This document defines two YANG 1.1 [RFC7950] data >> modules, one for augmenting the Subscription to YANG = Notifications >> [RFC8639] to add a transport type, and another for configuring = and >> ! managing HTTPS-based receivers for the notifications. > =20 > Fixed. >=20 >=20 >>=20 >> *************** >> *** 118,124 **** >> the same receiver instance. The second module describes how to >> enable the transmission of YANG modeled notifications, in the >> configured encoding (i.e., XML, JSON) over HTTPS. Notifications = are >> ! delivered in the form of a HTTPS POST. The use of HTTPS = maximizes >> transport-level interoperability, while the encoding selection = pivots >> between implementation simplicity (XML, JSON) and throughput = (text >> versus binary). >> --- 118,124 ---- >> the same receiver instance. The second module describes how to >> enable the transmission of YANG modeled notifications, in the >> configured encoding (i.e., XML, JSON) over HTTPS. Notifications = are >> ! delivered in the form of an HTTPS POST. The use of HTTPS = maximizes >> transport-level interoperability, while the encoding selection = pivots >> between implementation simplicity (XML, JSON) and throughput = (text >> versus binary). >> *************** > =20 > Fixed. >=20 >=20 >> *** 196,202 **** >>=20 >> In the case of "pipelining", the flow of messages would look >> something like this. This example shows the flow assuming that >> ! Subscribed Notifications is used and therefore a > started> notification is sent before sending the first = notification. >> The example would be the same for when Subscribed Notification is = not >> used by removing the first POST message for = . >> --- 196,202 ---- >>=20 >> In the case of "pipelining", the flow of messages would look >> something like this. This example shows the flow assuming that >> ! Subscribed Notification is used and therefore a > started> notification is sent before sending the first = notification. >> The example would be the same for when Subscribed Notification is = not >> used by removing the first POST message for = . >> *************** > =20 > This section has been rewritten. >=20 >=20 >> *** 342,350 **** >>=20 >> 2.1. Introduction >>=20 >> ! To learn the capabilities of the receiver, the publisher can = issue a >> HTTPS GET request with Accept-Type set to application/ietf-https- >> ! notif-cap+xml or application/ietf-https-notif-cap+json, with = latter >> as the mandatory to implement, and the default in case the type = is >> not specified. If the receiver supports capabilities such as = binary >> encoding of data, it can return that as a capability in a = response. >> --- 342,350 ---- >>=20 >> 2.1. Introduction >>=20 >> ! To learn the capabilities of the receiver, the publisher can = issue an >> HTTPS GET request with Accept-Type set to application/ietf-https- >> ! notif-cap+xml or application/ietf-https-notif-cap+json, with the = latter >> as the mandatory to implement, and the default in case the type = is >> not specified. If the receiver supports capabilities such as = binary >> encoding of data, it can return that as a capability in a = response. >> *************** > =20 > Fixed. >=20 >=20 >> *** 450,456 **** >> Internet-Draft HTTPS Configured Subscription November = 2020 >>=20 >> ! Copyright (c) 2018 IETF Trust and the persons identified as >> the document authors. All rights reserved. >> Redistribution and use in source and binary forms, with or >> without modification, is permitted pursuant to, and subject >> --- 450,456 ---- >> Internet-Draft HTTPS Configured Subscription November = 2020 >>=20 >> ! Copyright (c) 2021 IETF Trust and the persons identified as >> the document authors. All rights reserved. >> Redistribution and use in source and binary forms, with or >> without modification, is permitted pursuant to, and subject >> *************** > =20 > Fixed. >=20 >=20 >> *** 536,545 **** >>=20 >> This YANG module is a definition of a set of receivers that are >> interested in the notifications published by the publisher. The >> ! module contains the TCP, TLS and HTTPS parameters that are = needed to >> communicate with the receiver. The module augments the ietf-sub- >> notif-recv-list module to define a transport specific receiver. = As >> ! mentioned earlier, it uses POST method to deliver the = notification. >> The attribute 'path' defines the path for the resource on the >> receiver, as defined by 'path-absolute' in URI Generic Syntax >> [RFC3986]. The user-id used by Network Configuration Access = Control >> --- 536,545 ---- >>=20 >> This YANG module is a definition of a set of receivers that are >> interested in the notifications published by the publisher. The >> ! module contains the TCP, TLS, and HTTPS parameters that are = needed to >> communicate with the receiver. The module augments the ietf-sub- >> notif-recv-list module to define a transport specific receiver. = As >> ! mentioned earlier, it uses the POST method to deliver the = notification. >> The attribute 'path' defines the path for the resource on the >> receiver, as defined by 'path-absolute' in URI Generic Syntax >> [RFC3986]. The user-id used by Network Configuration Access = Control >> *************** > =20 > This section of the module has been rewritten. >=20 >=20 >> *** 639,645 **** >> description >> "YANG module for configuring HTTPS base configuration. >>=20 >> ! Copyright (c) 2018 IETF Trust and the persons identified as >> the document authors. All rights reserved. >> Redistribution and use in source and binary forms, with or >> without modification, is permitted pursuant to, and subject >> --- 639,645 ---- >> description >> "YANG module for configuring HTTPS base configuration. >>=20 >> ! Copyright (c) 2021 IETF Trust and the persons identified as >> the document authors. All rights reserved. >> Redistribution and use in source and binary forms, with or >> without modification, is permitted pursuant to, and subject >> *************** > =20 > Fixed. >=20 >=20 >> *** 704,710 **** >>=20 >> container receiver-identity { >> description >> ! "Specifies mechanism for identifying the receiver. >> The publisher MUST NOT include any content in a >> notification that the user is not authorized to = view."; >>=20 >> --- 704,710 ---- >>=20 >> container receiver-identity { >> description >> ! "Specifies the mechanism for identifying the = receiver. >> The publisher MUST NOT include any content in a >> notification that the user is not authorized to = view."; >>=20 >> *************** > =20 > This description statement has been updated. >=20 >=20 >> *** 791,801 **** >>=20 >> 6. Receiving Event Notifications >>=20 >> ! Encoding notifications for the HTTPS notifications is the same = as the >> encoding notifications as defined in RESTCONF [RFC8040] Section = 6.4, >> with the following changes. Instead of saying that for = JSON-encoding >> purposes, the module name for "notification" element will be = "ietf- >> ! restconf, it will say that for JSON-encoding purposes, the = module >> name for "notification" element will be "ietf-https-notif". >>=20 >> With those changes, the SSE event notification encoded JSON = example >> --- 791,801 ---- >>=20 >> 6. Receiving Event Notifications >>=20 >> ! Encoding notifications for the HTTPS notifications is the same = as for >> encoding notifications as defined in RESTCONF [RFC8040] Section = 6.4, >> with the following changes. Instead of saying that for = JSON-encoding >> purposes, the module name for "notification" element will be = "ietf- >> ! restconf", it will say that for JSON-encoding purposes, the = module >> name for "notification" element will be "ietf-https-notif". >>=20 >> With those changes, the SSE event notification encoded JSON = example >> *************** > =20 > This and all the following sections have been updated.=20 > =20 > Thanks. >=20 >=20 >> *** 815,826 **** >>=20 >> 7. IANA Considerations >>=20 >> ! This document registers two URI, two YANG module and two Media = Types. >>=20 >> 7.1. URI Registration >>=20 >> in the IETF XML registry [RFC3688]. Following the format in RFC >> ! 3688, the following registration is requested to be made: >>=20 >> URI: urn:ietf:params:xml:ns:yang:ietf-http-notif >> URI: urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list >> --- 815,826 ---- >>=20 >> 7. IANA Considerations >>=20 >> ! This document registers two URIs, two YANG modules, and two = Media Types. >>=20 >> 7.1. URI Registration >>=20 >> in the IETF XML registry [RFC3688]. Following the format in RFC >> ! 3688, the following registrations are requested to be made: >>=20 >> URI: urn:ietf:params:xml:ns:yang:ietf-http-notif >> URI: urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list >> *************** >> *** 854,860 **** >>=20 >> 7.3. Media Types >>=20 >> ! 7.3.1. Media Type "application/ietf-https-notif-cap+xml >>=20 >> Type name: application >>=20 >> --- 854,860 ---- >>=20 >> 7.3. Media Types >>=20 >> ! 7.3.1. Media Type "application/ietf-https-notif-cap+xml" >>=20 >> Type name: application >>=20 >> *************** >> *** 917,923 **** >>=20 >> Provisional registration? (standards tree only): no >>=20 >> ! 7.3.2. Media Type "application/ietf-https-notif-cap+json >>=20 >> Type name: application >>=20 >> --- 917,923 ---- >>=20 >> Provisional registration? (standards tree only): no >>=20 >> ! 7.3.2. Media Type "application/ietf-https-notif-cap+json" >>=20 >> Type name: application >>=20 >> *************** >> *** 1106,1112 **** >> >>=20 >> ! 8.2. Non Subscribed Notification based Configuration >>=20 >> In the case that it is desired to use HTTPS notif outside of >> Subscribed Notifications, there would have to be a module to = define >> --- 1106,1112 ---- >> >>=20 >> ! 8.2. Non-Subscribed Notification based Configuration >>=20 >> In the case that it is desired to use HTTPS notif outside of >> Subscribed Notifications, there would have to be a module to = define >>=20 >> Thanks, >> Acee >>=20 >>=20 >=20 > =20 > Mahesh Jethanandani > mjethanandani@gmail.com > =20 > =20 > =20 >=20 > =20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_C07B6F8E-8A25-4D1D-BEAC-56F9301FD96B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Acee,

See inline with [mj]

On Feb 10, 2021, at 11:03 AM, Acee Lindem (acee) <acee@cisco.com> = wrote:

Hi Mahesh, 
 
Thanks for the update. See = some inlines. 
 
From: Mahesh Jethanandani <mjethanandani@gmail.com>Date: Monday, February 8, = 2021 at 11:27 PM
To: Acee Lindem <acee@cisco.com>
Cc: YANG = Doctors <yang-doctors@ietf.org>, "draft-ietf-netconf-https-notif.all@ietf.org" <draft-ietf-netconf-https-notif.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: Yangdoctors last = call review of draft-ietf-netconf-https-notif-06
 
Hi Acee,
 
Thank you first of all for the review of the document. You = reviewed -06, and we have since submitted -07. I will in my responses = reflect the changes in -07 that might affect the comments you have = provided.


On Jan 27, 2021, at 9:01 AM, Acee = Lindem via Datatracker <noreply@ietf.org> wrote:
 
Reviewer: Acee Lindem
Review result: Almost Ready

The = document is almost ready for WG Last Call. I have the following = comments:

Model = ietf-sub-notif-recv-list:

   Seems odd to have a model that adds a = choice statement without any
   valid = options. I realize you expect other transports in the future but
   having a separate module the one defined in = the same draft seems like a
   profligate = design choice.
 
The = draft contains two models as you have noted. While the = ietf-sub-notif-recv-list adds a choice statement, the second model goes = on to adding a case statement for that choice statement. We could have = hard coded the two models together, but believe that by separating them, = we offer the flexibility to implementations that may choose not to = implement both the models. Also, other transports can augment = "receiver-instances", without including the entire http transport = model.
 
Well, right now, there is = only one choice for transport.
 
If it helps, we can add a comment to that effect in the model = to explain our motivation.
 
That would be good although I understood the = motivation. I guess this is one way to make it optional but currently = the only option is both models or neither. =  

[mj] True if you want to use https as the transport. = There is another WG draft, the UDP transport draft that will use the = ietf-sub-notif-recv-list module to add a case statement for udp = transport. If this draft proposes one model, the UDP transport would = have to import all the models https transport draft imports, just to = resolve all the dependencies.

Ideally,= this model should have been part of RFC 8639. But that train has = already left the station. We were surprised that no one suggested that = the model be spun into a draft of its own, although that draft would be = very small.

Thanks.




Model = ietf-sub-notif-recv-list:
   1. The prefix = "hn" seems inconsistent to lose the context. I'd use
       "snrlhn". =  This wouldn't be an issue if you combined the modules.
 
The = updated model in -07 now carries the prefix =E2=80=9Chnt=E2=80=9D.
 
That is an improvement but = since this augments a model with =E2=80=9Csnr=E2=80=9D as the prefix, it = seems that should be part of the prefix. If you didn=E2=80=99t have a = separate model, it wouldn=E2=80=99t be an issue. ;^) However, I=E2=80=99m = leave it to Tom (copied) for further debate. 


   2. This = comment is incomprehensible:

          &nb= sp;   // create the logical impossibility of enabling = "tcp"
          &nb= sp;   // transport
 
Would it help if we expanded the comment to say:
 
// The "http-client-stack-grouping=E2=80=9D= supports both HTTP and HTTPS stacks by default. This draft, however = supports HTTPS only. The following 
// if-feature statement makes it logically impossible to = configure HTTP transport.
 
Yes. 



In the IANA = section, the security considerations for the media types
point to this draft's security considerations. However, they = don't
include the referenced information. It seems these = IANA references
should point to other RFCs.
 
The = updated IANA section no longer carries the media-types.
 
That=E2=80=99s = better. 
 
Thanks,
Acee



It should = be noted that ietf-subscribed-notifications has a number of YANG
errors and warnings.

I also have = the following editorial comments:
Acee-Lindems-iMac-2:Desktop acee$ diff = -c
draft-ietf-netconf-https-notif-06.txt.orig
draft-ietf-netconf-https-notif-06.txt ***
draft-ietf-netconf-https-notif-06.txt.orig  2021-01-27 = 10:06:29.000000000 -0500
--- = draft-ietf-netconf-https-notif-06.txt =       2021-01-27 11:57:13.000000000
-0500
***************
*** 17,23 = ****
    This document defines a YANG = data module for configuring HTTPS based
    configured subscription, as defined = in RFC 8639.  The use of HTTPS
    maximizes transport-level = interoperability, while allowing for
! =    encoding selection from text, e.g.  XML or JSON, = to binary.

 Status of This Memo

--- 17,23 ----
    This document defines a YANG data = module for configuring HTTPS based
    configured subscription, as defined = in RFC 8639.  The use of HTTPS
    maximizes transport-level = interoperability, while allowing for
! =    encoding selection from text, e.g.,  XML or JSON, = to binary.
 
The = abstract section has been updated.



 Status = of This Memo

***************
*** 103,109 ****
    documents.  This document = defines two YANG 1.1 [RFC7950] data
    modules, one for augmenting the = Subscription to YANG Notifications
    [RFC8639] to add a transport type, = and another for configuring and
! =    managing HTTPS based receivers for the = notifications.

--- 103,109 ----
    documents.  This document = defines two YANG 1.1 [RFC7950] data
    modules, one for augmenting the = Subscription to YANG Notifications
    [RFC8639] to add a transport type, = and another for configuring and
! =    managing HTTPS-based receivers for the = notifications.
 
Fixed.



***************
*** 118,124 ****
    the same receiver instance.  The = second module describes how to
    enable the transmission of YANG = modeled notifications, in the
    configured encoding (i.e., XML, JSON) = over HTTPS.  Notifications are
! =    delivered in the form of a HTTPS POST.  The use = of HTTPS maximizes
    transport-level = interoperability, while the encoding selection pivots
    between implementation simplicity = (XML, JSON) and throughput (text
    versus binary).
--- = 118,124 ----
    the same receiver = instance.  The second module describes how to
    enable the transmission of YANG = modeled notifications, in the
    configured encoding (i.e., XML, JSON) = over HTTPS.  Notifications are
! =    delivered in the form of an HTTPS POST.  The use = of HTTPS maximizes
    transport-level = interoperability, while the encoding selection pivots
    between implementation simplicity = (XML, JSON) and throughput (text
    versus binary).
***************
 
Fixed.


*** 196,202 ****

    In the case of = "pipelining", the flow of messages would look
    something like this.  This = example shows the flow assuming that
! =    Subscribed Notifications is used and therefore a = <subscription-
    started> = notification is sent before sending the first notification.
    The example would be the same for = when Subscribed Notification is not
    used by removing the first POST = message for <susbscription-started>.
--- 196,202 = ----

    In the case of = "pipelining", the flow of messages would look
    something like this.  This = example shows the flow assuming that
! =    Subscribed Notification is used and therefore a = <subscription-
    started> = notification is sent before sending the first notification.
    The example would be the same for = when Subscribed Notification is not
    used by removing the first POST = message for <susbscription-started>.
***************
 
This= section has been rewritten.


*** 342,350 ****

 2.1.  Introduction

!    To learn the capabilities of the = receiver, the publisher can issue a
    HTTPS GET request with Accept-Type = set to application/ietf-https-
! =    notif-cap+xml or = application/ietf-https-notif-cap+json, with latter
    as the mandatory to implement, and = the default in case the type is
    not = specified.  If the receiver supports capabilities such as binary
    encoding of data, it can return that = as a capability in a response.
--- 342,350 ----

 2.1.  Introduction

!    To learn the capabilities of the = receiver, the publisher can issue an
    HTTPS GET request with Accept-Type = set to application/ietf-https-
! =    notif-cap+xml or = application/ietf-https-notif-cap+json, with the latter
    as the mandatory to implement, and = the default in case the type is
    not = specified.  If the receiver supports capabilities such as binary
    encoding of data, it can return that = as a capability in a response.
***************
 
Fixed.


*** 450,456 ****
 Internet-Draft =        HTTPS Configured Subscription =        November 2020

!      Copyright (c) 2018 IETF Trust = and the persons identified as
      the document authors. =  All rights reserved.
      Redistribution and use in = source and binary forms, with or
      without modification, is = permitted pursuant to, and subject
--- 450,456 ----
 Internet-Draft =        HTTPS Configured Subscription =        November 2020

!      Copyright (c) 2021 IETF Trust = and the persons identified as
      the document authors. =  All rights reserved.
      Redistribution and use in = source and binary forms, with or
      without modification, is = permitted pursuant to, and subject
***************
 
Fixed.


*** 536,545 ****

    This YANG module is a = definition of a set of receivers that are
    interested in the notifications = published by the publisher.  The
! =    module contains the TCP, TLS and HTTPS parameters that = are needed to
    communicate with the = receiver.  The module augments the ietf-sub-
    notif-recv-list module to define a = transport specific receiver.  As
! =    mentioned earlier, it uses POST method to deliver the = notification.
    The attribute 'path' = defines the path for the resource on the
    receiver, as defined by = 'path-absolute' in URI Generic Syntax
    [RFC3986].  The user-id used by = Network Configuration Access Control
--- 536,545 ----

    This YANG module is a = definition of a set of receivers that are
    interested in the notifications = published by the publisher.  The
! =    module contains the TCP, TLS, and HTTPS parameters = that are needed to
    communicate = with the receiver.  The module augments the ietf-sub-
    notif-recv-list module to define a = transport specific receiver.  As
! =    mentioned earlier, it uses the POST method to deliver = the notification.
    The attribute = 'path' defines the path for the resource on the
    receiver, as defined by = 'path-absolute' in URI Generic Syntax
    [RFC3986].  The user-id used by = Network Configuration Access Control
***************
 
This= section of the module has been rewritten.


*** 639,645 ****
      description
        "YANG module = for configuring HTTPS base configuration.

! =         Copyright (c) 2018 IETF = Trust and the persons identified as
         the = document authors.  All rights reserved.
         Redistrib= ution and use in source and binary forms, with or
         without = modification, is permitted pursuant to, and subject
--- = 639,645 ----
      description
        "YANG module = for configuring HTTPS base configuration.

! =         Copyright (c) 2021 IETF = Trust and the persons identified as
         the = document authors.  All rights reserved.
         Redistrib= ution and use in source and binary forms, with or
         without = modification, is permitted pursuant to, and subject
***************
 
Fixed.


*** 704,710 ****

          &nb= sp; container receiver-identity {
          &nb= sp;   description
! =             &n= bsp;  "Specifies mechanism for identifying the receiver.
          &nb= sp;      The publisher MUST NOT include = any content in a
          &nb= sp;      notification that the user is not = authorized to view.";

--- 704,710 ----

          &nb= sp; container receiver-identity {
          &nb= sp;   description
! =             &n= bsp;  "Specifies the mechanism for identifying the = receiver.
          &nb= sp;      The publisher MUST NOT include = any content in a
          &nb= sp;      notification that the user is not = authorized to view.";

***************
 
This= description statement has been updated.


*** 791,801 ****

 6.  Receiving Event = Notifications

!    Encoding = notifications for the HTTPS notifications is the same as the
    encoding notifications as defined in = RESTCONF [RFC8040] Section 6.4,
    with= the following changes.  Instead of saying that for = JSON-encoding
    purposes, the module = name for "notification" element will be "ietf-
! =    restconf, it will say that for JSON-encoding purposes, = the module
    name for "notification" = element will be "ietf-https-notif".

    With those changes, the SSE event = notification encoded JSON example
--- 791,801 ----

 6.  Receiving Event = Notifications

!    Encoding = notifications for the HTTPS notifications is the same as for
    encoding notifications as defined in = RESTCONF [RFC8040] Section 6.4,
    with= the following changes.  Instead of saying that for = JSON-encoding
    purposes, the module = name for "notification" element will be "ietf-
! =    restconf", it will say that for JSON-encoding = purposes, the module
    name for = "notification" element will be "ietf-https-notif".

    With those changes, the SSE event = notification encoded JSON example
***************
 
This= and all the following sections have been updated. 
 
Thanks.


*** 815,826 ****

 7.  IANA Considerations

!    This document registers = two URI, two YANG module and two Media Types.

 7.1.  URI Registration

    in the IETF XML registry [RFC3688]. =  Following the format in RFC
! =    3688, the following registration is requested to be = made:

    URI: = urn:ietf:params:xml:ns:yang:ietf-http-notif
    URI: = urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list
--- = 815,826 ----

 7.  IANA = Considerations

!    This = document registers two URIs, two YANG modules, and two Media Types.

 7.1.  URI Registration

    in the IETF XML = registry [RFC3688].  Following the format in RFC
! =    3688, the following registrations are requested to be = made:

    URI: = urn:ietf:params:xml:ns:yang:ietf-http-notif
    URI: = urn:ietf:params:xml:ns:yang:ietf-sub-notif-recv-list
***************
*** 854,860 ****

 7.3.  Media Types

! 7.3.1.  Media Type = "application/ietf-https-notif-cap+xml

 Type name: application

--- = 854,860 ----

 7.3.  Media = Types

! 7.3.1.  Media Type = "application/ietf-https-notif-cap+xml"

 Type name: application

***************
*** 917,923 ****

 Provisional registration? (standards = tree only): no

! 7.3.2.  Media Type = "application/ietf-https-notif-cap+json

 Type name: application

--- = 917,923 ----

 Provisional = registration? (standards tree only): no

! = 7.3.2.  Media Type "application/ietf-https-notif-cap+json"

 Type name: application

***************
*** 1106,1112 ****
 </config>

! 8.2. =  Non Subscribed Notification based Configuration

    In the case that it is desired to use = HTTPS notif outside of
    Subscribed = Notifications, there would have to be a module to define
---= 1106,1112 ----
 </config>

! 8.2.  Non-Subscribed Notification based = Configuration

    In = the case that it is desired to use HTTPS notif outside of
    Subscribed Notifications, there would = have to be a module to define

Thanks,
Acee

 
Mahesh Jethanandani
 
 

 

 

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_C07B6F8E-8A25-4D1D-BEAC-56F9301FD96B-- From nobody Tue Feb 16 14:25:38 2021 Return-Path: <01000177acf2de1b-e5e55c26-cdac-4282-904f-7e79c1fc18c0-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 778F43A11DC; Tue, 16 Feb 2021 14:25:36 -0800 (PST) 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 hYHWqov2zWQd; Tue, 16 Feb 2021 14:25:35 -0800 (PST) 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 F40623A11D9; Tue, 16 Feb 2021 14:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1613514333; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=yn5EDyt7wiJPzXQ+Xlz49A9KmSffR/akeKwbpUr39Ng=; b=G/B8NqSRvuU9adljr+4zJfPCN0H+O/QJ/mxevPRKMmznTsV+5ZeXVwpGpPEFbIRG JAm0XD8QnrvqI6CU8RnpK7vyJgrGABHqi1j/MJPDUYu/Ppnu3fl21cEJxlq0VmU2XLm qJpUde+SgmpJN+wPq1sPBfLNaXYVVJYHRv99CzL4= From: Kent Watsen Message-ID: <01000177acf2de1b-e5e55c26-cdac-4282-904f-7e79c1fc18c0-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_942D6E07-2CD3-4F6F-BDB2-C4DA755CD1F6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 16 Feb 2021 22:25:33 +0000 In-Reply-To: <2b62ca4e-5e8a-1ac1-6f38-70a0e61afe00@labn.net> Cc: "netconf-chairs@ietf.org" To: "netconf@ietf.org" References: <159373570027.29538.11387984048129033777@ietfa.amsl.com> <2b62ca4e-5e8a-1ac1-6f38-70a0e61afe00@labn.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.16-54.240.48.110 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] IETF 110 Slot Requests X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 22:25:37 -0000 --Apple-Mail=_942D6E07-2CD3-4F6F-BDB2-C4DA755CD1F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETCONF WG, According to the final agenda, NETCONF is scheduled to meet for 2-hours = on Monday, March 8th from 12:00-14:00 UTC. The link to the iCal invite = for the NETCONF session is here [2]. If you are interested in discussing one or more topics with the WG, = please send requests to the "netconf-chairs" alias (CC-ed) with the = following information, for each discussion, if more than one: - name of the drafts (if any) - name of discussion topic (usually the title of the draft) - name of the person(s) leading the discussion - desired time request (in minutes) Authors, per the 110 Important Dates page [3], the draft submission = cutoff is in one week, on Monday, March 22nd. Please be sure to update = your drafts before then. [1] https://datatracker.ietf.org/meeting/110/agenda [2] https://datatracker.ietf.org/meeting/110/sessions/netconf.ics [3] https://datatracker.ietf.org/meeting/110/important-dates Thank you ! Mahesh and Kent --Apple-Mail=_942D6E07-2CD3-4F6F-BDB2-C4DA755CD1F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
NETCONF WG,

According to the final agenda, NETCONF is = scheduled to meet for 2-hours on Monday, March 8th from 12:00-14:00 UTC.  The link to = the iCal invite for the NETCONF session is here [2].

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

- name of the drafts (if any)
- = name of discussion topic (usually the title of the draft)
- = name of the person(s) leading the discussion
- = desired time request (in minutes)

Authors, = per the 110 Important Dates page [3], the draft submission cutoff is in = one week, on Monday, March 22nd.  Please be sure to update your = drafts before then.

[1] = https://datatracker.ietf.org/meeting/110/agenda
[2] = https://datatracker.ietf.org/meeting/110/sessions/netconf.ics
[3] https://datatracker.ietf.org/meeting/110/important-dates

Thank you !
Mahesh = and Kent

= --Apple-Mail=_942D6E07-2CD3-4F6F-BDB2-C4DA755CD1F6-- From nobody Wed Feb 17 18:39:10 2021 Return-Path: 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 C0F203A1F13 for ; Wed, 17 Feb 2021 18:39:07 -0800 (PST) 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 qbacTm3xB3-p for ; Wed, 17 Feb 2021 18:39:04 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 B999F3A1ECB for ; Wed, 17 Feb 2021 18:39:04 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id o7so244948pgl.1 for ; Wed, 17 Feb 2021 18:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LHHR6gTfej93tkpT7eCLjaPF3JahTjZ+PIY88hfzxjY=; b=rdoYUxtLPi/bQYivRoKhKRBS1tqIv/Zxt/9n8DPXLrA9C8ov+SVZ4mUKQzwb8vsd+m Y4PXAsleXuvX5wlf8jeAUlkmPaa92WxmvWtsuNZDb/5u+a+pnsVyRDoWxt25yW/E2p/+ 305yBWJX1dYHmbngtZNJN5UZLjXj/9u3vxFnMID+PjOBFdYlGC3ZpbsMjk8VC6mKByrm Sk8rUfQ+A4YUhenwig4yfOcmA7cv1Z2ychlWTiVbvHvFVurUu5RoI5q0eAfdf/+yaO9L O/dTKYr6Suo1i1lgUVEHdLvEDTPKbhxhrfJfp4doApO1v0SusPAj3JdNYth69pq5rG0c z6HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LHHR6gTfej93tkpT7eCLjaPF3JahTjZ+PIY88hfzxjY=; b=lE0XbZfsESF1X4ODjpBqWJ92VQl7nZo2UCBkZjDmcPf3TJXmF0lowZPr9KSv32bJv1 r/apyp+kotZJvHCEk1LciaLx3IeSLvrODn73Kki5pSqTpxBHp0AUWRysC2Zp/e62I+QT 7um1pKBNOzZXvSJt2ubanQrRpPg+Rv99Lzv9Zn515qYnCmxS2pSykKHvM38Bts0JkYtM knlF0M4XIvUX9mWYzNhPD8exFnIZ/sw7vjcKYjr3VmMlQQ37K9KyA6OYZJ4afgnFjYyB METQARlslSFN9FiyF9RGGcM+TgKw0vggoeaiKHMM8VhFaLCRczeB2+n10fR0rORX11vd cFFA== X-Gm-Message-State: AOAM530U+t19JiWwKzftoWDZTP3gZf2YVBD46KB+iQz6bH7ZsgjFyeqc 1vFb8C+xs/wwFEJPUpN7aEg= X-Google-Smtp-Source: ABdhPJzYQ6Al6I2Z146VErCczUCFRdQdStcB/6gS/nv7h1QRLpNe03nmuJJ9wRzcfn8j5OCGdnyAtQ== X-Received: by 2002:a05:6a00:2b3:b029:1ec:adc7:645d with SMTP id q19-20020a056a0002b3b02901ecadc7645dmr2301149pfs.30.1613615943984; Wed, 17 Feb 2021 18:39:03 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:9559:eaee:bbd7:a39e? ([2601:647:5600:5020:9559:eaee:bbd7:a39e]) by smtp.gmail.com with ESMTPSA id x17sm3802349pfq.132.2021.02.17.18.39.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Feb 2021 18:39:03 -0800 (PST) From: Mahesh Jethanandani Message-Id: <57300FBC-8FDF-437A-87F5-B54579AFA687@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8B5D152C-9200-483E-AE86-BEC10368CF32" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 17 Feb 2021 18:39:01 -0800 In-Reply-To: <20210204.203944.1533922869570231478.id@4668.se> Cc: kent+ietf@watsen.net, netconf@ietf.org To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= , Jan Lindblad References: <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-000000@email.amazonses.com> <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com> <20210204.203944.1533922869570231478.id@4668.se> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 02:39:08 -0000 --Apple-Mail=_8B5D152C-9200-483E-AE86-BEC10368CF32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Martin/Jan, Thanks first of all for doing the review of the document.=20 See responses inline. > On Feb 4, 2021, at 11:39 AM, Martin Bj=C3=B6rklund = wrote: >=20 > Hi, >=20 > I have reviewed this document (-07), and I just have some minor > comments. The document is well written and easy to understand. >=20 >=20 > o Abstract >=20 > [...] It also presents an example > module for configuration without using the data model defined in RFC > 8639. >=20 > Is this such an important example that it should be mentioned in the > abstract? Does this mean that the NETCONF WG doesn't think that the > data model defined in RFC 8639 is useful anymore? Why is a > "simpler" module needed? Good point. Here is the current Abstract. This document defines a protocol for sending notifications over HTTPS. YANG modules for configuring publishers are also defined. Examples are provided illustrating how to configure various publishers. This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is a server. >=20 >=20 > o 3.1. Applicability >=20 > For publishers using Subscription to YANG Notifications [RFC8639], > dynamic discovery of a receiver's supported encoding is necessary > only when the "/subscriptions/subscription/encoding" leaf is not > configured, per the "encoding" leaf's description statement in the > "ietf-subscribed-notification" module. FIXME: do they need to > discover *any* capabilities? >=20 > Note that the "encoding" leaf has a when expression and is > present only if the chosen transport is derived from > sn:configurable-encoding. The "https" transport identity is not > derived from sn:configurable-encoding, so the "encoding" leaf will > never be present. Thanks for catching this. We have dropped the applicability section = because we choose that the =E2=80=9Cencoding=E2=80=9D leaf not be = defined, specifically because we think it is better for operators to = rely on dynamic discovery of capabilities over static configuration. In making some of these changes, we realize that we should put a must = statement around the augment statement for "transport-type=E2=80=9D that = gets evaluated only when the transport-type is https. Do you think you = could help us with that must statement? >=20 >=20 > 3.2. Request >=20 > To learn the capabilities of a receiver, a publisher can issue an > HTTPS GET request to the "capabilities" resource under a known path > on the receiver >=20 > I think you should mention what this "known path" is. After reading > the data model in detail I understand how it works, but it would be > good with an early explanation (the path is configured per > receiver). We have updated the first paragraph of Section 2 to say: The protocol consists of two HTTP-based target resources presented by the receiver. These two resources are sub-paths of a common resource that the publisher must know (e.g. specified in its configuration data model). >=20 >=20 > o 3.3 >=20 > leaf-list receiver-capability { > type string { > pattern "urn:ietf:capability:https-notif-receiver:*"; > } >=20 > What's the point of the "urn:..." prefix if it is required? It > would be simpler to just have the "*"-part in the registry. >=20 > But I think a better solution would be >=20 > leaf-list receiver-capability { > type inet:uri; > } >=20 > This would be more extensible. Another good point. Have updated the example accordingly.=20 Also added a statement saying that =E2=80=9CThe publisher MUST ignore = any capabilities that it does not recognize=E2=80=9D. >=20 >=20 > o 3.4. Example >=20 > The publisher can send the following request to learn the receiver > capabilities. In this example, the "Accept" states that the = receiver > wants to receive notifications in XML but, if not supported, to use > JSON encoding. >=20 > Copy&paste error? The "Accept" header states that the client wants > to get the capabilities as xml, json. Another good catch. Here is what the paragraph now looks like: The publisher can send the following request to learn the receiver capabilities. In this example, the "Accept" states that the receiver wants to receive the capabilities response in XML but, if not supported, then in JSON. >=20 >=20 > o 5.2 >=20 > file "ietf-subscribed-notif-receivers@2021-02-02.yang" > [note: '\' line wrapping for formatting only] >=20 > module ietf-subscribed-notif-receivers { >=20 > Remove the "note" line (no "\" is used, and this line should not be > part of the ). Hmm. I do not see the note or a =E2=80=9C\=E2=80=9D being added to the = line anymore. file "ietf-subscribed-notif-receivers@2021-02-17.yang" module ietf-subscribed-notif-receivers { >=20 > o 6.2 >=20 > As above, but also remove the "\" in the module; they are not > needed. Ditto. >=20 >=20 > o 6.2 >=20 > feature receiver-identity { > description > "Indicates if the server supports filtering notifications >=20 > s/if/that/ Fixed. >=20 >=20 >=20 > o Appendix >=20 > The examples would be easier to read if the "\"-line wrapping > convention was used only when absolutely needed. For example, this > doesn't look right: >=20 > my-password>=20 That line now shows up as follows. my-password >=20 > And this: >=20 > otifications"> >=20 > would be easier on the eye as: >=20 > xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"> Tried that, and now the =E2=80=9C\=E2=80=9D character appears as = follows. Thanks. >=20 >=20 >=20 >=20 >=20 > /martin >=20 >=20 >=20 >=20 > Kent Watsen wrote: >> NETCONF, >>=20 >> The just posted -07 addresses issues raised thus far. >> https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07 = >>=20 >> Henning, Eric, Reshad, >>=20 >> Please re-review as your comments are important to us. >>=20 >> Everyone else, >>=20 >> The hasn=E2=80=99t been many reviews as yet. Please review this >> version, as it is significantly better (ready for publication?) >> than the prevision version. >>=20 >> K. >>=20 >>=20 >>=20 >>> On Feb 1, 2021, at 11:33 AM, Reshad Rahman wrote: >>>=20 >>> Good with me. >>>=20 >>> Regards, >>> Reshad. >>>=20 >>> From: Kent Watsen >>> Date: Sunday, January 31, 2021 at 7:54 AM >>> To: Reshad Rahman >>> Cc: "netconf@ietf.org" , = "draft-ietf-netconf-https-notif@ietf.org" = >>> Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 >>>=20 >>>=20 >>>> I've reviewed this document and I think the document will be ready = once the changes planned by the authors (regarding = notification-messages) are made. >>>=20 >>> Thanks, but a couple more problems: >>>=20 >>> 1) the URLs are bad. Specifically, the example in the =E2=80=9CLearni= ng Receiver Capabilities=E2=80=9D section uses a nonsensical URL = (=E2=80=98/=E2=80=98). The authors propose to instead use a = sub-resource to the user-configured =E2=80=9Cpath=E2=80=9D (e.g., GET = /some/path/capabilities) and move the POST URL to another sub-resource = (e.g., /some/path/relay-notification). [see below for more on this] >>>=20 >>> 2) the media-types are bad: =E2=80=9Capplication/yang-data+[xml/json]=E2= =80=9D is used for notifications, which is wrong since they are not = YANG-defined, and the custom media-types for capabilities = (application/ietf-https-notif-cap+[xml/json]) is a way overkill. The = authors propose to use =E2=80=9Capplication/[xml/json]=E2=80=9D for both = cases. >>>=20 >>>=20 >>>=20 >>>> I have a question on the following YANG description. Section 4.1 = mentions 'path-absolute' for the URI but the description below says = "Relative URI...". Should this description be clarified/corrected or am = I missing something? >>>>=20 >>>> augment "transport/tls/tls/http-client-parameters" { >>>> leaf path { >>>> type string; >>>> description >>>> "Relative URI to the target resource."; >>>> } >>>> description >>>> "Augmentation to add a path to the target = resource."; >>>> } >>>=20 >>> Agreed. How about this? >>>=20 >>> leaf path { >>> type string; >>> mandatory true; >>> description >>> "URI prefix to the target resources. Under this >>> path the receiver must support both the 'capabilities' >>> and 'relay-notification' resource targets, as described >>> in RFC XXXX."; >>> } >>>=20 >>> So, if path=3D=3D=E2=80=9C/som/path=E2=80=9D, capability-discovery = would be to "/some/path/capabilities=E2=80=9D and notifications would be = sent to =E2=80=9C/some/path/relay-notification=E2=80=9D. >>>=20 >>> Thoughts? >>>=20 >>>=20 >>>> Formatting nit: >>>> Trust anchors (i.e. CA certs) that are used to = authenticat\ >>>> e >>>=20 >>> Fixed, but the other example cannot be fixed because the =E2=80=9Cxmln= s=E2=80=9D strings alone are too long, and XML doesn=E2=80=99t = internally support folding, and the =E2=80=9Cstring=E2=80=9D type = doesn=E2=80=99t allows for whitespace (include =E2=80=98\n=E2=80=99) = both at the beginning and end of strings (recall my request for = rfc6991-bis to define a =E2=80=9Ctoken=E2=80=9D type that would enable = the parser to discard any found, so our examples could more often be = manually-folded). >>>=20 >>> K. >>=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_8B5D152C-9200-483E-AE86-BEC10368CF32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Martin/Jan,

Thanks = first of all for doing the review of the document. 

See responses inline.

On Feb 4, 2021, at 11:39 AM, Martin Bj=C3=B6rklund <mbj+ietf@4668.se> = wrote:

Hi,

I have reviewed this = document (-07), and I just have some minor
comments. =  The document is well written and easy to understand.


o  Abstract

  [...] It also presents an = example
  module for configuration without = using the data model defined in RFC
  8639.

 Is this such an important example that = it should be mentioned in the
 abstract?  Does = this mean that the NETCONF WG doesn't think that the
=  data model defined in RFC 8639 is useful anymore?  Why is = a
 "simpler" module needed?

Good = point. Here is the current Abstract.

   This document defines a protocol = for sending notifications over
   HTTPS.  YANG = modules for configuring publishers are also defined.
  =  Examples are provided illustrating how to configure = various
   publishers.

   This document requires that the = publisher is a "server" (e.g., a
   NETCONF or = RESTCONF server), but does not assume that the receiver = is
   a server.



o  3.1. =  Applicability

  For = publishers using Subscription to YANG Notifications [RFC8639],
  dynamic discovery of a receiver's supported = encoding is necessary
  only when the = "/subscriptions/subscription/encoding" leaf is not
=   configured, per the "encoding" leaf's description statement = in the
  "ietf-subscribed-notification" module. =  FIXME: do they need to
  discover *any* = capabilities?

 Note that the = "encoding" leaf has a when expression and is
=  present only if the chosen transport is derived from
=  sn:configurable-encoding.  The "https" transport identity is = not
 derived from sn:configurable-encoding, so the = "encoding" leaf will
 never be present.

Thanks for = catching this. We have dropped the applicability section because we = choose that the =E2=80=9Cencoding=E2=80=9D leaf not be defined, = specifically because we think it is better for operators to rely on = dynamic discovery of capabilities over static = configuration.

In making some of = these changes, we realize that we should put a must statement around the = augment statement for "transport-type=E2=80=9D that gets evaluated only = when the transport-type is https. Do you think you could help us with = that must statement?



3.2.  Request

=   To learn the capabilities of a receiver, a publisher can = issue an
  HTTPS GET request to the = "capabilities" resource under a known path
  on = the receiver

 I think you should = mention what this "known path" is.  After reading
=  the data model in detail I understand how it works, but it would = be
 good with an early explanation (the path is = configured per
 receiver).

We have = updated the first paragraph of Section 2 to say:

   The protocol consists of two = HTTP-based target resources presented by
   the = receiver.  These two resources are sub-paths of a common = resource
   that the publisher must know (e.g. = specified in its configuration
   data = model).




o  3.3

    leaf-list receiver-capability {
      type string {
        pattern = "urn:ietf:capability:https-notif-receiver:*";
=       }

=  What's the point of the "urn:..." prefix if it is required? =  It
 would be simpler to just have the "*"-part = in the registry.

 But I think a = better solution would be

=     leaf-list receiver-capability {
=       type inet:uri;
=     }

 This would = be more extensible.

Another good point. Have updated the example = accordingly. 

Also added a = statement saying that =E2=80=9CThe publisher MUST ignore any = capabilities that it does not recognize=E2=80=9D.



o  3.4.  Example

  The publisher can send the = following request to learn the receiver
=   capabilities.  In this example, the "Accept" states = that the receiver
  wants to receive = notifications in XML but, if not supported, to use
=   JSON encoding.

=  Copy&paste error?  The "Accept" header states that the = client wants
 to get the capabilities as xml, = json.

Another good catch. Here is what the paragraph now = looks like:

   The = publisher can send the following request to learn the = receiver
   capabilities.  In this example, the = "Accept" states that the receiver
   wants to = receive the capabilities response in XML but, if not
  =  supported, then in JSON.



o  5.2

=   <CODE BEGINS> file "ietf-subscribed-notif-receivers@2021-02-02.yang"
  [note: '\' line wrapping for formatting only]

  module = ietf-subscribed-notif-receivers {

=  Remove the "note" line (no "\" is used, and this line should not = be
 part of the <CODE BEGINS>).

Hmm. I do = not see the note or a =E2=80=9C\=E2=80=9D being added to the line = anymore.

=
   module ietf-subscribed-notif-receivers {



o  6.2

=  As above, but also remove the  "\" in the module; they are = not
 needed.

Ditto.



o 6.2

 feature = receiver-identity {
   description
     "Indicates if the server = supports filtering notifications

=  s/if/that/

Fixed.




o  Appendix

=  The examples would be easier to read if the "\"-line wrapping
 convention was used only when absolutely needed. =  For example, this
 doesn't look right:

=             &n= bsp;    <cleartext-password>my-password</clea= rtext-password\


That line now shows up as follows.

            =         =  <cleartext-password>my-password</cleartext-passwor\
   d>


 And this:

=  <subscriptions = xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-n\
otifications">

 would = be easier on the eye as:

=  <subscriptions
=    xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-not= ifications">

Tried that, and now the =E2=80=9C\=E2=80=9D character = appears as follows.

  =    <subscriptions
        =  xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio\
   ns=E2=80=9D>

Thanks.






/martin




Kent Watsen <kent+ietf@watsen.net> wrote:
NETCONF,

=      The just posted -07 addresses issues = raised thus far.
     https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07 <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07>

Henning, Eric, Reshad,

     Please = re-review as your comments are important to us.

Everyone else,

=      The hasn=E2=80=99t been many reviews as = yet.  Please review this
=      version, as it is significantly better = (ready for publication?)
=      than the prevision version.

K.



On Feb 1, = 2021, at 11:33 AM, Reshad Rahman <reshad@yahoo.com> wrote:

Good with me.

Regards,
Reshad.

From: Kent Watsen <kent+ietf@watsen.net>
Date: Sunday, = January 31, 2021 at 7:54 AM
To: Reshad Rahman <reshad@yahoo.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-https-notif@ietf.org" <draft-ietf-netconf-https-notif@ietf.org>
Subject: Re: [netconf] WGLC: = draft-ietf-netconf-https-notif-06


I've reviewed this = document and I think the document will be ready once the changes planned = by the authors (regarding notification-messages) are made.

Thanks, but a couple more = problems:

1) the URLs are bad. =  Specifically, the example in the =E2=80=9CLearning Receiver = Capabilities=E2=80=9D section uses a nonsensical URL (=E2=80=98/=E2=80=98)= .   The authors propose to instead use a sub-resource to the = user-configured =E2=80=9Cpath=E2=80=9D (e.g., GET = /some/path/capabilities) and move the POST URL to another sub-resource = (e.g., /some/path/relay-notification).  [see below for more on = this]

2) the media-types are bad: = =E2=80=9Capplication/yang-data+[xml/json]=E2=80=9D is used for = notifications, which is wrong since they are not YANG-defined, and the = custom media-types for capabilities = (application/ietf-https-notif-cap+[xml/json]) is a way overkill. =  The authors propose to use =E2=80=9Capplication/[xml/json]=E2=80=9D = for both cases.



I have a question on the = following YANG description. Section 4.1 mentions 'path-absolute' for the = URI but the description below says "Relative URI...". Should this = description be clarified/corrected or am I missing something?

=            augment = "transport/tls/tls/http-client-parameters" {
=             &n= bsp;leaf path {
=             &n= bsp;  type string;
=             &n= bsp;  description
=             &n= bsp;    "Relative URI to the target resource.";
=             &n= bsp;}
=             &n= bsp;description
=             &n= bsp;  "Augmentation to add a path to the target resource.";
=            }

Agreed.  How about this?

=        leaf path {
=          type string;
=          mandatory true;
=          description
=            "URI = prefix to the target resources.  Under this
=             pa= th the receiver must support both the 'capabilities'
=             an= d 'relay-notification' resource targets, as described
=             in= RFC XXXX.";
=        }

So, if path=3D=3D=E2=80=9C/som/path=E2=80=9D, = capability-discovery would be to "/some/path/capabilities=E2=80=9D and = notifications would be sent to =E2=80=9C/some/path/relay-notification=E2=80= =9D.

Thoughts?


Formatting = nit:
=           Trust = anchors (i.e. CA certs) that are used to authenticat\
= e

Fixed, but the other example = cannot be fixed because the =E2=80=9Cxmlns=E2=80=9D strings alone are = too long, and XML doesn=E2=80=99t internally support folding, and the = =E2=80=9Cstring=E2=80=9D type doesn=E2=80=99t allows for whitespace = (include =E2=80=98\n=E2=80=99) both at the beginning and end of strings = (recall my request for rfc6991-bis to define a =E2=80=9Ctoken=E2=80=9D = type that would enable the parser to discard any found, so our examples = could more often be manually-folded).

K.

_______________________________________________netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_8B5D152C-9200-483E-AE86-BEC10368CF32-- From nobody Thu Feb 18 14:17:33 2021 Return-Path: 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 ACB433A191B for ; Thu, 18 Feb 2021 14:17:31 -0800 (PST) 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 RPU5xAhKR6E3 for ; Thu, 18 Feb 2021 14:17:29 -0800 (PST) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 90E963A1919 for ; Thu, 18 Feb 2021 14:17:29 -0800 (PST) Received: by mail-pj1-x1035.google.com with SMTP id gx20so2557531pjb.1 for ; Thu, 18 Feb 2021 14:17:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NFXhSntL5RYN1kx4nBwv+m60EFtwpeu5UTFboi3McPU=; b=Gq9+sm8Kl1Fnnb868RKRw7Z4D4QyuUzL1+7ho6nYZHybr6VQS/ZUiRbMFH/5aqPF3z kC7x/KvmD6dUTMqK6HEAdQNHPiGcX3anPdRtfaWODjGACl05qKMXHRDFzYnoWy9SM1Hx O8c1USWFRr9zI6vLE9g2EGWHf4xnvJKKyxEhei0o/ycFHmYqTdoccF1R/o7VxXPYRQWO RSDXM3sab7nbyP8I95pdndg0At+7llu6p+7JpjhBQ15l1vxIFWPXXmUZR7MNTy2/LkJb Tq+8h/1qit2IYSndNXO6tt/SiwN/zpR08JIgN82xTHSAnRhlNO/MU6wCqoBRlP8gk26I z9SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NFXhSntL5RYN1kx4nBwv+m60EFtwpeu5UTFboi3McPU=; b=LmiiNIldV2Yh3BLpWXrucz60mjv6j3c+WDxco97n0+iRcqCYOOVFiUBrVYB5tV/e3P 9xmK5K5LPhLCBKX20DC+CwPWbTKDvQJ2v9VxpbZcPqq8gB0qj5FGBvbX2girkrZRjgbp 9OYdQ8yPYvaIGQnqDTV0sjkezR4ksaYzQ+edyn+sW7VHZtCzUvJqZGTGYSkSTb0MC4sr uG0HTIgvwciqYUN3F6s4ZANbdtRCCsjTQ5pKU8d1rug72TVo2dNxcmWrFU2u0wPfmu+9 NaRj9CgfmC3n2NvfZ1TJZsK9FN2jKR+xwYrhrKPNr1Jdy8k4FvpQzeuwfyy4/WrV6eDu nGTQ== X-Gm-Message-State: AOAM530WeMBgsYfliZnAy247HzpM7WgTVS3apBg1St0bHVQjXTX2nVsJ 1NY5SxGQJpeNBGqREQEHvXk= X-Google-Smtp-Source: ABdhPJxhSCTQkZBqrwcID1PGa33NBhSkYR6Q5H1kLnuzmU1tPGbDPEZez9ANgzaqjmE9oI7Wx2gwWA== X-Received: by 2002:a17:90a:d998:: with SMTP id d24mr5882402pjv.169.1613686649128; Thu, 18 Feb 2021 14:17:29 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:9559:eaee:bbd7:a39e? ([2601:647:5600:5020:9559:eaee:bbd7:a39e]) by smtp.gmail.com with ESMTPSA id j34sm6600015pgi.62.2021.02.18.14.17.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Feb 2021 14:17:28 -0800 (PST) From: Mahesh Jethanandani Message-Id: <6BAA2A61-9E30-43F2-9F94-8D4FCB258009@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6E9140A7-C401-410A-8C6C-4BB0B8B02E2F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Feb 2021 14:17:27 -0800 In-Reply-To: Cc: Kent Watsen , "netconf@ietf.org" To: "maqiufang (A)" References: <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6.ref@yahoo.com> <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6@yahoo.com> <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-000000@email.amazonses.com> <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 22:17:32 -0000 --Apple-Mail=_6E9140A7-C401-410A-8C6C-4BB0B8B02E2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ma, See inline with [mj] > On Feb 3, 2021, at 11:28 PM, maqiufang (A) = wrote: >=20 > Hi, Kent: > =20 > I have read the latest version and find it more flexible. > Here comes a few suggestions: > 1=E3=80=81 You have got a wrong link at the end of section 1.1. It = supposed to be Appendix A.2, rather than Section 8.2. [mj] Corrected. > 2=E3=80=81 It seems that you are mix-using HTTP and HTTPS somewhere, = for example, "The protocol consists of two HTTP-based target resources = presented by the receiver"(Should be =E2=80=9CHTTPS-based=E2=80=9D, I = think). [mj] Fixed. > 3=E3=80=81 Section 3.3/4.2: Will the receiver return a HTTP 200/204 = definitely? Should we consider some other extreme situations( e.g., not = supported/implemented) ? Just my individual opinion.:) [mj] There is an e-mail from Andy that gets into this topic. Allow us to = address your question when we respond to that e-mail. > 4=E3=80=81 Section 4.3: You should replace = "fault" with "fault". [mj] Fixed. Thanks. > =20 > Qiufang Ma > =20 > From: netconf [mailto:netconf-bounces@ietf.org = ] On Behalf Of Kent Watsen > Sent: Wednesday, February 3, 2021 6:34 AM > To: netconf@ietf.org > Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 > =20 > NETCONF, > =20 > The just posted -07 addresses issues raised thus far. > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07 = > =20 > Henning, Eric, Reshad, >=20 >=20 > Please re-review as your comments are important to us. > =20 > Everyone else, > =20 > The hasn=E2=80=99t been many reviews as yet. Please review this > version, as it is significantly better (ready for publication?) > than the prevision version. > =20 > K. > =20 > =20 >=20 >=20 > On Feb 1, 2021, at 11:33 AM, Reshad Rahman > wrote: > =20 > Good with me. > =20 > Regards, > Reshad. > =20 > From: Kent Watsen > > Date: Sunday, January 31, 2021 at 7:54 AM > To: Reshad Rahman > > Cc: "netconf@ietf.org " >, "draft-ietf-netconf-https-notif@ietf.org = " = > > Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 > =20 > =20 > I've reviewed this document and I think the document will be ready = once the changes planned by the authors (regarding = notification-messages) are made. > =20 > Thanks, but a couple more problems: > =20 > 1) the URLs are bad. Specifically, the example in the =E2=80=9CLearning= Receiver Capabilities=E2=80=9D section uses a nonsensical URL = (=E2=80=98/=E2=80=98). The authors propose to instead use a = sub-resource to the user-configured =E2=80=9Cpath=E2=80=9D (e.g., GET = /some/path/capabilities) and move the POST URL to another sub-resource = (e.g., /some/path/relay-notification). [see below for more on this] > =20 > 2) the media-types are bad: =E2=80=9Capplication/yang-data+[xml/json]=E2= =80=9D is used for notifications, which is wrong since they are not = YANG-defined, and the custom media-types for capabilities = (application/ietf-https-notif-cap+[xml/json]) is a way overkill. The = authors propose to use =E2=80=9Capplication/[xml/json]=E2=80=9D for both = cases. > =20 >=20 >=20 >=20 > I have a question on the following YANG description. Section 4.1 = mentions 'path-absolute' for the URI but the description below says = "Relative URI...". Should this description be clarified/corrected or am = I missing something? >=20 > augment "transport/tls/tls/http-client-parameters" { > leaf path { > type string; > description > "Relative URI to the target resource."; > } > description > "Augmentation to add a path to the target resource."; > } > =20 > Agreed. How about this? > =20 > leaf path { > type string; > mandatory true; > description > "URI prefix to the target resources. Under this > path the receiver must support both the 'capabilities' > and 'relay-notification' resource targets, as described > in RFC XXXX."; > } >=20 > So, if path=3D=3D=E2=80=9C/som/path=E2=80=9D, capability-discovery = would be to "/some/path/capabilities=E2=80=9D and notifications would be = sent to =E2=80=9C/some/path/relay-notification=E2=80=9D. > =20 > Thoughts? > =20 > =20 > Formatting nit: > Trust anchors (i.e. CA certs) that are used to authenticat\ > e > =20 > Fixed, but the other example cannot be fixed because the =E2=80=9Cxmlns=E2= =80=9D strings alone are too long, and XML doesn=E2=80=99t internally = support folding, and the =E2=80=9Cstring=E2=80=9D type doesn=E2=80=99t = allows for whitespace (include =E2=80=98\n=E2=80=99) both at the = beginning and end of strings (recall my request for rfc6991-bis to = define a =E2=80=9Ctoken=E2=80=9D type that would enable the parser to = discard any found, so our examples could more often be manually-folded). > =20 > K. > =20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = Mahesh & Kent {as co-authors) --Apple-Mail=_6E9140A7-C401-410A-8C6C-4BB0B8B02E2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ma,

See inline with = [mj]

On Feb 3, 2021, at 11:28 PM, maqiufang (A) = <maqiufang1@huawei.com> wrote:

Hi, Kent:
 
I have read the latest = version and find it more flexible.
Here comes a few suggestions:
1=E3=80=81 You have got a wrong link at the end of = section 1.1. It supposed to be Appendix A.2, rather than Section = 8.2.

[mj] = Corrected.

2=E3=80=81 It seems that you are mix-using HTTP and = HTTPS somewhere, for example,  "The protocol consists of two = HTTP-based target resources presented by the receiver"(Should be = =E2=80=9CHTTPS-based=E2=80=9D, I = think).

[mj] Fixed.

3=E3=80=81 Section 3.3/4.2: Will the receiver return = a HTTP 200/204 definitely? Should we consider some other extreme = situations( e.g., not supported/implemented) ? Just my individual = opinion.:)

[mj] There is an e-mail from Andy that gets into this = topic. Allow us to address your question when we respond to that = e-mail.

4=E3=80=81 Section 4.3: You should replace = "<event-class>fault</fault>" with = "<event-class>fault</event-class>".

[mj] Fixed.

Thanks.

 
Qiufang Ma
 
From: netconf [mailto:netconf-bounces@ietf.org] On Behalf = Of Kent Watsen
Sent: Wednesday, February 3, 2021 = 6:34 AM
To: netconf@ietf.org
Subject: Re: [netconf] WGLC: = draft-ietf-netconf-https-notif-06
 
NETCONF,
 
      The just posted -07 = addresses issues raised thus far.
  =     https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07
 
Henning, = Eric, Reshad,


      Please re-review as your = comments are important to us.
 
Everyone else,
 
  =     The hasn=E2=80=99t been many reviews as yet.  Please = review this
      = version, as it is significantly better (ready for publication?)
      than the prevision version.
 
 
 


On Feb 1, 2021, at 11:33 AM, Reshad = Rahman <reshad@yahoo.com> = wrote:
 
Good with me.
 
Regards,
Reshad.
 
From: Kent Watsen = <kent+ietf@watsen.net>
Date: Sunday, January 31, = 2021 at 7:54 AM
To: Reshad Rahman <reshad@yahoo.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-https-notif@ietf.org" <draft-ietf-netconf-https-notif@ietf.org>
Subject: Re: [netconf] WGLC: = draft-ietf-netconf-https-notif-06
 
 
I've reviewed this document and I think the = document will be ready once the changes planned by the authors = (regarding notification-messages) are made.
 
Thanks, but a couple more problems:
 
1) the URLs are bad.  Specifically, the = example in the =E2=80=9CLearning Receiver Capabilities=E2=80=9D section = uses a nonsensical URL (=E2=80=98/=E2=80=98).   The authors propose = to instead use a sub-resource to the user-configured =E2=80=9Cpath=E2=80=9D= (e.g., GET /some/path/capabilities) and move the POST URL to another = sub-resource (e.g., /some/path/relay-notification).  [see below for = more on this]
 
2)= the media-types are bad: =E2=80=9Capplication/yang-data+[xml/json]=E2=80=9D= is used for notifications, which is wrong since they are not = YANG-defined, and the custom media-types for capabilities = (application/ietf-https-notif-cap+[xml/json]) is a way overkill. =  The authors propose to use =E2=80=9Capplication/[xml/json]= =E2=80=9D for both cases.
 



I = have a question on the following YANG description. Section 4.1 mentions = 'path-absolute' for the URI but the description below says "Relative = URI...". Should this description be clarified/corrected or am I missing = something?

          &nb= sp; augment "transport/tls/tls/http-client-parameters" {
          &nb= sp;   leaf path {
          &nb= sp;     type string;
          &nb= sp;     description
          &nb= sp;       "Relative URI to the target = resource.";
          &nb= sp;   }
          &nb= sp;   description
          &nb= sp;     "Augmentation to add a path to the = target resource.";
          &nb= sp; }
 
Agreed.  How about this?
 

        leaf path {
          type string;
        =   mandatory true;
      =     description
        =     "URI prefix to the target = resources.  Under this
      =        path the receiver must support both = the 'capabilities'
          =    and 'relay-notification' resource targets, = as described
          =    in RFC XXXX.";
      =   }

So, if path=3D=3D=E2=80=9C/som/path=E2=80=9D, = capability-discovery would be to "/some/path/capabilities=E2=80=9D and = notifications would be sent = to =E2=80=9C/some/path/relay-notification=E2=80=9D.
 
Thoughts?
 
 
Formatting nit:
          &nb= sp;Trust anchors (i.e. CA certs) that are used to authenticat\
 e
 
Fixed, but the other example cannot be fixed because the = =E2=80=9Cxmlns=E2=80=9D strings alone are too long, and XML doesn=E2=80=99= t internally support folding, and the =E2=80=9Cstring=E2=80=9D type = doesn=E2=80=99t allows for whitespace (include =E2=80=98\n=E2=80=99) = both at the beginning and end of strings (recall my request for = rfc6991-bis to define a =E2=80=9Ctoken=E2=80=9D type that would enable = the parser to discard any found, so our examples could more often be = manually-folded).
 
K.
 
_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
Mahesh & Kent {as co-authors)





= --Apple-Mail=_6E9140A7-C401-410A-8C6C-4BB0B8B02E2F-- From nobody Thu Feb 18 14:28:51 2021 Return-Path: <01000177b7428848-f48b34d9-2240-4916-9a62-2be1f06bb7df-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 775A53A1939; Thu, 18 Feb 2021 14:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 EMdHa73jotOF; Thu, 18 Feb 2021 14:28:48 -0800 (PST) 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 353BE3A1935; Thu, 18 Feb 2021 14:28:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1613687327; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=IzHYCw+ZXqPh9LZwJM7KaAwFakdAET5+S/2OmIcDWCo=; b=cfq/W8aad8z84o9Px6XEO+dNl21eFhqS9ghPQxTg1PFrk8wFqqfdmbUhma/OU4Me 9OKqj3eUn7YXUr1vrZFSFM00YCMmAGc54Sp+WG5oZCCw7vUFri0UyrehuiMn3A1w4DW LfA8ekygkiKh6hwr82SkAdHDMW5B9si/a8nrSzdc= 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 In-Reply-To: Date: Thu, 18 Feb 2021 22:28:46 +0000 Cc: "draft-ietf-netconf-https-notif@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000177b7428848-f48b34d9-2240-4916-9a62-2be1f06bb7df-000000@email.amazonses.com> References: To: "Eric Voit (evoit)" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.18-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 22:28:50 -0000 Hi Eric, > The majority of examples showing have been = removed. > The last place where they are discussed in -07 is the end of Section = 2. I > still feel that describing the coverage or non-coverage of the set of > subscription state change notifications within a stream of event = provides a > useful context. We=E2=80=99re unclear why this document should need or want to repeat = what is defined in another RFC. This document regards how to send = notifications, regardless where they are defined. As you note, Section 2 currently has the following statement: Note that, for RFC 8639 configured subscriptions, the very first notification must be the "subscription-started" notification. Perhaps we should remove this sentence too, or replace =E2=80=9Cmust=E2=80= =9D with =E2=80=9Cwould=E2=80=9D, so it doesn=E2=80=99t should = normative? Please advise. Thanks, Kent and Mahesh From nobody Thu Feb 18 14:48:42 2021 Return-Path: <01000177b754b3b3-87cb5eda-8f8b-4a27-be56-5dcc52a1e5c3-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 544493A197D; Thu, 18 Feb 2021 14:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H5=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 fbs8na5LCi4j; Thu, 18 Feb 2021 14:48:39 -0800 (PST) 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 DA4DC3A197B; Thu, 18 Feb 2021 14:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1613688517; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=TOckr77/fdvn+StNOKSyrch9iwPdvdsVTlkBubcBd3I=; b=fcc/Ti8hNo0reWVmVpiKXX+9fBBzEsWguPBXmQCShk3mU+xK6LtiP82KKoJFPz/v BaT4vZYBaO2biFCVk8cTvAvgcmE4L7dp/tQP4cLYeaKiN1+XX+U88eOCFLzbnVa7+/t KRzU+QPihacFJA7cLCQhmhW2NsSeiemXUrNUMMos= 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 In-Reply-To: Date: Thu, 18 Feb 2021 22:48:37 +0000 Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" , "draft-ietf-netconf-https-notif@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000177b754b3b3-87cb5eda-8f8b-4a27-be56-5dcc52a1e5c3-000000@email.amazonses.com> References: To: Andy Bierman X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.18-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 22:48:40 -0000 Hi Andy, > It seems too much of the language is limited to XML or JSON encoding. > The media type extensibility should be well-defined so this draft > does not have unintended limitations later on. We believe the defines an extensibility mechanism via the = =E2=80=9Ccapabilities=E2=80=9D resource target, which we recently = modified in our local copy in response to Martin=E2=80=99s comment = enabling the capabilities to use any URI. Please advise. > There is a significant architectural change made without any real = mention (sec. 4) > In NETCONF and RESTCONF, a notification is a one-way message, meaning = there > is no application layer response whatsoever. >=20 > That is not the case here. Instead, the publisher sends an HTTPS POST = for every notification > and expects a "204 No Content" response for each one. > The draft should explain the reasons for this change. > HTTP client implementations tend to wait for a response to a POST. > That is probably not what is intended here, but no text explains the = details. >=20 > Sec. 4 does not mention what the publisher is supposed to do if the = receiver does not > send a response or sends something other than 204. It seems like this = redundant ACK > adds complexity and network traffic for no benefit. It is agreed that notifications have historically not entailed having = any response from the receiver. However, the HTTP protocol defines that = there be a response, and since there is no content for a receiver to = return, we suppose it to be 204 (No Content). That said, please note that HTTP is a sessionless/stateless protocol and = authentication MAY be conveyed via HTTP headers, which might necessitate = a 401 (No Authentication) response. There may be other possible reasons = to return other values too (though we don=E2=80=99t have any examples to = share). To be clear, by no means are we suggesting that YANG =E2=80=9Cnotification= =E2=80=9D statements introduce application-level responses. It is unclear how HTTP responses cannot be returned; the only options = seem to be for the draft to explicitly enumerate all possible responses, = or leave it open. Thoughts on what text should added? Kent and Mahesh From nobody Thu Feb 18 15:11:44 2021 Return-Path: <01000177b769897b-d7be7bfc-fdd3-43e3-b5f4-3bc0fb262018-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 B09113A1A7A for ; Thu, 18 Feb 2021 15:11:37 -0800 (PST) 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 rQmYQHf8ueGP for ; Thu, 18 Feb 2021 15:11:36 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520DA3A19A8 for ; Thu, 18 Feb 2021 15:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1613689883; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=/dZ0Y8/bj7TTNSsnwTOXK3H3H7HvTZ4O+Dw9Nfh3TD0=; b=hbrCgeCkS88Umrw2hsrVA90TzDKR0JdQXi6DhAxrV+riYtfd6W7zYz9k72PMhhtG 1jRfDMIkAHTZegu/EwuHPZGvPPvj6Oo1Rr8Yz1AE6fwUToX9E2VRzmUYd3BTRVQKc9I WcqFf5aK7ujoYK2iY+CjC/BWVZTPx1jCrQ710V+A= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_DD28328E-8B9C-400E-9C35-598A21C12974" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 18 Feb 2021 23:11:23 +0000 References: <159373570027.29538.11387984048129033777@ietfa.amsl.com> <2b62ca4e-5e8a-1ac1-6f38-70a0e61afe00@labn.net> <01000177acf2de1b-e5e55c26-cdac-4282-904f-7e79c1fc18c0-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <01000177acf2de1b-e5e55c26-cdac-4282-904f-7e79c1fc18c0-000000@email.amazonses.com> Message-ID: <01000177b769897b-d7be7bfc-fdd3-43e3-b5f4-3bc0fb262018-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.18-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] IETF 110 Slot Requests X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 23:11:44 -0000 --Apple-Mail=_DD28328E-8B9C-400E-9C35-598A21C12974 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Authors, per the 110 Important Dates page [3], the draft submission = cutoff is in one week, on Monday, March 22nd. Please be sure to update = your drafts before then. Typo: the draft-submission cutoff is Feb 22 (this Monday), not Mar 22nd. K. --Apple-Mail=_DD28328E-8B9C-400E-9C35-598A21C12974 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Authors, per the 110 Important = Dates page [3], the draft submission cutoff is in one week, on Monday, = March 22nd.  Please be sure to update your drafts before = then.

Typo: the draft-submission cutoff = is Feb 22 (this Monday), not Mar 22nd.

K.


= --Apple-Mail=_DD28328E-8B9C-400E-9C35-598A21C12974-- From nobody Thu Feb 18 15:22:21 2021 Return-Path: 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 1F55E3A19C5 for ; Thu, 18 Feb 2021 15:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCas0IKw8uE0 for ; Thu, 18 Feb 2021 15:22:18 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43403A19C8 for ; Thu, 18 Feb 2021 15:22:17 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id g1so3279552ljj.13 for ; Thu, 18 Feb 2021 15:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f5aTb2OhXKwUBu780LilRmB/NIKkqmefPDsp6b6afrs=; b=GRKHV/rx6KRsz8Joj0PdIe1bRfsS5W5SUuY7/5kTdWSwvQSG/iXZtqullc0ucpjOOz QQlJuZY7ueMfs9VdAAHuFOevbOAcfyXRoV/htX3zJVIxjsvC+pkLOpcslSg5xXwCV0rA qWkP1aHiO/WEn73uLOgN3Z4o/fCL36WxEjPloIDlTY+BbRgwoOpKZyN7k9DwEFJ4gxMN qkSq/pQ1teFJ2EdDc3xpX3TOVqEzmBFCK4DvMGQoEiXeyQovVBilGvMyeOa4CZSXH0bm hppR+MTyElzC16Ad9rVh9LnA7T9Kk2POD1k1K0RokHI/W+WM/4tU4+KLVDEGynT0DbTp XhIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f5aTb2OhXKwUBu780LilRmB/NIKkqmefPDsp6b6afrs=; b=EcyGDtJpFQjrh62w17vN2FPSzj3Mzb3R/Y6qNAbpiMJlKYG/gTRV7WOySXCmyd1/3E YVl5bxgMMMOh0YjSy5C2pFy4LpNoOkcycUCuGshH1WHCCE3QIdEiGT2yiV86rL6edPbS ctpR56DyURfl9kPQ+gf6h9NlY5bBTxFXc8IvzxYF2O2X9q52BPRKXdT3FlDPM+rqR9mY kgmevPaLsS0u+JKjUif2wwvh/Nu9T5tgjZ6WuxOgXBhF0c9Ukcu3M44tsgkjiqQJ6iuy 7E9WDtjOQXATBucyUVWVIviR0fJnBeNbm+zi5/bwkvgLHyraGUB0ULa0E/l9o4N+7mfb oZkg== X-Gm-Message-State: AOAM532fjqwQJotaq14mdMlbcGFj4C4LBNn96UaLXPoKfATvG3I922kf y1NC47BvnOm9DtlSI+e63GGEdb0plGmqhv2RSz1L/Q== X-Google-Smtp-Source: ABdhPJwnLyG3XT8AaE6bX2FCRX/XQv3TAKpTUDuOUh+gCwnn5YMCnHv03edbeNEqX2Y6UmbKMkQqlHTPwzLXW/g0cJM= X-Received: by 2002:a19:f018:: with SMTP id p24mr771752lfc.568.1613690535418; Thu, 18 Feb 2021 15:22:15 -0800 (PST) MIME-Version: 1.0 References: <01000177b754b3b3-87cb5eda-8f8b-4a27-be56-5dcc52a1e5c3-000000@email.amazonses.com> In-Reply-To: <01000177b754b3b3-87cb5eda-8f8b-4a27-be56-5dcc52a1e5c3-000000@email.amazonses.com> From: Andy Bierman Date: Thu, 18 Feb 2021 15:22:04 -0800 Message-ID: To: Kent Watsen Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" , "draft-ietf-netconf-https-notif@ietf.org" Content-Type: multipart/alternative; boundary="000000000000242edc05bba49b41" Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 23:22:20 -0000 --000000000000242edc05bba49b41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 18, 2021 at 2:48 PM Kent Watsen wrote: > Hi Andy, > > > It seems too much of the language is limited to XML or JSON encoding. > > The media type extensibility should be well-defined so this draft > > does not have unintended limitations later on. > > We believe the defines an extensibility mechanism via the =E2=80=9Ccapabi= lities=E2=80=9D > resource target, which we recently modified in our local copy in response > to Martin=E2=80=99s comment enabling the capabilities to use any URI. P= lease > advise. > > > > There is a significant architectural change made without any real > mention (sec. 4) > > In NETCONF and RESTCONF, a notification is a one-way message, meaning > there > > is no application layer response whatsoever. > > > > That is not the case here. Instead, the publisher sends an HTTPS POST > for every notification > > and expects a "204 No Content" response for each one. > > The draft should explain the reasons for this change. > > HTTP client implementations tend to wait for a response to a POST. > > That is probably not what is intended here, but no text explains the > details. > > > > Sec. 4 does not mention what the publisher is supposed to do if the > receiver does not > > send a response or sends something other than 204. It seems like this > redundant ACK > > adds complexity and network traffic for no benefit. > > > It is agreed that notifications have historically not entailed having any > response from the receiver. However, the HTTP protocol defines that ther= e > be a response, and since there is no content for a receiver to return, we > suppose it to be 204 (No Content). > > That said, please note that HTTP is a sessionless/stateless protocol and > authentication MAY be conveyed via HTTP headers, which might necessitate = a > 401 (No Authentication) response. There may be other possible reasons to > return other values too (though we don=E2=80=99t have any examples to sha= re). > > To be clear, by no means are we suggesting that YANG =E2=80=9Cnotificatio= n=E2=80=9D > statements introduce application-level responses. > I do not think anyone suggested redefinition of the YANG notification-stmt. The notification delivery mechanisms are protocol-specific. In this case the application is HTTPS and 204 No Content is a normal response to a POST request. IMO notification delivery is not a good use-case for HTTP POST. > It is unclear how HTTP responses cannot be returned; the only options see= m > to be for the draft to explicitly enumerate all possible responses, or > leave it open. Thoughts on what text should added? > > > Kent and Mahesh > > > Andy --000000000000242edc05bba49b41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 18, 2021 at 2:48 PM Kent = Watsen <kent@watsen.net> wrote= :
Hi Andy,

> It seems too much of the language is limited to XML or JSON encoding.<= br> > The media type extensibility should be well-defined so this draft
> does not have unintended limitations later on.

We believe the defines an extensibility mechanism via the =E2=80=9Ccapabili= ties=E2=80=9D resource target, which we recently modified in our local copy= in response to Martin=E2=80=99s comment enabling the capabilities to use a= ny URI.=C2=A0 =C2=A0Please advise.


> There is a significant architectural change made without any real ment= ion (sec. 4)
> In NETCONF and RESTCONF, a notification is a one-way message, meaning = there
> is no application layer response whatsoever.
>
> That is not the case here. Instead, the publisher sends an HTTPS POST = for every notification
> and expects a "204 No Content" response for each one.
> The draft should explain the reasons for this change.
> HTTP client implementations tend to wait for a response to a POST.
> That is probably not what is intended here, but no text explains the d= etails.
>
> Sec. 4 does not mention what the publisher is supposed to do if the re= ceiver does not
> send a response or sends something other than 204.=C2=A0 It seems like= this redundant ACK
> adds complexity and network traffic for no benefit.


It is agreed that notifications have historically not entailed having any r= esponse from the receiver.=C2=A0 However, the HTTP protocol defines that th= ere be a response, and since there is no content for a receiver to return, = we suppose it to be 204 (No Content).

That said, please note that HTTP is a sessionless/stateless protocol and au= thentication MAY be conveyed via HTTP headers, which might necessitate a 40= 1 (No Authentication) response.=C2=A0 There may be other possible reasons t= o return other values too (though we don=E2=80=99t have any examples to sha= re).

To be clear, by no means are we suggesting that YANG =E2=80=9Cnotification= =E2=80=9D statements introduce application-level responses.


I do not think anyone suggested redefin= ition of the YANG notification-stmt.
The notification delivery me= chanisms are protocol-specific.
In this case the application is H= TTPS and 204 No Content is a normal response to a POST request.
<= br>
IMO notification delivery is not a good use-case for HTTP POS= T.


It is unclear how HTTP responses cannot be returned; the only options seem = to be for the draft to explicitly enumerate all possible responses, or leav= e it open.=C2=A0 Thoughts on what text should added?


Kent and Mahesh



Andy
=C2=A0
--000000000000242edc05bba49b41-- From nobody Thu Feb 18 18:01:58 2021 Return-Path: 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 2D9C43A0AD1; Thu, 18 Feb 2021 18:01:57 -0800 (PST) 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 Jf_9DMZoM8Y9; Thu, 18 Feb 2021 18:01:55 -0800 (PST) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 0D9A63A0ACB; Thu, 18 Feb 2021 18:01:54 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id a24so2469130plm.11; Thu, 18 Feb 2021 18:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mWGY9SqGETmxBmhxUuBP6V2toduP9TrjdUYgugB2KOM=; b=HVvlyB17fBZop9acHZKkYo1SVUmP7SDMb9dZXC6fzzXpIkz/+AfMWrETsJZ2j3EAhE 2Bpv3bQ1xd9dY5RgoQHitCOSdA79O6lzIO7jOiAlVmIV3J6Im4SPnBZcpoS3qtiQeu0X j7s67IUmO2oAwQJGB6VxwAhyZDER3xjt8Ztf8bOeRIrWZ6z+rVXVvf/Sazo+Io7y/Zyi 9+Vfcwj9l6k49Fx2Spye4WH43t5OaA61pKhjdhxiOZdEMjes53TgmbxXFC2SrMSXKPqT v47Gy3IsXaxMZZ6REGCzmi4uNLYhO/f1e/9NIPWU9bQoB1aQaz0hvatvQZ3FFMXZQlPI nYaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mWGY9SqGETmxBmhxUuBP6V2toduP9TrjdUYgugB2KOM=; b=qruIqr6om93MIGWbnQpOosRz5J/3BeE6MgAbn1m1anoYY82CPaYmTWTvyNbbkfljZH 4PlhqnQsRELVCTkKBGt0DoI22SK6UiwtCfx2Ir3I5lx1wrVjRVPLe2oiddWMuvAnIOU9 vDeOd42PzQAGUu4ZeLiaghV0VgA0II64XeNnk6bXUJlo+Lg46HX7gQnN8qm8JWyCS8Vi Bbd5iirvbJFmpAP3iF6b93yiFVujlI3w0fjG9WwmTGljpNVlSStEIJ6mkh+rk62F4+kc QzUaKnDqnulb435PxruSqHDWkM5CLCe+TLMfwFHHuz6TsuMeqZLae7j4XMVpCtlDdi6Q ruQw== X-Gm-Message-State: AOAM533yFcWQJy+6qHGDRbx6YtkxkEHyAsK9CdmF2TiXyPF08xyyRcQz CluX/9XY9BWBJnr65B0fM68= X-Google-Smtp-Source: ABdhPJw6ppU4OfPJ/CzQQtW3YOMWKa9Fhd64O4IWyNrI412oshifXblFAc+09BpAPM/atB9qPF0pOQ== X-Received: by 2002:a17:902:728a:b029:e3:530:cc73 with SMTP id d10-20020a170902728ab02900e30530cc73mr6603407pll.60.1613700114392; Thu, 18 Feb 2021 18:01:54 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:d5f6:3661:26de:c885? ([2601:647:5600:5020:d5f6:3661:26de:c885]) by smtp.gmail.com with ESMTPSA id ms24sm6491391pjb.18.2021.02.18.18.01.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Feb 2021 18:01:53 -0800 (PST) From: Mahesh Jethanandani Message-Id: <09EF5AF7-3983-41BF-90B7-6985C1ACCC38@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_43F21887-C7EF-4614-8375-7306972D755D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 18 Feb 2021 18:01:51 -0800 In-Reply-To: Cc: "netconf@ietf.org" , "draft-ietf-netconf-https-notif@ietf.org" To: Qin Wu References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 02:01:57 -0000 --Apple-Mail=_43F21887-C7EF-4614-8375-7306972D755D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Qin, > On Feb 6, 2021, at 4:51 AM, Qin Wu wrote: >=20 > Hi, authors of draft-ietf-netconf-https-notif > I have read the v-07 that has just been posted and have the following = comments: > 1. Section 1 said: > "future efforts may define support for other encodings (e.g., = binary)." > Why Cbor can not be supported as one of example binary encoding? Isn't = COBR IETF published standard work? We are not suggesting that CBOR cannot be supported. Note, =E2=80=9Ce.g. = binary=E2=80=9D is exactly that, an example. The draft in its latest = version (-08, unpublished as yet) allows for leaf-list definitions of = receiver-capabilities that can be specified using a URI. Another draft = can extend that list to advertise CBOR capability. >=20 > 2. Section 1 ,last paragraph said: > " > Configured subscriptions enable a server, acting as a publisher of > notifications, to proactively push notifications to external > receivers without the receivers needing to first connect to the > server, as is the case with dynamic subscriptions. > " > I want to make sure two things this paragraph want to convey: > 1. So call home is not needed in this case to establish service = initiated RESTCONF connection Yes. This draft does not leverage RESTCONF call home (RFC 8071) = capability. > 2. The connection between the server and the reciver is short live = connection rather than long live connection? Correct? Per standard practice, the underlying TCP connection may be kept around = longer if it is desired. >=20 > 3. Section 2 said: > " > The protocol consists of two HTTP-based target resources presented = by > the receiver: > " > Is target resource target URI? Can you provide a reference for target = resource? The updated draft (-08) clarifies that the two resources are sub-paths = of a common resource that the publisher must know (specified by the = =E2=80=9Cpath=E2=80=9D variable which acts a prefix to where the two = target resources are defined). >=20 > 4. Section 2 second bullet said: > " > a future effort MAY extend the protocol to send multiple notifications = per message. > " > What do you indicate for sending multiple notification per message? = Should you add reference to message header and bundle draft,i.e., = draft-ietf-netconf-notification-messages? draft-ietf-netconf-notification-messages would be the right place to = extend this draft to enable multiple notifications per message for e.g. = by adding =E2=80=9Cbundling=E2=80=9D capability. >=20 > 5. Section 4.1 said: > " > The publisher sends an HTTPS POST request to the "relay- > notifications" resource under a known path on the receiver > " > Where relay- notifications" resource is defined? In which RFC? Can you = provide a reference to it. It is a surprise to see = =E2=80=9Crelay-notification=E2=80=9D appeared without any context = information=20 > to be laid out for this? E.g., why relay-notification is picked? Is = there any other choice? =E2=80=9Crelay-notification=E2=80=9D (corrected for plurality) resource = is one of the two resources that are sub-paths of a common resource = defined by the receiver. It was probably not very clear, and therefore = in response to Martin=E2=80=99s comment, we have provided context to the = two resources in the draft in the latest version (-08). Please review = when it is published to make sure it addresses your comment. >=20 > 6. Section 4.1 said: > " > Instead of saying that, for JSON-encoding purposes, the module > name for the "notification" element is "ietf-restconf, the module > name will instead by "ietf-https-notif". > " > s/the module name will instead by/the module name will be instead by Fixed. Thanks. >=20 > -Qin > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: netconf [mailto:netconf-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Rob Wilton (rwilton) > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B41=E6=9C=8814=E6=97=A5= 21:12 > =E6=94=B6=E4=BB=B6=E4=BA=BA: netconf@ietf.org; = draft-ietf-netconf-https-notif@ietf.org > =E4=B8=BB=E9=A2=98: [netconf] WGLC: draft-ietf-netconf-https-notif-06 >=20 > This message begins a two-week WGLC for = draft-ietf-netconf-https-notif-06 ending on Jan 28. Here is a direct = link to the HTML version of the draft: >=20 > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-06 >=20 > Positive comments, e.g., "I've reviewed this document and believe it = is ready for publication", are welcome! This is useful and important, = even from authors. Objections, concerns, and suggestions are also = welcomed at this time. >=20 > Please note, the reason that I am making this request rather than the = WG chairs is because both chairs are listed as authors on this document. >=20 > Thank you, > Rob Wilton, OPS AD >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_43F21887-C7EF-4614-8375-7306972D755D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Qin,

On Feb 6, 2021, at 4:51 AM, Qin Wu <bill.wu@huawei.com> = wrote:

Hi, authors of draft-ietf-netconf-https-notif
I = have read the v-07 that has just been posted and have the following = comments:
1. Section 1 said:
"future efforts = may define support for other encodings (e.g., binary)."
Why = Cbor can not be supported as one of example binary encoding? Isn't COBR = IETF published standard work?

We are not = suggesting that CBOR cannot be supported. Note, =E2=80=9Ce.g. binary=E2=80= =9D is exactly that, an example. The draft in its latest version (-08, = unpublished as yet) allows for leaf-list definitions of = receiver-capabilities that can be specified using a URI. Another draft = can extend that list to advertise CBOR capability.


2. Section 1 ,last paragraph said:
"
  Configured subscriptions enable = a server, acting as a publisher of
=   notifications, to proactively push notifications to = external
  receivers without the receivers = needing to first connect to the
  server, as is = the case with dynamic subscriptions.
"
I = want to make sure two things this paragraph want to convey:
1. = So call home is not needed in this case to establish service = initiated RESTCONF connection

Yes. This = draft does not leverage RESTCONF call home (RFC 8071) = capability.

2.   The connection = between the server and the reciver is short live connection rather than = long live connection? Correct?

Per = standard practice, the underlying TCP connection may be kept around = longer if it is desired.


3.= Section 2 said:
"
  The protocol = consists of two HTTP-based target resources presented by
=   the receiver:
"
Is target = resource target URI? Can you provide a reference for target resource?

The = updated draft (-08) clarifies that the two resources are sub-paths of a = common resource that the publisher must know (specified by the = =E2=80=9Cpath=E2=80=9D variable which acts a prefix to where the two = target resources are defined).


4.= Section 2 second bullet said:
"
a future = effort MAY extend the protocol to send multiple notifications per = message.
"
What do you indicate for sending = multiple notification per message? Should you add reference to message = header and bundle draft,i.e., = draft-ietf-netconf-notification-messages?

draft-ietf-netconf-notification-messages would be the = right place to extend this draft to enable multiple notifications per = message for e.g. by adding =E2=80=9Cbundling=E2=80=9D = capability.


5. Section 4.1 = said:
"
  The publisher sends an = HTTPS POST request to the "relay-
=   notifications"  resource under a known path on the = receiver
"
Where relay- notifications" = resource is defined? In which RFC? Can you provide a reference to it. It = is a surprise to see =E2=80=9Crelay-notification=E2=80=9D appeared = without any context information
to be laid out for this? = E.g., why relay-notification is picked? Is there any other choice?

=E2=80=9Crelay-notification=E2=80=9D (corrected for = plurality) resource is one of the two resources that are sub-paths of a = common resource defined by the receiver. It was probably not very clear, = and therefore in response to Martin=E2=80=99s comment, we have provided = context to the two resources in the draft in the latest version (-08). = Please review when it is published to make sure it addresses your = comment.


6. Section 4.1 = said:
"
Instead of saying that, for = JSON-encoding purposes, the module
name for the = "notification" element is "ietf-restconf, the module
name = will instead by "ietf-https-notif".
"
s/the = module name will instead by/the module name will be instead by

Fixed.

Thanks.


-Qin
-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6---= --
=E5=8F=91=E4=BB=B6=E4=BA=BA: netconf [mailto:netconf-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Rob = Wilton (rwilton)
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2021=E5=B9=B41=E6=9C=8814=E6=97=A5 21:12
=E6=94=B6=E4=BB=B6=E4= =BA=BA: netconf@ietf.org; draft-ietf-netconf-https-notif@ietf.org
=E4=B8=BB=E9=A2=98: [netconf] WGLC: = draft-ietf-netconf-https-notif-06

This = message begins a two-week WGLC for draft-ietf-netconf-https-notif-06 = ending on Jan 28.  Here is a direct link to the HTML version of the = draft:

https://tools.ietf.org/html/draft-ietf-netconf-https-notif-06

Positive comments, e.g., "I've reviewed = this document and believe it is ready for publication", are welcome! =  This is useful and important, even from authors.  Objections, = concerns, and suggestions are also welcomed at this time.

Please note, the reason that I am making this = request rather than the WG chairs is because both chairs are listed as = authors on this document.

Thank you,
Rob Wilton, OPS AD

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




= --Apple-Mail=_43F21887-C7EF-4614-8375-7306972D755D-- From nobody Fri Feb 19 09:42:54 2021 Return-Path: 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 D9A813A128A; Fri, 19 Feb 2021 09:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.602 X-Spam-Level: X-Spam-Status: No, score=-9.602 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_H2=-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=S9cwar53; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=Nz61eNvv Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFmmMIFzp-2H; Fri, 19 Feb 2021 09:42:44 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497F03A1270; Fri, 19 Feb 2021 09:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8132; q=dns/txt; s=iport; t=1613756564; x=1614966164; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Tl/Zu6vSyzV7QZoFWDFPZWmECCxow/w8n9vxy/XWYxQ=; b=S9cwar535tkOLORPE7clE/63cwv1u0KFfLnvCOLC4kyjVBTVM5+pAAQO 13AE6Or4sENZJ4XeHsdw04hlqb/XkZGryoJH3X0KXgcPq9ONmO5abnOci l+pFQ50xl6OLZlAmr9wS8J2a4Btf5p1IaCtnA7I1/afp4/+hOZTfrvfxv U=; X-Files: smime.p7s : 3975 X-IPAS-Result: =?us-ascii?q?A0AYAAAs9i9gmIwNJK1iHAEBAQEBAQcBARIBAQQEAQGBe?= =?us-ascii?q?wcBAQsBgVIpKH0sLjYxCoQ3g0gDhFmJNQOZHoEuFIERA1QEBwEBAQoDAQEdC?= =?us-ascii?q?woCBAEBhAlEAoIMAiU0CQ4CAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBA?= =?us-ascii?q?YY2DYZEAQEBAwEBASEdAQEsCwEECwIBCCUdAgICJQslAQEEAQ0FCAaCEksBg?= =?us-ascii?q?X5XAw4RDwEOo18CiiV2gTKDBAEBBoUdGIILBwMGgTgBgVKBI4QHhkQmHIFBQ?= =?us-ascii?q?YERQ4JXPoJdAQGBRRyDFDSCK4FhaUwYBCIhEFsmAXoHKAYBuWcKgnuBG4NNg?= =?us-ascii?q?mqUYIMxikyVQ5RHnUeEQgICAgIEBQIOAQEGgVQ4gVlwFTuCaVAXAg2OHxmDV?= =?us-ascii?q?oUUhUVzNwIGAQkBAQMJfIoIAYEOAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3Auk1UPhaD6ysPNVTrmOJfvJD/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-AV: E=Sophos;i="5.81,189,1610409600"; d="p7s'?scan'208";a="650102023" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Feb 2021 17:42:43 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 11JHghLS013788 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2021 17:42:43 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Feb 2021 11:42:42 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Fri, 19 Feb 2021 11:42:41 -0600 Received: from NAM12-BN8-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; Fri, 19 Feb 2021 12:42:41 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZehYmTsULzSfiaiwQN0zXbp3RWz1QRIEmxqIvhnKujU29gFiD1lzZ388yhI6RvWukUrRxVIKW1k8TLGC5Uv9e8++wa1o9H8wUQms4TVxYV9x89YNMFLNtYXv8yLgO83SSPSuEpTUq7zdS+gdIPrtwgH8PwHNkVo1j3uTyOAbQ7EDI2lLLFISnSiO5ZvtNFulfwCkHOUeXYbTiDRmX86YoqvJDOQLG87bM7jqDNDH2JgirgJ6WFL5F32WKvKsfFnG6rUERHZ5AG/thpMB9KopZUKsyf5e92i5f5NYwAXMB5Mwawh7PvtDYxY+8S9IjxhhV2yYgeKw8cMNUQ8yGfM0aA== 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=Tzus6fkCLSN+Oybo8kU2+OZ18mJk2CA7bmyKi7r0mlo=; b=biWMOX7+DcsqTDztpm+LuzPBOvjM1ROO3VUFoa1cYee5MTlwVU3uGPD5kN2AsMcHPvdf1Uard+cZ+ikocLUHStopyWYXPhRWkk+WxnBZ1/igZ+LJMnH6vjzscF6Szl8BHgwzFReE6A/7BBazNnAtcD9pjF4SfuuLYEZptXuBVtBvWMdhLEf/0C2Vm+dzzWwZsZdbIfvKUDKmDD7o5/zZrgnrjOAh+3XveSuKSfda0RRpn0Lo83k2h43X+CCm8iiHpLRDWG+53IDj3+cjsFHyw7Xcu5X4vOKAoXIv4mf1QlWByPrCS9hhJ1HSNnKMGa87Ap52RvvwdSTUoNtQnjhLXQ== 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=Tzus6fkCLSN+Oybo8kU2+OZ18mJk2CA7bmyKi7r0mlo=; b=Nz61eNvvOlgdGoUptISp7MdLMczahgL8ULv/JOONReVIf5lPQ7v3QyBsPSrTRb7ZgncbfojIVAE1Tasb0FrVfJceqB48REyPGWJrKGoL3vV0VlAF7fcixLWTAALkoCc74iEmVtxRNi7NlzYiNxnPsaiT3x3OoZL3ZP53oWMM24I= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB2881.namprd11.prod.outlook.com (2603:10b6:208:7e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.27; Fri, 19 Feb 2021 17:42:40 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::88f5:c7e1:3338:cecf]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::88f5:c7e1:3338:cecf%3]) with mapi id 15.20.3846.042; Fri, 19 Feb 2021 17:42:40 +0000 From: "Eric Voit (evoit)" To: Kent Watsen , "Eric Voit (evoit)" CC: "netconf@ietf.org" , "draft-ietf-netconf-https-notif@ietf.org" Thread-Topic: [netconf] WGLC: draft-ietf-netconf-https-notif-06 Thread-Index: AdbqdYOgUz15Gs1wTZ6RgVXH+iq7RQGk0X5QA+xnatABYsEcAAAmtReg Date: Fri, 19 Feb 2021 17:42:40 +0000 Message-ID: References: <01000177b7428848-f48b34d9-2240-4916-9a62-2be1f06bb7df-000000@email.amazonses.com> In-Reply-To: <01000177b7428848-f48b34d9-2240-4916-9a62-2be1f06bb7df-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: [108.18.141.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e9e91b2a-fe4b-4686-991d-08d8d4fdc119 x-ms-traffictypediagnostic: BL0PR11MB2881: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: C8rn9W+SO6NdQ8SGVjOun/2lAtOSxH5A7sGkbJCnnUivOr2m58GYHoGB6Fq3GCcOV9E3KWELodR+5IWzUm32+boRElwh7ibmPpHcrlp8uSp3b9p4wdzg2Z/FKDX59wlCC12TNQd84t6dtOTjSlbeGQah/kGOFoFnD7bU+X5KwXCZr6X5bQNnjXXpgS3II2N8uS+5eorfBsggGp+6qImjM3Wm1+zUkuEg34Uei+F+gelOfsNcYknIIs2bS/kvDWDZTsGiikRxFY+taFjEoGshfaFpkS2XLhLgxBX/cLZR4lzBwTipr56vVPenpByrF/ynqUzxFW2bciUXFNNhv9rv8wZS2R7Wj8B3qBAAh7yR00BXkSORV6XcIpTMKh7HIwYJLVPL05pXe1mjFmyl7aK/kF3lqFdMnd6yr+aD4etL56FkP9Ww4xGVqWnO/paJ4Y5B7s2/w1PwjU2ZNfJEBUq/+g5ofCZ+WP7qzI5SBsEVmf5KKJ1CJoI8NuyOO/cDRN+PYCnY+UBgRCr52MfClKVauQ2NwBFX3ofVQAx7+gs0CpQiVf8f7pFN9HOEF7VrtTTzCx+VScJK1l1kNLamriGr/AHb/EOX2luHpg/oI9kQYls= 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; SFS:(376002)(396003)(346002)(136003)(366004)(39860400002)(316002)(83380400001)(55016002)(99936003)(33656002)(6506007)(478600001)(71200400001)(54906003)(52536014)(8676002)(110136005)(66616009)(5660300002)(2906002)(66556008)(7696005)(64756008)(66476007)(76116006)(4326008)(966005)(66446008)(8936002)(86362001)(66946007)(26005)(9686003)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?NWRSbGNWVnB2Ry9UOC9TVWs0WkdJMkdaaEpCSG44bTNFc3A1NTF3ajFrQWRI?= =?utf-8?B?TjNqTWdhZ0xnS2pNKzBCbElsYy9HaXpOSkpUcVRVdDBrYm9lSFkvNlN3R1N4?= =?utf-8?B?ZzlVVVc3cXlGMllKUDhHTlJYTk5hMERjSCtFb0NaVXdndFJkcGpJMnVzalJY?= =?utf-8?B?aFhDTzBxZld5SWlmQTlBaWVoOTJwR3NScXAvdnZ6aEJVNzJpekRRTW1lM3Yw?= =?utf-8?B?T3dMZVZuRUYyelptOEtJMURZR3grS1J0aGxTanlOaEpDUWhxcklva1VBbnNl?= =?utf-8?B?cDdDaE1NSjJHRG5lSHE5UnlXZVJHS3lIQWRiK1Iwb1IyUzcva0pnRmp0TEp2?= =?utf-8?B?MjdOSjJhUGphN3hFS1FSOTU5Um93WmtXaWFXaktka21tTCtQRTF4Wm9JaGhO?= =?utf-8?B?UUlmOTRQS3V3YlliRG1LeFFCWWxwUUx0aGFnVVV4eDNuN3JYU1l0Znh4NTZ6?= =?utf-8?B?c2R5NW5BNElJNzkrVHc3ZHhaMFJTSzFNV0d5ck5UaXkvczdQYUl4MjZrcnhT?= =?utf-8?B?bzdRWk9UeXFEd28zcWpRSVFycTI0MTJ6WTZVUzNIMVQ3Vnc0OUtWWldneXJz?= =?utf-8?B?RTc4MUY3YVRwQXU4QzBRanZNQ1VkN0c0T3E0ZDVaZDk3NHo2RGJvdkFPejh1?= =?utf-8?B?cmlsNitDV0lWWlRqaE1EWUNHaDdkdDJwVUU4OEgxSVJlUDBzL01UcTVoTkpV?= =?utf-8?B?SWt5NGdsS1cwSFgrQWR5cXVnRVRkZDZVRkZvRUlycDZ4TmRuWHh4NlVlYUpn?= =?utf-8?B?SXhqTm9aSlRoSkxzWmd3WU5yVnBhZ0tpQU1ucDBlVkJMWHZORGpQNnY4Z2x1?= =?utf-8?B?ZXFrV1cvYlZ2N3JGMi8yUWYveTFmSklkNklpSXAyTVJ0cTdEaVdKblJ3S3ly?= =?utf-8?B?RjNTbHlQb1hOK3ZYMENqck9nRDlpbFk3UWdmeWpDMmdQSDZRNjkyTW1SMWln?= =?utf-8?B?SUEwVld3dXJRT3RUN21ldVI2VnVNZ3BPTUlBR1Q2Z1RuV2dCOTZLSktVUVQv?= =?utf-8?B?enRNbTFOMTRMT2FKUkRCdkt3Z3lYbWRmbUdVQXdFRkdTcWpPbUQrUEFEb0NB?= =?utf-8?B?K0dUeTdYM1VuVjdDc2RKMVVFZndVQ2s5eUg0V0FnMjFOb1U0K280TUtRNDh0?= =?utf-8?B?KzhDS09hdnRWMm5meU1Jdlg1d3FhQVBKUWFlMVhSM0kzVGRRYjIvUjVyY3Ur?= =?utf-8?B?QTVldDhCT0xUN1FhZnV0V0ZsNElUaDd1cGJtdFZTZEJrZnEwZEhRYkc4ajJu?= =?utf-8?B?bFpEUVllcXJtYS9pZHdGbWtOYTJzOEcycVBMRUVHYzJYZFBCaWw1Y3BkRjlJ?= =?utf-8?B?R2RGWXN4OU9LRlVWVk02MFA0Ty85aURtUlFsQkJmRlQ2Uzc1RkE3djg0NWsx?= =?utf-8?B?QWU5K0tod3hoTzFiZXd2bnNVRmREQUk2NVZqV21SczVQNGgyOXl2eFFFc1Jv?= =?utf-8?B?SWtqZUwydDJsR0VwTURROU4yVWQrZEZ0U3l2NG84UTBybjJWR1V6ZmU0bGVk?= =?utf-8?B?MUpwcmgzY1pFcyt3cVg3UnR2OHFQVHIwNkF3ZzRDOWpUL2dXRnAvdXZWYjNL?= =?utf-8?B?QWxIM3IvTUlzejJneVViMnBPNHFQZnY4QndWanhSc2JiZnd0TDUwd01hNDlI?= =?utf-8?B?dHpnTkVtTlYvc1lBVzlWQ054VWpOQm5jbS9pNEZBU2pOYmxIWEs5akV3bE0w?= =?utf-8?B?bkh3K1hRczR1U0Q0d3BRdUZLTEZTOXJWVTY2dFJzeEFpaE5IdVFzZ3dpTGZo?= =?utf-8?Q?2ZKXOjc5HsQoBZ/qrhfsl9MbA52e4TDsXPtrbwc?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02AB_01D706BB.80BF9850" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e9e91b2a-fe4b-4686-991d-08d8d4fdc119 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2021 17:42:40.2990 (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: aYCCTslnkvY9u/8lNOdP1otjdGFIUV0IttJdz2S9fvqLzEabtaahcAHuBlODZuy1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2881 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 17:42:53 -0000 ------=_NextPart_000_02AB_01D706BB.80BF9850 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kent and Mahesh, > Hi Eric, >=20 > > The majority of examples showing have been = removed. > > The last place where they are discussed in -07 is the end of Section = 2. I > > still feel that describing the coverage or non-coverage of the set = of > > subscription state change notifications within a stream of event > > provides a useful context. >=20 > We=E2=80=99re unclear why this document should need or want to repeat = what is defined > in another RFC. This document regards how to send notifications, = regardless > where they are defined. >=20 > As you note, Section 2 currently has the following statement: >=20 > Note that, for RFC 8639 configured subscriptions, the very first > notification must be the "subscription-started" = notification. >=20 > Perhaps we should remove this sentence too, or replace = =E2=80=9Cmust=E2=80=9D with =E2=80=9Cwould=E2=80=9D, > so it doesn=E2=80=99t should normative? Please advise. The intent of my comment was mainly to assist the understandability = between drafts. Subscription state change notifications are a part of = RFC8639. This draft's Section 1.1 Applicability statement *totally = appropriately* notes that only a subset of RFC8639 constructs are = applicable. As a result subscription state change notifications are not = required when leveraging this specification. =20 If there is a minimum set of subscription state change notifications = required or desired, it would be good to list them. I suspect there = are not (as per the Applicability Statement). Based on this, I believe = it be worth listing some implications of not having the subscription = state change notifications in the Security Considerations section. = E.g., not sending a might mean a receiver can't = be sure that a compliant publisher is sending the full set of events = expected. Such a statement would make it easily apparent to an = implementer of the differences in functionality delivered as they choose = which RFCs to support. Eric =20 > Thanks, > Kent and Mahesh >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_02AB_01D706BB.80BF9850 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjE5MTczNDAxWjAjBgkqhkiG 9w0BCQQxFgQUFtT5TV1ET95HlgjCgK31WFZ+3/cwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQARt8f+0hMXxpx1kZ6YJ1qnhFQbPiRHiuLkgCvWK08aV9J1BqIUT+46mHfpVMRf+MZ4 LBCx23sdiBOPCdt2MvbuJywXX1diLIOOdnRce9MoNr+SmX7Ee2WwedA4TdtywVNCysepLadfLcnV LP/w5SYqOb2rPY73CKBHcDIFs97b8tM2DzNd//vuOCQfc92tNznufPfv/4c3Xrr5UAoHScJNTdKs fhL9RwgchrgI+8dnwF6nmayi8N63ahzwm2LCKcQBikLG6QX+Ib0HYTOKZmdfmmqBAmw29AVDe/tU oMBKHIHifpbrVB1OgQFrz8g7BQuOL00yK0KpGOlXx36BfGKAAAAAAAAA ------=_NextPart_000_02AB_01D706BB.80BF9850-- From nobody Fri Feb 19 13:15:32 2021 Return-Path: <01000177bc25655a-b590a758-26cf-4ef4-9bcc-aae75b40c7e2-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 F15573A0E1A; Fri, 19 Feb 2021 13:15:23 -0800 (PST) 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=unavailable 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 SoczjsV41ULP; Fri, 19 Feb 2021 13:15:22 -0800 (PST) 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 CFC673A0BC5; Fri, 19 Feb 2021 13:15:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1613769303; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=0uylRTyRza7mDJPDzpiecU7hBHQ0DNEwNWu7xWXJmS4=; b=YhZgCz93qm8XWT8E6f/avlPmIzPjNESODdQT9gr1FNxD6pWV3oOuvEOjzij8SHYt JNZ3Ns9L5IvTpLwd0ZYf7UCJ55a30KHH7NBo53zdXQS/SyJ6dXxrFOTdUViSA79rrlH EN5HUMGdrDtmHhyOBVTFB0ClXUZ3cZpfCCpbrZxs= From: Kent Watsen Message-ID: <01000177bc25655a-b590a758-26cf-4ef4-9bcc-aae75b40c7e2-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E6C7D75B-91B3-4E15-9B6E-2E927DCC6936" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 19 Feb 2021 21:15:03 +0000 In-Reply-To: Cc: "Eric Voit (evoit)" , "netconf@ietf.org" , "draft-ietf-netconf-https-notif@ietf.org" To: "Eric Voit (evoit)" References: <01000177b7428848-f48b34d9-2240-4916-9a62-2be1f06bb7df-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.19-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 21:15:29 -0000 --Apple-Mail=_E6C7D75B-91B3-4E15-9B6E-2E927DCC6936 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, > The intent of my comment was mainly to assist the understandability = between drafts. Subscription state change notifications are a part of = RFC8639. =20 Assisting understandability is good! :) > This draft's Section 1.1 Applicability statement *totally = appropriately* notes that only a subset of RFC8639 constructs are = applicable. The -06 "applicability statement=E2=80=9D was removed in -07. -07 also has an =E2=80=9Capplicability=E2=80=9D section (Section 3.1), = but it regards an entirely different matter. That said, this = =E2=80=9Capplicability=E2=80=9D section has also been removed (or will = be, when -08 is posted), per comments from Martin. > As a result subscription state change notifications are not required = when leveraging this specification. > If there is a minimum set of subscription state change notifications = required or desired, it would be good to list them. I suspect there are = not (as per the Applicability Statement). Based on this, I believe it = be worth listing some implications of not having the subscription state = change notifications in the Security Considerations section. E.g., not = sending a might mean a receiver can't be sure = that a compliant publisher is sending the full set of events expected. = Such a statement would make it easily apparent to an implementer of the = differences in functionality delivered as they choose which RFCs to = support. RFC 8639 needs to state what notifications are required by valid = implementations. The notif drafts MUST NOT limit any notifications from = being sent. If there are Security Considerations related to certain = notifications not being sent, they should be stated in RFC 8639. Stated differently, the =E2=80=9Cnotif=E2=80=9D drafts define = effectively *dumb* transport-level protocols. If higher-level logic is = layered on top of raw notifications, considerations for if certain = notifications are *not* sent needs to be defined in the higher-level = documents. Does this make sense, or do you mean something else? Please provide = specific text that you are hoping to see included. K. --Apple-Mail=_E6C7D75B-91B3-4E15-9B6E-2E927DCC6936 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,


The intent of my comment was = mainly to assist the understandability between drafts. =   Subscription state change notifications are a part of = RFC8639.  

Assisting understandability is good! =  :)


This draft's Section 1.1 Applicability = statement *totally appropriately* notes that only a subset of RFC8639 = constructs are applicable.

The -06 "applicability statement=E2=80=9D was removed in = -07.

-07 also has an =E2=80=9Capplicability=E2=80=9D = section (Section 3.1), but it regards an entirely different matter. =  That said, this =E2=80=9Capplicability=E2=80=9D section has also = been removed (or will be, when -08 is posted), per comments from = Martin.


As a = result subscription state change notifications are not required when = leveraging this specification.
If there is a minimum set of = subscription state change notifications required or desired, it would be = good to list them.  I suspect there are not (as per the = Applicability Statement).  Based on this, I believe it be worth = listing some implications of not having the subscription state change = notifications in the Security Considerations section.  E.g., not = sending a <subscription-modified> might mean a receiver can't be = sure that a compliant publisher is sending the full set of events = expected.   Such a statement would make it easily apparent to = an implementer of the differences in functionality delivered as they = choose which RFCs to = support.

RFC 8639 = needs to state what notifications are required by valid implementations. =  The notif drafts MUST NOT limit any notifications from being sent. =  If there are Security Considerations related to certain = notifications not being sent, they should be stated in RFC = 8639.

Stated = differently, the =E2=80=9Cnotif=E2=80=9D drafts define effectively = *dumb* transport-level protocols.  If higher-level logic is layered = on top of raw notifications, considerations for if certain notifications = are *not* sent needs to be defined in the higher-level = documents.

Does this make sense, or = do you mean something else?  Please provide specific text that you = are hoping to see included.


K.

= --Apple-Mail=_E6C7D75B-91B3-4E15-9B6E-2E927DCC6936-- From nobody Fri Feb 19 14:29:14 2021 Return-Path: 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 66E163A0BF1; Fri, 19 Feb 2021 14:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.899 X-Spam-Level: X-Spam-Status: No, score=-11.899 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_DNSWL_MED=-2.3, 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=GLifF2Xg; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=RIskBJa8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gUCd0fCZxzM; Fri, 19 Feb 2021 14:29:10 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369D53A0BEF; Fri, 19 Feb 2021 14:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9598; q=dns/txt; s=iport; t=1613773750; x=1614983350; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zol9rzdqOl+HqWSma9UzmqKFbBO5KDll/TTDUjUx2M4=; b=GLifF2Xg9GxhzLvOBfPlOINBGq2SjMdm3yZD96P4t0NbzAZwdcuIIYf6 owXCVTZytUREPDOx1Q/sQ4LPLbp8fQgAKNusrdANwqUygRjU26lITFaxu ag7bmoQIY/QVKECRENcQ6HNwmhwxRn0YeeW30GBiQnUxTtZIiiAw1K3mm 4=; X-Files: smime.p7s : 3975 X-IPAS-Result: =?us-ascii?q?A0AgCABEOjBg/4MNJK1bBx4BAQsSDIIEC4FTKSgHdiwuN?= =?us-ascii?q?jEKAYQ2g0gDjg0DmR6BLhSBEQNUCwEBAQoDAQEoCgIEAQGETQKCDAIlNgcOA?= =?us-ascii?q?gMBAQEDAgMBAQEBBQEBAQIBBgRxhWENhkQBAQEBAgEjHQEBNwEECwIBCCUdA?= =?us-ascii?q?gICMCUCBA4NBoISTIF+VwMOEQ8BDqRNAooldoEygwQBAQaBNwKDeBiCCwcDB?= =?us-ascii?q?oE4gVOBI4QHhkQmHIFBQYERQ4JXPoJdAQEDgTQOBReDFDSCK4JKFzUZA0MOA?= =?us-ascii?q?oEBAVcTFwEnBgEZuU4KgnuBG4NNgmqBaZJ3gzGKTJVDkxmMYZZWAgQCBAUCD?= =?us-ascii?q?gEBBoFaATOBV3AVO4JpUBcCDY4fDBaDTYUUhUVzNwIGAQkBAQMJfIhTAScDA?= =?us-ascii?q?YEJATFdAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3Ae/rJZxGbJu2s266a7looU51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QGbQozH8P9Czezbr/OoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXhbkHJr3v06zMOSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,191,1610409600"; d="p7s'?scan'208";a="650028781" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Feb 2021 22:29:09 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 11JMT9jU012631 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2021 22:29:09 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Feb 2021 16:29:08 -0600 Received: from xfe-aln-002.cisco.com (173.37.135.122) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Feb 2021 16:29:08 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Fri, 19 Feb 2021 16:29:08 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UgiibXn3qGlCW/xx//Xn0+opVGUL7h0I3oIuIEODz7GXPdFuJ11OZ9OYQM8NyGiBjzm5dCd2e2jQopn5nGMKNNjmkVg/WMI9UufpFwL/wZ3iBBmH8F5bR/afvUc6hH58jLpeF/kDBdyr/xpUIxKWqcLkfccXYRupjuScvf4nkhfmZwcNwQKPnOyjDnlU3AX+3DJfS19nbIqYRPQK0/3eREwvcAbnL61ayzGt7UN5DL8aGiz087XalEs/YmpnRo1Np+9K2XsdFsffDwHEhneyOqaMkO5/XtxtUBGJVaofJ+/jEwNEVHB841FYJISJmBrwDAhUMtziGm0TnWKg10fhXQ== 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=obwi+Vn/6WYoJDNcdNZRFFq6kQeYg0O1WRAzNfTwKAM=; b=ZnC3R8rzI+jtmXZ8l9yOfJkcj8k2N2Xzx4fJS12e14km8VFnpDWmjdPZ6J+K5bqojAvA6+lQXrm4NLHMf8WRZ3pVIXDpGS/rozYP6iAHgzqQZc1a0mDIMdtmfCWqRQ6pGPquYUskxW424Ru8e4acFeA6KIkHGE/M1GIUPZwkl9fkD45uzmOWDwogDAsNHd4vi17HfUuaBrTdlS6c59q8dzSp4xB7YugxEQ/vO1zgQtkZHy1Bzkwb5P+3rRqcPh1BNbU6R8OdbEqb7Xs3tqbpiVH7AADJ+Z+vQHyFoIITNEC6mG5z9fBTcnrSZ4eZ1f1baEqvo/UIIvXpBbyhcEJ2mQ== 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=obwi+Vn/6WYoJDNcdNZRFFq6kQeYg0O1WRAzNfTwKAM=; b=RIskBJa8WmD9XSi6Q3D4uvulRK1hdz+napoCTEwoUveDXfpgswIdwYMlUDifwZvgRG0i1DmepMVE7xh8P1Fo15yCJyi2kOv5eJ9x1YinD+AR2ZFwHmuck9Dkq0T4kjbusEWke0Xt/nwe1zRQqgQ8LZlInvSxoCtntrRD7P/UljI= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4272.namprd11.prod.outlook.com (2603:10b6:208:196::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.29; Fri, 19 Feb 2021 22:29:05 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::88f5:c7e1:3338:cecf]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::88f5:c7e1:3338:cecf%3]) with mapi id 15.20.3846.042; Fri, 19 Feb 2021 22:29:05 +0000 From: "Eric Voit (evoit)" To: Kent Watsen CC: "netconf@ietf.org" , "draft-ietf-netconf-https-notif@ietf.org" Thread-Topic: [netconf] WGLC: draft-ietf-netconf-https-notif-06 Thread-Index: AdbqdYOgUz15Gs1wTZ6RgVXH+iq7RQGk0X5QA+xnatABYsEcAAAmtRegAAkCb4AAAEKZwAAACaOw Date: Fri, 19 Feb 2021 22:29:05 +0000 Message-ID: References: <01000177b7428848-f48b34d9-2240-4916-9a62-2be1f06bb7df-000000@email.amazonses.com> <01000177bc25655a-b590a758-26cf-4ef4-9bcc-aae75b40c7e2-000000@email.amazonses.com> In-Reply-To: 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.141.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cdbce7a5-381b-4b55-f8c5-08d8d525c41b x-ms-traffictypediagnostic: MN2PR11MB4272: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +hUJL1WziiQV6t+c2o6QdurSDWqXKBTAA4evNZjjs+CDh2YeyqkKmf+XALwVYrLsB8OLGxfbtxCTkOT2RQvPYZDUydQ35iD6wJ0lwQsKRQNwaLYdCfEPuQ+hbX6+FFhQnKzFCZE0liqbgT/rbyg+2ahASTr+A/sYcT2qcDFfZPh7hSVgJl7YDwn3BYUSy3U8WW3T2OObH+8EcOSsqIGlmcXAK4Tg+4c3tx/pUAgiS0Q+F/C3goFehdxFqY1C0+StsxoJGIRPFeDJAIcewhLFQvU2ht4Wy5xO4Z0TwyJSH0xG5DQUCYz+SVxrOqDZRjisQIru/vrHrnCykWM9R1B6qWFZgN/JBjfh+tn7w6dQj4xCF7JE2ytDmyMY9eTFlHz4RIjWp0OCGIbzHNxSVVGgNXhZH9yoYUgkCZh1dq3MGTdr43PFTBg557HaLE5nDad5GNG6DUrFf7O5726YxGbcqkFBx0J3H0evC3yuNrMjh62LLFEzH4H96kpvtemzX34tENNV6xyUIORrQQDm/y+99iXt/3Um6eDzLRB9s/oB1B5lHKCcD7kPPnp5P5kHEHBUrMKg6CVTgkhDDw+aJKQIrGlQ9Thfoj26giZIoSWfxVU= 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; SFS:(376002)(366004)(136003)(396003)(39860400002)(346002)(66616009)(66946007)(66446008)(966005)(6916009)(86362001)(66476007)(2940100002)(33656002)(66556008)(9686003)(64756008)(54906003)(5660300002)(71200400001)(4326008)(8676002)(55016002)(186003)(7696005)(316002)(478600001)(8936002)(52536014)(26005)(99936003)(76116006)(2906002)(6506007)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?MWhtVGJjYXZ1YlJuVHpqMCtFUlBwOUZkQUUvdmJMbVpyTCtuNmdYUHoxVXVj?= =?utf-8?B?YWRHWnpIdFhHSkgwZlVmcVN2cEI5OFFVcTJHZUZGTmpuMXJzd1JINDlRYS9Z?= =?utf-8?B?ZGZUQUxoNThqTkxpelpreVo5cUhQVVRyVTBrb0t6QVBLNjliMUFHWVRaY2xt?= =?utf-8?B?Mmt5RzZlaGRHTHhYL2FpVGVtQmwzOHVOYzZ6SkdIYnEvVXNENUE2VDQ0S0cy?= =?utf-8?B?WWNVdlFFME9QTnFVRlBVdy9DWHdKWFRVMThPcExORVVqdy9ENG1BaXFWcEdJ?= =?utf-8?B?bFArTktOL3J3MzRZNWJkMko2WTJiNDJrRkdLZ2FDS1ZrbXdlM1QyNW5odUdz?= =?utf-8?B?N3lQa2wzV2gxRWRUVS9aeHZLdGlEZFJETHJ5ckFpNHFGaWtBOUpWWjVMeCtY?= =?utf-8?B?NWhsRlB4KytRaE1kUFZDd2o4QUNDbDJIaFhzYkI3Zzc4a0JWcUNZMTUzYXVB?= =?utf-8?B?WENZY2k2cW8rWEhhVnNGUWNxYnhHZUNqdFFXRXdnSkpOUkdiWWZ1eHhvSHdP?= =?utf-8?B?aXg4UjlDNG9nOE9DY1Ezc2MrLzFSRWdoa3ZCSG9ZbTF0REpzQWUzNG55QnVC?= =?utf-8?B?VGdJN21yVUxnY3ZBbU54SDc5QU80QlpOYnhqM0lJaiszQUVVY045NXVObHRG?= =?utf-8?B?NU8rNHJaSlk0YS8rMVRHbkdGbnE0T2xtWi9OUnkwRUdvNFlobG5zbnN2cSt2?= =?utf-8?B?Zy9tZHBST0t1SEltTGhqSDNuWXJ5TTFnY1Vjb2VrbmdGaVJ5L296Wi9DVENJ?= =?utf-8?B?a2JNMWN6c2RDQkNHMUhxeXowaHVYSjJIbHBBc0tTVFkrcmNCNkRLOHpRVURB?= =?utf-8?B?N0l1cnpLSytjWVprbnBJc1Z4Y2Z5VUJTQ0tqcjYwSnQ5RDlERy9nUlJUTUJr?= =?utf-8?B?MFVQdkZJaUlNUksvblZJTGlZTDR3K2VJcVhReFhodFpLcUhHYWhOL0N5U1dl?= =?utf-8?B?cFhwQ2xYZHdQRnVNdDN4NFpvOUJxeTVvanZtT1g2cWwyTWdLZ0svY1lNd3c1?= =?utf-8?B?cXZySmg4UGNKbkFHS2h2NTdUcFFCNTRMQnk2NXJwbHNzNXJkNldvMnFxRlRh?= =?utf-8?B?dXN4RzVGTGUxeEZzbjFjTWVkZzJyNHdXSUsxWkozblUyQWVna0o0VmxlTExq?= =?utf-8?B?VHVST25CWGZLcGpoSzZ5OElYdXlNejZwVXFXYUNrSnNMWHpiN3Ayd3VXdWdE?= =?utf-8?B?bnBzVU45M0FkNDhDT3N4dnVndlYzL2cycURWUDdVbnJqQ3lFOW95U1ZsRXZH?= =?utf-8?B?aHNMUFo3SmQ3TTF4UkZTbngvdksra3lyMzcxV2c3TWVSa2FuMm9UaEZwWi82?= =?utf-8?B?bmYzNzlPZStUMXhVbXhPQnVaeURSalR5SFFNdFJiZXpCZEg4ZWZoU2I1VU02?= =?utf-8?B?YnJEZEJ6d29zV1FycGtONGltOUtSUlh3VVVPak5WUktDV3lMbkRIVThPeS96?= =?utf-8?B?cjJhNHJiWHRwWDg2b01DaGl6b21uOVZma2pnOU5aVXRxcEFPZmtFbHFaOGxY?= =?utf-8?B?VzB3NU5DMDRRbVUwd2FIK0dQYlYvbE4yUU5oQTROVlI4MTFWcjBaTHB5RU8y?= =?utf-8?B?M0pvcFBId3pWb0diNUxFVFFOVFZXTWJ6U3dJS0JOd3F4YkJVUkUwdU5KcVJj?= =?utf-8?B?bm83OEd1dWpoK3UvOXovdmdDZVdvcFBRR2xGMUx1QjEvQWpKUThRQ0FLd3NP?= =?utf-8?B?Z1ZMb1hGOWIrRHJmRTBHN3VVN3g5WkVQeHdSK3B1SHJ4THUzZzcwQzc0Qmxy?= =?utf-8?Q?kzUU+KnZCM0JMrgmYBt93YfABSb5KpAGNIdC8xJ?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0341_01D706E3.BA6AE730" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdbce7a5-381b-4b55-f8c5-08d8d525c41b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2021 22:29:05.2499 (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: hj3nvvz7za1zlsD9RaMUdh2D8hoaQxbm9AkqGe8a2BeA3TKjUDWiUgTGigbM7NE7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4272 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 22:29:12 -0000 ------=_NextPart_000_0341_01D706E3.BA6AE730 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kent, > Hi Eric, >=20 >=20 >=20 > The intent of my comment was mainly to assist the understandability = between > drafts. Subscription state change notifications are a part of = RFC8639. >=20 > Assisting understandability is good! :) >=20 >=20 >=20 >=20 > This draft's Section 1.1 Applicability statement *totally = appropriately* notes that > only a subset of RFC8639 constructs are applicable. >=20 > The -06 "applicability statement=E2=80=9D was removed in -07. I still see "1.1. Applicability Statement" in -v07 of https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07 =20 > -07 also has an =E2=80=9Capplicability=E2=80=9D section (Section 3.1), = but it regards an entirely > different matter. That said, this =E2=80=9Capplicability=E2=80=9D = section has also been removed > (or will be, when -08 is posted), per comments from Martin. >=20 >=20 >=20 > As a result subscription state change notifications are not required = when > leveraging this specification. > If there is a minimum set of subscription state change notifications = required or > desired, it would be good to list them. I suspect there are not (as = per the > Applicability Statement). Based on this, I believe it be worth = listing some > implications of not having the subscription state change notifications = in the > Security Considerations section. E.g., not sending a = > might mean a receiver can't be sure that a compliant publisher is = sending the full > set of events expected. Such a statement would make it easily = apparent to an > implementer of the differences in functionality delivered as they = choose which > RFCs to support. >=20 > RFC 8639 needs to state what notifications are required by valid > implementations. =20 RFC 8639 Section 2.7 "Subscription State Change Notifications" starts = with "In addition to sending event records to receivers, a publisher = MUST also send subscription state change notifications when events = related to subscription management have occurred... The complete set of = subscription state change notifications is described in the following = subsections." So the only optional ones are related to replay (if = replay is supported) and suspension (if a publisher is capable of that.) = =20 > The notif drafts MUST NOT limit any notifications from being > sent. If there are Security Considerations related to certain = notifications not > being sent, they should be stated in RFC 8639. >=20 > Stated differently, the =E2=80=9Cnotif=E2=80=9D drafts define = effectively *dumb* transport-level > protocols. If higher-level logic is layered on top of raw = notifications, > considerations for if certain notifications are *not* sent needs to be = defined in > the higher-level documents. And the dumb transport is excellent. All I was asking for is the = differences in behavior between A.1 and A.2 to be noted somewhere. The = two are unlikely to be equivalent in functionality, however a reader new = to the space could perceive equivalence.=20 > Does this make sense, or do you mean something else? Please provide = specific > text that you are hoping to see included. Perhaps something like second paragraph in Section A.2 like: Note that if the receiver requires: * being fed metadata about the intended contents of the Event Stream, * that changes to the publisher's configuration of Stream have occurred, = or * the publisher has temporarily suspended event transmission then this application specific module should include functionality = similar to that supported by the RFC-8639 Section 2.7 Subscription State = Change Notifications.=20 Eric=20 >=20 > K. >=20 ------=_NextPart_000_0341_01D706E3.BA6AE730 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjE5MjIyMTU4WjAjBgkqhkiG 9w0BCQQxFgQUWyfr7EHgrnWIXJDn9v0VESylnJQwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBUWHiRqIjmdfDmkhFgnABWQlPXa6BzyBKivBQKdvms6jEyJzKq+QkpHiJOg4k97VEd 1FBMffO3kiZAzdDtbrK6ZERusbKceOXwldsNP9ko+RqxEY+GcDDgw5FDtboC1T3wWIjsRnDgdSvT Vrg97+Hr5WuDJSStMv+8ueVHcmZo+Ufx2vt5pVdjovuPOmocWtMklNzgGKK0EEnSCwlzGmbuRnkA SPnTNMbf4R/98XaHoI+euGTEAYjHFCwcV+WJP6In7zm7ZF4ni6zVK1IGjgz4gjKCRjGa/jZkrlY2 ORUNcFYkn0D4Lgz9wF0SwDN8k3XtwdleHnrA0Q7g4EEqLkh2AAAAAAAA ------=_NextPart_000_0341_01D706E3.BA6AE730-- From nobody Mon Feb 22 13:16:22 2021 Return-Path: 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 3BCE93A2052; Mon, 22 Feb 2021 13:16:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <161402857820.14422.13454696317587962202@ietfa.amsl.com> Date: Mon, 22 Feb 2021 13:16:18 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-14.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 21:16:18 -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 Modules describing Capabilities for Systems and Datastore Update Notifications Authors : Balazs Lengyel Alexander Clemm Benoit Claise Filename : draft-ietf-netconf-notification-capabilities-14.txt Pages : 27 Date : 2021-02-22 Abstract: This document defines two YANG modules,"ietf-system-capabilities" and "ietf-notification-capabilities". The module "ietf-system-capabilities" provides a placeholder structure that can be used to specify YANG related system capabilities for servers. The module can be used to report capability information from the server at run-time or implementation- time, per the YANG Instance Data File Format. The module "ietf-notification-capabilities" augments "ietf-system- capabilities" to specify capabilities related to Subscription to YANG Notifications for Datastore Updates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-14 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 22 13:20:49 2021 Return-Path: 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 302E03A205C for ; Mon, 22 Feb 2021 13:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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 y8IaDeK4VoON for ; Mon, 22 Feb 2021 13:20:42 -0800 (PST) Received: from smtpout1.mo529.mail-out.ovh.net (smtpout1.mo529.mail-out.ovh.net [178.32.125.2]) (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 665763A205B for ; Mon, 22 Feb 2021 13:20:41 -0800 (PST) Received: from mxplan1.mail.ovh.net (unknown [10.109.146.68]) by mo529.mail-out.ovh.net (Postfix) with ESMTPS id 7537A899D998; Mon, 22 Feb 2021 22:20:39 +0100 (CET) Received: from claise.be (37.59.142.99) by DAG7EX1.mxp1.local (172.16.2.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 22 Feb 2021 22:20:38 +0100 Authentication-Results: garm.ovh; auth=pass (GARM-99G0030fcf37ae-e2cd-41a6-8dd7-d2bcfee19b1b, 404B63CE72D38D6B077338B7A87E2E35B71EDAE6) smtp.auth=benoit@claise.be X-OVh-ClientIp: 109.89.184.41 To: Kent Watsen , "netconf@ietf.org" References: <0100017179dc6961-166c9a34-ed06-4e26-9240-83728a433691-000000@email.amazonses.com> From: Benoit Message-ID: Date: Mon, 22 Feb 2021 22:20:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <0100017179dc6961-166c9a34-ed06-4e26-9240-83728a433691-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="------------7A047582F0DC0DE73331DD31" Content-Language: en-US X-Originating-IP: [37.59.142.99] X-ClientProxiedBy: DAG4EX1.mxp1.local (172.16.2.7) To DAG7EX1.mxp1.local (172.16.2.13) X-Ovh-Tracer-GUID: 97c99fb2-0c40-44d1-9237-576e1c2bf132 X-Ovh-Tracer-Id: 2316820537388386202 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrkeefgddugeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtghisegrtderredtfeejnecuhfhrohhmpeeuvghnohhithcuoegsvghnohhithestghlrghishgvrdgsvgeqnecuggftrfgrthhtvghrnhepgfefieffieeijeeileelkedtleeiteevgedugeelfedukeejhedvheejleeifeeknecuffhomhgrihhnpeifihhkihhpvgguihgrrdhorhhgpdhivghtfhdrohhrghenucfkpheptddrtddrtddrtddpfeejrdehledrudegvddrleelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepmhigphhlrghnuddrmhgrihhlrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpegsvghnohhithestghlrghishgvrdgsvgdprhgtphhtthhopehkvghnthdoihgvthhfseifrghtshgvnhdrnhgvth Archived-At: Subject: Re: [netconf] Shepherd review of draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 21:20:48 -0000 --------------7A047582F0DC0DE73331DD31 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, Sorry it took us so long to update the draft. Below are our answer. We believe we have addressed all comments. Title: - it would be best for the title to not use the “YANG-Push” term before it’s been imported. How about this? OLD: YANG Modules for describing System Capabilities and Yang-Push Notification Capabilities NEW: YANG Modules describing Capabilities for Systems and Notifications for Datastore Updates NEW2: YANG Modules describing Capabilities for Systems and Datastore Updates Notifications BALAZS: OK, used New2 Be sure to update any change in the title in the YANG modules as well! BALAZS: OK, used New2 Note: https://en.wikipedia.org/wiki/YANG#Standards-track_data_models has a preference for "Data Models” over “Modules”, but I left that part alone since it’s not unheard of either... Abbreviated title: - "YANG-Push Notification Capabilities” is not an accurate description... BALAZS: OK, changed to System and Notification Capabilities Abstract: - module names should be in quotes when introduced BALAZS: OK - s/This document defines two YANG modules:/This document defines two YANG modules,"ietf-system-capabilities” and "ietf-notification-capabilities”. BALAZS: OK - s/YANG Instance Data/YANG Instance Data (I-D.ietf-netmod-yang-instance-file-format)/ BALAZS: OK - s/"Subscription to YANG Datastores" (YANG-Push)/Subscription to YANG Notifications for Datastore Updates (RFC 8641)/ BALAZS: OK - Actually (in ref to the above two comments), the sentence structure in p2 seems backwards. Better would be to say "The module can be used to report capability information from the server at run-time or implementation-time, per I-D.ietf-netmod-yang-instance-file-format.” BENOIT: idnits complains when we have references in the abstract. Removed the references Section 1: - Why isn’t the “Introduction” Section ‘1’ as is common in RFCs? BALAZS: OK, changed order of sections - Each term should be in double-quotes when first introduced, or use hanging text like other RFCs do. BALAZS: OK - don’t capitalize terms unless they appear at the beginning of a sentence, unless they’re capitalized throughout the entire document consistently! Which they’re not here.v Personally, I can never capitalize them consistently, so I just normal sentence-capitalization rules… BALAZS: OK - Neither "Run-time information” nor "Implementation-time information” constitute terms. Seriously, no one is going to care this document for those terms. Also not that "Run-time information” is only used once, as "Implementation-time information” would be as well if the text in the two back-to-back paragraphs were rearranged slightly. BENOIT: in the context of this draft, we have 2 separate scenarios (run-time information and implementation-time information). Instead of re-explaining them in different sections and risking that the terms are misunderstood, we believe it's best to define them. We seem to recall that we also received that feedback from the WG (during LC, possibly) - "On-change notification capability” is not a term and it’s not used anywhere in the document BALAZS: OK, removed Section 2: - The first sentence uses the word “capabilities” without explanation (and it’s not a term). Given that this document defines the “capabilities”, I’m expecting a term to be defined for it. S3 provides examples, but it seems too far away…thoughts? Maybe S1 and S2 could be collapsed: OLD: Systems implementing a server and/or a publisher often have capabilities that are not defined by the YANG model itself. There is a need to publish this capability information as it is part of the contract between the server and client. NEW: Servers and/or a publishers often have capabilities, values describing operational behavior, that need to be conveyed to clients, which is enabled by the YANG modules described in this document. BENOIT: DONE - the bullet list should be indented (i.e., put inside another list with symbols="empty”) BENOIT: please advice, the following doesn't work                                       vendor independent                   machine readable                   available in identical format both at implementation-time and run-time                     Section 2.1: - remove all instances of “we” throughout the document. s/we/this document/? BENOIT: done - why is there a “2.1” if there isn’t at least a “2.2”? (Is this meant to actually be a section 3?) BENOIT: corrected - the bullet lists should be indented (i.e., put inside another list with symbols="empty”) BENOIT: same remark; - P4 (the paragraph beginning "Publishers have limitations”) doesn’t seem to say anything concrete (i.e., relavent to the draft). Actually, the same can be said for P5. BENOIT: OLD    Publishers have limitations in how many update notifications and how    many datastore node updates they can send out in a certain time-    period.    Publishers might not support periodic subscriptions to all    datastores. NEW: Publishers might have some capabilities (or limitations) to document.    For example, how many update notifications and how many datastore node updates    they can send out in a certain time-period. Other publishers might    not support periodic subscriptions to all datastores. - P6 and P7 appear to be (unnecessary) elaborations of bullet-point #2 above. BENOIT: combined the paragraphs to make a longer series of capabilities/limitations to document. The entire section is:           Publishers might have some capabilities (or limitations) to document.           For example, how many update notifications and how many datastore node           updates they can send out in a certain time-period. Other publishers might           not support periodic subscriptions to all datastores. In some cases, a publisher supporting           on-change notifications will not           be able to push updates for some object types on-change. Reasons for           this might be that the value of the datastore node changes frequently           (e.g., in-octets counter), that small object changes are           frequent and irrelevant to the receiver (e.g., a temperature gauge changing 0.1           degrees within a predetermined and acceptable range), or that the           notification for a particular object. In all those cases,           it will be important for subscriber applications to have           a way to identify which objects on-change notifications are           supported and for which ones not. - s/Clients of a server, subscribers to a publisher/Clients of a server/ (note: that subscribers are clients) BENOIT: NEW Clients of a server (and subscribers to a publisher, as subscribers are also clients) need a method to gather capability information. - the last 2-3 paragraphs seem to go into the weeds wrt the focus of this draft…and the whole Implementation-time vs Runtime tradeoff is repeated in Section 3. Honestly, I don’t think this draft needs to discuss this at all but, if you must, factor it out into a separate section and keep it short, e.g., as in Section 3. BENOIT: Actually, we believe that we must address the implementation-time vs runtime topics, as the two provides the background for two distinct use cases, both solved with the solution in this draft. However, we agreed with you that the section order was not right. We introduced the more generic text in the introduction and kept the specifiations for subsequent sections. Section 3: - why doesn’t this section come before Section 2.1 (which maybe should actually be a Section 3)? BENOIT: corrected - System-level capabilities is the “base” model, in hence should be introduced first… BENOIT: corrected - actually, after reading the entirely of Section 3, I no understand the purpose of Section 2.1 BENOIT: yes, there is some history behind the draft. First it was about the YANG push capabilities only. Then, as we foresaw that other type of capabilities would be needed, we added the generic system capabilities information. Reviewing the draft, the history still transpired through the section order. Hopefully, this is solved now. - recommend 1) extracting the middle part out into a new “providing data” section where the Implementation-time vs Runtime options are discussed and 2) moving the remainder to End of the Introduction section… - s/The module ietf-system-capabilities/The module "ietf-system-capabilities"/ BALAZS: OK . - s/is defined to provide a structure/provides a structure/ - s/any YANG related system capability/YANG-defined capabilities/ BENOIT: It might be best to keep it aligned with the abstract. The last two points become: The module "ietf-system-capabilities" provides a placeholder structure to be used to specify any YANG related system capability. - s/The module ietf-notification-capabilities/The module "ietf-notification-capabilities”/ BALAZS: OK - s/"Subscription to YANG Datastores" (YANG-Push)/Subscription to YANG Notifications for Datastore Updates [RFC8641]/ BENOIT: done - Re: "on system/publisher level” - why is “publisher” mentioned in Section 4 at all? BENOIT: removed Section 4: - s/The module ietf-system-capabilities/The module "ietf-system-capabilities"/ BENOIT: DONE - s/is defined to provide a structure/provides a structure/ BENOIT: DONE - s/that can be used to specify/that can be used to discover (as read-only operational state)/ BENOIT: DONE - s/any YANG related system capability/YANG-defined capabilities/ BENOIT: see above - P3 should be P2 (like they are in the YANG module) BENOIT: right - the presence of P2 is confusing, if “this module itself does not contain any capabilities” BENOIT: See below. - I think you want to say something like the “structure” provides augmentation points for capabilities to be defined at different levels: a) system, when foo, b) datastore, when bar, and c) specific data nodes, the baz. (where foo/bar/baz describe the augmentation points used) - right? BENOIT: right.     This module itself does not contain any capabilities; it provides augmentation points     for capabilities to be defined in subsequent YANG modules. - s/config=false/“config false”/ BENOIT: DONE Section 4.2: (ietf-system-capabilities@2020-03-23.yang) - should the “description” statement for "import ietf-yang-library” 1) s/a revision/a backwards-compatable revision/ and 2) state that the module must be implemented? (Better, see my other comment regarding the YANG Doctor;s comment) BENOIT: Done - s/RFC RFC8525/RFC 8525/ BENOIT: Done - OLD: This module specifies a module intended to contain system capabilities. System capabilities may include capabilities of a NETCONF or RESTCONF server or a notification publisher. NEW: This module specifies a structure to specify system capabilities for s server or a publisher. BENOIT: OK - s/capabilities it only/capabilities, it only/ BENOIT: OK - s/should be augmented in/are augmented in/ BENOIT: OK - be sure there is a blank line between paragraphs and numbered list items, and/or list items are indented (this comment applies to *all* “description” statements) BENOIT: OK - list item (4) is missing punctuation and the first “sentence” doesn’t form a sentence. BENOIT: OK - "RFC XXX: YANG-Push Notification Capabilities” has both an incorrect number of X’s as well as incorrect document title. BENOIT: OK - rather than have the “description” statement "// augmentation point for system level capabilities”, why not have an empty “choice” statement with the same description statement? BALAZS: choice would not be a good solution because it would only allow one set of capabilities, while our goal is to allow different capability set side by side. - re: "Only individual datastores”, is “individual” the right word? Would “specific” or “leaf” be better? BALAZS: we used "specific" - rather than have the “description” statement "// augmentation augmentation point for datastore or data node level capabilities”, why not have an empty “choice” statement with the same description statement? BALAZS: see above. - is the comment "The special value '/' denotes all data nodes in the datastore.” should state if it’s a CLR or simply consistent with XPath 1.0 expressions. BALAZS: we are consistent witjh the NACM RFC, which says:                     The special value '/' refers to all possible                     datastore contents."; - this command detected an issue: pyang --ietf ietf-system-capabilities\@2020-03-23.yang. (I’m unsure why, exactly, as I see the keywords block in the module…suggest copying text directly from `pyang --ietf-help`. Section 5 - s/The YANG module ietf-notification-capabilities is defined to provide/The YANG module "ietf-notification-capabilities” provides/ BENOIT: done Section 5.2: (ietf-notification-capabilities@2020-03-23.yang) - P1 doesn’t specify all the normative imports BENOIT: done - be sure there is a blank line between paragraphs and numbered list items, and/or list items are indented (this comment applies to *all* “description” statements) BENOIT: done - s/If, different/If different/ BENOIT: done - "RFC XXX: YANG-Push Notification Capabilities” has both an incorrect number of X’s as well as incorrect document title. BENOIT: done - s/config=true/‘config true’/ BENOIT: done - s/config=false/‘config false’/ BENOIT: done - "supported for none” - nonsensical, rephrase. BENOIT:               "Type for defining whether 'on-change' or            'periodic' notifications are supported 'config false'            data nodes, 'config true' date nodes, no data nodes,            or all data nodes. - s/ or all data nodes/, or all data nodes/ (also try to fix the sentence so it makes sense) - s/ or a set of/, or a set of/ - s/update-too-big/'update-too-big’/ BENOIT: done - many of the “reference” statements are being misused. Move content information into the “description” and only set the reference per https://tools.ietf.org/html/rfc7950#section-7.21.4 BENOIT: all corrected - s/and the subtree below them/including any subtrees that may exist below them/ BENOIT: done - s/on-change notifications/'on-change' notifications/ BENOIT: done - this command detected a number of issues: pyang -f yang --keep-comments --yang-line-length 69 ietf-notification-capabilities\@2020-03-23.yang > tmp; diff ietf-notification-capabilities\@2020-03-23.yang tmp. (whitespace at end of lines) Section 7.2 (really 5.2, but I didn’t catch it until here) - the “inc” prefix seems odd, perhaps wrong, how about “notc” (to match “sysc”)?: BENOIT: You're right, changed Appendix A - the example is wrapped in the /, but now that `rfcstrip` has the “-a” parameter, these are no longer needed - agreed? Please move the filename augment to the “name” attribute in the element for both examples. BALAZS: OK - ideally there are subsections (i.e., A.1 and A.2) delineating each example BENOIT: done - s/config=false/“config false”/ BENOIT: done - please reorder the examples so that the system-capability examples precedes the notification-capability example BENOIT: done - in both examples: - s/following instance-data/following instance data/ (or "instance data set”?) BENOIT: done ^-- also add a reference to I-D.ietf-netmod-yang-instance-file-format - please remove the "

Hi Mahesh,

 

I believe = that my comments from Friday are still open.

 

Thanks,

Eric

 

From: = netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh = Jethanandani
Sent: Monday, February 22, 2021 6:39 = PM
To: netconf@ietf.org
Subject: Re: [netconf] I-D = Action: = draft-ietf-netconf-https-notif-08.txt

 

Hi = WG,

 

The authors believe that this version of the draft = addresses comments received during LC.

 

Thanks.



On Feb 22, 2021, at 3:33 PM, internet-drafts@ietf.org = wrote:

 


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

       Title =           : An = HTTPS-based Transport for YANG = Notifications
       Authors =         : Mahesh = Jethanandani
         &nb= sp;           &nbs= p;   Kent Watsen
        &n= bsp;    Filename =        : = draft-ietf-netconf-https-notif-08.txt
        &n= bsp;    Pages =           : = 27
        &n= bsp;    Date =            : = 2021-02-22

Abstract:
  This document defines a = protocol for sending notifications over
  HTTPS.  YANG = modules for configuring publishers are also = defined.
  Examples are provided illustrating how to = configure various
  publishers.

  This = document requires that the publisher is a "server" (e.g., = a
  NETCONF or RESTCONF server), but does not assume that = the receiver is
  a server.


The IETF datatracker = status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/
=
There are also htmlized versions available at:
ht= tps://tools.ietf.org/html/draft-ietf-netconf-https-notif-08
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-no= tif-08

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-https-notif-= 08


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/


_______________________________________________netconf mailing list
netconf@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netconf

 

Mahesh = Jethanandani

 

 

 

 

------=_NextPart_001_04D3_01D70950.21199F80-- ------=_NextPart_000_04D2_01D70950.21197870 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjIzMDAyMjU4WjAjBgkqhkiG 9w0BCQQxFgQULTJEyuwnVpfLDF41eHrRPwmzX+swSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAv/IlS6G6pvX9ltkNQFSAk1PkXRQFYF5CZ6qTstAyvRFsaV+4/5yiQ+STmMLA9ilr5 V/KejRcxhyYbR4uWbZfXceLYZ56+4kH5wQpfNDos9t7K1MZJClxVOR6N/iHDNjEJH3ql46DBIwYF khcyoU3vMHYi87sSLre730xlGZrlyu4sQSOg3K89YPYnGNRRYh+8rG5pVIBi34jQ+geMKg2no3MZ 9Rk39gEvH2bFGC53fL0i7kJVVZjM4trh+vJ3uugEnoUVt+DvrTqM7unTuHn2oHiHom7W/71aAuWm OhFIC/7Px40jv5BxEffmkl37QZ0cP+a9IOXpfS7Tz86qDYWFAAAAAAAA ------=_NextPart_000_04D2_01D70950.21197870-- From nobody Mon Feb 22 17:55:05 2021 Return-Path: <01000177cc98c51b-76384a63-688a-4849-8906-d728236c2ba4-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 4F1853A23C3 for ; Mon, 22 Feb 2021 17:55:03 -0800 (PST) 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_DNSWL_BLOCKED=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 3IF3Cgrqco_i for ; Mon, 22 Feb 2021 17:55:01 -0800 (PST) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D34B3A23C2 for ; Mon, 22 Feb 2021 17:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1614045300; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=vDvlRDHkJg52i64LW+/KaMF4m29iJQh9iEz5Rf2+f6w=; b=gZpkBJ+Fj0RiEd3Jf3cK9T9fhNxcMsz1OI+dntJ51Z45R29VS0ewz/N+zYsjm5+q LuRRiOBg980iH2KvRbyncDlaecVBYsLYa289Og1y6WpUKQZW1FVCEmh4Umc+ucVbEBG 730PlppiFqIDuVxwY7/n1phN0j3RhI5RRwZu5TvU= From: Kent Watsen Message-ID: <01000177cc98c51b-76384a63-688a-4849-8906-d728236c2ba4-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_65561755-EA4D-4F13-B462-3F567DD6310E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 23 Feb 2021 01:55:00 +0000 In-Reply-To: Cc: Mahesh Jethanandani , "netconf@ietf.org" To: "Eric Voit (evoit)" References: <161403681984.28848.17868609938843218324@ietfa.amsl.com> <0B59DF91-71AC-45BC-AE05-8BA81D036D2A@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.23-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 01:55:03 -0000 --Apple-Mail=_65561755-EA4D-4F13-B462-3F567DD6310E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, > I believe that my comments from Friday are still open. We did something different. We added an =E2=80=9Crfc8639-enabled=E2=80=9D= capability so that receivers can indicate when they support the RFC = 8639 state machine, thus highlighting the goodness that is had when = using it that, obviously, is not present when not used. K.= --Apple-Mail=_65561755-EA4D-4F13-B462-3F567DD6310E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Eric,

I believe that my comments from Friday are still = open.

We did = something different.  We added an =E2=80=9Crfc8639-enabled=E2=80=9D = capability so that receivers can indicate when they support the RFC 8639 = state machine, thus highlighting the goodness that is had when using it = that, obviously, is not present when not used.

K.
= --Apple-Mail=_65561755-EA4D-4F13-B462-3F567DD6310E-- From nobody Mon Feb 22 19:14:18 2021 Return-Path: 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 66A8D3A24F5 for ; Mon, 22 Feb 2021 19:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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_H2=-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=buQSudKQ; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=Jm0WicAA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAAp7-74HPzW for ; Mon, 22 Feb 2021 19:14:15 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387B43A250C for ; Mon, 22 Feb 2021 19:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9943; q=dns/txt; s=iport; t=1614050055; x=1615259655; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rcLM0ZukEFBJmqRkaPB1zRZt0BOc3AIn6lZJsZ6ie1E=; b=buQSudKQs7QralXK+/Gyo1obwpG/JqZIC1ZnVSO/g+2fqojvPhriAlBd CxeBBhff/Rs1qL0wFdRoS/RoB8rEv3j+YPA39QiZbMsPTxB3qf+ZCVLxq oCW5KmyPPH8eFvI0vAE21vNTNOfHHdQ2b0J2U/jA92UN8huIMDgQJqpY3 I=; X-Files: smime.p7s : 3975 X-IPAS-Result: =?us-ascii?q?A0A5BADdcDRgkIwNJK1iHgEBCxIMggQLgSMwUX0sLjYxC?= =?us-ascii?q?gGENoNIA4U5iFeKI4oKhHOBLoElA1QEBwEBAQoDAQEyAgQBAYRNAoINAiU2B?= =?us-ascii?q?w4CAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQGGOA2GRAEBAQEDIwoTAQE3A?= =?us-ascii?q?Q8CAQgEDQQBASsCAgIfER0IAgQOBQgGgl0BgX5XAx8PAaN1AooldoEygwQBA?= =?us-ascii?q?QaFCg0LggsHCYE4gVOBI4QFAQGGRCYcgUFBgVSCVz6CG4IlgxQ0giuBT4FjU?= =?us-ascii?q?4EBEJRrpUVbCoJ7gRuDUIJqjxiFTaNEowCTVwIEAgQFAg4BAQaBWgExgVlwF?= =?us-ascii?q?YMkUBcCDY4fDA0Jg02KWXM4AgYBCQEBAwl8iggBgQ4BAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AL8dxuhXmOgKbYGTO15H9kn3qsCDV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyFue1Nl/HbtebmVHBTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBvXSu9jMUXB?= =?us-ascii?q?PyKVk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,199,1610409600"; d="p7s'?scan'208,217";a="651309282" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Feb 2021 03:14:14 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 11N3EEEW004952 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 23 Feb 2021 03:14:14 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 22 Feb 2021 21:14:14 -0600 Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 22 Feb 2021 21:14:13 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Mon, 22 Feb 2021 21:14:13 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BBsc8uQwduCqN4QRlt+U6Ua8ik1liBQEYfKGTxS4fQPurlJF58Ih1Co8TlerA5wZgWTcnCGXf5Ch4edxtO1o5+n2wxhGD5zIlSjAp9KC5RBQx9qjRVBpOukwR/F3pvKcyzpK+Mu3tNdorDAzITKjELn86kh+HX1/oDCJynhgbeAhFbeVdb4hy2l/LC9ZadEhZ7A3ZlPRv7AYiipcfkwTRtIU9WcMBd5ggFpEM29k4Ksuf37mLForVnbregNTfJw7/BSH8wMNU7aXL6oZLwf6aOrS4RvuyQytbTi4cq8xKfqWROnGyZstooX2BTirzF4TGRkeNsDcDmCO3g6B7msNOg== 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=WH/lH2SF4fWzShVA/mIT5lDZId4Rw4w/61TaRTd7dNA=; b=YkDOmrWg1i4JkT4XzuBujXqEuYi9vF923M4UBM9QQWDOxp3oSJCcY2dksBgoaEbyt7PFyMQKVNWH8LZ7HIRgEGIIHOG+IUnW6eW3UVsXMfleLXXM1Ky1fC0dAR4lkHRNt/STSVgBHWX7Af3whN3rF3sRYIGpz487GuSXyYgL+sSI37aSThAoaTR2xM9UuP/nBdDdCZHmkOxqURKQVU8cVH99qL9Czh1ITg7W0vFIWdcUXVDuURfEJycUykSfLS82QuyUIf0/9/LdKA44WrKAUA0EfTE69t4OldEMZsXPIWEKHKip/d8NgF4gfmp69pG04Zcwyq6cFId3uVyNiBhd5g== 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=WH/lH2SF4fWzShVA/mIT5lDZId4Rw4w/61TaRTd7dNA=; b=Jm0WicAAT8/rp5RMXgdbJnmgznD00ZJXikYUObKFO4wyOGZ62Orqz9Rp2++hwW72s0cDkjKA/DvJWbgJYTM3FQvIpv8FWyISaZSg71qLapbwgUuVtWjLyhxiQMle3pSAHhlQ8vouqRDSfm3MuHB5LpqFWyVwpbk/yXaoxHnqJsU= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3330.namprd11.prod.outlook.com (2603:10b6:208:64::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.32; Tue, 23 Feb 2021 03:14:12 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::88f5:c7e1:3338:cecf]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::88f5:c7e1:3338:cecf%3]) with mapi id 15.20.3868.032; Tue, 23 Feb 2021 03:14:11 +0000 From: "Eric Voit (evoit)" To: Kent Watsen CC: Mahesh Jethanandani , "netconf@ietf.org" Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt Thread-Index: AQHXCXRURH7YU9DZ7EKOZZKX4nA6Vapk4NLwgAAaDgCAABXjcA== Date: Tue, 23 Feb 2021 03:14:11 +0000 Message-ID: References: <161403681984.28848.17868609938843218324@ietfa.amsl.com> <0B59DF91-71AC-45BC-AE05-8BA81D036D2A@gmail.com> <01000177cc98c51b-76384a63-688a-4849-8906-d728236c2ba4-000000@email.amazonses.com> In-Reply-To: <01000177cc98c51b-76384a63-688a-4849-8906-d728236c2ba4-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: [108.18.141.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8266dcf5-03e2-4139-d032-08d8d7a9179e x-ms-traffictypediagnostic: BL0PR11MB3330: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sed+xuORGOxDfxHPrq5wBPuZF3TIe7KpS3fq+rqSOfVU1xL0+I4F908BML8gWBHEy+ATeXiod/6mhFypZfATBe6QL9dCaVQSE6KewbINhIj6BaNvA3t21l2ZMBYyWT1eIGPRuWgBqC7YMmzPrhTJf7xGqWUkoiiCSpHggR+ToOsME86/Jou4haVnYDLiyEkPCsZ7AJyNmKon8BbWmpeNMioTHJXSJabk24yE322oWzjrSKO2WgcU+/BBnS0ti2bkKaH5jYlVUjfUFZKHVG0VwlHZ1bC4RltWmLQfGWiZVr8VnAImRTMkzSDKEAF6rqSvws257vRW68ZQaQAhF9qh1mJbEa+Duqy9O9H3gQnBtIfD0DK1kFaTpVa4IPk0KBi7iY0Bss10jwhNbEoXqJRqFqlzQPoEZ5eMGzzXQBrilnXx+lLHHo3eQk10FVQ9OOoitNabcDuifdpplz35XzN/CZxlJa+cVEBod9ZBwazH1+HRCowHwNuCBn3Tg0kaYsraXpP0vEuAii5dJ+3IzqzBgA== 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; SFS:(39860400002)(366004)(396003)(136003)(376002)(346002)(99936003)(71200400001)(8676002)(478600001)(6506007)(4326008)(9686003)(26005)(8936002)(53546011)(55016002)(66556008)(316002)(76116006)(33656002)(186003)(52536014)(86362001)(54906003)(66476007)(66616009)(5660300002)(66446008)(66946007)(2906002)(4744005)(64756008)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Mlo5WitDMWI4V202eEF5SEFWY1h3Zk4zQTZtOUFpM3E1YXRGZXBScmpybnov?= =?utf-8?B?T0ovNmp4cDRGZzFoR1hIVTkxRWxlOWtlWTh5UFZMV1FkOXlTbVZCblJsMGtt?= =?utf-8?B?bjJuRXVlOURZY3BFWStyZjJSR1FLS0R5QUY1dWRHcmFtaisybnJ5cjBzam1L?= =?utf-8?B?WmNoREZKdzNuTDNNelNicGhuVlBLVjh6cXFXeWp2UktaTUF5WkZnL3l2RFVE?= =?utf-8?B?NnhmYVkxYUZoNDFCZlhNWkdxQ0c0SWhSaVhKalQ4OGk3cUZjNDZ0SWVCektO?= =?utf-8?B?aUduMFRtamZ6eS9NUWYyWVNVcGhZWGswcTBMaHlnV3Qwd0RlRW5BV0YwTEpO?= =?utf-8?B?ZWY1N015QXRWL0tIeThqbjhxM2o2SWJXQ1ViWEhnVjg2VW9JYmJCRmF4bXVx?= =?utf-8?B?NytQRzRtVjZhdEVxZGNySWdpb3Q3MWpOQnRCMER6Y09ET1dES3czVTc4NzF0?= =?utf-8?B?WjlyNEZ1Kzdvc0hPbTkzNndBMkFubmROdzcrWVdRU2hqclppM3pXSlpaNnJh?= =?utf-8?B?MVhNTldWRzFlaFVTaVRGaHBkQVhPNStlb2QzMlV4TTg1Nyt1LzV0ak5jL0Vr?= =?utf-8?B?U1pJQ3VjelRvSzdXL3NWVUhOSkhvT2dLUlJ2YXpqMXgyVXAva2RrWlc5V3Z5?= =?utf-8?B?ZlNuNU5JVUtmbk05cklucUJ3aThabXZ3cU5JdlprWmZmbnJBbUYvNVNUVmV5?= =?utf-8?B?MWErNWFWUlhGdjEwNTYzVDVtMFVwMG9BdjhLRDFYUWtiZ3ZsdGZzd1BJcVlp?= =?utf-8?B?UXp3eUduY1hkU2piR3lZWENZZWpYWVNtMFBidUt3WDREMU83UVlBdEVSTGo0?= =?utf-8?B?bGlEZHRXSzB5bVlpY2lqcC9NWmFNTTU4TUlVVE4ySlF5eXVKRkQ1RWowN0Zs?= =?utf-8?B?di9nbnBUTlR1S1kzZ1F5ZWpEbWxCb3AxODB1dm5naFdZcll0K1pzOXZoZUtL?= =?utf-8?B?dWtrM2Y2MkJLVXhPRnYrc2hjSzJXRzFheHk2dks2a1NzNVc1NGJVSUlqMFJj?= =?utf-8?B?WmdkbTdJNkg0UnpTRSsraDFVQzQ0ZkJZdSswellYSW8wRGoxRmtHYjVJMTJ1?= =?utf-8?B?WnZnQ3dEeEhZbEdrc1Q5OVRBeE5SNVNtUE1oRXNOenc2WjBKbW5KWWt5QmJ3?= =?utf-8?B?TTBPNGIwTzA4Q3FBVkRnWVhReFdnd0pGM0N6cit0MkRvT0dSRzF3NFZuUHJk?= =?utf-8?B?Z1pJMlNsaDdpenk2V2hILzdsNmN3ZkdtZjNBdlNyYytLSW1XRTE5ZXR1bTdz?= =?utf-8?B?U0MvRjhvcWFFVitHYjhPcURXNDZKQzdxb2c5d1BUWDVkL2xadjNGZnhHaEEw?= =?utf-8?B?Q3dpMXlWMzVPR2NGZG5RY2lzTnZOTFoxTkp5NDdaNE5lc3lIRGhtTW02TG02?= =?utf-8?B?c3gxUlVJSVRnVWpnR2RRc2w4YVVES2N0N3pFbmZPWHB5TGg4Tm5kY1UvS3FO?= =?utf-8?B?Y2dSamhHZjEvOE5rSDhZbHNIc3JpbE5NWVJpOGpRWU4rdDYzMmM0dWwvZTFS?= =?utf-8?B?NXRHVkVieWZ3SThmQ015ajZrVHdmOUVTV3hjZWJRaVpVTERxQXlFSTFOZ1lv?= =?utf-8?B?LzVOZkkwMzZhaGpjYTlUeHA2UkI4c2tEYk9zMXQ4NzV1SGdFcHR5L0pRRndX?= =?utf-8?B?U3JSNGRISkdrWDVudDBENTlQb3JQSUw2OHBIQlRoaDluZzNrdVArVmpvaWNt?= =?utf-8?B?b3lWM2VxZUc1QTF3LzhjN3ZYWi9KNlZXcDVMeU5tamdCeFF0dWoxdHJTZFB4?= =?utf-8?Q?mzLOvb79STwbG5GNOuRh79CcwEqOa9nIrPRabGJ?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04DF_01D70968.0A591CE0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3122.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8266dcf5-03e2-4139-d032-08d8d7a9179e X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2021 03:14:11.7124 (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: eAHuGEHEZwLhkgwTd1REKOxW7aHUHFTNFTXPlIXneEB0wgBD1CIOBtVcFk4BE51D X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3330 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 03:14:17 -0000 ------=_NextPart_000_04DF_01D70968.0A591CE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_04E0_01D70968.0A591CE0" ------=_NextPart_001_04E0_01D70968.0A591CE0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I can live with that. Thanks. Eric =20 From: Kent Watsen =20 Sent: Monday, February 22, 2021 8:55 PM To: Eric Voit (evoit) Cc: Mahesh Jethanandani ; netconf@ietf.org Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt =20 =20 Hi Eric, =20 I believe that my comments from Friday are still open. =20 We did something different. We added an = =E2=80=9Crfc8639-enabled=E2=80=9D capability so that receivers can = indicate when they support the RFC 8639 state machine, thus highlighting = the goodness that is had when using it that, obviously, is not present = when not used. =20 K. ------=_NextPart_001_04E0_01D70968.0A591CE0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I can live with that.=C2=A0 = Thanks.


Eric

 

From: Kent = Watsen <kent+ietf@watsen.net>
Sent: Monday, February = 22, 2021 8:55 PM
To: Eric Voit (evoit) = <evoit@cisco.com>
Cc: Mahesh Jethanandani = <mjethanandani@gmail.com>; netconf@ietf.org
Subject: Re: = [netconf] I-D Action: = draft-ietf-netconf-https-notif-08.txt

 

 

Hi Eric,

 

I believe that my comments from Friday are still = open.

 

We did something different.  We added an = =E2=80=9Crfc8639-enabled=E2=80=9D capability so that receivers can = indicate when they support the RFC 8639 state machine, thus highlighting = the goodness that is had when using it that, obviously, is not present = when not used.

 

K.

------=_NextPart_001_04E0_01D70968.0A591CE0-- ------=_NextPart_000_04DF_01D70968.0A591CE0 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwMjIzMDMxNDA4WjAjBgkqhkiG 9w0BCQQxFgQUDzJOwGNFIKG9XlxUReWGl7j2h98wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAPP5LMS0iSTeD7JJ1VZfx26PJ2SR7jCnBIXHhriZ3NujmmiTmka+yKcuzSHe+Aj2O9 k6DNPel/h9AV3uC784gQSjRu/uqD1rpLMvqLNL4b3yMMm8qWvK+qnNGlPcPZhPGDmtsOtFhMjfIa vhBYWduag60ElfXcCvnowc4IcrwVl8Sm6sn1H2GZwWecYwG7HpSlO1FxJjgOvGWVjcu1SxYjbmIe 83Qr5Z6qXfLiwvL097eX9oPtSCpYSK/4uzrteAJ+PbWSBYwErVq/of2/5gI+VH/I96bv88MIU2xS XHSIdvIwelc4UYgDbwRuUBY5xOXbvT8m+0EY/TROzdgRK4qtAAAAAAAA ------=_NextPart_000_04DF_01D70968.0A591CE0-- From nobody Tue Feb 23 00:59:12 2021 Return-Path: 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 0329B3A28A1 for ; Tue, 23 Feb 2021 00:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.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, PDS_NAKED_TO_NUMERO=1.999, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=ic94divT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QBQaBWXO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHMXZU-SC7bb for ; Tue, 23 Feb 2021 00:59:09 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDB33A271B for ; Tue, 23 Feb 2021 00:59:09 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 164CF10AB for ; Tue, 23 Feb 2021 03:59:08 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 23 Feb 2021 03:59:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:subject:from:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=fm1; bh=ASxtqAdl0OFCk sXCSWGQz7wCDmWg3e0u6MEqji/xe/0=; b=ic94divTawttjdF6OfpWaizTzaxWd Yrtp7KNRoTZ1WJN5d7VIUcoUpZtiIC48jUH7dWy0i3OUtb3LhDDwFGm1Z9WERmO2 ZpUWkpjBJBkwV+CI2x8DpjLMfylvG+ph2kmIFFcOCMW9VfKGA7fYPHLXM1T/8Af1 2d+hdKXo7+LZy2akLiKtxSz3qbOGr+o4rkt3VyVcksz0iJBU68y99dSzjiJ7OM96 qXFO52u4Yp1Ytvb/SlRcRmjADhhjG7YEXuc1mIhE0SUZ7FC+EmAcXuCbIrDyN/Ab AEJAidopM6r2d6Btr90y++YN6B9u/xFr0OxoA22vhBdxeVo2YAR6FPYBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ASxtqAdl0OFCksXCSWGQz7wCDmWg3e0u6MEqji/xe /0=; b=QBQaBWXOO9/WM0vj7xyy0GuubhhLm7ClGYgA5fW9rBsKYGH2anB6afa9B X96V+JvYc5u/DLKzu1ileTNiJM3/ZOFwALnLzpt7KrMK72+I4Hcg8MbubdpxzsrZ 5JN7OQaKoPaGdrD/u3V8cWsBugpFdBK1zBUFcnTfLJSVmTL5VymHGbHeXb8eu9/p SwPc/5CmXP5w5jzGZmcrv+SYa6BX/fjhX1F7GnH/cb6KD+Kt/gPssoJG9fRrkdFQ VFS2r3hslmZdCaEYGiIT39vf/LcrgRVWYDbrxAa/KP8exkGlWvo9YAkW8zpnRuis nwzSPB2FOVoDOeFSkzHnyMWrAkAgw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeeggdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtje ertdertddvnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepteefheegkeehfeeujeehie egfeejvedtteegveejieegieejfeeljeevgfejuddtnecuffhomhgrihhnpehhthhtphdq tghlihgvnhhtqdhprghrrghmvghtvghrshdrihhnpdhhthhtphhsnhhothhifhhitggrth hiohhnrhgvtggvihhvvghrshhrvghgihhsthhrhihsvggvrhhftgiggiiggidrrghsnecu kfhppeduheekrddujeegrdegrddvudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepmhgsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 7C75D24005B for ; Tue, 23 Feb 2021 03:59:05 -0500 (EST) Date: Tue, 23 Feb 2021 09:59:03 +0100 (CET) Message-Id: <20210223.095903.174502091636867084.id@4668.se> To: netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <161403681984.28848.17868609938843218324@ietfa.amsl.com> References: <161403681984.28848.17868609938843218324@ietfa.amsl.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 08:59:11 -0000 Hi, I have read this version, and most of my comments for -07 are addressed. However, I still have some comments: o 2. Overview of Publisher to Receiver Interaction The protocol consists of two HTTP-based target resources presented by the receiver. These two resources are sub-paths of a common resource that the publisher must know (e.g. specified in its configuration data model). When reading this text (and 3.2 and 4.1) it is still not clear how this path is made known to the publisher. I suggest these changes: NEW: The protocol consists of two HTTP-based target resources presented by the receiver. These two resources are sub-paths of a common resource that the publisher must know. If the data model in section 6.2 is used, this common resource is defined in the "path" leaf in "http-client-parameters". o "capabilities": A target resource enabling the publisher to discover what optional capabilities a receiver supports. Publishers SHOULD query this target before sending any notifications or if ever an error occurs. o "relay-notifications": A target resource enabling the publisher to send one or more notification to a receiver. This document defines support for sending only one notification per message; a future effort MAY extend the protocol to send multiple notifications per message. (note that sections 3.2 and 4.1 already refer to these resources by the names "capabilities" and "relay-notifications"). Additional note: are these really "sub-paths of a common resource"? The "path" is just a prefix, it is not a resource. Perhaps rephrase to: The protocol consists of two HTTP-based target resources presented by the receiver. If the data model in section 6.2 is used, these resources are defined by the "path" leaf in "http-client-parameters". In 3.2 and 4.1 I would also do: OLD: To learn the capabilities of a receiver, a publisher can issue an HTTPS GET request to the "capabilities" resource under a known path on the receiver NEW: To learn the capabilities of a receiver, a publisher can issue an HTTPS GET request to the "capabilities" resource (see Section 2) on the receiver and similar in 4.1. o 3.3. leaf-list receiver-capability { type "inet:uri"; description "A capability supported by the receiver. A full list of capabilities is defined in the 'Capabilities for HTTPS Notification Receivers' registry (see RFC XXXX)."; } } As it is possible that the receiver may return custom capability URIs, the publisher MUST ignore any capabilities that it does not recognize. This seems contradictory - how can the server return custom capabilities if there is a full list of capabilities available in an IANA registry? o 3 and 8.3 There's a new capability defined: Name: urn:ietf:capability:https-notif-receiver:encoding:rfc8639-enabled Reference: RFC XXXX Description: Identifies support for RFC 8639 state machine. This is the only description of this capability in this document. How is it supposed to work? What should a publisher do with this information? Which state machine is referred to? (And, the name of the capability should be more descriptive, and not contain the RFC number. What if there's a bis version published with some errors fixed?) /martin From nobody Tue Feb 23 18:12:14 2021 Return-Path: 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 ABAED3A138A; Tue, 23 Feb 2021 18:12:11 -0800 (PST) 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 XGp4CHh9ok9b; Tue, 23 Feb 2021 18:12:09 -0800 (PST) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 AABF63A1388; Tue, 23 Feb 2021 18:12:09 -0800 (PST) Received: by mail-pj1-x102c.google.com with SMTP id gm18so267803pjb.1; Tue, 23 Feb 2021 18:12:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=T/+Hdbla1DkfH8RTAILXIIWuWK5ohDaKuziqTCXTkjE=; b=hRxXdq4eHGVIm7/wi/Tuam1QN70LJBEEufl1nF7AVU3bvKx8zP9V8s5lBQF9QsMPj4 8XCm8gb+bhbOIyF4GbuldYZEoSO57UCOa9qiiNb6x8XMzPmgfvW0pw8Cn8INu6/VVulH olzUIf5w0zCYECClcftYiStdMERZOGt5siSF2UNB6ysEu1DtMNavo+qBm1l33KW7vsmU Hog6R5/aLC/8E8yR0VMrH7J+wKcK53vtgVil0ZHn6Y/iYe644mhtnojGWHHNpgZZr87/ 8C0dk2+ykYtJjqJ98W7oeR7RUXPxcF6Wo21c9uvOyktaZ8lOuWzafrahJxEfjlGcAMxa TPXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=T/+Hdbla1DkfH8RTAILXIIWuWK5ohDaKuziqTCXTkjE=; b=szUXL+3k5H/MG90zcfgmlrgScHc7VpSJUTYU4XAlobiVBRUiP1UfGTlQ+1q85h1132 s57df2KLt17rEyd4Eddx25guWfc+eu1kWvomOUJo8Cs3txiib7JjZCxGvkEjGDUK/XRz 5AREnw53k+hQwe77w6t+fR4CZBAIFy8k1bDEgq+COfaG2bI947FGJfaeWQVRgVwnsl9X ekl3pCZKdgORCalViysKXKdBxGImu/aditJmcdtz/NHAT24KbEXLAu5MowcubiwnVvT2 PqXkgMYMNc4lKGO+kV23pVqUsAXFbd4CGEb6Cm+vjwNlbiZmvy3bP87A28msf+lFJUnU rvxA== X-Gm-Message-State: AOAM533RVbUD/A6cPl+KfpJ9MsvgLlS5mYwWRD9llFXqxuykLwJA+d93 4moe/QuvbMMHMHRW5ZWQlLijy3T7gjOeFw== X-Google-Smtp-Source: ABdhPJxPfTGC0dbfjlz8p/g4pcXX4kcGASS1FuqkMGVJGSZh6s5SkosViYsXt46MvmFTwzY6vpV5Tw== X-Received: by 2002:a17:90a:990f:: with SMTP id b15mr1875262pjp.56.1614132728730; Tue, 23 Feb 2021 18:12:08 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:7d6e:1c69:17df:2398? ([2601:647:5600:5020:7d6e:1c69:17df:2398]) by smtp.gmail.com with ESMTPSA id 4sm415956pjc.23.2021.02.23.18.12.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Feb 2021 18:12:07 -0800 (PST) From: Mahesh Jethanandani Message-Id: <14B11029-19C9-47D2-9215-4236E69BD6BE@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0DCB1FF6-C4D1-4F61-BF3E-F92A7DE0376F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 23 Feb 2021 18:12:06 -0800 In-Reply-To: Cc: netconf-chairs To: Netconf References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] WGLC on SZTP CSR draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 02:12:12 -0000 --Apple-Mail=_0DCB1FF6-C4D1-4F61-BF3E-F92A7DE0376F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We have not received any comments on this draft.=20 The document had been reviewed extensively even before it was put on LC. = So this was more of an opportunity for anyone else who wanted to provide = comments, to do so. With that in mind, and because we are close to the = virtual meeting, we are extending the call till after IETF 110. At that = time, if there are no objections and no more comments are received, we = will get this document ready for publication. Thanks. > On Jan 11, 2021, at 3:00 PM, Mahesh Jethanandani = wrote: >=20 > We are starting a 2 week WGLC for draft-ietf-netconf-sztp-csr which is = at version -01. >=20 > https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ = >=20 > Please respond on this thread indicating your support or concerns = about why this document should/should not be adopted. >=20 > We are particularly interested in statement of the form: >=20 > - I have reviewed the draft and found no issues.=20 > - I have reviewed the draft and found the following issues =E2=80=A6 >=20 > This WGLC will conclude on Monday, January 25. An IPR call has already = been issued separately. >=20 > Thank you. >=20 > Mahesh & Kent (as co-chairs) Mahesh & Kent (as co-chairs) --Apple-Mail=_0DCB1FF6-C4D1-4F61-BF3E-F92A7DE0376F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We = have not received any comments on this draft. 

The document had been reviewed = extensively even before it was put on LC. So this was more of an = opportunity for anyone else who wanted to provide comments, to do so. = With that in mind, and because we are close to the virtual meeting, we = are extending the call till after IETF 110. At that time, if there are = no objections and no more comments are received, we will get this = document ready for publication.

Thanks.

= --Apple-Mail=_0DCB1FF6-C4D1-4F61-BF3E-F92A7DE0376F-- From nobody Wed Feb 24 11:22:04 2021 Return-Path: <01000177d57dae49-6d751689-df68-4e97-ab8c-545c101f71be-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 D4A1C3A1A36 for ; Wed, 24 Feb 2021 11:22:02 -0800 (PST) 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_H5=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 1mOaL9GbKIef for ; Wed, 24 Feb 2021 11:22:01 -0800 (PST) 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 1DAA63A1A38 for ; Wed, 24 Feb 2021 11:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1614194519; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=Z7mEOekhh1Fuyr1NsWzd6eFQMRawacEt7qW0H6QQTwE=; b=YHa9AFSudgzaLrmES4hxFb+Z9WKJmRoIH5t70jTPl++PPqJFhvz0QA85Z6LxEkjC 0OZIsG7hl7UkhzbaPpuDcFIcWaIIlt8Yla0nMghpnP/eQlJr4tu39bQYpc1DvfQEf4d wFftT92SurX5FXIO+Y9MDv5wtq0DqlBy1bGatsus= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000177d57dae49-6d751689-df68-4e97-ab8c-545c101f71be-000000@email.amazonses.com> Date: Wed, 24 Feb 2021 19:21:59 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.24-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Draft 110 agenda posted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 19:22:03 -0000 The draft agenda has been posted here and reproduced below: = https://datatracker.ietf.org/meeting/110/materials/agenda-110-netconf Please let the chairs know if anything is amiss or awry. There is significant free-time remaining, so please submit discussion = topics if there is anything that you would like to discuss, it does not = have to be related to a draft. K. Agenda for the NETCONF 110 WG Session ------------------------------------- https://datatracker.ietf.org/meeting/110/materials/agenda-110-netconf Session: Monday, March 8, 2021 Session 1 (12:00-14:00 UTC, 13:00-15:00 CET, 07:00-09:00 EST) WG Chairs: Mahesh Jethanandani (mjethanandani at gmail dot com) Kent Watsen (kent plus ietf at watsen dot net) Available During Session: ICS: = https://datatracker.ietf.org/meeting/110/sessions/netconf.ics MeetEcho: = https://meetings.conf.meetecho.com/ietf110/?group=3Dnetconf Jabber: xmpp:netconf@jabber.ietf.org?join Available During and After Session: CodiMD: https://codimd.ietf.org/notes-ietf-110-netconf Slides (TGZ): = https://datatracker.ietf.org/meeting/110/agenda/netconf-drafts.tgz Slides (PDF): = https://datatracker.ietf.org/meeting/110/agenda/netconf-drafts.pdf Available After Session: Recording: = https://ietf110.conf.meetecho.com/index.php/Recordings#NETCONF Jabber Logs: https://www.ietf.org/jabber/logs/netconf Introduction Chairs (10 minutes) Session Intro & WG Status Chartered items: Network Telemetry with BMP and YANG Push @ IETF 110 Hackathon (5 min) https://trac.ietf.org/trac/ietf/meeting/wiki/110hackathon https://tools.ietf.org/html/draft-ietf-netconf-udp-notif-01 https://tools.ietf.org/html/draft-ietf-netconf-distributed-notif-01 Discussion Leader: Thomas Graf Status and Issues on Client-Server Suite of Drafts (10 min) https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-19 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-14 https://tools.ietf.org/html/draft-ietf-netconf-keystore-21 https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-09 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-23 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-23 https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-06 = https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-22 = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-22 Discussion Leader: Kent Watsen An HTTPS-based Transport for Configured Subscriptions (10 min) https://tools.ietf.org/html/draft-ietf-netconf-https-notif-08 Discussion Leader: Mahesh Jethanandani Non-Chartered items: With System Capability for NETCONF (10 min) https://tools.ietf.org/html/draft-ma-netconf-with-system-01 Discussion Leader: Qiufang Ma Remaining 75 min. From nobody Wed Feb 24 13:39:35 2021 Return-Path: <01000177d5fb3ffd-e089de07-6d01-490b-a38b-48952673f978-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 2A66C3A1D28 for ; Wed, 24 Feb 2021 13:39:34 -0800 (PST) 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_H5=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 79bgzF1No-2F for ; Wed, 24 Feb 2021 13:39:32 -0800 (PST) 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 4987D3A1D26 for ; Wed, 24 Feb 2021 13:39:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1614202749; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=dc9Vmg6Oikjhda+jNj7BBaPyo7Mx5UTcDbu1HJD1biY=; b=a0x0uhPrl0Y445y6NrcfdvqmDOTdkLh9QBI5+/d0z9y0VuSFsHETLV+ua+BDuIzA p8oWjzZwamEeAF6Ym2Mr2SOWZkidEh2nGUV14O0QJnb84nVTJj0bER9p47dk/Z8TOzf anVDwIEFBPmbtG1GOIFBTuHNH/+BJ2ogofBdw9rg= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_9A178F2B-4722-402F-97EA-CE460252D117" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 24 Feb 2021 21:39:08 +0000 References: <01000177d57dae49-6d751689-df68-4e97-ab8c-545c101f71be-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <01000177d57dae49-6d751689-df68-4e97-ab8c-545c101f71be-000000@email.amazonses.com> Message-ID: <01000177d5fb3ffd-e089de07-6d01-490b-a38b-48952673f978-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2021.02.24-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Draft 110 agenda posted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 21:39:34 -0000 --Apple-Mail=_9A178F2B-4722-402F-97EA-CE460252D117 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft agenda has been updated. Two additional presentations were = added. Updated agenda here: = https://datatracker.ietf.org/meeting/110/materials/agenda-110-netconf = Plenty of time remaining for additional requests. K. --Apple-Mail=_9A178F2B-4722-402F-97EA-CE460252D117 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii The draft agenda has been updated.  Two additional presentations were added. --Apple-Mail=_9A178F2B-4722-402F-97EA-CE460252D117-- From nobody Wed Feb 24 15:51:36 2021 Return-Path: <01000177d6745212-37524245-c74e-4de1-922e-53f80dac68e1-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 0F95C3A1DE7 for ; Wed, 24 Feb 2021 15:51:27 -0800 (PST) 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 vxy29k5Jif2V for ; Wed, 24 Feb 2021 15:51:25 -0800 (PST) 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 E04343A1DDA for ; Wed, 24 Feb 2021 15:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1614210683; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=J/2DCBevF0sC/5HbRX2Rtr0LVA3+wDkAdKV0+d55BvQ=; b=flyEXXf3m2u3zkafSc9BiotSbSPOrWoQZ/RBXDHIa9JLPIACaH7vOp/Z2zmptORX oIS1hC20xyaC7hIJkePrOeuzJi2t2MBAK5qZ28Ayf32igQ/D2YqejoEgcC+cShm4MRZ bNjUEzoDSqbih7ENVQARny00/yDjMBK4NWK/RwgI= From: Kent Watsen Message-ID: <01000177d6745212-37524245-c74e-4de1-922e-53f80dac68e1-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E3B821DE-2DAE-4712-BBF1-F2B0BA1BFD1A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 24 Feb 2021 23:51:23 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: "Christofer Tornkvist (ctornkvi)" References: X-Mailer: Apple Mail (2.3654.60.0.2.21) X-SES-Outgoing: 2021.02.24-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] NACM read access for actions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 23:51:33 -0000 --Apple-Mail=_E3B821DE-2DAE-4712-BBF1-F2B0BA1BFD1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Christofer, Looking at unread email, I noticed your message didn't receive any = responses. Could someone with familiarity with this NACM-question reply? Thanks, Kent > On Dec 4, 2020, at 3:40 AM, Christofer Tornkvist (ctornkvi) = wrote: >=20 > Hi, > =20 > I read in the NACM RFC 8341 that for actions to not be rejected > they both must have execute access and also read access > for all its parent (instance) nodes along the node hierarchy > up to the top node -described by the path for the action node. > =20 > The read access property, is that equivalent of having NACM rules > stating read access for all parent (instance) nodes? > =20 > If that is the case, does not that open up the node tree > structure unnecessarily much? > =20 > =20 > I support the idea of just having to state one NACM rule > containing read and execute access for the action node itself for it > to be able to be run, > and also that all the parent (instance) nodes > will be readable only along the path up to the action node without > any additional NACM rules. > And if there is a read access deny rule on any parent (instance) node > the action will be rejected. > =20 > =20 > Would appreciate a clarification. > =20 > Below are references to RFC 8341. > =20 > Regards > /Christofer Tornkvist > =20 > =20 > References in RFC 8341 are: > Ch. 3.1.3 s.3 > The new "pre-read data node acc. ctl" boxes in the diagram below > refer to group read access as it relates to data node ancestors of = an > action or notification. As an example, if an action is defined as > /interfaces/interface/reset-interface, the group must be authorized > to (1) read /interfaces and /interfaces/interface and (2) execute = on > /interfaces/interface/reset-interface. > =20 > Ch. 3.1.3 p.12 bullet 2 > o If the operation defined in [RFC7950] is invoked, then > read access is required for all instances in the hierarchy of = data > nodes that identifies the specific action in the datastore, and > execute access is required for the action node. If the user is > not authorized to read all the specified data nodes and execute > the action, then the request is rejected with an "access-denied" > error. > =20 > =20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = --Apple-Mail=_E3B821DE-2DAE-4712-BBF1-F2B0BA1BFD1A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Christofer,

Looking = at unread email, I noticed your message didn't receive any = responses.

Could= someone with familiarity with = this NACM-question reply?

Thanks,
Kent


On Dec = 4, 2020, at 3:40 AM, Christofer Tornkvist (ctornkvi) <ctornkvi=3D40cisco.com@dmarc.ietf.org> wrote:

Hi,
 
I read in = the NACM RFC 8341 that for actions to = not be rejected
they both must have execute access and also read access
for all its = parent (instance) nodes along the node hierarchy
up to the top = node -described by the path for the action node.
 
The read = access property, is that equivalent of having NACM rules
stating read access for all parent = (instance) nodes?
 
If that is the case, does not that open up the node tree
structure = unnecessarily much?
 
 
I support the = idea of just having to state one NACM rule
containing read and execute access for = the action node itself for it
to be able to be run,
and also that = all the parent (instance) nodes
will be readable only along the path up = to the action node without
any additional NACM rules.
And if there = is a read access deny rule on any parent (instance) node
the action = will be rejected.
 
 
Would appreciate a clarification.
 
Below are = references to RFC 8341.
 
Regards
/Christofer Tornkvist
 
 
References in RFC 8341 are:
Ch. 3.1.3 = s.3
   The new "pre-read data node acc. ctl" boxes in the diagram below
   refer to group read access as it relates to = data node ancestors of an
   action or = notification.  As an example, if an action is defined as
   /interfaces/interface/reset-interface, the = group must be authorized
   to (1) read = /interfaces and /interfaces/interface and (2) execute on
   /interfaces/interface/reset-interface.
 
Ch. 3.1.3 p.12 = bullet 2
   o  If the <action> = operation defined in [RFC7950] is invoked, then
    =   read access is required for all instances in the hierarchy = of data
      nodes that identifies the specific = action in the datastore, and
      execute access = is required for the action node.  If the user is
    =   not authorized to read all the specified data nodes and = execute
      the action, then the request is = rejected with an "access-denied"
      error.
 
 
_______________________________________________
netconf = mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_E3B821DE-2DAE-4712-BBF1-F2B0BA1BFD1A-- From nobody Wed Feb 24 17:34:53 2021 Return-Path: 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 F058F3A0B59 for ; Wed, 24 Feb 2021 17:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrS2RmU4IS6A for ; Wed, 24 Feb 2021 17:34:48 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 7F2763A0B56 for ; Wed, 24 Feb 2021 17:34:47 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id x22so315977lfc.6 for ; Wed, 24 Feb 2021 17:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GScu1K8EFdFuIjGmyFlPA6lWEJ4PLacVvZwCks8HQUc=; b=w9wVK5jhRZGio0U0gqaoIVnxjmgBfJ4O1dU0McciGE3tP3kC+FbvQqWOQZD9LXYOtP 4nqStIxpQgg5wRobhcecRLZgiBEK8ScBH9o8jIYiW99S/yfMXp22HHmsz2jVz1TysBW8 n1rwmzRu0eFwemq0ZcfmQKSRjjzLR07U9vzlbQ/zTIA563EbpmR2zrbq9IxYNTiaXyeD hYbBK8/Qqf9wgiu5LPiTKQZqIOqhKH3YWZ3CuJwGo2Ng8f+qc8lwJYOOn9wlDM+iC5UP SeEP61RvOCUBPP0gkdFIJJhEel7hstmV6tmnpc1Gd37PBeY9HpVMgWgZrKn1g0po0Zjv +bYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GScu1K8EFdFuIjGmyFlPA6lWEJ4PLacVvZwCks8HQUc=; b=hgmgLsvjwOUyqaz/udIGKqm4GZvp/fK9c4bWg9d9nDkj+9VzBuwW/46kHC62FTbM80 zFkHrI50UxDplyYOUzRoPTNgsLXr1EO9xIj1pY1wd/ECPdNZ8Y2hSEYDCMur9op9s1Bl S3Zv8iKRmMEVRCZYyG3eubN/N/rA4pHNDhRK8sloRtDdClMTnfs1ZbpSvIU9kphqGa0Y 0ZF6EX3Q+XhWCAMufi1Lkihm9E6avlJFfcyeUL16z6FlPFdd6u39wss+0y45GufePxzB EFpGIc24DVJh5T63mBHJ6nEolnnngFJWs/z9VeC49ibk1h1HEleNO7a8gOu1RtazFafF HMRQ== X-Gm-Message-State: AOAM5310wWjgZ434L4oVGgx81ImR0aozaBoOrFFbRWWCRdLMlhG5JpCX 78TzthaW33ggXUcU7FqzHZcwJq1NWwB9YsQqWpNowg== X-Google-Smtp-Source: ABdhPJyCt6qaJJ+b6aiSdDIxvOE/X1WsdUe5wHZ1T3+fxQb/gSkX/wE4Hog3cLTLJEUjO/EHu9x/xcskEBaCYsv/hZ4= X-Received: by 2002:a19:8186:: with SMTP id c128mr428200lfd.377.1614216885360; Wed, 24 Feb 2021 17:34:45 -0800 (PST) MIME-Version: 1.0 References: <01000177d6745212-37524245-c74e-4de1-922e-53f80dac68e1-000000@email.amazonses.com> In-Reply-To: <01000177d6745212-37524245-c74e-4de1-922e-53f80dac68e1-000000@email.amazonses.com> From: Andy Bierman Date: Wed, 24 Feb 2021 17:34:34 -0800 Message-ID: To: Kent Watsen Cc: "Christofer Tornkvist (ctornkvi)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000aeba205bc1f2880" Archived-At: Subject: Re: [netconf] NACM read access for actions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 01:34:50 -0000 --0000000000000aeba205bc1f2880 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 24, 2021 at 3:52 PM Kent Watsen wrote: > Hi Christofer, > > Looking at unread email, I noticed your message didn't receive any > responses. > > Could someone with familiarity with this NACM-question reply? > > I think the question is whether the read access required for exec access exposes too much data. I think the original intent of the text is that read access to the container or list element is required, not the entire subtree. It could be argued that read access to the key leafs within a list entry is also required. Thanks, > Kent > > Andy > > On Dec 4, 2020, at 3:40 AM, Christofer Tornkvist (ctornkvi) < > ctornkvi=40cisco.com@dmarc.ietf.org> wrote: > > Hi, > > I read in the *NACM* RFC 8341 that for actions to not be rejected > they both must have execute access and also read access > for all its parent (instance) nodes along the node hierarchy > up to the top node -described by the path for the action node. > > The read access property, is that equivalent of having *NACM* rules > stating read access for all parent (instance) nodes? > > If that is the case, does not that open up the node tree > structure unnecessarily much? > > > I support the idea of just having to state one *NACM* rule > containing read and execute access for the action node itself for it > to be able to be run, > and also that all the parent (instance) nodes > will be readable only along the path up to the action node without > any additional *NACM* rules. > And if there is a read access deny rule on any parent (instance) node > the action will be rejected. > > > Would appreciate a clarification. > > Below are references to RFC 8341. > > Regards > /*Christofer* *Tornkvist* > > > References in RFC 8341 are: > Ch. 3.1.3 s.3 > The new "*pre*-read data node acc. ctl" boxes in the diagram below > refer to group read access as it relates to data node ancestors of an > action or notification. As an example, if an action is defined as > /interfaces/interface/reset-interface, the group must be authorized > to (1) read /interfaces and /interfaces/interface and (2) execute on > /interfaces/interface/reset-interface. > > Ch. 3.1.3 p.12 bullet 2 > o If the operation defined in [RFC7950] is invoked, then > read access is required for all instances in the hierarchy of data > nodes that identifies the specific action in the datastore, and > execute access is required for the action node. If the user is > not authorized to read all the specified data nodes and execute > the action, then the request is rejected with an "access-denied" > error. > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --0000000000000aeba205bc1f2880 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 24, 2021 at 3:52 PM Kent = Watsen <kent@watsen.net> wrote= :
Hi Christofer,

Looking at un= read email, I noticed your message didn't receive any responses.
<= div>
Could someone with=C2=A0familiarity with this=C2=A0NACM-question reply?


I think the question is whether the= read access required for exec access exposes
too much data.

I think the original intent of the text is that read a= ccess to the container or list
element is required, not the entir= e subtree.=C2=A0 It could be argued that read access to the
key l= eafs within a list entry is also required.


Thanks,
Kent


Andy
=C2=A0

On Dec 4, 2020, at= 3:40 AM, Christofer Tornkvist (ctornkvi) <ctornkvi=3D40cisco.com@dmarc.= ietf.org> wrote:

Hi,=
=C2=A0
I read in the=C2=A0NACM=C2=A0RFC 8341= that for actions to not be rejected
they both must have exec= ute access and also read access
for all its parent (instance) n= odes along the node hierarchy
up to the top node -described by = the path for the action node.
=C2=A0
=
The read acces= s property, is that equivalent of having=C2=A0NACM<= /span>=C2=A0rules
stating read access for all parent (instance) no= des?
=C2=A0
If that is the case, does not that op= en up the node tree
structure unnecessarily much?=
= =C2=A0
=C2=A0
I support the idea of just having to = state one=C2=A0NACM=C2=A0rule
conta= ining read and execute access for the action node itself for it
to be able to be run,
and also that all the parent (instance) = nodes
will be readable only along the path up to the action nod= e without
any additional=C2=A0NACM= =C2=A0rules.
And if there is a read access deny rule on any par= ent (instance) node
the action will be rejected.<= /span>
= =C2=A0
=C2=A0
Would appreciate a clarification.<= /u>
=C2=A0
Below are references to RFC 8341.=
= =C2=A0
Regards
/Christofer=C2=A0Tornkvist=
=C2=A0
=C2=A0
=
References in = RFC 8341 are:
Ch. 3.1.3 s.3
=C2=A0=C2=A0=C2=A0The= new "pre-read data node acc. ctl" box= es in the diagram below
=C2=A0=C2=A0=C2=A0refer to group read= access as it relates to data node ancestors of an
<= span lang=3D"EN-US" style=3D"font-size:10pt;font-family:Menlo">=C2=A0=C2=A0= =C2=A0action or notification.=C2=A0=C2=A0As an example, if an action is def= ined as
=C2=A0=C2=A0=C2=A0/interfaces/interface/reset-interface= , the group must be authorized
=C2=A0=C2=A0=C2=A0to (1) read /i= nterfaces and /interfaces/interface and (2) execute on=
=C2=A0= =C2=A0=C2=A0/interfaces/interface/reset-interface.
<= span lang=3D"EN-US" style=3D"font-size:10pt;font-family:Menlo">=C2=A0
Ch. 3.1.3 p.12 bullet 2
=C2=A0=C2=A0=C2=A0o=C2=A0=C2=A0I= f the <action> operation defined in [RFC7950] is invoked, then=
=C2=A0 =C2=A0 =C2=A0=C2=A0read access is required for all instances i= n the hierarchy of data
=C2=A0 =C2=A0 =C2=A0=C2=A0nodes that = identifies the specific action in the datastore, and
=C2=A0 =C2= =A0 =C2=A0=C2=A0execute access is required for the action node.=C2=A0=C2=A0= If the user is
=C2=A0 =C2=A0 =C2=A0=C2=A0not authorized to read= all the specified data nodes and execute
=C2=A0 =C2=A0 =C2=A0= =C2=A0the action, then the request is rejected with an "access-denied&= quot;
=C2=A0 =C2=A0 =C2=A0=C2=A0error.
=C2=A0
=C2=A0
__________________________________________= _____
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

_____________________________________= __________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--0000000000000aeba205bc1f2880-- From nobody Thu Feb 25 23:35:43 2021 Return-Path: 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 BCE0C3A08C5 for ; Thu, 25 Feb 2021 23:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=QA1dVSfp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wtsT67j8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai9Y8gVVVxUF for ; Thu, 25 Feb 2021 23:35:39 -0800 (PST) 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 C0DDF3A08BE for ; Thu, 25 Feb 2021 23:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22604; q=dns/txt; s=iport; t=1614324937; x=1615534537; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jvsbSVrfhfLqJ2Tq6+tDnxfy6ZLPVD+Nw6q538nMa5E=; b=QA1dVSfpUjj5DOnBdNNI8q2nxl1WEerBCrN/BUMsbccb+56vUFOTwhs4 UXj8YhY3NPOEFcahVNR3Gw2I9t8bjTwHXc2qreUrNjCxQsd2q8tBf9eWY Z86IqJvoMBZsjR+ncbdj01jVMdoohkwyOJ/0KX65KO66uuPC22gPqId76 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AReh2FB08Ol7WKGkYsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFv6d8kVrAQoLB6OkCgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS9fjYlTNpWex9ngZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BEBgDCozhg/5pdJa1iHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BIzBRB3ZaNjEKAYd+A4U5iGWPHooGgUKBEQNUCwEBAQ0?= =?us-ascii?q?BAR0BCgoCBAEBhAlEAoF4AiU4EwIDAQELAQEFAQEBAgEGBHGFYQ2GRQIBAwE?= =?us-ascii?q?BPgEBLAsBDwIBCDgHBycLFBECBAENBQiCaYF+VwMvAQMLpSMCiiV0gTSDBAE?= =?us-ascii?q?BBoUiGIISAwaBOIJ2hAaCVINzJhyCB4ERQ4JXPoJdAQECgSkBEgEIGysJgxS?= =?us-ascii?q?CK4FPCQIPLC+BAj9bJREHFy4KGgIbJ5BAPopNLoMRiRKRQQuDBpw/gzWQR49?= =?us-ascii?q?RlE6dGj4JhDkCBAIEBQIOAQEGgWsjKj1wMyIbFTuCaVAXAg2OH4NvhRSFRXM?= =?us-ascii?q?CNgIGCgEBAwl8iggBgQ4BAQ?= X-IronPort-AV: E=Sophos;i="5.81,207,1610409600"; d="scan'208,217";a="865659370" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Feb 2021 07:35:36 +0000 Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 11Q7ZbiS009135 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 26 Feb 2021 07:35:37 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 26 Feb 2021 01:35:37 -0600 Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 26 Feb 2021 01:35:34 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Fri, 26 Feb 2021 01:35:34 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JAX3OHVC75qLfFQZfo90R0Sg8GNRFxcHMtl/GYijLGQYiNKj4MNSMo5YTNPMaImZw2MeHJ31DPpnCkoeT9u9ioBjH8akXG9sskwZMjVSmOyGVGv0k0SX5Gnr2snMcvqSd8hqCjOVeHNswI0WBKHCWMu5AAYKUpgSGsoTDJJDmfMscsbBfLgE0P00GQGr4D1poBfIk0LOXpyNEHi0CxC9RPQCrR70C6NL6B0C+9foQ42Al/2tXqveApi8v1YU/6baR7lQKxPDl6RsxygEBvV+HkwsiI3o5RxIicoGGDT7HLr/WrzJx89G0fh77j3D9kMoI1Q8lQb7z0DwWsEgVFxHUA== 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=oF0qLFaKv4AghSL54DoldLHbqzsGDeRp9BqDrQgtmvs=; b=OZ5y+psO7So+IaOO+lQlelNSnubEHfjcQlPoe/1/NUfMG/u8P+FWl8cpGcyJWRFB0oT3fcP7ryi+n28t4kNrSLy0eBhbuHaB7NoomCiTVA9hYKBg7APCBYnn7kzKhisFMYXtHzSNhl3RLNuUCKCesEJPNPPXmDaxf8ENijmKI2FGlHlLHVXV+cIEvduJg6S3iRhr4sBXRG+Xt6JqXYfsfQ0Mv7dj4ed4L0QZcgPHkuAC5o/4qQmKJtSi5uj7D3wf1veriHpW6lGHkVUlfn45AWfa5HZYu2OpRvoZDvsvkB3BagmNxQXUmvg5kOUtGAPfoimrep+QBNJnvhRoEweAiQ== 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=oF0qLFaKv4AghSL54DoldLHbqzsGDeRp9BqDrQgtmvs=; b=wtsT67j8hHevWMllF9sMXUZcu5zdacTW3wDNXZf5d1Ln5iy824RDwiLCfG9WYgP1rA9m8txqcEKaMfH4TDke91nyLH9uTBVJtkgiQJ4U0fzduwJXJFWRnjpBaY0OIoTYfLtLT3/6yADfzSIRKKWBuw8F6B2IitT8A9cfJN1rAFA= Received: from SJ0PR11MB4862.namprd11.prod.outlook.com (2603:10b6:a03:2de::16) by BY5PR11MB3976.namprd11.prod.outlook.com (2603:10b6:a03:187::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.20; Fri, 26 Feb 2021 07:35:31 +0000 Received: from SJ0PR11MB4862.namprd11.prod.outlook.com ([fe80::9c2d:ffbd:1695:c115]) by SJ0PR11MB4862.namprd11.prod.outlook.com ([fe80::9c2d:ffbd:1695:c115%7]) with mapi id 15.20.3890.020; Fri, 26 Feb 2021 07:35:31 +0000 From: =?Windows-1252?Q?Johan_Vikman_Lundstr=F6m_=28jvikman=29?= To: Andy Bierman , Kent Watsen CC: "Christofer Tornkvist (ctornkvi)" , "netconf@ietf.org" Thread-Topic: [netconf] NACM read access for actions Thread-Index: AQHWyhe8pG7lD1hfBEGgzpuUtjTj9Kpoe7qAgAAc1ACAAfJI8w== Date: Fri, 26 Feb 2021 07:35:31 +0000 Message-ID: References: <01000177d6745212-37524245-c74e-4de1-922e-53f80dac68e1-000000@email.amazonses.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [31.208.108.100] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 214ac9be-8d64-4d14-f3ca-08d8da291887 x-ms-traffictypediagnostic: BY5PR11MB3976: x-ms-exchange-minimumurldomainage: ietf.org#9484 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3a5P6YaR3r+t4FIcWHBFecGAZsGukk4nUhjE9of+vdgAPPFB0rcBccOh7HTsdfDxEkjO+owulF+a4Dgfym0/P4bYsmA3SWbqcqDPy17TIOkimODHsHJJIO3lxQEa6ZEC9L/w+ODieMxdZRzkkFQ8Rh2WuqzJYBKaqZxRxp9vH4suFV9EAvcF7q211TMjlJoFhOnISdk8yGiD7D9YyUUC5evMQoHk88eVelsdWC+//YNpBbShgiTOn3fLHeP/acGtKIJSLwnxAVJQGxpKTNw9+j4DKDzbKzTdjX94h0Vs2ALEHmn/Fprkr7lKeucLiWjsfprHDcT9tzmAVnnSCrF+xPZaWFmTooiUS46B+J5JL3rDSajGjb6a+xcQB0oScjKrxZjdYCEBq05znAtJcQ5GDullXqmaBV6CWqvM0WHjZDbDK9l2Z+o5Jb4klEgaIjdHafSNTiMZkivdMK7LbXUvLnxYBYGgg18uGEt5HQH+r3NEI30pBUB9oronXilHaSbUY56MtBjGZ4gY+uekOKmOzZLJNZqeoD4s/4TH9q1jhrWCKs0szHO81t03AyEfrG0nc+QKYw73Amg3kL5AvXap2OwEsnrFnP3iAcn7f7ZNnDY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB4862.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(396003)(346002)(366004)(376002)(4326008)(64756008)(5660300002)(66446008)(76116006)(66556008)(66476007)(52536014)(66946007)(33656002)(2906002)(186003)(91956017)(26005)(6506007)(54906003)(166002)(7696005)(478600001)(55016002)(8936002)(8676002)(110136005)(9686003)(316002)(966005)(53546011)(86362001)(71200400001)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?+4XpnR/ooaVl5QW7Z+rWG1lFJSkjqJWE/idi+mpiGnrqpwNZssFGxP7y?= =?Windows-1252?Q?/SRaUZZRdyCj4AZ6X+gAwcyDeZu1YFSQDgkOj8Lw4hMfDi2N9d3+8Xzz?= =?Windows-1252?Q?AhSK1xbYaAtV/nwidd8DywGS3AjlXwsZfo6Mq/Xl4F/JPRXw4Lb4xg1A?= =?Windows-1252?Q?iVln4M3YSLjAtKn5A6ThcYQtBBBotJ3rnmo1hfT4R+rJlfzQzF0M8AHy?= =?Windows-1252?Q?3xANfFNmUJZR6YIUpP5ul+GvpElK0pxrz/9x0EeSJbFwZ/hzpo+uYTYB?= =?Windows-1252?Q?YzC1X6t2zabgBi49ZnreS1oK9cU4GIn3Jrq5hXSBUvgm2lglxDHov1md?= =?Windows-1252?Q?Ia5aNMdLJaH+9RXVhZt3e5Mohc83Ox+ILyt7QXYqPvBAWznM1R57z1fB?= =?Windows-1252?Q?HYF8DILFPuXa/XNFsvaHJdZDlNXeh9rltw2w5vJFFCKdodOpc41V5d4P?= =?Windows-1252?Q?BywMG5rKoL8u3w2jYbGFXaoD3Wt+iq2w4nm4f96CgyFJ1Sljm2/PNWqL?= =?Windows-1252?Q?vBPzzirNbOmIyifB65yspNA6RNPB9kfbsGMtVaY9qDK5QNHRqRxoz/cs?= =?Windows-1252?Q?GaHmak93inDjJryD5MxxLr/IcNmMK9I9xlq6xJcJOr/lKjpSG7po6lj6?= =?Windows-1252?Q?0OqKqqp7FuBR1oeStujChjM4Md7WgsM0WT8Xn/ZoSywG97MzO89mLmld?= =?Windows-1252?Q?UsebRj49sOzWdxTtaTdErgBOw17ekh1xHYOkZVX57Jm11UAAo2wWB1J4?= =?Windows-1252?Q?mfaC0LmCW93Erw/oCd3hleOfMfYjApiwmTR0Csmp6gPKGUmaSLEs0zT2?= =?Windows-1252?Q?+w9Fqa9hZq9Y3AKUIFr9fhLkKVa2ckB3ZWMZwbZBtbIRe8XaOUsj6tyq?= =?Windows-1252?Q?NE0FVfRmQdpsOU/mDH6/lfOxQzigOncm76KOYclrnihJk5IH2U4ELU9S?= =?Windows-1252?Q?KbdO89rVxGTDetckDvvUFKwqJrXkG1hG5780BG5aY7hS3bNV59IFdlgJ?= =?Windows-1252?Q?GzRaB6dKAFaZnsJseda+Hgheu4iQWKXkIRFHDjyocK5QO5oMcoTEpObm?= =?Windows-1252?Q?ROmcMOvIoMVjGFoaPGbD8e6EzvfAifuOSInvYALLjsNYcYXN0o55T6BZ?= =?Windows-1252?Q?r/zO5liYleiyDF5A01gRVX76BUsQ2uS1VluO3xia8EnYqSWM4x64HbjQ?= =?Windows-1252?Q?FYHDpMKQLVUVh8ef2n6u3X2kJRealgZ8RKD6cKxmflUY8i6dCBGgI0ng?= =?Windows-1252?Q?xE9eEy4gMcP8g/I90n3LDDMXnKuLhstDpxDZ4MnZdOnsbNebvaBH522w?= =?Windows-1252?Q?GvnVIsb5+jxqrhjk5E8sd2xHxUlnVmQKuiuMKGvJGW8qB4p48IdAN59R?= =?Windows-1252?Q?nMcK9vE5CkpKqfYQjuGN1RZintKb0sSbJE2ikw1+tb03jm7C8iLjZ0vi?= =?Windows-1252?Q?xe8zgSru6d1QFa1hYg4KWQ=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SJ0PR11MB4862C7E65F306358235D869ABC9D9SJ0PR11MB4862namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB4862.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 214ac9be-8d64-4d14-f3ca-08d8da291887 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2021 07:35:31.1897 (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: ougF1TnUx1hpegjPXANWJKlFFF2baAmXHIw3FwTyrWN8EmcaJdJBvAa0gNoIHwCapJ31EghXVwou/xOJd6LcDA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3976 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [netconf] NACM read access for actions X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2021 07:35:42 -0000 --_000_SJ0PR11MB4862C7E65F306358235D869ABC9D9SJ0PR11MB4862namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Wed, Feb 24, 2021 at 3:52 PM Kent Watsen > wrote: Hi Christofer, Looking at unread email, I noticed your message didn't receive any response= s. Could someone with familiarity with this NACM-question reply? I think the question is whether the read access required for exec access ex= poses too much data. I think the original intent of the text is that read access to the containe= r or list element is required, not the entire subtree. It could be argued that read = access to the key leafs within a list entry is also required. JV: I agree with your interpretation of the question. Looking at the RFC an= d the default read being =93permit=94 I think the paragraphs makes sense, r= eusing the /interfaces/interface/reset-interface example an admin could for= instance add a deny on /interfaces for the group and thus stopping the ope= rator from using the action. When it gets interesting is when the the default read setting is =93deny=94= , it=92s not unreasonable to think that the admin wants to deny everything = and only open up what is needed. But then adding an explicit rule permit re= ad on /interfaces /interfaces/interface would open up a lot. Interpreting your thought on original intent, it would be enough to have re= ad access on /interfaces/interface[name=3D=92if0=92] OR /interfaces/interfa= ce, even if the default read permission was =91deny=92 (which would affect = /interface), right? /Johan Thanks, Kent Andy On Dec 4, 2020, at 3:40 AM, Christofer Tornkvist (ctornkvi) > wrot= e: Hi, I read in the NACM RFC 8341 that for actions to not be rejected they both must have execute access and also read access for all its parent (instance) nodes along the node hierarchy up to the top node -described by the path for the action node. The read access property, is that equivalent of having NACM rules stating read access for all parent (instance) nodes? If that is the case, does not that open up the node tree structure unnecessarily much? I support the idea of just having to state one NACM rule containing read and execute access for the action node itself for it to be able to be run, and also that all the parent (instance) nodes will be readable only along the path up to the action node without any additional NACM rules. And if there is a read access deny rule on any parent (instance) node the action will be rejected. Would appreciate a clarification. Below are references to RFC 8341. Regards /Christofer Tornkvist References in RFC 8341 are: Ch. 3.1.3 s.3 The new "pre-read data node acc. ctl" boxes in the diagram below refer to group read access as it relates to data node ancestors of an action or notification. As an example, if an action is defined as /interfaces/interface/reset-interface, the group must be authorized to (1) read /interfaces and /interfaces/interface and (2) execute on /interfaces/interface/reset-interface. Ch. 3.1.3 p.12 bullet 2 o If the operation defined in [RFC7950] is invoked, then read access is required for all instances in the hierarchy of data nodes that identifies the specific action in the datastore, and execute access is required for the action node. If the user is not authorized to read all the specified data nodes and execute the action, then the request is rejected with an "access-denied" error. _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_SJ0PR11MB4862C7E65F306358235D869ABC9D9SJ0PR11MB4862namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

On Wed, Feb 24, 2021 at 3:52 PM Kent Watsen <kent@watsen.net> wrote:

Hi Christofer,

 

Looking at unread email, I noticed your message didn= 't receive any responses.

 

Could someone with = familiarity with this NACM-question reply?

 

 

I think the question is whether the read access requ= ired for exec access exposes

too much data.

 

I think the original intent of the text is that read= access to the container or list

element is required, not the entire subtree.  I= t could be argued that read access to the

key leafs within a list entry is also required.=

 

 

JV: I agree with your interpret= ation of the question. Looking at the RFC and the default read being =93per= mit=94 I think the paragraphs makes sense, reusing the /interfaces/interfac= e/reset-interface example an admin could for instance add a deny on /interfaces for the group and thus stopping the= operator from using the action.

 

When it gets interesting is whe= n the the default read setting is =93deny=94, it=92s not unreasonable to th= ink that the admin wants to deny everything and only open up what is needed= . But then adding an explicit rule permit read on /interfaces /interfaces/interface would open up a lot.<= /span>

 

Interpreting your thought on or= iginal intent, it would be enough to have read access on /interfaces/interf= ace[name=3D=92if0=92] OR /interfaces/interface, even if the default read pe= rmission was =91deny=92 (which would affect /interface), right?

 

/Johan

 

Thanks,

Kent

 

 

Andy

 



On Dec 4, 2020, at 3:40 AM, Christofer Tornkvist (ct= ornkvi) <ctornkvi=3D40cisco.com@dmarc.ietf.org> wrote:=

 

Hi,=

 

I read in the NACM RFC 8341 that for actions to not be rejected

they both must have execute access and also read access

for all its parent (instance) nodes along the node hierarchy<= /span>

up to the top node -described by the path for the action node= .

 

The read access property, is that equivalent of having <= b>NACM rules

stating read access for all parent (instance) nodes?

 

If that is the case, does not that open up the node tree

structure unnecessarily much?

 

 

I support the idea of just having to state one NACM rule

containing read and execute access for the action node itself= for it

to be able to be run,=

and also that all the parent (instance) nodes

will be readable only along the path up to the action node wi= thout

any additional NACM<= /span> rules.

And if there is a read access deny rule on any parent (instan= ce) node

the action will be rejected.

 

 

Would appreciate a clarification.

 

Below are references to RFC 8341.

 

Regards

/Christofer Tornkvist<= span style=3D"font-size:12.0pt">

 

 

References in RFC 8341 are:

Ch. 3.1.3 s.3

   The new "pre-read data node acc. ctl" boxes in the diagra= m below

   refer to group read access as it relates to= data node ancestors of an

   action or notification.  As an ex= ample, if an action is defined as

   /interfaces/interface/reset-interface, the = group must be authorized=

   to (1) read /interfaces and /interfaces/int= erface and (2) execute on

   /interfaces/interface/reset-interface.

 

Ch. 3.1.3 p.12 bullet 2

   o  If the <action> operatio= n defined in [RFC7950] is invoked, then

      read access is required for all ins= tances in the hierarchy of data

      nodes that identifies the specific = action in the datastore, and

      execute access is required for the = action node.  If the user is

      not authorized to read all the spec= ified data nodes and execute

      the action, then the request is rej= ected with an "access-denied"

      error.<= /o:p>

&= nbsp;

 

___________________________________________= ____
netconf mailing list
netco= nf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

 

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--_000_SJ0PR11MB4862C7E65F306358235D869ABC9D9SJ0PR11MB4862namp_--