From nobody Wed Jul 1 07:26:31 2020 Return-Path: <010001730ac58f90-0ce0fc67-2c25-403e-98c4-983d7007ea68-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 4F0A43A0C41 for ; Wed, 1 Jul 2020 07:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRT8vle4WRoq for ; Wed, 1 Jul 2020 07:26:28 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A13863A0C3D for ; Wed, 1 Jul 2020 07:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1593613586; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=WDXzy8jRsF9V8Q8VSNY4IEpUdqQfm6xdpTmILCyOtM4=; b=SV95gukQD5cO7QKjBbagKoF0Fzy7RvQRQmarKafSdnp5yFow9YZQ4aVIvSeFtWDL tO1whtpIMz6Srhtxk7OLRGBmAJBMHPGpEcvtYCHTIarbvJctDyCSY7Bj6fqagmgow2g rA8YbXSL9fxk3/jZaA/VdziXh5ri0YfagHbrzf9g= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_BAE40F33-A9F4-4706-B1B6-489B6B924C42" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <010001730ac58f90-0ce0fc67-2c25-403e-98c4-983d7007ea68-000000@email.amazonses.com> Date: Wed, 1 Jul 2020 14:26:26 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.01-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Added restconf-next for restructuring error messages 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, 01 Jul 2020 14:26:29 -0000 --Apple-Mail=_BAE40F33-A9F4-4706-B1B6-489B6B924C42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Folks, I just added this =E2=80=9Crestconf-next=E2=80=9D issue for = restructuring error messages: https://github.com/netconf-wg/restconf-next/issues/3 = K. --Apple-Mail=_BAE40F33-A9F4-4706-B1B6-489B6B924C42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Folks,

I just added this =E2=80=9Crestconf-next=E2=80=9D issue for = restructuring error messages:

<= div class=3D"">
K.

= --Apple-Mail=_BAE40F33-A9F4-4706-B1B6-489B6B924C42-- From nobody Wed Jul 1 08:16:48 2020 Return-Path: <010001730af39de0-1e13fb74-a12c-4223-9d2c-4a0d60b7d0c5-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 2AE573A0F27 for ; Wed, 1 Jul 2020 08:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1txjrvjX9u0d for ; Wed, 1 Jul 2020 08:16:46 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C05C3A0F23 for ; Wed, 1 Jul 2020 08:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1593616604; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=yr2PjZUxt0KJykzNSg/q7HbfhFrvCY7X17w61jMvQPM=; b=R+g6WvVHAqslMDgUk5+9CIu/cMHxK/rGbKm4+XTUdGyoI4HJM/8/1sGG4eyJMPzL 9uacufXwYO7Gk1JCiOu2PelnL4HLCGRSeOJgdskf4zuSpmzkRdXSCGhBL7WEPFJdsIs XZq+hGyrbG5PpAaq3cEIgvRv01nw7btt6nlRo+7k= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_FD315D7D-8BF3-49CC-B19D-1CB6A3CFF46A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <010001730af39de0-1e13fb74-a12c-4223-9d2c-4a0d60b7d0c5-000000@email.amazonses.com> Date: Wed, 1 Jul 2020 15:16:44 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.01-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] restconf-next issue to let list/leaf-list be "data resources" 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, 01 Jul 2020 15:16:47 -0000 --Apple-Mail=_FD315D7D-8BF3-49CC-B19D-1CB6A3CFF46A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I added this =E2=80=9Crestconf-next=E2=80=9D issue for letting = list/leaf-list be "data resources": https://github.com/netconf-wg/restconf-next/issues/4 = K. --Apple-Mail=_FD315D7D-8BF3-49CC-B19D-1CB6A3CFF46A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I = added this =E2=80=9Crestconf-next=E2=80=9D issue for letting = list/leaf-list be "data resources":

<= div class=3D"" style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, = 0);">
K.

= --Apple-Mail=_FD315D7D-8BF3-49CC-B19D-1CB6A3CFF46A-- From nobody Wed Jul 1 08:16:58 2020 Return-Path: <010001730af3aad8-b7fdf478-34dd-4cd8-99ba-cc6d71cc8612-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 02A173A0F36 for ; Wed, 1 Jul 2020 08:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tADDoKcs1Ty for ; Wed, 1 Jul 2020 08:16:49 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD0A3A0F2B for ; Wed, 1 Jul 2020 08:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1593616608; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=NhLEOcfN22HVGa8qA7JW1bw075+kGabMyjLFqzxxq1Y=; b=bq43bj7McPlmLF9CQAtOIDCnkpYc9+ZTUGTbWaqOsGeztCWyi9yu95OqdNz82DNg d1H7c+KCslPpxkLPJZgAU5nBtiXKBUGtELC6ZeT636ZOHoVNKOcg8+81jiTUCIaLiSK KXhJMjhB1eIEJiHWzvTfhTwFgyDxkeu0FUn7LOQ8= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_6EB60A3B-3843-4B15-9544-7D7FA91A5E9A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <010001730af3aad8-b7fdf478-34dd-4cd8-99ba-cc6d71cc8612-000000@email.amazonses.com> Date: Wed, 1 Jul 2020 15:16:48 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.01-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] restconf-next issue to remove encoding the "list" for list-items in JSON encodings 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, 01 Jul 2020 15:16:57 -0000 --Apple-Mail=_6EB60A3B-3843-4B15-9544-7D7FA91A5E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I just added this =E2=80=9Crestconf-next=E2=80=9D issue to remove = encoding the "list" for list-items in JSON encodings: https://github.com/netconf-wg/restconf-next/issues/5 = K. --Apple-Mail=_6EB60A3B-3843-4B15-9544-7D7FA91A5E9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I = just added this =E2=80=9Crestconf-next=E2=80=9D issue to remove encoding = the "list" for list-items in JSON encodings:

<= div class=3D"" style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, = 0);">
K.

= --Apple-Mail=_6EB60A3B-3843-4B15-9544-7D7FA91A5E9A-- From nobody Wed Jul 1 09:41:32 2020 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 C6D8F3A12BA for ; Wed, 1 Jul 2020 09:41:30 -0700 (PDT) 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 eRw3zO1Od5rf for ; Wed, 1 Jul 2020 09:41:29 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 420E93A12B2 for ; Wed, 1 Jul 2020 09:41:29 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id y18so14056522lfh.11 for ; Wed, 01 Jul 2020 09:41:29 -0700 (PDT) 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=kGTq+/qaxYYu+rVDIQCV1A+DjR5aBZSfyPtQgLCozqU=; b=097K4c9yLsSlqaTVhkcfOy+2oKbIf+qDEGil3cxOXJ41zMHITSf0HvrgGQuvye9qiS xb2n73xvkZkxkgeuNHqSPJuxy6IrZb9LT5IJeqEY0hrMRxFKlcRie+7vmGHugCDIUyYc bmz10TUausFIl0Da+iVvUkSuQk7NKHgWKSd+eJcsu0OteJWFY5LnX+WmLz8HPCThGUIz zPbSQ5KWmnC9jvWZMsVPBWLbQIi1fJYOL17tsJyMWB5k5sSwesr6UXVePAuuG6hG+JDv j+JqlU0ejW63N/DlXzndVS7KduVKAZbpqRGJU4BZZeJ0JKxVEB0Y/GMpumdie0ziy3BM pn/Q== 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=kGTq+/qaxYYu+rVDIQCV1A+DjR5aBZSfyPtQgLCozqU=; b=XdvmMKC0NetXC9oB4QuRaD/2TqR6L9AKYtHozQ9LpA++OEkyA32saK9LZz7wXU48pk DQfoOz/yL0l2khxNEN+G9TFhgh+ztasyTFdDsYDcu5ZMa04OSnMMlE9v2N4UsFMyh2Ge 06kSSjz66//SmlCyJgOkY36P6tk5TktgRjSxJGuVFSBg5jl4Dxg31I8lYlBIwcYA5irr FSPMadVklkRqH3EivuViivl7RRkz/8BWSvhu2Kc5Xo18iHMwZyqOFvVgY/IkBzGrQRL5 +OkrkQwrIxbg2TOIlrPhccJV6BCdJZd2+kOqGFgRLPpol9Z4gNxHs0w57B/Q3VwyEjE/ NPLQ== X-Gm-Message-State: AOAM533OHxl3Ps5APPNxiRTG9gCQZrt7YFTGbf5FpcSGoTKuFTztwdoF 6U+1HH2/AnyjwaqvtYx3mIlfD2gCI4G2wp1cGKnuDopta/w= X-Google-Smtp-Source: ABdhPJzJIpFjHWjP1VAtdgJB4FC4lkuaMPhBRuGNWvNLwl4UNk9UfRgidcnt9zwrPsnj/zTUW8qnhI8D4loaUFEdsQ4= X-Received: by 2002:a19:4247:: with SMTP id p68mr15698314lfa.22.1593621687349; Wed, 01 Jul 2020 09:41:27 -0700 (PDT) MIME-Version: 1.0 References: <010001730ac58f90-0ce0fc67-2c25-403e-98c4-983d7007ea68-000000@email.amazonses.com> In-Reply-To: <010001730ac58f90-0ce0fc67-2c25-403e-98c4-983d7007ea68-000000@email.amazonses.com> From: Andy Bierman Date: Wed, 1 Jul 2020 09:41:16 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="00000000000094cd3905a963f6a7" Archived-At: Subject: Re: [netconf] Added restconf-next for restructuring error messages 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, 01 Jul 2020 16:41:31 -0000 --00000000000094cd3905a963f6a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I don't agree that any NBC changes are needed to RESTCONF, including this one. I agree servers usually send 1 error, but not always. E.g., the operation returns as many errors as it can find and does not stop on the first error. It is not a burden to have an "errors" container so the protocol allows for multiple errors and is the same data model for XML and JSON. Andy On Wed, Jul 1, 2020 at 7:26 AM Kent Watsen wrote: > Folks, > > I just added this =E2=80=9Crestconf-next=E2=80=9D issue for restructuring= error messages: > > https://github.com/netconf-wg/restconf-next/issues/3 > > K. > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --00000000000094cd3905a963f6a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I don't agree that any NBC chan= ges are needed to RESTCONF, including this one.
I agree servers u= sually send 1 error, but not always. E.g., the <validate> operation
returns as many errors as it can find and does not stop on the fir= st error.
It is not a burden to have an "errors" contai= ner so the protocol allows for multiple errors
and is the same da= ta model for XML and JSON.

Andy



On Wed, Jul 1, 2020 at 7:26 AM Kent Watsen <kent+ietf@watsen.net> wrote:
Folks,

I just added this = =E2=80=9Crestconf-next=E2=80=9D issue for restructuring error messages:


K.

______________________________________= _________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--00000000000094cd3905a963f6a7-- From nobody Wed Jul 1 11:12:50 2020 Return-Path: <010001730b94bddd-e070a169-e418-46ec-b639-294fa7c5fbd2-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 64E323A0937 for ; Wed, 1 Jul 2020 11:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33xYkTP4iGPB for ; Wed, 1 Jul 2020 11:12:45 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEF23A0929 for ; Wed, 1 Jul 2020 11:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1593627164; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=EMP7A3m0gOqsZaE/w+zBUIChvyWVpXFI9rYJ+PIqzv0=; b=HB1QtGJ05MvDNYQfqigmyv77D7qe9iVNNczf9Mwk1JVY8NzVTAJgUjP8YCVi1v8l YWEUEaU++7PM7JqKC31XjC03Dr7hOFvd9qguXsmQi898XLa3Hb7HFHFytwBNcTy/3Am UXJ3cQiZo34znO4htWD98i473i1REUnOjoUbZh6Y= From: Kent Watsen Message-ID: <010001730b94bddd-e070a169-e418-46ec-b639-294fa7c5fbd2-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A3C69E4B-2EC9-45A6-8D24-6B4FC499DA61" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 1 Jul 2020 18:12:44 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: Andy Bierman References: <010001730ac58f90-0ce0fc67-2c25-403e-98c4-983d7007ea68-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.01-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Added restconf-next for restructuring error messages 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, 01 Jul 2020 18:12:48 -0000 --Apple-Mail=_A3C69E4B-2EC9-45A6-8D24-6B4FC499DA61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I was expecting this response ;) We could grandfather the current =E2=80=9Cerrors=E2=80=9D structure by, = e.g., using a =E2=80=9Cchoice=E2=80=9D... We don=E2=80=99t even have to wait for RC-next, as someone could submit = a short I-D for just this issue. We just need to define a way for the = client to signal to the server its preferences=E2=80=A6likely the = existing "Accept-Type=E2=80=9D header could be used. K. > On Jul 1, 2020, at 12:41 PM, Andy Bierman wrote: >=20 > Hi, >=20 > I don't agree that any NBC changes are needed to RESTCONF, including = this one. > I agree servers usually send 1 error, but not always. E.g., the = operation > returns as many errors as it can find and does not stop on the first = error. > It is not a burden to have an "errors" container so the protocol = allows for multiple errors > and is the same data model for XML and JSON. >=20 > Andy >=20 >=20 >=20 > On Wed, Jul 1, 2020 at 7:26 AM Kent Watsen > wrote: > Folks, >=20 > I just added this =E2=80=9Crestconf-next=E2=80=9D issue for = restructuring error messages: >=20 > https://github.com/netconf-wg/restconf-next/issues/3 = >=20 > K. >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = --Apple-Mail=_A3C69E4B-2EC9-45A6-8D24-6B4FC499DA61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I was expecting this response  ;)
We could grandfather the current = =E2=80=9Cerrors=E2=80=9D structure by, e.g.,= using a =E2=80=9Cchoice=E2=80=9D...

We don=E2=80=99t even have to wait for = RC-next, as someone could submit a short I-D for just this issue.  We just need to define a way for the client to = signal to the server its preferences=E2=80=A6likely the existing = "Accept-Type=E2=80=9D header could be used.

K.


On Jul 1, 2020, at 12:41 PM, Andy Bierman <andy@yumaworks.com> = wrote:

Hi,

I don't agree that any NBC changes are needed to RESTCONF, = including this one.
I agree servers usually send 1 = error, but not always. E.g., the <validate> operation
returns as many errors as it can find and does not stop on = the first error.
It is not a burden to have an = "errors" container so the protocol allows for multiple errors
and is the same data model for XML and JSON.

Andy



On Wed, Jul 1, 2020 at 7:26 AM Kent = Watsen <kent+ietf@watsen.net> wrote:
Folks,

I just added this =E2=80=9Crestconf-next=E2= =80=9D issue for restructuring error messages:

<= div class=3D"">
K.

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

= --Apple-Mail=_A3C69E4B-2EC9-45A6-8D24-6B4FC499DA61-- From nobody Wed Jul 1 16:05:15 2020 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 31A593A0983 for ; Wed, 1 Jul 2020 16:05:14 -0700 (PDT) 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 8GxAEh8wKcxW for ; Wed, 1 Jul 2020 16:05:12 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 5C6C03A095A for ; Wed, 1 Jul 2020 16:05:12 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id g2so14712001lfb.0 for ; Wed, 01 Jul 2020 16:05:12 -0700 (PDT) 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=xbsxgR/bAzuXEyfmAOQL0UK4cOqjzoQDNYlIO6u9lLU=; b=BIr99dfEQ9zuionter1ZJD0EFg3l4ydJSkUEh71VyQjYDUxjcOZILxOgDc3McCg5od FXZ9YMKsgyrj0iunS3IFl/3pBku5PGMT33oTEet8Lz8AhpxEhqRitw/rS0OdVVTyRcs3 bmGRU9nNd4Jt0FXRvwBLYmQSf2RuBkwl8R20TOgqSizZ6/7wvi+3eMPYuSEq3nLe4ULr 2662Nml7aKGd09cfwc8MQLpfsqF0crdXNH0BqRptRbmd58YVrbGSgoDyQdG9xWsPMwv5 BQlzGjUHO2niz5edfwjNoZFauDYdjJTpw6EidVorDLJw7NqYe2Pk4xvO16sZB1SoBRUx r4zQ== 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=xbsxgR/bAzuXEyfmAOQL0UK4cOqjzoQDNYlIO6u9lLU=; b=BJYQoUVecouvAxjdZKf/XSbbq+ws0fWqWjuLesxaKKXrcg4T8W8tC1uc7mU1zuaokw 8gSYLt4fMJ+/xdu7D+0LaRgwa3kxUvCc5r2keppelk+LyZu8nZqaSBtQre7qnqWEkw5u Og9xeNTpbIHtOJqcI/M7Z7B6Gb2UiPGcJqAE0FdYg0fSLX0htxxDiPM63U7x7/Kj8jKY hcc8WjboO1J5BxiM2FE2Ew+iDwcBq8YngU4u8dEYJN+d1JUE+T6uYJChlWn8C2xoBj+f PR6K8stI9cF41BhjopueGOMSTPMZpqRq4g1G6cWV6dH9oU6vxO+3MA6VTZ/MCpI1pCN+ oF+Q== X-Gm-Message-State: AOAM532JjbhSeueC991an8tCytLw8D2uWRFud71VwYVd59vs/XPF0Ud5 dDoq9SVUu/Nn3Afa6p7eIx32v4SANBR8DXhQimE6fUqhi9o= X-Google-Smtp-Source: ABdhPJx8tGKzeUvjDbDJBd2nRxS781tJSUoR5WOwNJ26dHmANIl3EgD4CxE4SzdAW5ChkbnsgFBaLHXXo0udoXFj1D4= X-Received: by 2002:ac2:5e34:: with SMTP id o20mr16529125lfg.5.1593644710627; Wed, 01 Jul 2020 16:05:10 -0700 (PDT) MIME-Version: 1.0 References: <010001730ac58f90-0ce0fc67-2c25-403e-98c4-983d7007ea68-000000@email.amazonses.com> <010001730b94bddd-e070a169-e418-46ec-b639-294fa7c5fbd2-000000@email.amazonses.com> In-Reply-To: <010001730b94bddd-e070a169-e418-46ec-b639-294fa7c5fbd2-000000@email.amazonses.com> From: Andy Bierman Date: Wed, 1 Jul 2020 16:04:59 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e0227105a96952a4" Archived-At: Subject: Re: [netconf] Added restconf-next for restructuring error messages 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, 01 Jul 2020 23:05:14 -0000 --000000000000e0227105a96952a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 1, 2020 at 11:12 AM Kent Watsen wrote: > I was expecting this response ;) > > We could grandfather the current =E2=80=9Cerrors=E2=80=9D structure by, e= .g., using a > =E2=80=9Cchoice=E2=80=9D... > > We don=E2=80=99t even have to wait for RC-next, as someone could submit a= short > I-D for just this issue. We just need to define a way for the client to > signal to the server its preferences=E2=80=A6likely the existing "Accept-= Type=E2=80=9D > header could be used. > > Seems like a lot of trouble to save about 8 bytes in the JSON response. Adding a request header (larger than 8 byes) actually increases the overall size of the operation. I prefer stability and consistency across XML and JSON encoding of the same protocol messages. K. > > Andy > > On Jul 1, 2020, at 12:41 PM, Andy Bierman wrote: > > Hi, > > I don't agree that any NBC changes are needed to RESTCONF, including this > one. > I agree servers usually send 1 error, but not always. E.g., the > operation > returns as many errors as it can find and does not stop on the first erro= r. > It is not a burden to have an "errors" container so the protocol allows > for multiple errors > and is the same data model for XML and JSON. > > Andy > > > > On Wed, Jul 1, 2020 at 7:26 AM Kent Watsen wrote: > >> Folks, >> >> I just added this =E2=80=9Crestconf-next=E2=80=9D issue for restructurin= g error messages: >> >> https://github.com/netconf-wg/restconf-next/issues/3 >> >> K. >> >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > --000000000000e0227105a96952a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable




<= div dir=3D"ltr">Hi,

I don't agree that any NBC chang= es are needed to RESTCONF, including this one.
I agree servers us= ually send 1 error, but not always. E.g., the <validate> operation
returns as many errors as it can find and does not stop on the firs= t error.
It is not a burden to have an "errors" contain= er so the protocol allows for multiple errors
and is the same dat= a model for XML and JSON.

Andy



On Wed, Jul 1, 2020 at 7:26 AM Kent Watsen <kent+ietf@watsen.net>= ; wrote:
Folks,

I just added this =E2=80=9Crestconf-next= =E2=80=9D issue for restructuring error messages:


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

--000000000000e0227105a96952a4-- From nobody Thu Jul 2 17:20:48 2020 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 B10D73A093D; Thu, 2 Jul 2020 17:20:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rwilton@cisco.com, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373562770.30173.10529598946753105952@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:20:27 -0700 Archived-At: Subject: [netconf] netconf - Requested session has been scheduled for IETF 108 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: Fri, 03 Jul 2020 00:20:28 -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 (1:40 requested) Tuesday, 28 July 2020, Session I 1100-1240 Room Name: Room 4 size: 4 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/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): 100 Minutes Number of Attendees: 65 Conflicts to Avoid: Chair Conflict: netmod httpbis tcpm idr Technology Overlap: opsarea opsawg Key Participant Conflict: anima rats People who must be present: Mahesh Jethanandani Kent Watsen Robert Wilton Resources Requested: Special Requests: Chair is not available on Friday --------------------------------------------------------- From nobody Wed Jul 8 17:20:45 2020 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 D613E3A0A47; Wed, 8 Jul 2020 17:20:42 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159425404276.17725.3273200947906120844@ietfa.amsl.com> Date: Wed, 08 Jul 2020 17:20:42 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-crypto-types-16.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, 09 Jul 2020 00:20:44 -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-16.txt Pages : 53 Date : 2020-07-08 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-16 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 Jul 8 17:21:43 2020 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 970BA3A0A65; Wed, 8 Jul 2020 17:21:42 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159425410258.14486.11714395689289278988@ietfa.amsl.com> Date: Wed, 08 Jul 2020 17:21:42 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-11.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, 09 Jul 2020 00:21: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 : A YANG Data Model for a Truststore Author : Kent Watsen Filename : draft-ietf-netconf-trust-anchors-11.txt Pages : 35 Date : 2020-07-08 Abstract: This document defines a YANG 1.1 data model for configuring globally- accessible bags of certificates and public keys that can be referenced by other data models for trust. 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: * "2020-07-08" --> 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-11 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-trust-anchors-11 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 Jul 8 17:22:54 2020 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 8AEF23A0A49; Wed, 8 Jul 2020 17:22:49 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159425416952.14334.15615811461093122775@ietfa.amsl.com> Date: Wed, 08 Jul 2020 17:22:49 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-keystore-18.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, 09 Jul 2020 00:22:50 -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 Keystore Author : Kent Watsen Filename : draft-ietf-netconf-keystore-18.txt Pages : 46 Date : 2020-07-08 Abstract: This document defines a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted. Asymmetric keys may be associated with certificates. 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 * "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: * "2020-07-08" --> 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-keystore-18 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 8 17:27:43 2020 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 045D73A0A65; Wed, 8 Jul 2020 17:27:41 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159425446096.14334.5048966471441767417@ietfa.amsl.com> Date: Wed, 08 Jul 2020 17:27:41 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-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: Thu, 09 Jul 2020 00:27:41 -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-07.txt Pages : 31 Date : 2020-07-08 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-07 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tcp-client-server-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 Wed Jul 8 17:28:56 2020 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 DB0BB3A0A65; Wed, 8 Jul 2020 17:28:54 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159425453485.14117.13821098981602126117@ietfa.amsl.com> Date: Wed, 08 Jul 2020 17:28:54 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-20.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, 09 Jul 2020 00:28:55 -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 Authors : Kent Watsen Gary Wu Filename : draft-ietf-netconf-ssh-client-server-20.txt Pages : 59 Date : 2020-07-08 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: * "2020-07-08" --> 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-20 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 8 17:30:06 2020 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 71D3E3A0A66; Wed, 8 Jul 2020 17:30:04 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159425460442.17925.608140647287214923@ietfa.amsl.com> Date: Wed, 08 Jul 2020 17:30:04 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-20.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, 09 Jul 2020 00:30: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 TLS Clients and TLS Servers Authors : Kent Watsen Gary Wu Filename : draft-ietf-netconf-tls-client-server-20.txt Pages : 57 Date : 2020-07-08 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: * "2020-07-08" --> 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-20 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 8 17:32:13 2020 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 288803A0A66; Wed, 8 Jul 2020 17:32:08 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159425472813.14117.9852128395936600431@ietfa.amsl.com> Date: Wed, 08 Jul 2020 17:32:08 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-http-client-server-04.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, 09 Jul 2020 00:32:08 -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-04.txt Pages : 30 Date : 2020-07-08 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: * "2020-07-08" --> 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-04 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-http-client-server-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 8 17:33:06 2020 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 816A43A0AFE; Wed, 8 Jul 2020 17:32:57 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159425477748.24840.1030768034403180864@ietfa.amsl.com> Date: Wed, 08 Jul 2020 17:32:57 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-client-server-20.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, 09 Jul 2020 00:33:02 -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-20.txt Pages : 57 Date : 2020-07-08 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: * "2020-07-08" --> 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-20 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-client-server-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 8 17:33:58 2020 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 923BA3A0AE7; Wed, 8 Jul 2020 17:33:46 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159425482654.17494.16595985832026206145@ietfa.amsl.com> Date: Wed, 08 Jul 2020 17:33:46 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-restconf-client-server-20.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, 09 Jul 2020 00:33:54 -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-20.txt Pages : 55 Date : 2020-07-08 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: * "2020-07-08" --> 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-20 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-client-server-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 8 18:39:20 2020 Return-Path: <01000173313a1282-63366836-4a52-453a-a111-fd3334b2506e-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 5AA0F3A0BC7 for ; Wed, 8 Jul 2020 18:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDpE7e7eEm6j for ; Wed, 8 Jul 2020 18:39:17 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB71F3A0BA5 for ; Wed, 8 Jul 2020 18:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1594258756; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=jJ1CuCZzpr26X3x4oj2YiQ5+q7iXv0tJOhaVXPuLHLE=; b=LQ1fC+spcqJSbbcWNsdh7YZgSuGmuIo2f3WkFPHUBVZw7b/Ab1Gg4iAECVjlvsSs JhzubVlJ7W1JC2MixGa7XqzJMSpcCnTykkWGBgYjU47EVXyt4aGClcOEiX0FY6B68Kr oUY+8Y6ms3am1wuCDNdAmF1PG0aeE0U7IYSfe/Ig= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_9FAD2F7D-A104-4A14-B049-1604EEE66987" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000173313a1282-63366836-4a52-453a-a111-fd3334b2506e-000000@email.amazonses.com> Date: Thu, 9 Jul 2020 01:39:16 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.09-54.240.48.93 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Regarding today's 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, 09 Jul 2020 01:39:19 -0000 --Apple-Mail=_9FAD2F7D-A104-4A14-B049-1604EEE66987 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii TR;DL; - first 3 WGLC drafts updated per comments received - please review to ensure your comments were addressed! - remaining drafts 99% WGLC-ready - just a few niggles left ;) K. crypto-types * Updated draft title (refer to "Groupings" too). * Removed 'end-entity-certs-grouping' as it wasn't being used anywhere. * Removed 'trust-anchor-certs-grouping' as it was no longer being used after modifying 'local-or-truststore-certs-grouping' to use lists (not leaf-lists). * Renamed "cert" to "cert-data" in trust-anchor-cert-grouping. * Added "csr-info" typedef, to complement the existing "csr" typedef. * Added "ocsp-request" and "ocsp-response" typedefs, to complement the existing "crl" typedef. * Added "encrypted" cases to both symmetric-key-grouping and asymmetric-key-pair-grouping (Moved from Keystore draft). * Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams]. * Updated the Security Considerations section. truststore * Corrected module prefix registered in the IANA Considerations section. * Modified 'local-or-truststore-certs-grouping' to use a list (not a leaf-list). * Added new example section "The Local or Truststore Groupings". * Clarified expected behavior for "built-in" certificates in * Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams]. * Updated the Security Considerations section. keystore * Removed dangling/unnecessary ref to RFC 8342. * r/MUST/SHOULD/ wrt strength of keys being configured over transports. [UPDATE: oops, I think I deleted it altogether later] * Added an example for the "certificate-expiration" notification. * Clarified that OS MAY have a multiplicity of underlying keystores and/or HSMs. * Clarified expected behavior for "built-in" keys in * Clarified the "Migrating Configuration to Another Server" section. * Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams]. * Updated the Security Considerations section. tcp-client-server * Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams]. * Updated the Security Considerations section. ssh-client-server * Added a "must 'public-key or password or hostbased or none or certificate'" statement to the "user" node in ietf-ssh-client * Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams]. * Moved the "ietf-ssh-common" module section to proceed the other two module sections. * Updated the Security Considerations section. tls-client-server * Modified the 'must' expression in the "ietf-tls-client:server- authention" node to cover the "raw-public-keys" and "psks" nodes also. * Added a "must 'ca-certs or ee-certs or raw-public-keys or psks'" statement to the ietf-tls-server:client-authentication" node. * Added "mandatory true" to "choice auth-type" and a "presence" statement to its ancestor. * Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams]. * Moved the "ietf-ssh-common" module section to proceed the other two module sections. * Updated the Security Considerations section. http-client-server * Added a parent "container" to "client-identity-grouping" so that it could be better used by the proxy model. * Added a "choice" to the proxy model enabling selection of proxy types. * Added 'http-client-stack-grouping' and 'http-server-stack- grouping' convenience groupings. * Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams]. * Updated the Security Considerations section. netconf-client-server * Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams]. * Removed expanded tree diagrams that were listed in the Appendix. * Updated the Security Considerations section. restconf-client-server * Moved and changed "must" statement so that either TLS *or* HTTP auth must be configured. * Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams]. * Updated the Security Considerations section. --Apple-Mail=_9FAD2F7D-A104-4A14-B049-1604EEE66987 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
TR;DL;  

    - first 3 WGLC drafts updated per comments = received
        - please = review to ensure your comments were addressed!

    - remaining drafts 99% = WGLC-ready 
        - just = a few niggles left  ;)

K.


crypto-types

   *  Updated draft title = (refer to "Groupings" too).

  =  *  Removed 'end-entity-certs-grouping' as it = wasn't being used
    =   anywhere.

  =  *  Removed 'trust-anchor-certs-grouping' as it was = no longer being
      used after = modifying 'local-or-truststore-certs-grouping' to use
 =     lists (not leaf-lists).

   *  Renamed "cert" to "cert-data" in = trust-anchor-cert-grouping.

  =  *  Added "csr-info" typedef, to complement the = existing "csr"
      typedef.

   *  Added "ocsp-request" = and "ocsp-response" typedefs, to complement
  =     the existing "crl" typedef.

   *  Added "encrypted" cases to both = symmetric-key-grouping and
    =   asymmetric-key-pair-grouping (Moved from = Keystore draft).

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Updated the Security Considerations section.



truststore

   *  Corrected module prefix registered = in the IANA Considerations
    =   section.

  =  *  Modified 'local-or-truststore-certs-grouping' to = use a list (not a
    =   leaf-list).

  =  *  Added new example section "The Local or = Truststore Groupings".

  =  *  Clarified expected behavior for = "built-in" certificates in
    =   <operational>

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Updated the Security Considerations section.



keystore

  =  *  Removed dangling/unnecessary ref to RFC 8342.

   *  r/MUST/SHOULD/ wrt = strength of keys being configured over
    =   transports.  [UPDATE: oops, I think I deleted it = altogether later]

  =  *  Added an example for the = "certificate-expiration" notification.

   *  Clarified that OS MAY have a = multiplicity of underlying keystores
    =   and/or HSMs.

  =  *  Clarified expected behavior for "built-in" keys = in <operational>

  =  *  Clarified the "Migrating Configuration to = Another Server" section.

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Updated the Security Considerations section.



tcp-client-server

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Updated the Security Considerations section.



ssh-client-server

  =  *  Added a "must 'public-key or password or = hostbased or none or
    =   certificate'" statement to the "user" node in = ietf-ssh-client

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Moved the "ietf-ssh-common" module section = to proceed the other
      two = module sections.

  =  *  Updated the Security Considerations section.



tls-client-server

  =  *  Modified the 'must' expression in the = "ietf-tls-client:server-
    =   authention" node to cover the "raw-public-keys" = and "psks" nodes
      also.

   *  Added a "must = 'ca-certs or ee-certs or raw-public-keys or psks'"
  =     statement to the = ietf-tls-server:client-authentication" node.

   *  Added "mandatory true" to "choice = auth-type" and a "presence"
    =   statement to its ancestor.

 =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Moved the "ietf-ssh-common" module section = to proceed the other
      two = module sections.

  =  *  Updated the Security Considerations section.



http-client-server

  =  *  Added a parent "container" to = "client-identity-grouping" so that
    =   it could be better used by the proxy model.

   *  Added a "choice" to the proxy model = enabling selection of proxy
    =   types.

  =  *  Added 'http-client-stack-grouping' and = 'http-server-stack-
      grouping' = convenience groupings.

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Updated the Security Considerations section.



netconf-client-server

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Removed expanded tree diagrams that were listed = in the Appendix.

  =  *  Updated the Security Considerations section.



restconf-client-server

   *  Moved = and changed "must" statement so that either TLS *or* HTTP
      auth must be configured.

   *  Expanded "Data Model = Overview section(s) [remove "wall" of tree
  =     diagrams].

  =  *  Updated the Security Considerations section.




= --Apple-Mail=_9FAD2F7D-A104-4A14-B049-1604EEE66987-- From nobody Thu Jul 9 07:11:13 2020 Return-Path: <0100017333ea7297-2838a6f2-40ad-4ca5-a83a-23d3014bef92-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 2C6553A0B0E for ; Thu, 9 Jul 2020 07:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoHxmoeX8BFZ for ; Thu, 9 Jul 2020 07:11:11 -0700 (PDT) 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 D23973A0B02 for ; Thu, 9 Jul 2020 07:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1594303869; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=VFf+Lv9dtWLAKDcOQJSAPIJ3MGfk7J8+JaP1phIpbec=; b=OjF1UHSTvtbQ/Mv9OWCF/K5Ss2h8t/jdtLOaV8Ab3ICXcbWHZwudj1cX66pKqgV4 bCehMycZ/NcfV4qzXWm4n6D03Nct1ghBOBO2R2LqOzutHJI6h5oXJxfzMipZCtw49dl yux1nPjpp2ZuTL+EJGM3r6KYNx+1RnH3TjMHZYO0= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_A043D553-FF2B-4B2C-8787-125406B63C3C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 9 Jul 2020 14:11:09 +0000 References: <01000173313a1282-63366836-4a52-453a-a111-fd3334b2506e-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <01000173313a1282-63366836-4a52-453a-a111-fd3334b2506e-000000@email.amazonses.com> Message-ID: <0100017333ea7297-2838a6f2-40ad-4ca5-a83a-23d3014bef92-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.09-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] question regarding key naming 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, 09 Jul 2020 14:11:12 -0000 --Apple-Mail=_A043D553-FF2B-4B2C-8787-125406B63C3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Question: In the crypto-types draft, the symmetric and asymmetric key definitions = each support three encodings for the secret key-data: cleartext, hidden, = and encrypted. To see this, here are direct links to the tree diagrams: - = https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.1= .4.2 = - = https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.1= .4.4 = My question is, should the =E2=80=9Ckey=E2=80=9D and =E2=80=9Cprivate-key=E2= =80=9D nodes be renamed to =E2=80=9Ccleartext-key=E2=80=9D and = =E2=80=9Ccleartext-private-key=E2=80=9D? PROs: - a positive assertion the key is in the clear is more secure CONs: - a longer name for the most common case Thoughts? PS: I=E2=80=99m aware that the truststore draft=E2=80=99s "Data at = Rest=E2=80=9D Security Consideration section has a copy/paste error in = it, which I=E2=80=99ll update that before the cutoff... K. --Apple-Mail=_A043D553-FF2B-4B2C-8787-125406B63C3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Question:

In the crypto-types draft, the symmetric and asymmetric key = definitions each support three encodings for the secret key-data: = cleartext, hidden, and encrypted.  To see this, here are direct = links to the tree diagrams:

    - https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#= section-2.1.4.2

My question is, should the =E2=80=9Ckey=E2=80=9D and = =E2=80=9Cprivate-key=E2=80=9D nodes be renamed to =E2=80=9Ccleartext-key=E2= =80=9D and =E2=80=9Ccleartext-private-key=E2=80=9D?

    = PROs:
        - a positive = assertion the key is in the clear is more secure

    CONs:
        - a longer name for the most = common case

Thoughts?



PS: I=E2=80=99m aware that the truststore draft=E2=80=99s = "Data at Rest=E2=80=9D Security Consideration section has a copy/paste = error in it, which I=E2=80=99ll update that before the = cutoff...

K.


= --Apple-Mail=_A043D553-FF2B-4B2C-8787-125406B63C3C-- From nobody Thu Jul 9 07:27:23 2020 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 1B6553A0BF3 for ; Thu, 9 Jul 2020 07:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGavgHlgSQNo for ; Thu, 9 Jul 2020 07:27:19 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E80B3A0BF2 for ; Thu, 9 Jul 2020 07:27:18 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A574F830; Thu, 9 Jul 2020 16:27:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id gwdxBoUWtq5Q; Thu, 9 Jul 2020 16:27:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Jul 2020 16:27:16 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E98E20156; Thu, 9 Jul 2020 16:27:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id 44H2kGSx5oz0; Thu, 9 Jul 2020 16:27:16 +0200 (CEST) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 0BF9B200E4; Thu, 9 Jul 2020 16:27:16 +0200 (CEST) Date: Thu, 9 Jul 2020 16:27:15 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: "netconf@ietf.org" Message-ID: <20200709142715.6a3wqdeht2ipiryl@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <01000173313a1282-63366836-4a52-453a-a111-fd3334b2506e-000000@email.amazonses.com> <0100017333ea7297-2838a6f2-40ad-4ca5-a83a-23d3014bef92-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0100017333ea7297-2838a6f2-40ad-4ca5-a83a-23d3014bef92-000000@email.amazonses.com> X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] question regarding key naming 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, 09 Jul 2020 14:27:21 -0000 On Thu, Jul 09, 2020 at 02:11:09PM +0000, Kent Watsen wrote: > Question: >=20 > In the crypto-types draft, the symmetric and asymmetric key definitions= each support three encodings for the secret key-data: cleartext, hidden,= and encrypted. To see this, here are direct links to the tree diagrams: >=20 > - https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#se= ction-2.1..4.2 > - https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#se= ction-2.1..4.4 >=20 > My question is, should the =E2=80=9Ckey=E2=80=9D and =E2=80=9Cprivate-k= ey=E2=80=9D nodes be renamed to =E2=80=9Ccleartext-key=E2=80=9D and =E2=80= =9Ccleartext-private-key=E2=80=9D? >=20 > PROs: > - a positive assertion the key is in the clear is more secure >=20 > CONs: > - a longer name for the most common case >=20 > Thoughts? I think longer names are a good thing here since the longer name may also serve as a warning. Perhaps raw-key (hidden-key, encrypted-key) and raw-private-key (hidden-private-key, encrypted-private-key) if you want shorter names? /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 9 07:43:42 2020 Return-Path: <01000173340803ac-47ae5791-0b76-479d-8be2-b8904ca48535-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 818D33A0C3D for ; Thu, 9 Jul 2020 07:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=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 87oe2QsaTPXT for ; Thu, 9 Jul 2020 07:43:28 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00D83A0C34 for ; Thu, 9 Jul 2020 07:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1594305807; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ecHUdQ/u97p6wSccFwC35hOBa3/PPrF6K39r9+LOX1M=; b=ieh3nfeM3fjLVeDZwLcON5fO/A5vF5IZmpxc6TXK13iX2MiFPOo2w7Xpap+wfrgy OBxRdqULMYCE5tZq+KNXoRQThsQA8MQQNu4cTN+wSoNllMgXwsbeZ1h/G2VpPQd6AKW qywu0mwxqXjwu4uFsodKxpwxw9dt058ytB56r3OI= From: Kent Watsen Message-ID: <01000173340803ac-47ae5791-0b76-479d-8be2-b8904ca48535-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1E1DD9BD-58C7-4189-923F-6A8E1531E0FA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 9 Jul 2020 14:43:27 +0000 In-Reply-To: <20200709142715.6a3wqdeht2ipiryl@anna.jacobs.jacobs-university.de> Cc: "netconf@ietf.org" To: Juergen Schoenwaelder References: <01000173313a1282-63366836-4a52-453a-a111-fd3334b2506e-000000@email.amazonses.com> <0100017333ea7297-2838a6f2-40ad-4ca5-a83a-23d3014bef92-000000@email.amazonses.com> <20200709142715.6a3wqdeht2ipiryl@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.09-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] question regarding key naming 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, 09 Jul 2020 14:43:41 -0000 --Apple-Mail=_1E1DD9BD-58C7-4189-923F-6A8E1531E0FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > I think longer names are a good thing here since the longer name may > also serve as a warning. Exactly. > Perhaps raw-key (hidden-key, encrypted-key) and raw-private-key > (hidden-private-key, encrypted-private-key) if you want shorter names? =E2=80=9CRaw=E2=80=9D is not a bad option. Semantically, the = difference to =E2=80=9Ccleartext=E2=80=9D seems very small. Length = isn=E2=80=99t a huge-issue either, being a programmatic API. Maybe one = is preferred from a historical-use perspective? (Rich, maybe you can = comment here?) Here=E2=80=99s a couple relevant snippets from = https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.2= .1: = ex-octet-string-based-symmetric-key ct:octet-string-key-format base64encodedvalue=3D=3D ex-subject-public-info-based-asymmetric-key ct:subject-public-key-info-format base64encodedvalue=3D=3D ct:rsa-private-key-format base64encodedvalue=3D=3D ex-cert base64encodedvalue=3D=3D The name is not visually prevalent in context --> any prefix would be = fine... K. --Apple-Mail=_1E1DD9BD-58C7-4189-923F-6A8E1531E0FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I think longer names are a good thing here = since the longer name may
also serve as a warning.

Exactly.


Perhaps raw-key = (hidden-key, encrypted-key) and raw-private-key
(hidden-private-key, encrypted-private-key) if you want = shorter names?

=E2=80=9CRaw=E2=80=9D is not a bad option.   = Semantically, the difference to =E2=80=9Ccleartext=E2=80=9D seems very = small.   Length isn=E2=80=99t a huge-issue either, being a = programmatic API.  Maybe one is preferred from a historical-use = perspective?  (Rich, maybe you can comment here?)



     =
<symmetric-key>
       <name>ex-octet-string-based-symmetric-key</name>
       <key-format>ct:octet-string-key-format</key-format>
       <key>base64encodedvalue=3D=3D</key>
     </symmetric-key>


     <asymmetric-key>
       =
<name>ex-subject-public-info-based-asymmetric-key</name>
       <public-key-format>
         ct:subject-public-key-info-format
       </public-key-format>
       <public-key>base64encodedvalue=3D=3D</public-key>
       <private-key-format>
         ct:rsa-private-key-format
       </private-key-format>
       <private-key>base64encodedvalue=3D=3D</private-key>
       <certificates>
         <certificate>
           <name>ex-cert</name>
           <cert-data>base64encodedvalue=3D=3D</cert-data>
         </certificate>
       </certificates>
     </asymmetric-key>


The name is not visually prevalent in = context --> any prefix would be fine...

K.


= --Apple-Mail=_1E1DD9BD-58C7-4189-923F-6A8E1531E0FA-- From nobody Thu Jul 9 07:51:33 2020 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 40D813A0C1A for ; Thu, 9 Jul 2020 07:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlJsA9C-qeAH for ; Thu, 9 Jul 2020 07:51:27 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEFD3A0C16 for ; Thu, 9 Jul 2020 07:51:27 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 069EngWc030470; Thu, 9 Jul 2020 15:50:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=Ezukf7SqfLai5bhvrjNKdXXUzW6Y2XO2ZgTAQLI0Jhc=; b=GzvhVhHKLw5r12kF+rN6XicVktPBKxPi3rKLnuyOYElcqILS+0cLXY4rIq4Jnzx7NSBA B6++i+lSjAzSenp2vAShLQpQn2rtXxcVNw302DxnQP8Lc9THRf+t2KYxWi5Q30oXlnYK 05/UvDW6cV8SdkM9sqafrhep1O/XvpyRx98TZrm1i4AMvE+hUmXof+SzFb9oQKYMO/+b FBNzLYEy18MSaZ1qqEXUouAwqvTRwxyTf0555RwszgkcH1bGmLuzMuemriFFiDX7vv6Y qJR/3Vyuof29hnHvBUc+rdJiDPlNXNjYitAtdAq/1Lw1guwcurVRbLpmlqmDB282ANNF eA== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 325k20u5ss-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jul 2020 15:50:26 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 069Eaep5023190; Thu, 9 Jul 2020 10:50:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.117]) by prod-mail-ppoint4.akamai.com with ESMTP id 325k4wewnj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 09 Jul 2020 10:50:07 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 9 Jul 2020 09:50:06 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Thu, 9 Jul 2020 09:50:06 -0500 From: "Salz, Rich" To: Kent Watsen , Juergen Schoenwaelder CC: "netconf@ietf.org" Thread-Topic: [netconf] question regarding key naming Thread-Index: AQHWVfrSGKcexYJyFEW86XIjvzdQ/aj/ofGAgAAEh4D//77MgA== Date: Thu, 9 Jul 2020 14:50:06 +0000 Message-ID: <619A9842-6A74-4058-9C62-D133A7EBA2F1@akamai.com> References: <01000173313a1282-63366836-4a52-453a-a111-fd3334b2506e-000000@email.amazonses.com> <0100017333ea7297-2838a6f2-40ad-4ca5-a83a-23d3014bef92-000000@email.amazonses.com> <20200709142715.6a3wqdeht2ipiryl@anna.jacobs.jacobs-university.de> <01000173340803ac-47ae5791-0b76-479d-8be2-b8904ca48535-000000@email.amazonses.com> In-Reply-To: <01000173340803ac-47ae5791-0b76-479d-8be2-b8904ca48535-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.48] Content-Type: multipart/alternative; boundary="_000_619A98426A7440589C62D133A7EBA2F1akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-09_08:2020-07-09, 2020-07-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0 phishscore=0 mlxscore=0 adultscore=0 suspectscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007090104 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-09_08:2020-07-09, 2020-07-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 adultscore=0 phishscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 priorityscore=1501 lowpriorityscore=0 suspectscore=0 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007090111 Archived-At: Subject: Re: [netconf] question regarding key naming 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, 09 Jul 2020 14:51:30 -0000 --_000_619A98426A7440589C62D133A7EBA2F1akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAg4oCcUmF34oCdIGlzIG5vdCBhIGJhZCBvcHRpb24uICAgU2VtYW50aWNhbGx5LCB0aGUg ZGlmZmVyZW5jZSB0byDigJxjbGVhcnRleHTigJ0gc2VlbXMgdmVyeSBzbWFsbC4gICBMZW5ndGgg aXNu4oCZdCBhIGh1Z2UtaXNzdWUgZWl0aGVyLCBiZWluZyBhIHByb2dyYW1tYXRpYyBBUEkuICBN YXliZSBvbmUgaXMgcHJlZmVycmVkIGZyb20gYSBoaXN0b3JpY2FsLXVzZSBwZXJzcGVjdGl2ZT8g IChSaWNoLCBtYXliZSB5b3UgY2FuIGNvbW1lbnQgaGVyZT8pDQoNCkkgdGhpbmsgaW5mb3JtZWQg Zm9sa3Mgd29u4oCZdCBjYXJlIGFib3V0IHJhdy9jbGVhcnRleHQuICBCdXQgSSB0aGluayBuZXdl ciBmb2xrcyB3aWxsIGFwcHJlY2lhdGUg4oCcY2xlYXJ0ZXh04oCdIGJldHRlci4gIEZXSVcsIHRv IG1lIGEg4oCccmF34oCdIGtleSBpcyBvbmUgdGhhdCBzdGFuZHMgYWxvbmUsIGFzIG9wcG9zZWQg dG8gYSBwdWJsaWMga2V5IGVtYmVkZGVkIGluIGFuIFg1MDkgY2VydGlmaWNhdGUuDQoNCkhUSC4N Cg== --_000_619A98426A7440589C62D133A7EBA2F1akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <25D77C110971B844A378A4901CF95BAD@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJh Z3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDo4NDgxODE5OTA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjE1NzQyMzk0MzAgMTE4MTYzMDAyOCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPuKAnFJhd+KAnSBpcyBub3QgYSBiYWQg b3B0aW9uLiAmbmJzcDsgU2VtYW50aWNhbGx5LCB0aGUgZGlmZmVyZW5jZSB0byDigJxjbGVhcnRl eHTigJ0gc2VlbXMgdmVyeSBzbWFsbC4gJm5ic3A7IExlbmd0aCBpc27igJl0IGEgaHVnZS1pc3N1 ZSBlaXRoZXIsIGJlaW5nIGEgcHJvZ3JhbW1hdGljIEFQSS4gJm5ic3A7TWF5YmUgb25lIGlzIHBy ZWZlcnJlZCBmcm9tDQogYSBoaXN0b3JpY2FsLXVzZSBwZXJzcGVjdGl2ZT8gJm5ic3A7KFJpY2gs IG1heWJlIHlvdSBjYW4gY29tbWVudCBoZXJlPyk8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpbmZvcm1lZCBmb2xrcyB3b27igJl0IGNhcmUgYWJv dXQgcmF3L2NsZWFydGV4dC4mbmJzcDsgQnV0IEkgdGhpbmsgbmV3ZXIgZm9sa3Mgd2lsbCBhcHBy ZWNpYXRlIOKAnGNsZWFydGV4dOKAnSBiZXR0ZXIuJm5ic3A7IEZXSVcsIHRvIG1lIGEg4oCccmF3 4oCdIGtleSBpcyBvbmUgdGhhdCBzdGFuZHMgYWxvbmUsIGFzIG9wcG9zZWQgdG8gYSBwdWJsaWMg a2V5IGVtYmVkZGVkIGluIGFuIFg1MDkgY2VydGlmaWNhdGUuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhUSC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_619A98426A7440589C62D133A7EBA2F1akamaicom_-- From nobody Thu Jul 9 08:06:58 2020 Return-Path: <01000173341d79a3-8d3dfae2-7e8e-44d8-848b-2aa5df8e3f03-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 0086A3A0C1D for ; Thu, 9 Jul 2020 08:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 JPfPU7kyXzt9 for ; Thu, 9 Jul 2020 08:06:55 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284CE3A0C19 for ; Thu, 9 Jul 2020 08:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1594307214; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=GXAgDzdSZLeeuTI4SM/EBeYjsv2ILac2C3XdDOW6B0o=; b=PRXygCBifwsx8Mj4BBqYmvkaTq9k6sPinzNJkwtxU21uCqQQjhwgk+11vYlXEoUp ffZf3bwXgoKe7xyHUZC4baeRgF0sM/jzjDVZY7GP1FMgB4ZXrOGZGauDKedwpaqqiys zQjlBlBIujfoRMf/mTp/yi6r5ZAwKaecuUzp1kJg= 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: <20200617191009.hn7ftmkrzxiysqwr@anna.jacobs.jacobs-university.de> Date: Thu, 9 Jul 2020 15:06:53 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000173341d79a3-8d3dfae2-7e8e-44d8-848b-2aa5df8e3f03-000000@email.amazonses.com> References: <20200617105328.rqqw2wssa3q74etj@anna.jacobs.jacobs-university.de> <01000172c36f9602-0647d5e3-4a24-42b6-92b8-c10542feb59f-000000@email.amazonses.com> <20200617191009.hn7ftmkrzxiysqwr@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.09-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WG LC for three drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 15:06:57 -0000 Hi Juergen Following up on this thread=E2=80=A6 >> OLD: Common YANG Data Types for Cryptography >> NEW: Common YANG Data Types and Groupings for Cryptography >>=20 >=20 > Works for me. Done (and I also took out the word =E2=80=9CCommon=E2=80=9D). >>> - The certificate-expiration notification of the >>> trust-anchor-certs-grouping probably needs adjustment; I assume >>> this applies to any certificate the the cert leaf-list. >>=20 >> Yes, a notification could be for any =E2=80=9Ccert=E2=80=9D entry in = the leaf-list. What adjustment is needed? Is it just the description = text? Or are you thinking that the notification will be unable to = identify the specific leaf-list entry that is expiring? >>=20 >> For NETCONF, it seems that the XPath would be able to identity the = specific certificate (e.g., [1], [2], etc.). RESTCONF might be = problematic though, maybe the full cert is listed? >>=20 >> Digging deeper, I note that =E2=80=9Cleaf-list cert=E2=80=9D appears = only in two groupings: >>=20 >> 1) the "end-entity-certs-grouping=E2=80=9D grouping >> - this grouping isn=E2=80=99t used anywhere (AFAIK) and could = be removed >>=20 >> 2) the "trust-anchor-certs-grouping=E2=80=9D grouping >> - this grouping is used in the truststore draft, but only in = the definition >> of the "local-or-truststore-certs-grouping=E2=80=9D grouping, = and then only to >> support the =E2=80=9Clocal=E2=80=9D case=E2=80=A6 >> - FWIW, the =E2=80=9Ctruststore=E2=80=9D case is a = "certificate-bag-ref=E2=80=9D, that is, a bag=20 >> of certs... >> - at first I was thinking that we could adjust the =E2=80=9Clocal= =E2=80=9D case to use >> the "trust-anchor-cert-cms=E2=80=9D typedef but, actually, it = already does. >> That is, it is a leaf-list of CMS structs=E2=80=A6 >> - another option would be to expand the =E2=80=9Clocal=E2=80=9D = case to be a =E2=80=9Clist=E2=80=9D >> instead of a =E2=80=9Cleaf-list=E2=80=9D. This would = necessitate each cert to have >> a =E2=80=9Ckey=E2=80=9D (e.g., name), but that is how it is = in the truststore's bag >> definition, so probably okay... >=20 > Giving certs a name and using a list may make things simpler. But I > have no overview of all the usage implications (since I did not look > at the other documents). Done. Converted the leaf-list to a list. >>> - Is there any semantic difference between >>> trust-anchor-cert-grouping and end-entity-cert-grouping, i.e., why >>> do we need two groupings? Same question for >>> trust-anchor-certs-grouping and end-entity-certs-grouping. If >>> there is a semantic difference, perhaps this should be highlighted >>> in the grouping description. >>=20 >> There is a huge semantic difference (albeit, no syntactic = difference), TAs and EEs are used in entirely different ways. >=20 > Yes, but if its the same structure, why do we need two definitions of > the structure? It is the same structure, but the description statements differ. >> That said, the truststore could (really, SHOULD) be used to configure = the system-level SSH server as well, as it portends to have security = protections beyond regular config. This is analogous the folks = migrating to storing TAs in system-level mechanisms, such as Mac=E2=80=99s= =E2=80=9Ckeychain=E2=80=9D. >>=20 >> What makes sense to me is to have a future 7317bis that migrates that = definition to use the =E2=80=9Cts:local-or-truststore-public-keys-grouping= =E2=80=9D grouping. >=20 > Yes, perhaps it is OK to stay silent about and to keep a record > somewhere that this needs to be looked at when 7317 is being revised. I modified the example (s/User/Application/) and removed the "relation = to authorized-keys" comment to tamper it down more. >>> - Do we need the truststore-supported feature? We do not have this >>> in other YANG modules. Is the idea to distinguish implementations >>> that only import groupings? Even in this case, should this not be >>> handled by the yang library somehow? >>=20 >> The "truststore-supported=E2=80=9D feature is used to prune out the = =E2=80=9Ctruststore=E2=80=9D case from the various =E2=80=9Clocal-of = truststore=E2=80=9D groupings. Yes, it is for implementations that do = not implement the module (they only import the groupings). I=E2=80=99m = unsure how YANG Library could be used differently, that is, it's already = currently used to indicate if the module is implemented/imported as well = as what features are supported. >>=20 >=20 > I assume (have not checked) that you don't toggle the implement bit in > the yang library if you just import type definitions and groupings. Correct. But the implement bit *does* need to be toggled in order for = =E2=80=9Cidentity=E2=80=9D statements to be defined, along with RPCs and = protocol-accessible nodes. >>> - Do the leaf names always look good in instance data? For example, >>> is may not be the most descriptive name in >>> instance data. >>=20 >> All of the downstream drafts (ssh-, tls-, netconf-, restconf-) have = examples illustrating "truststore-reference=E2=80=9D in use. [and the = ssh- and tls- drafts have examples illustrating "keystore-reference=E2=80=9D= in use]. >=20 > I guess I will eventually have to look at them... >=20 >>> Perhaps it would help to also have examples that >>> show how various groupings are used, not just the bags. >>=20 >> This would entail defining an example module to instantiate those = groupings (such as is done in the crypto-types and keystore drafts). If = the goal is to make this draft as readable as possible in a standalone = fashion, then perhaps that should be done. Or perhaps we could just = point readers to the examples in the aforementioned drafts? >>=20 >=20 > My preference is to point to the other drafts. These are likely > non-normative references, i.e., they are not problematic process wise I added examples to the trust-anchors draft. More work, but better = contained... >>> - I have to think about the 'copy to running' procedure described in >>> section 3. Perhaps this is the way to go but who happens if things >>> get out of sync? >>=20 >> We previously had "require-instance false=E2=80=9D statements (also = in the keystore draft), but they were removed (see the Change Log) = because it seemed skewed to throwout validation for 99% of the TAs/keys = in orderbto support the 1% case for builtin TA/keys. So we moved to the = current approach, which isn=E2=80=99t ideal, but seems better then the = alternative... >>=20 >> FWIW, it=E2=80=99s intended (though perhaps not stated) that the = server will reject any attempt to configure a new TA certificate. That = is, only a subset of the certificate can appear in . Any = attempt to configure a new cert, or change an exist cert, should cause = the commit to fail. In this way, configurations that refer to the = builtin definitions can be assured that the values used are only those = approved by the manufacturer.=20 >>=20 >=20 > Spelling this out would make me happy. The server has to enforce > consistency here. Spelled out in spades. Please re-review. >>> - Why is it useful to define truststore-grouping, i.e., why is this >>> not just a part of the truststore container definition? How are >>> the reference types going to work if you instantiate the >>> truststore-grouping elsewhere? >>=20 >> I use this grouping in a project outside the IETF, where there are a = multiplicity of context specific truststores. I use the features to = disable to default =E2=80=9Clocal-or-truststore=E2=80=9D cases and then = augment-in my own case statement containing a reference to my = context-specific truststore. >>=20 >=20 > Well, to do this properly, one would have to invent a way to make the > references to different truststores. You are essentially dropping the > truststore and adding new ones, no? Still a hack, like cut'n'paste. Maybe. Still, it=E2=80=99s useful, and not a hardship to support. >>> * draft-ietf-netconf-keystore-17.txt >>>=20 >>> - Looking at the overview figure (that is unfortunately to be >>> removed), I wonder whether trust-anchors should be renamed to >>> truststore as this seems to be the term used by the yang module. >>=20 >> The artwork is helpful, but it=E2=80=99s easy to see that it won=E2=80=99= t age well - right? For instance, already there are other WGs using = some of this work and, let=E2=80=99s not forget the =E2=80=9Csyslog=E2=80=9D= draft that has been parked in NETMOD for ~2 years due to a MISREF to = the TLS draft... >>=20 >=20 > I can't follow, artwork is no different than text. I moved the artwork into the Introduction section for all drafts. No = longer removed by RFC Editor. >>> - Several pages of yang tree output without explanations is not very >>> helpful. I suggest to break this into pieces and to explain for >>> each grouping when it may be used (or not used). >>=20 >> This suggestion is in line with the response I gave Tom, regarding it = being consistent with what I did in the =E2=80=9Csztp-csr=E2=80=9D = draft. I think the trick is to rename the section from =E2=80=9CTree = Diagram=E2=80=9D to =E2=80=9CData Model Overview=E2=80=9D and go from = there... >>=20 >=20 > Short tree diagrams very helpful, multi pages tree diagramm are almost > pointless (and can always be generated when needed). The art is to > slice things into meaningful pieces. I replaced the wall of tree-diagram with new =E2=80=9CData Model = Overview=E2=80=9D section in all drafts. This was a ton of work, and I pray that the WGLCs don=E2=80=99t result = in many changes that would entail needing to update both the YANG = definition and also the draft-text. BTW, in the course of doing this, it occurred to me that a = =E2=80=9Cyang2rfc=E2=80=9D utility could effectively automate the = per-module snippet put into each draft. We might need to add some YANG = extensions to support =E2=80=9Cdocstrings=E2=80=9D but, otherwise, I = think it could be done and would be a huge time-saver for future = I-Ds=E2=80=A6and also provide a consistency across I-Ds=E2=80=A6maybe a = good student project? ;) >>> - Should the support for encrypted keys be moved to the cryto-types >>> module? Is there a reason why we add the feature to have keys >>> encrypted here? Perhaps this is sensible, I am just trying to >>> check whether this has been given some thought. >>=20 >> In order to persist an encrypted key, it is necessary to reference = the other key that was used to encrypt the key (so the server knows how = to decrypt the key). =20 >>=20 >> The expectation is that the other key will be in the keystore, but = note that a =E2=80=9Cchoice=E2=80=9D node is used for the references, = and all the existing cases are protected by =E2=80=9Cfeature=E2=80=9D = statements, so that, e.g., a =E2=80=9Clocal=E2=80=9D key or key in a = context-specific instance of the keystore grouping can be used = alternatively. >>=20 >> To your point, we could move the essence of the encrypted-key support = directly into the key groupings in the crypto-types draft, but leave the = =E2=80=9Ccase=E2=80=9D statement empty, and then have the keystore draft = augment in =E2=80=9Ccase=E2=80=9D statements for keys in the keystore, = when the keystore module is =E2=80=9Cimplemented=E2=80=9D. Makes sense? >>=20 >=20 > I have no strong opinion - it just felt that adding encrypted keys > later adds additional noise, more groupings to understand and to deal > with. Done. I did exactly what is in my last paragraph. Much cleaner! >>> - The text in 5.3 scares me a bit. Migrating root keys may be seen >>> as a bad idea by some. If you have a new device with new root >>> keys, then you better re-encrypt or re-key instead of patching the >>> root key. Or are you essentially saying that encrypted keys >>> should be encrypted with a key-encryption-key instead of the 'root >>> key'? >>=20 >> More the latter. The 2nd-to-last paragraph intends to say this.=20 >=20 > Perhaps this recommendation should be spelled out clearer and the > =C2=A7obscure copy root keys approach be given as a reason to have = such > key-encryption-keys. Done. I re-wrote these sections do be much clearer. Please re-review! >>> - I am not sure how one implements the 'MUST ensure that the >>> strength of the key being configured is not greater than the >>> strength of the underlying secure transport' nor am I sure that >>> the consequences are really desirable, i.e., I can never move to >>> 'more secure keys' than what the transport currently allows. I >>> think I understand the argument that says a key can't be more >>> trustworthy than the transport used to configure it but I do not >>> think we should disallow upgrade paths. >>=20 >> Changed to a SHOULD in my local copy. >=20 > Works for me.=20 I did it, but then deleted it (ooops). I now have a =E2=80=9CStrength = of Configured Keys=E2=80=9D Security Considerations section in my local = copy of the crypto-types draft. K. From nobody Thu Jul 9 08:16:08 2020 Return-Path: <010001733425c8e0-7a4174bd-93a1-48a5-a719-14bd0645a84f-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 048043A0C5C for ; Thu, 9 Jul 2020 08:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 hYXNcofJXYn3 for ; Thu, 9 Jul 2020 08:16:00 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85943A0C7C for ; Thu, 9 Jul 2020 08:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1594307758; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=aG6K3NqEzDcZL5JAr+OrXEKSUSYv7CxvS//hj7Lp93A=; b=QjoPUo30D1Qbset5BpomXTeDUk6U4U7SY0InAWBnnINcXXzw8agD5UJauxFXxoJ0 ruMaEfzbrmCez6F/rm0ASAwX2wD4pCSsxi+t4QPJqgdt2SHX15q/Vih1fiyTf9mDA8m suKh4KKB/hiVAHs/0qEVkl77eoAkyIGA0t9D4dlM= 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, 9 Jul 2020 15:15:58 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001733425c8e0-7a4174bd-93a1-48a5-a719-14bd0645a84f-000000@email.amazonses.com> References: <01000172c7a9cda8-3214ef17-890f-4f42-a9ab-b5b3730350a7-000000@email.amazonses.com> To: tom petch X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.09-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WG LC for three drafts or two of them X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 15:16:07 -0000 Hi Tom, > 1) Much of this text should surround tree diagram snippets. As = Juergen implied yesterday, a wall of tree diagram artwork alone = doesn=E2=80=99t make for a great =E2=80=9Coverview=E2=80=9D. >=20 > > I am unconvinced about surrounding tree snippets in this case. I note = that Juergen said > ' - Is there any semantic difference between > trust-anchor-cert-grouping and end-entity-cert-grouping, i.e., why > do we need two groupings? Same question for > trust-anchor-certs-grouping and end-entity-certs-grouping. If > there is a semantic difference, perhaps this should be highlighted > in the grouping description' > and if you are reverse engineering the YANG I think that that is a = likely view. What I did was put the text side by side. no intervening = YANG or tree diagram or ..., when I think that the semantic difference = is clearer to the reader. It may then be a question as to whether or = not we need both but I think that my formatting brings out the existing = semantic difference which inserting anything YANG or YANG-like obscures. >=20 > Tom Petch I=E2=80=99ve probably failed you here with the latest updates, where I = did replace the wall of tree diagrams with snippet-specific sections. = Each section does have some discussion about the nature of the snippet, = but it may not get at each specific detail. The problem is that there are so many details that reproducing it all = would likely take more text than the YANG module itself=E2=80=A6and, = worse, the duplicate text would be difficult to maintain. Honestly, as I wrote in my other response to Juergen just now, a = =E2=80=9Cyang2rfc=E2=80=9D utility that could generate all this text off = the YANG+docstrings would be awesome. Kent From nobody Fri Jul 10 04:48:57 2020 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 868E33A0A6A for ; Fri, 10 Jul 2020 04:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Duf1VJmo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FM3ykft6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJg3oXR1ibMC for ; Fri, 10 Jul 2020 04:48:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB433A0A69 for ; Fri, 10 Jul 2020 04:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5116; q=dns/txt; s=iport; t=1594381733; x=1595591333; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=5Cfyc+vP01AzicW6iaCMF0BM+mdsf43f6QV+X3xhzFs=; b=Duf1VJmoAMjuKINCGB18rmjPlTfopE7ezfp2VqXuvE6n/ZtD891HB/Zv PVHEqynA1w5LFpLuRBHOAQxPXF4lr6y7gDU2pdtd3jKdr7jDP/t3uKBH1 x9c5ileHT7lrVgpTPhJDqQ6tzT7uXJTIwm5bKAXCzJBCfvjLqLqGZBuTL 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AiRXPkhTQqq8Dktm4tJDpHmib5dpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN+J6v9YhazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrCgAQVQhf/4kNJK1gHgEBCxIMQIM?= =?us-ascii?q?cIy4Hb1gvLAqEKYNGA40qmQKCUwNVCwEBAQwBARgPBgIEAQGECEUZKoFVAiQ?= =?us-ascii?q?4EwIDAQELAQEFAQEBAgEGBG2FWwELhXACAQMBARAREQwBASwMEQEIGgImAgQ?= =?us-ascii?q?lCxUSBBMUDoMEAYJLAy4BDp8pAoE5iGF2gTKDAQEBBYJJgl0Ygg4DBoEOKoJ?= =?us-ascii?q?qgk4RNj+GMxqBQT+BECgMEIJNPoEEgVgBAQIBgUQvgn8zgi2PMgSDCoZtixa?= =?us-ascii?q?QWAqCXYdTfJEDAx2fJow6hSqKH5AthCECBAIEBQIOAQEFgWojgVdwFTsqAYI?= =?us-ascii?q?+UBcCDY4eGINZhRSFQnQCCSwCBgEHAQEDCXyNfwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,335,1589241600"; d="scan'208";a="533127114" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Jul 2020 11:48:52 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 06ABmqn7015777 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 10 Jul 2020 11:48:52 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Jul 2020 06:48:51 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Jul 2020 06:48:51 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 10 Jul 2020 07:48:51 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N07TICp6EdDCnZKdLDTNd0Sw7dwV8kRnvUjJQ6qy8OsboFZ8NNTVODEVcQ3wQRhTrJJtcM8U5RvgEy/O9uNLB6KNw3NXqn36mli4J5Z4C3E2FMMgygDjLEWPlxdexfVMmD/8ifoG72uE+6Mw3sGngVL8n/6/cAbms1FvTRsvqAHiQ51Kxm0VLfcRuKdfpztnjOh9LM+zYM4wxuNUwCGDD3iYI2cymVKqLWV2qjK1NZgQ4D8TNY0uDmkCuy9/C1qr5ByPLWfdeqscTouGI1eqYj1zVAj+BJ4AQ3OgiIMTIk7Tl5AWBcLVRbatURp+r5n3Ek0EswRm9Op6BMUPTDBkhQ== 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=5Cfyc+vP01AzicW6iaCMF0BM+mdsf43f6QV+X3xhzFs=; b=ZPbzUdMAMft5u9tBJtXZlnGoEmwOHiM5tUjKxxYPCoyWs8DHC1EGMJfImyNYSoBejExWrgrL2Ia5TXi8U3gufIapYPIN57bimAFQfKcBddEdZHH8SG2dLql1mGF9CqAFatH5XXOBBukPX6HZnLlPV5BNhuf2aboOUYLbRDX6oP8uis76xuR9/PCWafFB9gVmVrvaCax3IoF+wgbTHJzawS0izu0tYUovIQ9LZf+rprCbVaYLSD/Vexz+/VRa7jl0VH3ZfAfAA9O9n190vze5bO8W9/JOZ99AfJCGoJQachRcT+jkgyi44D3aEUrakKDPN3nXTJUxavw6TMBmcKsWTg== 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=5Cfyc+vP01AzicW6iaCMF0BM+mdsf43f6QV+X3xhzFs=; b=FM3ykft6bH9rswad5TYXJcvkVJxnCt5J6/rawxfvzNOFUqRsely6sWsHvCM8ugjtlb/jgdQJVv3cxVb9QJOETHGQmnS2Icgo2c/g/LHxzuLq06xdIRDLzoQvU2tSd5+N7OqxmrtsjYh/xKZ7JS6/qRiBjR7rMVJuvos0KoZpbsE= Received: from SN6PR11MB2622.namprd11.prod.outlook.com (2603:10b6:805:57::31) by SN6PR11MB3535.namprd11.prod.outlook.com (2603:10b6:805:ce::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23; Fri, 10 Jul 2020 11:48:50 +0000 Received: from SN6PR11MB2622.namprd11.prod.outlook.com ([fe80::7d01:cabe:b62e:8b6d]) by SN6PR11MB2622.namprd11.prod.outlook.com ([fe80::7d01:cabe:b62e:8b6d%6]) with mapi id 15.20.3174.023; Fri, 10 Jul 2020 11:48:50 +0000 From: "Jeffrey Ladouceur (jladouce)" To: "netconf@ietf.org" Thread-Topic: [netconf] Question about RFC 6242 : netconf over ssh Thread-Index: AQHWVrAUfJy27ReAREyTYbhH/u7f+A== Date: Fri, 10 Jul 2020 11:48:50 +0000 Message-ID: <0BAF9F36-26A8-4896-99CD-D9CB1DE7E59C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [135.12.130.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b83e99bd-133d-4db1-89ed-08d824c736a4 x-ms-traffictypediagnostic: SN6PR11MB3535: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 046060344D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: X2YYq7t6FHPGD6/pCv5NsNzb1sHAHeddbKEW0sXeSOVXQfZF72bC3DS9Uuo3oPWjmSnQrT7A2LwAfAIisw06MOwjgcR4I+TNmYn+zwspIXHJYLXvraBsmnqw118VVJ/f4IQZSMJ+1ZsWpQuaAWFM+UjTb8liRaegPW5eONerUa1zYqfP1FimlCON1kz8HvgDOsiDC4nuPtLECtGgph5umpWIHccDI9CnOMcP+wLmxuQVX2xjgmGZ3tQlf1WR/d3eh4ZNQs0lcTGKze9EKsG1Elt4bvAq092PEQrSw2UrNhfGwBSnkTBx+hJuqR7kRqEzmbeClfok0cTH1Qh8Y7/mWLnhj2o5kCwU2WEUlT4KT6Wav+zIiYliu0pj+/su5jW1EXm5QPQJhTh49nY4ne735w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB2622.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(366004)(376002)(346002)(478600001)(8676002)(6506007)(66446008)(36756003)(64756008)(5660300002)(66556008)(66946007)(966005)(66476007)(76116006)(86362001)(91956017)(26005)(6512007)(6486002)(2616005)(33656002)(186003)(2906002)(71200400001)(316002)(83380400001)(6916009)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 5rQWApWLq3Bz9dZ7g+Z7t1ErL9gneN6nybFWPNEkNCBNu1NIZDqlf7yyO6e3xwqSWqAeBxJ+ROu6OebLKd9s9/oqw7JT8QDNt9WpJt+IkyL9Y7+ngY8skMMGLv4bS08XJyGTmIyqDWkREt9H2pihqCpxgFJ4rzScfkQoi+9mOGKYkIiX/3pN+cZz/GgtWj2Ql0QF2VEhSzlxoBoK8OQGMlRxMOBwaXnz+nEWSkUz+cM7oeZeI8IC5G2ZBOcyX5eoiRIwFdHZeVLRkYtgdqrCBbca0mg3dPV2PE+XIIoXlm4DlT4tHQo/g+NAEcWcC1JqHtAZ7b+OlmHEMbI2tHAqKq8Ue54hIt91TG5tajuBHTP+Yfd4tilD68xcw2ePzOzUqQxoNsy5kYqBPVkfFM2xA8MMkg0jAZr2BpdzCviL3R187er98ZbueYkDrgClwQJZYuZ9vdcjlFvc4Zrnu+vgXOy9aHN5lOtQEMnAeoi/qG3rE7bgJyMapYz6HqtGyyL0 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <4C6B453B23D27A40BEB48CCBAB88B056@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB2622.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b83e99bd-133d-4db1-89ed-08d824c736a4 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2020 11:48:50.5880 (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: Btz7eG4hjqDkewy4x5WHHd0ss/tcohmoHbS42hp4pjs+VYWh2xE9uPoOgXq6XM0k+btwUKvq0BaTmFrJGZtS9w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3535 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [netconf] Question about RFC 6242 : netconf over ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 11:48:56 -0000 SGVsbG8sDQoNCk1heWJlIEknbGwgdHJ5IGFuZCByZS1waHJhc2UuDQoNCk91ciBuZXRjb25mIHN1 YnN5c3RlbSBleHBlY3RzIHRvIGJlIGNvbm5lY3RlZCBkaXJlY3RseSB0byB0aGUgZm9ya2VkIHNz aGQgcHJvY2VzcyB2aWEgcGlwZXMuDQpJdCBkb2VzIG5vdCBleHBlY3QgdG8gYmUgY29ubmVjdGVk IHRvIGEgcHNldWRvIHRlcm1pbmFsIGRldmljZS4NCg0KSWYgYSBjbGllbnQgcmVxdWVzdHMgdGhh dCBhIHB0eSBkZXZpY2UgYmUgYWxsb2NhdGUganVzdCBwcmlvciB0byBpbnZva2luZyB0aGUgbmV0 Y29uZiBzdWJzeXN0ZW0sIHRoZSBkZWZhdWx0IGxpbnV4IE5fVFRZIGxpbmUgZGlzY2lwbGUgZGV2 aWNlIHdpbGwgaW50ZXJmZXJlIHdpdGggdGhlIG5ldGNvbmYtb3Zlci1zc2ggcHJvdG9jb2wuDQoN CkkndmUgc2VlbiB2YXJpb3VzIG5ldGNvbmYgaW1wbGVtZW50YXRpb25zIG5vdCBiZSBhZmZlY3Rl ZCBieSB0aGlzIHVzZS1jYXNlLCBtYWlubHkgYmVjYXVzZSB0aGV5IGhhdmUgY3VzdG9taXplZCB0 aGUgc3NoIHNlcnZlciB0byBlaXRoZXI6DQotIHRyZWF0IHRoZSBwdHktcmVxIGFzIGEgbm9wIChz ZWUgaHR0cHM6Ly9naXRodWIuY29tL0NFU05FVC9saWJuZXRjb25mMi9ibG9iL2FhYWFkYTJhZTM4 YmVkNzYwMWQxMjk2NWIxYzlmZDgyNmY4NTViYWIvc3JjL3Nlc3Npb25fc2VydmVyX3NzaC5jI0wx MDc0ICkNCi0gdW5kbyB0aGUgcHR5IGFsbG9jYXRpb24gYW5kIHJldmVydCB0byB1c2luZyBwaXBl cyB3aGVuIHRoZSBuZXRjb25mIHN1YnN5c3RlbSBpcyBpbnZva2VkLg0KDQpIb3dldmVyIG90aGVy IG5ldGNvbmYgc2VydmVyIHNpbXBseSB0cmVhdCB0aGlzIGFzIGEgImdhcmJhZ2UtaW4vZ2FyYmFn ZS1vdXQiIHNjZW5hcmlvLiBJZiB0aGUgY2xpZW50IGhhcyBjaG9zZW4gdG8gYWxsb2NhdGUgYSBw c2V1ZG8tdGVybWluYWwgdGhlbiBjYW4gd2UgdHJlYXQgdGhpcyBpcyBhIG1pc2NvbmZpZ3VyYXRp b24gYW5kIHRoZSBuZXRjb25mIHNlcnZlciBpcyB1bmRlciBubyBvYmxpZ2F0aW9uIHRvIGZpeCBh IG1pc2JlaGF2aW5nIGNsaWVudC4NCg0KT3VyIG5ldGNvbmYgc3Vic3lzdGVtIGNvdWxkIGVhc2ls eSBjaGVjayBpZiBTU0hfVFRZIGlzIHNldCBhbmQgZXhpdCBhcyB0aGlzIHdvdWxkIHByb3RlY3Qg dGhlIGNsaWVudCBmcm9tIHJlY2VpdmluZyBpbmNvcnJlY3QgZGF0YS4NCg0KT3Igd2UgY291bGQg bGVhdmUgaXQgYXMuDQoNCkkgd2FzIHdvbmRlcmluZyBpZiB0aGUgY29tbXVuaXR5IGhhZCBhbnkg aW5wdXQgb24gc3VjaCBhIHVzZS1jYXNlLg0KDQpSZWdhcmRzLA0KSmVmZg0KDQoNCg0K77u/T24g MjAyMC0wNS0wNywgNDo1OSBQTSwgIm5ldGNvbmYgb24gYmVoYWxmIG9mIEplZmZyZXkgTGFkb3Vj ZXVyIChqbGFkb3VjZSkiIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGps YWRvdWNlPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCg0KICAgIEhlbGxvLA0K DQogICAgSSB3b3VsZCBsaWtlIHNvbWUgaW5wdXQgb24gYSB0aGUgZm9sbG93aW5nIHVzZS1jYXNl IGFuZCBwb3NzaWJsZSBhY2NlcHRhYmxlIG91dGNvbWVzLiANCg0KICAgIFN1bW1hcnk6DQoNCiAg ICBSRkMgNjI0MiBkb2Vzbid0IGV4cGxpY2l0bHkgaW5kaWNhdGUgYW55IGxvd2VyIGxldmVsIG1l c3NhZ2luZyBpbiBSRkMgNDI1NCB3aGljaCBjb3VsZCAiYnJlYWsiIHRoZSBuZXRjb25mIG1lc3Nh Z2luZyBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLg0KICAgIFNwZWNpZmljYWxseSwgdGhlIGNs aWVudCBjYW4gc2VuZCBhIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MjU0I3NlY3Rp b24tNi4gInB0eS1yZXEiIGp1c3QgcHJpb3IgdG8gaW52b2tpbmcgdGhlICJuZXRjb25mIiBzc2gg c3Vic3lzdGVtLg0KICAgIEhhdmluZyBhIHBzZXVkby10ZXJtaW5hbCBkZXZpY2UgaW4gYmV0d2Vl biB0aGUgY2xpZW50LXNlcnZlciBjb3VsZCByZXN1bHQgaW4gdGhlIGJyZWFrYWdlIG9mIHRoZSBt ZXNzYWdpbmcgYmVpbmcgY2xpZW50L3NlcnZlci4gDQoNCiAgICBSRkMgNjI0MiBzdGF0ZXM6DQog ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYyNDIjc2VjdGlvbi0zIChTdGFydGlu ZyBORUNPTkYgb3ZlciBTU0gpDQoNCiAgICAxLiBPbmNlIHRoZSB1c2VyIGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBhdXRoZW50aWNhdGVkLCB0aGUgU1NIIGNsaWVudCB3aWxsIGludm9rZSB0aGUgInNz aC1jb25uZWN0aW9uIiBzZXJ2aWNlLCBhbHNvIGtub3duIGFzIHRoZSBTU0ggY29ubmVjdGlvbiBw cm90b2NvbC4NCiAgICAyLiBBZnRlciB0aGUgc3NoLWNvbm5lY3Rpb24gc2VydmljZSBpcyBlc3Rh Ymxpc2hlZCwgdGhlIFNTSCBjbGllbnQgd2lsbCBvcGVuIGEgY2hhbm5lbCBvZiB0eXBlICJzZXNz aW9uIiwgd2hpY2ggd2lsbCByZXN1bHQgaW4gYW4gU1NIIHNlc3Npb24uDQogICAgMy4gT25jZSB0 aGUgU1NIIHNlc3Npb24gaGFzIGJlZW4gZXN0YWJsaXNoZWQsIHRoZSBORVRDT05GIGNsaWVudCB3 aWxsIGludm9rZSBORVRDT05GIGFzIGFuIFNTSCBzdWJzeXN0ZW0gY2FsbGVkICJuZXRjb25mIi4N CiAgICA0LiBSdW5uaW5nIE5FVENPTkYgYXMgYW4gU1NIIHN1YnN5c3RlbSBhdm9pZHMgdGhlIG5l ZWQgZm9yIHRoZSBzY3JpcHQgdG8gcmVjb2duaXplIHNoZWxsIHByb21wdHMgb3Igc2tpcCBvdmVy IGV4dHJhbmVvdXMgaW5mb3JtYXRpb24sIHN1Y2ggYXMgYSBzeXN0ZW0gbWVzc2FnZSB0aGF0IGlz IHNlbnQgYXQgc2hlbGwgc3RhcnQtdXAuDQoNCiAgICBJZiBJIHdlcmUgdG8gdHJhbnNsYXRlIHRo ZXNlIHN0ZXBzIGludG8gdGhlIGNvcnJlc3BvbmRpbmcgUkZDIDQyNTQgbWVzc2FnZXMuDQoNCiAg ICBTdGVwICgyKSB0cmFuc2xhdGVzIHRvOg0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM0MjU0I3NlY3Rpb24tNi4xIChPcGVuaW5nIGEgU2Vzc2lvbikgLCB1cG9uIHdoaWNoIGEg c2Vzc2lvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZA0KDQogICAgU3RlcCAoMyksIHRoaXMgdHJhbnNs YXRlcyB0byBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDI1NCNzZWN0aW9uLTYuNSAo U3RhcnRpbmcgYSBTaGVsbCBvciBhIENvbW1hbmQpLCBidXQgc3BlY2lmaWNhbGx5IHRoZSAic3Vi c3lzdGVtIiB2YXJpYW50Lg0KICAgIFdpdGggYSBzdHJpbmcgb2Yg4oCcc3Vic3lzdGVt4oCdIGFu ZCDigJxzdWJzeXN0ZW0gbmFtZeKAnSBzZXQgdG8gbmV0Y29uZi4NCg0KICAgIFF1ZXN0aW9uOg0K ICAgIDEtIERvZXMgIFJGQyA2MjQyIGltcGx5IHRoYXQgaXQgZXhwZWN0cyBkaXJlY3QgY2xpZW50 L3NlcnZlciBjb25uZWN0aW9uIHdpdGhvdXQgYW55IGludGVyZmVyZW5jZSBmcm9tIGEgcHR5IGRl dmljZSA/IFRoZSB0ZXh0IGluIGl0ZW0gKDQpIGFwcGVhcnMgdG8gbWUgdG8gaW1wbHkgdGhpcy4N Cg0KICAgIEZyb20gd2hhdCBJIGNhbiB0ZWxsLCB0aGUgdXNhZ2Ugb2YgdGhpcyBwdHkgcGF0dGVy biBpcyB3aGVuIGEgY2xpZW50IHdhbnRzIG5ldGNvbmYgb3ZlciB0dHkuDQoNCiAgICBUaGFuayB5 b3UgZm9yIGFueSBmZWVkYmFjay4NCg0KICAgIFJlZ2FyZHMsDQogICAgSmVmZg0KDQogICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBuZXRjb25m IG1haWxpbmcgbGlzdA0KICAgIG5ldGNvbmZAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0K From nobody Fri Jul 10 10:41:27 2020 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 9FE173A07F2; Fri, 10 Jul 2020 10:41:22 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159440288260.29660.1882956283740039536@ietfa.amsl.com> Date: Fri, 10 Jul 2020 10:41:22 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.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: Fri, 10 Jul 2020 17:41:23 -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-03.txt Pages : 27 Date : 2020-07-10 Abstract: 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 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 10 12:17:10 2020 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 0A9323A08A2; Fri, 10 Jul 2020 12:16:52 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159440861196.14281.17808697285900895600@ietfa.amsl.com> Date: Fri, 10 Jul 2020 12:16:52 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-crypto-types-17.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: Fri, 10 Jul 2020 19:16: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-17.txt Pages : 53 Date : 2020-07-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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-17 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 10 12:17:46 2020 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 5AF963A096C; Fri, 10 Jul 2020 12:17:38 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159440865832.25150.1951703018267057875@ietfa.amsl.com> Date: Fri, 10 Jul 2020 12:17:38 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-12.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: Fri, 10 Jul 2020 19:17:45 -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-12.txt Pages : 35 Date : 2020-07-10 Abstract: This document defines a YANG 1.1 data model for configuring globally- accessible bags of certificates and public keys that can be referenced by other data models for trust. 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: * "2020-07-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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-12 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-trust-anchors-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 10 12:18:44 2020 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 3EF173A0888; Fri, 10 Jul 2020 12:18:42 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159440872221.21242.3032334720319022576@ietfa.amsl.com> Date: Fri, 10 Jul 2020 12:18:42 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-keystore-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: Fri, 10 Jul 2020 19:18: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 : A YANG Data Model for a Keystore Author : Kent Watsen Filename : draft-ietf-netconf-keystore-19.txt Pages : 46 Date : 2020-07-10 Abstract: This document defines a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted. Asymmetric keys may be associated with certificates. 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 * "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: * "2020-07-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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-keystore-19 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-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 Fri Jul 10 12:19:46 2020 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 A12E83A0888; Fri, 10 Jul 2020 12:19:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159440878362.2171.4939497513392734790@ietfa.amsl.com> Date: Fri, 10 Jul 2020 12:19:43 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-21.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: Fri, 10 Jul 2020 19:19:44 -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 Authors : Kent Watsen Gary Wu Filename : draft-ietf-netconf-ssh-client-server-21.txt Pages : 59 Date : 2020-07-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: * "2020-07-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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-21 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-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 Fri Jul 10 12:22:30 2020 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 03D643A0928; Fri, 10 Jul 2020 12:22:17 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159440893694.27912.11549519389483860732@ietfa.amsl.com> Date: Fri, 10 Jul 2020 12:22:17 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-21.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: Fri, 10 Jul 2020 19:22:24 -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 Authors : Kent Watsen Gary Wu Filename : draft-ietf-netconf-tls-client-server-21.txt Pages : 58 Date : 2020-07-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: * "2020-07-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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-21 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-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 Fri Jul 10 13:02:50 2020 Return-Path: <010001733a52b310-16677e23-fb64-4b7c-8ccf-7006a5dab530-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 E95C33A08F6 for ; Fri, 10 Jul 2020 13:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQZwht7eRnqN for ; Fri, 10 Jul 2020 13:02:46 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E853A08EC for ; Fri, 10 Jul 2020 13:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1594411365; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=QSp0D/Ki7pfJRyE8PlYoGEQUZSUUmE2J9YHvB3g7AVk=; b=foCjj6+7vLPf0WLB0o7BgoIs4WhsX/gmmNoqQarZn+QgwxT8MJAsIHkDltM9tgMJ /qHLUBjrJdfvCazIQEHPMN6ty4ZizFQyCVXgt6P19pnuwSNM4b8E0D+WVmljxZGRBmG dUYRvgwCyTucJ1IstJfuwqKMANVQ7t/zyKVLP1e4= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_F1E8677A-D7E2-477F-987B-62E15621EB1D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 10 Jul 2020 20:02:45 +0000 References: <01000173313a1282-63366836-4a52-453a-a111-fd3334b2506e-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <01000173313a1282-63366836-4a52-453a-a111-fd3334b2506e-000000@email.amazonses.com> Message-ID: <010001733a52b310-16677e23-fb64-4b7c-8ccf-7006a5dab530-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.10-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Regarding today's 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: Fri, 10 Jul 2020 20:02:49 -0000 --Apple-Mail=_F1E8677A-D7E2-477F-987B-62E15621EB1D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Minor updates (not all drafts updated) crypto-types: * [Re]-added a "Strength of Keys Configured" Security Consideration * Prefixed "cleartext-" in the "key" and "private-key" node names. trust-anchors: * Fixed a copy/paste issue in the "Data at Rest" Security Considerations section. keystore + ssh-client-server + tls-client-server: * Updated examples to reflect new "cleartext-" prefix in the crypto-types draft. K. > On Jul 8, 2020, at 9:39 PM, Kent Watsen wrote: > > TR;DL; > > - first 3 WGLC drafts updated per comments received > - please review to ensure your comments were addressed! > > - remaining drafts 99% WGLC-ready > - just a few niggles left ;) > > K. > > > crypto-types > > * Updated draft title (refer to "Groupings" too). > > * Removed 'end-entity-certs-grouping' as it wasn't being used > anywhere. > > * Removed 'trust-anchor-certs-grouping' as it was no longer being > used after modifying 'local-or-truststore-certs-grouping' to use > lists (not leaf-lists). > > * Renamed "cert" to "cert-data" in trust-anchor-cert-grouping. > > * Added "csr-info" typedef, to complement the existing "csr" > typedef. > > * Added "ocsp-request" and "ocsp-response" typedefs, to complement > the existing "crl" typedef. > > * Added "encrypted" cases to both symmetric-key-grouping and > asymmetric-key-pair-grouping (Moved from Keystore draft). > > * Expanded "Data Model Overview section(s) [remove "wall" of tree > diagrams]. > > * Updated the Security Considerations section. > > > > truststore > > * Corrected module prefix registered in the IANA Considerations > section. > > * Modified 'local-or-truststore-certs-grouping' to use a list (not a > leaf-list). > > * Added new example section "The Local or Truststore Groupings". > > * Clarified expected behavior for "built-in" certificates in > > > * Expanded "Data Model Overview section(s) [remove "wall" of tree > diagrams]. > > * Updated the Security Considerations section. > > > > keystore > > * Removed dangling/unnecessary ref to RFC 8342. > > * r/MUST/SHOULD/ wrt strength of keys being configured over > transports. [UPDATE: oops, I think I deleted it altogether later] > > * Added an example for the "certificate-expiration" notification. > > * Clarified that OS MAY have a multiplicity of underlying keystores > and/or HSMs. > > * Clarified expected behavior for "built-in" keys in > > * Clarified the "Migrating Configuration to Another Server" section. > > * Expanded "Data Model Overview section(s) [remove "wall" of tree > diagrams]. > > * Updated the Security Considerations section. > > > > tcp-client-server > > * Expanded "Data Model Overview section(s) [remove "wall" of tree > diagrams]. > > * Updated the Security Considerations section. > > > > ssh-client-server > > * Added a "must 'public-key or password or hostbased or none or > certificate'" statement to the "user" node in ietf-ssh-client > > * Expanded "Data Model Overview section(s) [remove "wall" of tree > diagrams]. > > * Moved the "ietf-ssh-common" module section to proceed the other > two module sections. > > * Updated the Security Considerations section. > > > > tls-client-server > > * Modified the 'must' expression in the "ietf-tls-client:server- > authention" node to cover the "raw-public-keys" and "psks" nodes > also. > > * Added a "must 'ca-certs or ee-certs or raw-public-keys or psks'" > statement to the ietf-tls-server:client-authentication" node. > > * Added "mandatory true" to "choice auth-type" and a "presence" > statement to its ancestor. > > * Expanded "Data Model Overview section(s) [remove "wall" of tree > diagrams]. > > * Moved the "ietf-ssh-common" module section to proceed the other > two module sections. > > * Updated the Security Considerations section. > > > > http-client-server > > * Added a parent "container" to "client-identity-grouping" so that > it could be better used by the proxy model. > > * Added a "choice" to the proxy model enabling selection of proxy > types. > > * Added 'http-client-stack-grouping' and 'http-server-stack- > grouping' convenience groupings. > > * Expanded "Data Model Overview section(s) [remove "wall" of tree > diagrams]. > > * Updated the Security Considerations section. > > > > netconf-client-server > > * Expanded "Data Model Overview section(s) [remove "wall" of tree > diagrams]. > > * Removed expanded tree diagrams that were listed in the Appendix. > > * Updated the Security Considerations section. > > > > restconf-client-server > > * Moved and changed "must" statement so that either TLS *or* HTTP > auth must be configured. > > * Expanded "Data Model Overview section(s) [remove "wall" of tree > diagrams]. > > * Updated the Security Considerations section. > > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_F1E8677A-D7E2-477F-987B-62E15621EB1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Minor= updates (not all drafts updated)

   crypto-types:
  =      *  [Re]-added a "Strength of Keys = Configured" Security Consideration
    =    *  Prefixed "cleartext-" in the "key" and = "private-key" node names.

   trust-anchors:
  =      *  Fixed a copy/paste issue in the "Data = at Rest" Security
        =   Considerations section.

   keystore + = ssh-client-server + tls-client-server:
  =      *  Updated examples to reflect new = "cleartext-" prefix in the
    =       crypto-types draft.

K.






On Jul 8, 2020, at 9:39 PM, Kent Watsen = <kent+ietf@watsen.net> wrote:

TR;DL; =  

  =   - first 3 WGLC drafts updated per comments received
        - please review to ensure your = comments were addressed!

    - remaining drafts 99% = WGLC-ready 
        - just = a few niggles left  ;)

K.


crypto-types

   *  Updated draft title = (refer to "Groupings" too).

  =  *  Removed 'end-entity-certs-grouping' as it = wasn't being used
    =   anywhere.

  =  *  Removed 'trust-anchor-certs-grouping' as it was = no longer being
      used after = modifying 'local-or-truststore-certs-grouping' to use
 =     lists (not leaf-lists).

   *  Renamed "cert" to "cert-data" in = trust-anchor-cert-grouping.

  =  *  Added "csr-info" typedef, to complement the = existing "csr"
      typedef.

   *  Added "ocsp-request" = and "ocsp-response" typedefs, to complement
  =     the existing "crl" typedef.

   *  Added "encrypted" cases to both = symmetric-key-grouping and
    =   asymmetric-key-pair-grouping (Moved from = Keystore draft).

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Updated the Security Considerations section.



truststore

   *  Corrected module prefix registered = in the IANA Considerations
    =   section.

  =  *  Modified 'local-or-truststore-certs-grouping' to = use a list (not a
    =   leaf-list).

  =  *  Added new example section "The Local or = Truststore Groupings".

  =  *  Clarified expected behavior for = "built-in" certificates in
    =   <operational>

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Updated the Security Considerations section.



keystore

  =  *  Removed dangling/unnecessary ref to RFC 8342.

   *  r/MUST/SHOULD/ wrt = strength of keys being configured over
    =   transports.  [UPDATE: oops, I think I deleted it = altogether later]

  =  *  Added an example for the = "certificate-expiration" notification.

   *  Clarified that OS MAY have a = multiplicity of underlying keystores
    =   and/or HSMs.

  =  *  Clarified expected behavior for "built-in" keys = in <operational>

  =  *  Clarified the "Migrating Configuration to = Another Server" section.

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Updated the Security Considerations section.



tcp-client-server

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Updated the Security Considerations section.



ssh-client-server

   *  Added a "must 'public-key or = password or hostbased or none or
    =   certificate'" statement to the "user" node in = ietf-ssh-client

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Moved the "ietf-ssh-common" module section = to proceed the other
      two = module sections.

  =  *  Updated the Security Considerations section.



tls-client-server

   *  Modified the 'must' expression in = the "ietf-tls-client:server-
    =   authention" node to cover the "raw-public-keys" = and "psks" nodes
      also.

   *  Added a "must = 'ca-certs or ee-certs or raw-public-keys or psks'"
  =     statement to the = ietf-tls-server:client-authentication" node.

   *  Added "mandatory true" to "choice = auth-type" and a "presence"
    =   statement to its ancestor.

 =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Moved the "ietf-ssh-common" module section = to proceed the other
      two = module sections.

  =  *  Updated the Security Considerations section.



http-client-server

   *  Added a parent "container" to = "client-identity-grouping" so that
    =   it could be better used by the proxy model.

   *  Added a "choice" to the proxy model = enabling selection of proxy
    =   types.

  =  *  Added 'http-client-stack-grouping' and = 'http-server-stack-
      grouping' = convenience groupings.

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Updated the Security Considerations section.



netconf-client-server

  =  *  Expanded "Data Model Overview section(s) = [remove "wall" of tree
    =   diagrams].

  =  *  Removed expanded tree diagrams that were listed = in the Appendix.

  =  *  Updated the Security Considerations section.



restconf-client-server

   *  Moved = and changed "must" statement so that either TLS *or* HTTP
      auth must be configured.

   *  Expanded "Data Model = Overview section(s) [remove "wall" of tree
  =     diagrams].

  =  *  Updated the Security Considerations section.




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

= --Apple-Mail=_F1E8677A-D7E2-477F-987B-62E15621EB1D-- From nobody Fri Jul 10 13:13:33 2020 Return-Path: <010001733a5c82bf-56c40eb5-00f1-457b-98a8-d86fe128db13-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 4D9643A0911 for ; Fri, 10 Jul 2020 13:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 pY0gAHTDkbG0 for ; Fri, 10 Jul 2020 13:13:29 -0700 (PDT) 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 7FC1A3A0909 for ; Fri, 10 Jul 2020 13:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1594412008; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=XHelKhxWgyC6vtmECPd/A+jrsyj/nAeXsvKlJixyIKY=; b=hrX0oSFOA02jIb/4tu4Tza3N33FAt/LXvyiZE2MdTHno3n7qJLsOssoFo/bMPpG1 kaffC+jPYoBV8sjC8o9avlnNoOK1Dw38m2tI/fwO7iWoJSxL60YZs3fVPxkJyQTcGju KFcpgxgZGsDpd/YL626Po+R7WDg7Ak7gos799IlM= 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: <0BAF9F36-26A8-4896-99CD-D9CB1DE7E59C@cisco.com> Date: Fri, 10 Jul 2020 20:13:28 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001733a5c82bf-56c40eb5-00f1-457b-98a8-d86fe128db13-000000@email.amazonses.com> References: <0BAF9F36-26A8-4896-99CD-D9CB1DE7E59C@cisco.com> To: "Jeffrey Ladouceur (jladouce)" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.10-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Question about RFC 6242 : netconf over ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 20:13:32 -0000 Hi Jeff, I=E2=80=99m unfamiliar with how the negative case is handled on Juniper = devices (I used to work there). Perhaps you could write a portable script to test the various ways a = client might try to start a NETCONF session and ask folks to run it and = report findings here? [Be sure the script is a small as possible to = aid folk=E2=80=99s ability to audit it first.] Otherwise, I don=E2=80=99t know if there is an official standards-based = answer to this. K. > On Jul 10, 2020, at 7:48 AM, Jeffrey Ladouceur (jladouce) = wrote: >=20 > Hello, >=20 > Maybe I'll try and re-phrase. >=20 > Our netconf subsystem expects to be connected directly to the forked = sshd process via pipes. > It does not expect to be connected to a pseudo terminal device. >=20 > If a client requests that a pty device be allocate just prior to = invoking the netconf subsystem, the default linux N_TTY line disciple = device will interfere with the netconf-over-ssh protocol. >=20 > I've seen various netconf implementations not be affected by this = use-case, mainly because they have customized the ssh server to either: > - treat the pty-req as a nop (see = https://github.com/CESNET/libnetconf2/blob/aaaada2ae38bed7601d12965b1c9fd8= 26f855bab/src/session_server_ssh.c#L1074 ) > - undo the pty allocation and revert to using pipes when the netconf = subsystem is invoked. >=20 > However other netconf server simply treat this as a = "garbage-in/garbage-out" scenario. If the client has chosen to allocate = a pseudo-terminal then can we treat this is a misconfiguration and the = netconf server is under no obligation to fix a misbehaving client. >=20 > Our netconf subsystem could easily check if SSH_TTY is set and exit as = this would protect the client from receiving incorrect data. >=20 > Or we could leave it as. >=20 > I was wondering if the community had any input on such a use-case. >=20 > Regards, > Jeff >=20 >=20 >=20 > =EF=BB=BFOn 2020-05-07, 4:59 PM, "netconf on behalf of Jeffrey = Ladouceur (jladouce)" wrote: >=20 > Hello, >=20 > I would like some input on a the following use-case and possible = acceptable outcomes.=20 >=20 > Summary: >=20 > RFC 6242 doesn't explicitly indicate any lower level messaging in = RFC 4254 which could "break" the netconf messaging between client and = server. > Specifically, the client can send a = https://tools.ietf.org/html/rfc4254#section-6. "pty-req" just prior to = invoking the "netconf" ssh subsystem. > Having a pseudo-terminal device in between the client-server could = result in the breakage of the messaging being client/server.=20 >=20 > RFC 6242 states: > https://tools.ietf.org/html/rfc6242#section-3 (Starting NECONF over = SSH) >=20 > 1. Once the user has been successfully authenticated, the SSH = client will invoke the "ssh-connection" service, also known as the SSH = connection protocol. > 2. After the ssh-connection service is established, the SSH client = will open a channel of type "session", which will result in an SSH = session. > 3. Once the SSH session has been established, the NETCONF client = will invoke NETCONF as an SSH subsystem called "netconf". > 4. Running NETCONF as an SSH subsystem avoids the need for the = script to recognize shell prompts or skip over extraneous information, = such as a system message that is sent at shell start-up. >=20 > If I were to translate these steps into the corresponding RFC 4254 = messages. >=20 > Step (2) translates to: > https://tools.ietf.org/html/rfc4254#section-6.1 (Opening a Session) = , upon which a session has been established >=20 > Step (3), this translates to = https://tools.ietf.org/html/rfc4254#section-6.5 (Starting a Shell or a = Command), but specifically the "subsystem" variant. > With a string of =E2=80=9Csubsystem=E2=80=9D and =E2=80=9Csubsystem = name=E2=80=9D set to netconf. >=20 > Question: > 1- Does RFC 6242 imply that it expects direct client/server = connection without any interference from a pty device ? The text in item = (4) appears to me to imply this. >=20 > =46rom what I can tell, the usage of this pty pattern is when a = client wants netconf over tty. >=20 > Thank you for any feedback. >=20 > Regards, > Jeff >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Jul 10 13:21:59 2020 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 B27083A0930 for ; Fri, 10 Jul 2020 13:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_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=h5oQb+zO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LkWKdwJf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_F31zQT_cKo for ; Fri, 10 Jul 2020 13:21:55 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D7C3A0928 for ; Fri, 10 Jul 2020 13:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7796; q=dns/txt; s=iport; t=1594412515; x=1595622115; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=z97UX1WlW0GjEK1HfJnQ9KBLLETnTzcANdTd5Xtoneo=; b=h5oQb+zOjbdhYrCZPKxEfEB2emdSPEo0IquaDA3Bdm/PVa3m9l+QoGru 3f4Rylus9H/ytKzM6/r/d1GudlcLLm2bUc/4LzSL5YkXFVOKyqmSDhqGB o+2Kwx2tQJs5EwTeOGQSofymU2tvC5WOJTVGKMDVPeTrV760oYgx+vFKt Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AaTDrWh2yh11c5WOdsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGu6dyhUPSUIOd7f9Y2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YldcBN3zYRvUr2HhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4BQCUzAhf/4wNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUiMuB29YLywKhCmDRgONKiWYXYJTA1ULAQEBDAEBGA8?= =?us-ascii?q?GAgQBAYQIRQIXKoFVAiQ4EwIDAQELAQEFAQEBAgEGBG2FWwyFbwEBAQECAQE?= =?us-ascii?q?BEBERDAEBLAsBDwIBCBgCAiYCAgIlCxUQAgQOBRQOgwQBgksDDiABDp5lAoE?= =?us-ascii?q?5iGF2gTKDAQEBBYJJgmkYgg4DBoEOKoJqgk4RNj+GMxqBQT+BEAEnDBCCTT6?= =?us-ascii?q?BBIFYAQECAYFEL4J/M4ItjxoPCYMOhm2LFpBYCoJdiE+RBgMdnyaMOo9JkC+?= =?us-ascii?q?EIQIEAgQFAg4BAQWBaiOBV3AVOyoBgj5QFwINjh4MDAuDToUUhUJ0AgksAgY?= =?us-ascii?q?BBwEBAwl8jWkBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,336,1589241600"; d="scan'208";a="522123429" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Jul 2020 20:21:54 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 06AKLsnZ002756 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Jul 2020 20:21:54 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Jul 2020 15:21:54 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Jul 2020 16:21:53 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 10 Jul 2020 15:21:52 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AfO2205BhoAvqRtJulbmVtrRBEX4yGIDIUb8tDgL/w4HQPwk49brqyoKSI4yLV6kT1j0Pzi0b7YarlCmD3tZa3DR26XruZ6072k79B8ud8jvRjJCiC1dcxO5U/RY92XoJ/ZedYvni+AMymfu7quHFJnFW08HkNwx4E/kYdW1Q0Ta3/Tl+telCI3UXTCsiu55C36IhrRiHxdQmDcwkUS/zoZZWbWRJdH8p5pwJx/rnfuTABhJPMRpeqc074i7cF+A6Xh1h8spvfhIvEecpawMoY0ZLYN3euwXzuPvJX96TCWS7n9hQ1k4L5p38JrZlfmbkMSPWoQlkZ0ZFUkUDaioCw== 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=z97UX1WlW0GjEK1HfJnQ9KBLLETnTzcANdTd5Xtoneo=; b=e4zr2HZNC1DHmEg7clzNDrZDHdrHBCCLbRtajfcH/DGfNspA4zJcStO72CgXCbokhaUcGyi7aTZMTn76w83qzH/eOtJU6TjzX2Wz1LMdqZDgfTJRKkEmchgFy3zsDFY7hlwclHO8sHoqmyU6441B8ij/3RDlFzKsEqQt9ra+avHEQkPlmNZtD9o20/xb2O3Gxl2DPdEaQo/DDZSu+36hjnyzyip6o9t6lSdwPWzDrvRziiAVTyyDAOaDyx6elboYZ6nZN8jlr+z74bcrqJnQIjsMxN8O45r6xMnofbA8CxL1HV8aSFilNEz1XadHhPgo+HJPF3mLZCrKj7tnwcQAUw== 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=z97UX1WlW0GjEK1HfJnQ9KBLLETnTzcANdTd5Xtoneo=; b=LkWKdwJfntGk2zzriYZrmsYLiNQJ4mQoMfq/SpdrWXveOGNcSBcn16vfRc1lrDk8aXZ8duLx93oQN6Qbq9g+Rhg7obdxFyi0+1RZFbHhLbdf0gtk+K39sPF+ACW0NZRTvTkqrXOqANgBmjd4cW7+q+NRVVwHAXBP+IDxbh4vHGU= Received: from SN6PR11MB2622.namprd11.prod.outlook.com (2603:10b6:805:57::31) by SN6PR11MB2957.namprd11.prod.outlook.com (2603:10b6:805:cd::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Fri, 10 Jul 2020 20:21:51 +0000 Received: from SN6PR11MB2622.namprd11.prod.outlook.com ([fe80::7d01:cabe:b62e:8b6d]) by SN6PR11MB2622.namprd11.prod.outlook.com ([fe80::7d01:cabe:b62e:8b6d%6]) with mapi id 15.20.3174.023; Fri, 10 Jul 2020 20:21:51 +0000 From: "Jeffrey Ladouceur (jladouce)" To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] Question about RFC 6242 : netconf over ssh Thread-Index: AQHWVrAUfJy27ReAREyTYbhH/u7f+KkBP8UA//+/SAA= Date: Fri, 10 Jul 2020 20:21:51 +0000 Message-ID: <1E3ED10C-7344-4223-B08B-9C544F4C4683@cisco.com> References: <0BAF9F36-26A8-4896-99CD-D9CB1DE7E59C@cisco.com> <010001733a5c82bf-56c40eb5-00f1-457b-98a8-d86fe128db13-000000@email.amazonses.com> In-Reply-To: <010001733a5c82bf-56c40eb5-00f1-457b-98a8-d86fe128db13-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [135.12.130.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0053d3d6-3290-4dd1-a10d-08d8250ee1a8 x-ms-traffictypediagnostic: SN6PR11MB2957: 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: ubUoguGo0r0Ku4gkAtlR/MkUOZXRkZRxZFrqVRagLrXcfJJpJgSuJGxa8bdjUpLZyGP5OxdXwSLK4EGFN5u4U00aU9rqhSWc7QewZHINwNY/h8PmEKO4wlMssGuOv8JGUhs0dXa8ETeAu3eFmjERVs8emV+0eYHEwsGhXMwMGRojO4HUqNkzibC9eZ5S3vq3FmXs8NbinJ8ow+eQNYguloLiStQYs3sxyS7p6c5KEb68DYe1sAugM+77i2a0Nsnuu9l/5xqs00z2gA29HS2OEvHLumqrzcRE4C8k9HBLne+hPzYHFKsYcFqKxGpXuuSnk7hfGOjZfroboMt4d9kEaq3Sp9bVzAMz8tNatUS9Qknwj7ANhJw7iXU4nUr3+jKlxJIGBozZQuU/8t6Xwz6yig== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB2622.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(366004)(39860400002)(136003)(376002)(8936002)(4326008)(66574015)(26005)(83380400001)(53546011)(186003)(6512007)(966005)(91956017)(6486002)(66446008)(478600001)(66946007)(71200400001)(76116006)(66556008)(36756003)(66476007)(8676002)(316002)(86362001)(6506007)(64756008)(2616005)(6916009)(2906002)(5660300002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: CqoE+fr7KAB3BJULoV3BRZQJRmLHkQd+0uNWpGpZ4kRdTpsZSuKzVdj4qaEyzMJfz2Cz0bfBRgxyxcAhyYfbTcS2K4x1C6cBglrwrtVHzZYgvqNGQV5dxXHY28ykUVQOfIYoLPkPLSYka1nhYrtCe53khc9MQmIpoKLzrIE0r5BEKuJE3wh3Fpy64SKteXaLo0FyLI39htpozbDX508q32oRzIRJECpb/W2LVYdl4RbwBx+d53i5DpzG+IRmF41mhaodCRFN6OP9LPXVzS/AMiTfM5E4qQAOvxmEyMwFc0jK//iEIL2M9I328cPmCSRDvBCvF3Pkx/Z0jbABEH8J8B7kujHwegysiGr4l+mG0VNbVoE5OxYrQuA8v7UdTLKqwE4FztLGGKlFLNlNMFPGdzsLTYXAHtd0fBtxGCZggyWxlOj059EWa+Oz0xvejlnzYMdn6C7GSo8EgJwl1EQieghcWaCluOpzPdbvWgzxPtXQhc0ZhCjBeEAGmZ9utMF4 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB2622.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0053d3d6-3290-4dd1-a10d-08d8250ee1a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2020 20:21:51.6601 (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: sN7de2k7+D7aS9+j+7Ycb2N7ZUqLE0eHgp2s5hJLrfMzYtSoDrGSnGHL9wtCju5Fm3cf9J7yn8PJOPwt5KVPMg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2957 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [netconf] Question about RFC 6242 : netconf over ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 20:21:58 -0000 SGkgS2VudCwNCg0KV2l0aCByZWdhcmRzIHRvIEp1bmlwZXIsIGZ3aXcgSSBmb3VuZCBhIHJlZmVy ZW5jZSBpbiAiSnVuT1MgQXV0b21hdGlvbiBDb29rYm9vayIgd2hpY2ggc2F5czoNCg0KIk5FVENP TkYtb3Zlci1TU0ggcnVucyBvbiBhIHNlcGFyYXRlIFRDUCBwb3J0IHRvIHRoZSBjb252ZW50aW9u YWwgU1NIIHRyYW5zcG9ydC4gVGhlIGRlZmF1bHQsIEludGVybmV0IEFzc2lnbmVkIG51bWJlcnMg QXV0aG9yaXR5IChJQU5BKSBpcyA4MzAsIGJ1dCBKVU5PUyBPUyBhbGxvd3MgeW91IHRvIHNlbGVj dCBhbnkgYXJiaXRyYXJ5IG51bWJlci4gV2hlbiBORVRDT05GLW92ZXItU1NIIGlzIHVzZWQgaW4g dGhpcyBtYW5uZXIsIHRoZSBTU0ggc2VydmVyIG1ha2VzIHVzZSBvZiBhIHByb3RvY29sIGZlYXR1 cmUgY2FsbGVkIHN1YnN5c3RlbXMuIFRoaXMgYWxsb3dzIHRoZSBTU0ggc2VydmVyIHRvIGRpcmVj dGx5IGNvbm5lY3QgdG8gYW5vdGhlciBpbnRlcm5hbCBjb21wb25lbnQgd2l0aG91dCBjb25zaWRl cmF0aW9uIGZvciBkZXRhaWxzIHN1Y2ggYXMgcHNldWRvLXRlcm1pbmFsIG9yIHVzZXIgc2hlbGwu Ig0KDQpCYXNlIG9uIHRoZSBsYXN0IHNlbnRlbmNlIGl0IGFwcGVhcnMgdGhhdCBhIHBzZXVkby10 ZXJtaW5hbCBpcyBub3QgZXhwZWN0ZWQgd2hlbiBjb25uZWN0aW5nIHZpYSBuZXRjb25mIHN1YnN5 c3RlbS4NCg0KQXBwcmVjaWF0ZWQgeW91ciBmZWVkYmFjay4NCg0KUmVnYXJkcywNCkplZmYNCg0K DQrvu79PbiAyMDIwLTA3LTEwLCA0OjEzIFBNLCAiS2VudCBXYXRzZW4iIDxrZW50QHdhdHNlbi5u ZXQ+IHdyb3RlOg0KDQogICAgSGkgSmVmZiwNCg0KICAgIEnigJltIHVuZmFtaWxpYXIgd2l0aCBo b3cgdGhlIG5lZ2F0aXZlIGNhc2UgaXMgaGFuZGxlZCBvbiBKdW5pcGVyIGRldmljZXMgKEkgdXNl ZCB0byB3b3JrIHRoZXJlKS4NCg0KICAgIFBlcmhhcHMgeW91IGNvdWxkIHdyaXRlIGEgcG9ydGFi bGUgc2NyaXB0IHRvIHRlc3QgdGhlIHZhcmlvdXMgd2F5cyBhIGNsaWVudCBtaWdodCB0cnkgdG8g c3RhcnQgYSBORVRDT05GIHNlc3Npb24gYW5kIGFzayBmb2xrcyB0byBydW4gaXQgYW5kIHJlcG9y dCBmaW5kaW5ncyBoZXJlPyAgIFtCZSBzdXJlIHRoZSBzY3JpcHQgaXMgYSBzbWFsbCBhcyBwb3Nz aWJsZSB0byBhaWQgZm9sa+KAmXMgYWJpbGl0eSB0byBhdWRpdCBpdCBmaXJzdC5dDQoNCiAgICBP dGhlcndpc2UsIEkgZG9u4oCZdCBrbm93IGlmIHRoZXJlIGlzIGFuIG9mZmljaWFsIHN0YW5kYXJk cy1iYXNlZCBhbnN3ZXIgdG8gdGhpcy4NCg0KICAgIEsuDQoNCg0KICAgID4gT24gSnVsIDEwLCAy MDIwLCBhdCA3OjQ4IEFNLCBKZWZmcmV5IExhZG91Y2V1ciAoamxhZG91Y2UpIDxqbGFkb3VjZT00 MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQogICAgPiANCiAgICA+IEhlbGxvLA0K ICAgID4gDQogICAgPiBNYXliZSBJJ2xsIHRyeSBhbmQgcmUtcGhyYXNlLg0KICAgID4gDQogICAg PiBPdXIgbmV0Y29uZiBzdWJzeXN0ZW0gZXhwZWN0cyB0byBiZSBjb25uZWN0ZWQgZGlyZWN0bHkg dG8gdGhlIGZvcmtlZCBzc2hkIHByb2Nlc3MgdmlhIHBpcGVzLg0KICAgID4gSXQgZG9lcyBub3Qg ZXhwZWN0IHRvIGJlIGNvbm5lY3RlZCB0byBhIHBzZXVkbyB0ZXJtaW5hbCBkZXZpY2UuDQogICAg PiANCiAgICA+IElmIGEgY2xpZW50IHJlcXVlc3RzIHRoYXQgYSBwdHkgZGV2aWNlIGJlIGFsbG9j YXRlIGp1c3QgcHJpb3IgdG8gaW52b2tpbmcgdGhlIG5ldGNvbmYgc3Vic3lzdGVtLCB0aGUgZGVm YXVsdCBsaW51eCBOX1RUWSBsaW5lIGRpc2NpcGxlIGRldmljZSB3aWxsIGludGVyZmVyZSB3aXRo IHRoZSBuZXRjb25mLW92ZXItc3NoIHByb3RvY29sLg0KICAgID4gDQogICAgPiBJJ3ZlIHNlZW4g dmFyaW91cyBuZXRjb25mIGltcGxlbWVudGF0aW9ucyBub3QgYmUgYWZmZWN0ZWQgYnkgdGhpcyB1 c2UtY2FzZSwgbWFpbmx5IGJlY2F1c2UgdGhleSBoYXZlIGN1c3RvbWl6ZWQgdGhlIHNzaCBzZXJ2 ZXIgdG8gZWl0aGVyOg0KICAgID4gLSB0cmVhdCB0aGUgcHR5LXJlcSBhcyBhIG5vcCAoc2VlIGh0 dHBzOi8vZ2l0aHViLmNvbS9DRVNORVQvbGlibmV0Y29uZjIvYmxvYi9hYWFhZGEyYWUzOGJlZDc2 MDFkMTI5NjViMWM5ZmQ4MjZmODU1YmFiL3NyYy9zZXNzaW9uX3NlcnZlcl9zc2guYyNMMTA3NCAp DQogICAgPiAtIHVuZG8gdGhlIHB0eSBhbGxvY2F0aW9uIGFuZCByZXZlcnQgdG8gdXNpbmcgcGlw ZXMgd2hlbiB0aGUgbmV0Y29uZiBzdWJzeXN0ZW0gaXMgaW52b2tlZC4NCiAgICA+IA0KICAgID4g SG93ZXZlciBvdGhlciBuZXRjb25mIHNlcnZlciBzaW1wbHkgdHJlYXQgdGhpcyBhcyBhICJnYXJi YWdlLWluL2dhcmJhZ2Utb3V0IiBzY2VuYXJpby4gSWYgdGhlIGNsaWVudCBoYXMgY2hvc2VuIHRv IGFsbG9jYXRlIGEgcHNldWRvLXRlcm1pbmFsIHRoZW4gY2FuIHdlIHRyZWF0IHRoaXMgaXMgYSBt aXNjb25maWd1cmF0aW9uIGFuZCB0aGUgbmV0Y29uZiBzZXJ2ZXIgaXMgdW5kZXIgbm8gb2JsaWdh dGlvbiB0byBmaXggYSBtaXNiZWhhdmluZyBjbGllbnQuDQogICAgPiANCiAgICA+IE91ciBuZXRj b25mIHN1YnN5c3RlbSBjb3VsZCBlYXNpbHkgY2hlY2sgaWYgU1NIX1RUWSBpcyBzZXQgYW5kIGV4 aXQgYXMgdGhpcyB3b3VsZCBwcm90ZWN0IHRoZSBjbGllbnQgZnJvbSByZWNlaXZpbmcgaW5jb3Jy ZWN0IGRhdGEuDQogICAgPiANCiAgICA+IE9yIHdlIGNvdWxkIGxlYXZlIGl0IGFzLg0KICAgID4g DQogICAgPiBJIHdhcyB3b25kZXJpbmcgaWYgdGhlIGNvbW11bml0eSBoYWQgYW55IGlucHV0IG9u IHN1Y2ggYSB1c2UtY2FzZS4NCiAgICA+IA0KICAgID4gUmVnYXJkcywNCiAgICA+IEplZmYNCiAg ICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IE9uIDIwMjAtMDUtMDcsIDQ6NTkgUE0sICJuZXRj b25mIG9uIGJlaGFsZiBvZiBKZWZmcmV5IExhZG91Y2V1ciAoamxhZG91Y2UpIiA8bmV0Y29uZi1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqbGFkb3VjZT00MGNpc2NvLmNvbUBkbWFyYy5p ZXRmLm9yZz4gd3JvdGU6DQogICAgPiANCiAgICA+ICAgIEhlbGxvLA0KICAgID4gDQogICAgPiAg ICBJIHdvdWxkIGxpa2Ugc29tZSBpbnB1dCBvbiBhIHRoZSBmb2xsb3dpbmcgdXNlLWNhc2UgYW5k IHBvc3NpYmxlIGFjY2VwdGFibGUgb3V0Y29tZXMuIA0KICAgID4gDQogICAgPiAgICBTdW1tYXJ5 Og0KICAgID4gDQogICAgPiAgICBSRkMgNjI0MiBkb2Vzbid0IGV4cGxpY2l0bHkgaW5kaWNhdGUg YW55IGxvd2VyIGxldmVsIG1lc3NhZ2luZyBpbiBSRkMgNDI1NCB3aGljaCBjb3VsZCAiYnJlYWsi IHRoZSBuZXRjb25mIG1lc3NhZ2luZyBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyLg0KICAgID4g ICAgU3BlY2lmaWNhbGx5LCB0aGUgY2xpZW50IGNhbiBzZW5kIGEgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzQyNTQjc2VjdGlvbi02LiAicHR5LXJlcSIganVzdCBwcmlvciB0byBpbnZv a2luZyB0aGUgIm5ldGNvbmYiIHNzaCBzdWJzeXN0ZW0uDQogICAgPiAgICBIYXZpbmcgYSBwc2V1 ZG8tdGVybWluYWwgZGV2aWNlIGluIGJldHdlZW4gdGhlIGNsaWVudC1zZXJ2ZXIgY291bGQgcmVz dWx0IGluIHRoZSBicmVha2FnZSBvZiB0aGUgbWVzc2FnaW5nIGJlaW5nIGNsaWVudC9zZXJ2ZXIu IA0KICAgID4gDQogICAgPiAgICBSRkMgNjI0MiBzdGF0ZXM6DQogICAgPiAgICBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjI0MiNzZWN0aW9uLTMgKFN0YXJ0aW5nIE5FQ09ORiBvdmVy IFNTSCkNCiAgICA+IA0KICAgID4gICAgMS4gT25jZSB0aGUgdXNlciBoYXMgYmVlbiBzdWNjZXNz ZnVsbHkgYXV0aGVudGljYXRlZCwgdGhlIFNTSCBjbGllbnQgd2lsbCBpbnZva2UgdGhlICJzc2gt Y29ubmVjdGlvbiIgc2VydmljZSwgYWxzbyBrbm93biBhcyB0aGUgU1NIIGNvbm5lY3Rpb24gcHJv dG9jb2wuDQogICAgPiAgICAyLiBBZnRlciB0aGUgc3NoLWNvbm5lY3Rpb24gc2VydmljZSBpcyBl c3RhYmxpc2hlZCwgdGhlIFNTSCBjbGllbnQgd2lsbCBvcGVuIGEgY2hhbm5lbCBvZiB0eXBlICJz ZXNzaW9uIiwgd2hpY2ggd2lsbCByZXN1bHQgaW4gYW4gU1NIIHNlc3Npb24uDQogICAgPiAgICAz LiBPbmNlIHRoZSBTU0ggc2Vzc2lvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCwgdGhlIE5FVENPTkYg Y2xpZW50IHdpbGwgaW52b2tlIE5FVENPTkYgYXMgYW4gU1NIIHN1YnN5c3RlbSBjYWxsZWQgIm5l dGNvbmYiLg0KICAgID4gICAgNC4gUnVubmluZyBORVRDT05GIGFzIGFuIFNTSCBzdWJzeXN0ZW0g YXZvaWRzIHRoZSBuZWVkIGZvciB0aGUgc2NyaXB0IHRvIHJlY29nbml6ZSBzaGVsbCBwcm9tcHRz IG9yIHNraXAgb3ZlciBleHRyYW5lb3VzIGluZm9ybWF0aW9uLCBzdWNoIGFzIGEgc3lzdGVtIG1l c3NhZ2UgdGhhdCBpcyBzZW50IGF0IHNoZWxsIHN0YXJ0LXVwLg0KICAgID4gDQogICAgPiAgICBJ ZiBJIHdlcmUgdG8gdHJhbnNsYXRlIHRoZXNlIHN0ZXBzIGludG8gdGhlIGNvcnJlc3BvbmRpbmcg UkZDIDQyNTQgbWVzc2FnZXMuDQogICAgPiANCiAgICA+ICAgIFN0ZXAgKDIpIHRyYW5zbGF0ZXMg dG86DQogICAgPiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDI1NCNzZWN0aW9u LTYuMSAoT3BlbmluZyBhIFNlc3Npb24pICwgdXBvbiB3aGljaCBhIHNlc3Npb24gaGFzIGJlZW4g ZXN0YWJsaXNoZWQNCiAgICA+IA0KICAgID4gICAgU3RlcCAoMyksIHRoaXMgdHJhbnNsYXRlcyB0 byBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDI1NCNzZWN0aW9uLTYuNSAoU3RhcnRp bmcgYSBTaGVsbCBvciBhIENvbW1hbmQpLCBidXQgc3BlY2lmaWNhbGx5IHRoZSAic3Vic3lzdGVt IiB2YXJpYW50Lg0KICAgID4gICAgV2l0aCBhIHN0cmluZyBvZiDigJxzdWJzeXN0ZW3igJ0gYW5k IOKAnHN1YnN5c3RlbSBuYW1l4oCdIHNldCB0byBuZXRjb25mLg0KICAgID4gDQogICAgPiAgICBR dWVzdGlvbjoNCiAgICA+ICAgIDEtIERvZXMgIFJGQyA2MjQyIGltcGx5IHRoYXQgaXQgZXhwZWN0 cyBkaXJlY3QgY2xpZW50L3NlcnZlciBjb25uZWN0aW9uIHdpdGhvdXQgYW55IGludGVyZmVyZW5j ZSBmcm9tIGEgcHR5IGRldmljZSA/IFRoZSB0ZXh0IGluIGl0ZW0gKDQpIGFwcGVhcnMgdG8gbWUg dG8gaW1wbHkgdGhpcy4NCiAgICA+IA0KICAgID4gICAgRnJvbSB3aGF0IEkgY2FuIHRlbGwsIHRo ZSB1c2FnZSBvZiB0aGlzIHB0eSBwYXR0ZXJuIGlzIHdoZW4gYSBjbGllbnQgd2FudHMgbmV0Y29u ZiBvdmVyIHR0eS4NCiAgICA+IA0KICAgID4gICAgVGhhbmsgeW91IGZvciBhbnkgZmVlZGJhY2su DQogICAgPiANCiAgICA+ICAgIFJlZ2FyZHMsDQogICAgPiAgICBKZWZmDQogICAgPiANCiAgICA+ ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg PiAgICBuZXRjb25mIG1haWxpbmcgbGlzdA0KICAgID4gICAgbmV0Y29uZkBpZXRmLm9yZw0KICAg ID4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQogICAg PiANCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQogICAgPiBuZXRjb25mIG1haWxpbmcgbGlzdA0KICAgID4gbmV0Y29uZkBpZXRmLm9yZw0KICAg ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg0K From nobody Fri Jul 10 13:46:53 2020 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 B8E2B3A096B for ; Fri, 10 Jul 2020 13:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nHKNf-gDQt0 for ; Fri, 10 Jul 2020 13:46:49 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86CA3A096C for ; Fri, 10 Jul 2020 13:46:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4024B821; Fri, 10 Jul 2020 22:46:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id W3S8Zy8ZlIfG; Fri, 10 Jul 2020 22:46:45 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Jul 2020 22:46:45 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE13020154; Fri, 10 Jul 2020 22:46:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id oBjVtReAW3I0; Fri, 10 Jul 2020 22:46:45 +0200 (CEST) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 74AEA200E4; Fri, 10 Jul 2020 22:46:45 +0200 (CEST) Date: Fri, 10 Jul 2020 22:46:45 +0200 From: Juergen Schoenwaelder To: "Jeffrey Ladouceur (jladouce)" Cc: "netconf@ietf.org" Message-ID: <20200710204645.5cq5eo2pmbsk5yhn@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Jeffrey Ladouceur (jladouce)" , "netconf@ietf.org" References: <529EE682-F67A-4A04-A869-65882A895528@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <529EE682-F67A-4A04-A869-65882A895528@cisco.com> Archived-At: Subject: Re: [netconf] Question about RFC 6242 : netconf over ssh X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 20:46:51 -0000 On Mon, Jun 08, 2020 at 03:39:01PM +0000, Jeffrey Ladouceur (jladouce) wrote: > Hello, > > It's my understanding that running netconf over a pseudo terminal via ssh (i.e. pty-req) is most likely not a widely supported use-case as I don't see any refence to such use-case. > > The pseudo terminal is typically used by an ssh client when the program on the server side expect to interreact with a terminal. To the best of my knowledge, a netconf server has no expectation, and in-fact may expect to be directly connected to the ssh server instance and not to a pty device. I think that requesting a pty is a client error, NETCONF is not designed to be used as an interactive terminal session. > Would it be reasonable for a netconf subsytem to sanitize its STDIN/STDOUT/STDERR and if they were attached to a tty to exit and drop the connection ? RFC 6242 is silent about what happens if SSH protocol features are used that do not make much sense for NETCONF and hence it is implementation specific how such situations are handled. Signaling the allocation of a pty as an error seems to be a good thing (but I do not know how 'popular' this is). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 13 14:46:17 2020 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 B1E0F3A0C6C for ; Mon, 13 Jul 2020 14:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pM33cxaeUwv0 for ; Mon, 13 Jul 2020 14:46:13 -0700 (PDT) Received: from sjmda12.webex.com (sjmda12.webex.com [64.68.124.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F5C3A0C5F for ; Mon, 13 Jul 2020 14:46:08 -0700 (PDT) Received: from rva2rmd101.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda12.webex.com (Postfix) with ESMTP id ED740301C665 for ; Mon, 13 Jul 2020 21:46:07 +0000 (GMT) Received: from rva2rmd101.webex.com (localhost [127.0.0.1]) by rva2rmd101.webex.com (Postfix) with ESMTP id B6302103108B for ; Mon, 13 Jul 2020 21:46:07 +0000 (GMT) Date: Mon, 13 Jul 2020 21:46:07 +0000 (GMT) From: NETCONF Working Group Reply-To: netconf-chairs@ietf.org To: netconf@ietf.org Message-ID: <1085649208.9513891594676767745.JavaMail.nobody@rva2rmd101.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1902726_1773988547.1594676767744" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=166689491560443829, X-WBX-TID=2nzld2s4ssz3q22018b3jmwnn7oyf9623y3spxwv06lfmomykdjl48rn, X-WBX-RID=6bdff062f92f4332a82ae4f9b5b833d5, X-WBX-SVC:Meeting Center, X-WBX-TT:Meeting Invitation, Date:Mon Jul 13 21:46:07 GMT 2020 reminder-40.6.2-3143 Archived-At: Subject: [netconf] Webex meeting invitation: NETCONF 108 Virtual Meeting 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, 13 Jul 2020 21:46:16 -0000 ------=_Part_1902726_1773988547.1594676767744 Content-Type: multipart/Alternative; boundary="----=_Part_1902727_332445217.1594676767744" ------=_Part_1902727_332445217.1594676767744 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCBuZXRjb25mQGlldGYub3JnLAoKTkVUQ09ORiBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91 IHRvIGpvaW4gdGhpcyBXZWJleCBtZWV0aW5nLgoKCk5FVENPTkYgMTA4IFZpcnR1YWwgTWVldGlu ZwpUdWVzZGF5LCBKdWx5IDI4LCAyMDIwCjExOjAwIGFtICB8ICAoVVRDKzAwOjAwKSBNb25yb3Zp YSwgUmV5a2phdmlrICB8ICAxIGhyIDQwIG1pbnMKTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogMTYxIDI2OCAzNDU5IApNZWV0aW5nIHBhc3N3b3JkOiB0RjVtVlMybjR3ZgoKCgpXaGVuIGl0 J3MgdGltZSwgam9pbiB0aGUgbWVldGluZy4KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bTFhOGMxOGJjMmY1NjU0MDZhN2Y1MDU2NWJkYTdkN2RkCgpBZGQgdG8gQ2FsZW5k YXIKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWFhOGZkMWU5ODllYjQ3 YWMwYjg0YTJmYmU3ZTQ0NDZjDQoNCgoKDQpUQVAgVE8gSk9JTiBGUk9NIEEgTU9CSUxFIERFVklD RSAoQVRURU5ERUVTIE9OTFkpDQorMS02NTAtNDc5LTMyMDgsLDE2MTI2ODM0NTkjIyB0ZWw6JTJC MS02NTAtNDc5LTMyMDgsLCowMSoxNjEyNjgzNDU5JTIzJTIzKjAxKiBDYWxsLWluIHRvbGwgbnVt YmVyIChVUy9DYW5hZGEpCg0KDQpKT0lOIEJZIFBIT05FDQoxLTY1MC00NzktMzIwOCBDYWxsLWlu IHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpCg0KR2xvYmFsIGNhbGwtaW4gbnVtYmVycw0KaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNhbGxpbi5waHA/TVRJRD1tOGVhOTczMmQ5MTg5 MzRiYjY5ZGMyMjBkMWJjYTAxNmYNCg0KCkpPSU4gRlJPTSBBIFZJREVPIFNZU1RFTSBPUiBBUFBM SUNBVElPTgpEaWFsIHNpcDoxNjEyNjgzNDU5QGlldGYud2ViZXguY29tCllvdSBjYW4gYWxzbyBk aWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci4KCgpKb2luIHVz aW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3MKRGlhbCBz aXA6MTYxMjY4MzQ1OS5pZXRmQGx5bmMud2ViZXguY29tCgoKCgoKQ2FuJ3Qgam9pbiB0aGUgbWVl dGluZz8KaHR0cHM6Ly9jb2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAw MjkwNTUKCgpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2Vy dmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBz ZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVn YWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29u c2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyBy ZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpv aW4gdGhlIHNlc3Npb24uCg== ------=_Part_1902727_332445217.1594676767744 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KdGFibGUgewoJYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0 ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7fQoKdHIgewoJbGlu ZS1oZWlnaHQ6IDE4cHg7fQoKYSwgdGQgewoJZm9udC1zaXplOiAxNHB4Owlmb250LWZhbWlseTog QXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5v cm1hbDsJcGFkZGluZzogMDt9CgoudGl0bGUgewoJZm9udC1zaXplOiAyOHB4O30KCi5pbWFnZSB7 Cgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO30KCi5mb290ZXIgewoJd2lkdGg6IDYwNHB4 O30KCi5tYWluIHsKCn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgp IHsKCS50aXRsZSB7CgkJZm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX0KCS5pbWFnZSB7CgkJ d2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9Cgku Zm9vdGVyIHsKCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1w b3J0YW50Cgl9CgkubWFpbiB7CgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDog NjA0cHggIWltcG9ydGFudAoJfQp9Cjwvc3R5bGU+Cgo8dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIg c3R5bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFs aWduPSJsZWZ0Ij4KCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3Ry PgoJPHRyPgoJCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2lu OiAwIj4KCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7 IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBh bGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPgoJCQkJPHRyPgoJCQkJCTx0ZCBhbGlnbj0iY2VudGVy IiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD4KCQkJCTwvdHI+CgkJCTwvdGFibGU+LS0+ CgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgIDx0ZCBzdHlsZT0iaGVpZ2h0OiAyMnB4 O2NvbG9yOiAjMDAwMDAwO2ZvbnQtZmFtaWx5OiBBcmlhbDsJZm9udC1zaXplOiAxNnB4O2ZvbnQt d2VpZ2h0OiBib2xkO2xpbmUtaGVpZ2h0OiAyMnB4OyI+CiAgICAgICAgICAgICAgICBORVRDT05G IFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYmV4IG1lZXRpbmcuCiAg ICAgICAgICAgICAgICAJICAgICAgICAgICA8L3RkPgogICAgICA8L3RyPgo8L3RhYmxlPgoKCjx0 YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBw eCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgogICAgPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRv OyB3aWR0aDphdXRvIWltcG9ydGFudDsiPgogICAgICAgIDx0cj4KICAgICAgICAgICAgPHRkIHN0 eWxlPSJmb250LWZhbWlseTogQXJpYWw7IGNvbG9yOiAjMDAwMDAwOyBmb250LXNpemU6IDE2cHg7 IGxpbmUtaGVpZ2h0OiAyMnB4OyI+CiAgICAgICAgICAgICAgICBNZWV0aW5nIG51bWJlciAoYWNj ZXNzIGNvZGUpOiAxNjEgMjY4IDM0NTkKICAgICAgICAgICAgPC90ZD4KICAgICAgICA8L3RyPgog ICAgPC90YWJsZT4KICAgIDx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBv cnRhbnQiPgogICAgICAgIDx0ciA+CiAgICAgICAgICAgIDx0ZCBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsOyBjb2xvcjogIzAwMDAwMDsgZm9udC1zaXplOiAxNnB4OyBsaW5lLWhlaWdodDogMjJw eDsiPk1lZXRpbmcgcGFzc3dvcmQ6IHRGNW1WUzJuNHdmPC90ZD4KICAgICAgICA8L3RyPgogICAg PC90YWJsZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9 ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCiAgICA8dGFibGUgIHdpZHRo PSIxMDAlIj4KICAgICAgICA8dHIgc3R5bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9u dC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsiPgogICAg ICAgICAgICA8dGQgc3R5bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6 IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsiPlR1ZXNkYXksIEp1bHkg MjgsIDIwMjAKICAgICAgICAgICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgICAgIDx0ciBzdHls ZT0ibWFyZ2luOjBweDtjb2xvcjogIzY2NjY2Njtmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXpl OiAxNHB4O2xpbmUtaGVpZ2h0OiAyMnB4OyI+CiAgICAgICAgICAgIDx0ZCBzdHlsZT0ibWFyZ2lu OjBweDtjb2xvcjogIzY2NjY2Njtmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xp bmUtaGVpZ2h0OiAyMnB4OyI+MTE6MDAgYW0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7KFVUQysw MDowMCkgTW9ucm92aWEsIFJleWtqYXZpayZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsxIGhyIDQw IG1pbnMKICAgICAgICAgICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KCiA8Rk9O VCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwv Rk9OVD4KCiAgICAKCgkJCTx0YWJsZSBzdHlsZT0icGFkZGluZy1ib3R0b206IDRweDtmb250LWZh bWlseTogQXJpYWw7Ij48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9Imhl aWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlIHN0eWxlPSd3aWR0 aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50Oyc+PHRyPjx0ZCBzdHlsZT0nd2lkdGg6YXV0byFp bXBvcnRhbnQ7ICc+PHRhYmxlIGJvcmRlcj0nMCcgY2VsbHBhZGRpbmc9JzAnIGNlbGxzcGFjaW5n PScwJyBzdHlsZT0nd2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDsgYmFja2dyb3VuZC1j b2xvcjojNDNBOTQyOyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjBw eDsgbWluLXdpZHRoOjE2MHB4IWltcG9ydGFudDsnPjx0Ym9keT48dHI+PHRkIGFsaWduPSdjZW50 ZXInIHN0eWxlPSdwYWRkaW5nOjEwcHggMzZweDtmb250LWZhbWlseTogQXJpYWw7Jz48YSBocmVm PSdodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMWE4YzE4YmMyZjU2NTQw NmE3ZjUwNTY1YmRhN2Q3ZGQnIHN0eWxlPSdjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsg dGV4dC1kZWNvcmF0aW9uOm5vbmU7Jz5Kb2luIG1lZXRpbmc8L2E+PC90ZD48L3RyPjwvdGJvZHk+ PC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWln aHQ6IDQ4cHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjQ4cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxl PgoKCgk8dGFibGU+PHRyPjx0ZCBzdHlsZT0iY29sb3I6ICMwMDAwMDA7Zm9udC1mYW1pbHk6IEFy aWFsOyBmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhlaWdodDogMjRw eDsiPjxiPlRhcCB0byBqb2luIGZyb20gYSBtb2JpbGUgZGV2aWNlIChhdHRlbmRlZXMgb25seSk8 L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJmb250LWZhbWls eTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4OyI+PGEgaHJlZj0ndGVs OiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMTYxMjY4MzQ1OSUyMyUyMyowMSonIHN0eWxlPSdjb2xv cjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtmb250 LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Jz4rMS02NTAtNDc5LTMyMDgsLDE2MTI2ODM0 NTkjIzwvYT4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyNHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyNHB4Ij4mbmJzcDs8L3Rk PjwvdHI+PC90YWJsZT48dGFibGU+PHRib2R5Pjx0cj48dGQgc3R5bGU9ImNvbG9yOiAjMDAwMDAw O2ZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsg bGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48dHIgc3R5 bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7Zm9udC1mYW1pbHk6IEFy aWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsiPjEtNjUwLTQ3OS0zMjA4Jm5i c3A7PHNwYW4gc3R5bGU9ImNvbG9yOiAjMzMzMzMzOyI+Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMv Q2FuYWRhKTwvc3Bhbj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9 ImZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Ij48 YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElE PW04ZWE5NzMyZDkxODkzNGJiNjlkYzIyMGQxYmNhMDE2ZiIgc3R5bGU9InRleHQtZGVjb3JhdGlv bjpub25lO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMEFGRjkiPkdsb2JhbCBjYWxsLWluIG51bWJl cnM8L2E+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNl bGxzcGFjaW5nPSIwIj48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOHB4OyI+PHRkIHN0eWxlPSJo ZWlnaHQ6MjhweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+Cgk8dGFibGU+PHRyPjx0ZCAgc3R5 bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBm b250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIGZyb20gYSB2aWRl byBzeXN0ZW0gb3IgYXBwbGljYXRpb248L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBw eCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNp emU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjE2MTI2ODM0 NTlAaWV0Zi53ZWJleC5jb20iICAgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMw MEFGRjkiPjE2MTI2ODM0NTlAaWV0Zi53ZWJleC5jb208L2E+PC90ZD48L3RyPjx0ciBzdHlsZT0i bWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFs OyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+WW91IGNhbiBhbHNvIGRpYWwg MTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjwvdGQ+PC90cj48L3Rh YmxlPjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWln aHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CiAgICA8dGFibGUgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIwIj48dHI+PHRkICBzdHlsZT0iY29sb3I6ICMwMDAwMDA7IGZvbnQt ZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xkOyBsaW5lLWhl aWdodDogMjRweDsiPjxiPkpvaW4gdXNpbmcgTWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNr eXBlIGZvciBCdXNpbmVzczwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQg c3R5bGU9ImNvbG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRw eDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5EaWFsIDxhIGhyZWY9IiBzaXA6MTYxMjY4MzQ1OS5pZXRm QGx5bmMud2ViZXguY29tIiAgIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBB RkY5Ij4xNjEyNjgzNDU5LmlldGZAbHluYy53ZWJleC5jb208L2E+PC90ZD48L3RyPjwvdGFibGU+ CgoJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCgoJCQk8dGFibGUgc3R5bGU9IndpZHRo OiAxMDAlOyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj4KICAgICAgICAgICAgICAgIDx0ciBz dHlsZT0iaGVpZ2h0OiA3MnB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPgoJCQkJPHRyPgoJCQkJCTx0 ZCBzdHlsZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7 IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxh IGhyZWY9Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQt ZGVjb3JhdGlvbjpub25lOyI+aHR0cDovL2hlbHAud2ViZXguY29tPC9hPgoJCQkJCTwvdGQ+CgkJ CQk8L3RyPgogICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJz cDs8L3RkPjwvdHI+CgkJCTwvdGFibGU+CgkJPC90ZD4KCTwvdHI+CjwvdGFibGU+Cg== ------=_Part_1902727_332445217.1594676767744 Content-Type: text/calendar;method=REQUEST;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL1JleWtqYXZpaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96 b25laW5mby1vdXRsb29rL0F0bGFudGljL1JleWtqYXZpaw0KWC1MSUMtTE9DQVRJT046QXRsYW50 aWMvUmV5a2phdmlrDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9GRlNF VFRPOiswMDAwDQpUWk5BTUU6R01UDQpEVFNUQVJUOjE5NzAwMTAxVDAwMDAwMA0KRU5EOlNUQU5E QVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDA3MTNUMjE0NjA3 Wg0KQVRURU5ERUU7Q049Im5ldGNvbmZAaWV0Zi5vcmciO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JT VlA9VFJVRTpNQUlMVE86bmV0Y29uZkBpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJORVRDT05GIFdv cmtpbmcgR3JvdXAiOk1BSUxUTzpuZXRjb25mLWNoYWlyc0BpZXRmLm9yZw0KRFRTVEFSVDtUWklE PUF0bGFudGljL1JleWtqYXZpazoyMDIwMDcyOFQxMTAwMDANCkRURU5EO1RaSUQ9QXRsYW50aWMv UmV5a2phdmlrOjIwMjAwNzI4VDEyNDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTFhOGMxOGJjMmY1NjU0MDZhN2Y1MDU2NWJkYTdkN2RkDQpUUkFO U1A6T1BBUVVFDQpTRVFVRU5DRToxNTk0Njc2NzY3DQpVSUQ6YjFjZTkyNDYtYzJjNy00Y2Y0LThh NzktZGNmZWJhMGFlMjQ1DQpERVNDUklQVElPTjpcblxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xu aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTFhOGMxOGJjMmY1NjU0MDZh N2Y1MDU2NWJkYTdkN2RkXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiAxNjEgMjY4IDM0 NTlcblxuTWVldGluZyBwYXNzd29yZDogdEY1bVZTMm40d2ZcblxuXG5cblRBUCBUTyBKT0lOIEZS T00gQSBNT0JJTEUgREVWSUNFIChBVFRFTkRFRVMgT05MWSlcbisxLTY1MC00NzktMzIwOCwsMTYx MjY4MzQ1OSMjIHRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjE2MTI2ODM0NTklMjMlMjMqMDEq IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1 MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cbkdsb2JhbCBjYWxs LWluIG51bWJlcnNcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhw P01USUQ9bThlYTk3MzJkOTE4OTM0YmI2OWRjMjIwZDFiY2EwMTZmXG5cblxuSk9JTiBGUk9NIEEg VklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDoxNjEyNjgzNDU5QGlldGYud2Vi ZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVl dGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQg U2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDoxNjEyNjgzNDU5LmlldGZAbHluYy53ZWJleC5j b21cblxuXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9jb2xsYWJvcmF0 aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTVcblxuXG5JTVBPUlRBTlQgTk9U SUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5k IG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVk LCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5n IHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGlu Z3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3Vy IGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4NClgt QUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3NzIj5cbnRhYmxl IHtcbglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwli b3JkZXItc3BhY2luZzogMDt9XG5cbnRyIHtcbglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRk IHtcbglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdv cmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxu LnRpdGxlIHtcbglmb250LXNpemU6IDI4cHg7fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwlt YXgtd2lkdGg6IGF1dG87fVxuXG4uZm9vdGVyIHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7 XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0 bGUge1xuCQlmb250LXNpemU6IDIycHggIWltcG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRo OiBhdXRvICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290 ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0 YW50XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDog NjA0cHggIWltcG9ydGFudFxuCX1cbn1cbjwvc3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZG RkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAl OyIgYWxpZ249ImxlZnQiPlxuCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90 ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4 OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9y ZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6 IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFs aWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4J CQk8L3RhYmxlPi0tPlxuXG5cblxuXG5cbgkJCTx0YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5c bgkJCQkJCTxGT05UIFNJWkU9IjQiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBp dCdzIHRpbWUsIGpvaW4gdGhlIFdlYmV4IG1lZXRpbmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+ XG4JCQkJPC90cj5cbgkJCQk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxl PSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJ CQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51 bWJlciAoYWNjZXNzIGNvZGUpOiAxNjEgMjY4IDM0NTk8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJ PC90cj5cbgkJCTwvdGFibGU+XG4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRk PjxGT05UIFNJWkU9IjIiICBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPnRGNW1WUzJuNHdm PC9GT05UPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4gICAgICAgIDx0YWJsZT5cbiAgICAgICAgCTx0 ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJz cDs8L3RkPjwvdHI+XG4JCQk8dHI+XG4JCQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFu dDsgIj5cbgkJCQkJPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIwIiBzdHlsZT0id2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDtiYWNrZ3JvdW5kLWNv bG9yOiM0M0E5NDI7IGJvcmRlcjowcHggc29saWQgIzQzQTk0MjsgYm9yZGVyLXJhZGl1czoyNXB4 OyBtaW4td2lkdGg6MTYwcHghaW1wb3J0YW50OyI+XG4JCQkJCQk8dHI+XG4JCQkJCQkJPHRkIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJwYWRkaW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xYThjMThiYzJmNTY1NDA2YTdmNTA1NjVi ZGE3ZDdkZCIgc3R5bGU9ImNvbG9yOiNGRkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29y YXRpb246bm9uZTsiPkpvaW4gbWVldGluZzwvYT48L3RkPlxuCQkJCQkJPC90cj5cbgkJCQkJPC90 YWJsZT5cbgkJCQk8L3RkPlxuCQkJPC90cj5cbgkJPC90YWJsZT5cblxuIDxGT05UIHNpemU9IjIi IENPTE9SPSIjRkYwMDAwIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyI+PC9GT05UPlxuPEZP TlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPlxuXG4m bmJzcDsgPEJSPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPlRhcCB0byBqb2luIGZyb20gYSBtb2JpbGUgZGV2aWNl IChhdHRlbmRlZXMgb25seSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSd0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCow MSoxNjEyNjgzNDU5JTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29y YXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdo dDogMjRweDsnPisxLTY1MC00NzktMzIwOCwsMTYxMjY4MzQ1OSMjPC9hPiBDYWxsLWluIHRvbGwg bnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEJSPjxGT05UIFNJWkU9IjQiIEZB Q0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpv aW4gYnkgcGhvbmU8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9D YW5hZGEpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNh bGxpbi5waHA/TVRJRD1tOGVhOTczMmQ5MTg5MzRiYjY5ZGMyMjBkMWJjYTAxNmYiIHN0eWxlPSJ0 ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTRweDtjb2xvcjojMDBBRkY5Ij5HbG9iYWwg Y2FsbC1pbiBudW1iZXJzPC9hPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48 dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5i c3A7PC90ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9O VCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gZnJvbSBhIHZpZGVv IHN5c3RlbSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJzaXA6MTYxMjY4MzQ1OUBp ZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFs Ij4xNjEyNjgzNDU5QGlldGYud2ViZXguY29tPC9GT05UPjwvYT4mbmJzcDsgPEJSPjxGT05UIFNJ WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+WW91IGNhbiBhbHNvIGRpYWwgMTcz LjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjwvRk9OVD4gJm5ic3A7IDxC Uj48L0ZPTlQ+Jm5ic3A7IDxCUj5cblxuPHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMCI+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7 Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48 Yj5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5l c3M8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjog IzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0 OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjE2MTI2ODM0NTkuaWV0ZkBseW5jLndlYmV4LmNv bSIgICBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+MTYxMjY4MzQ1 OS5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4JPHRhYmxlPjx0 ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNw OzwvdGQ+PC90cj48L3RhYmxlPlxuCVxuXG4JCQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIg YWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9Imhl aWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHls ZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQt c2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9 Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3Jh dGlvbjpub25lOyI+aHR0cDovL2hlbHAud2ViZXguY29tPC9hPlxuCQkJCQk8L3RkPlxuCQkJCTwv dHI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8 L3RkPjwvdHI+XG4JCQk8L3RhYmxlPlxuCQk8L3RkPlxuCTwvdHI+XG48L3RhYmxlPlxuDQpTVU1N QVJZOk5FVENPTkYgMTA4IFZpcnR1YWwgTWVldGluZw0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElD DQpCRUdJTjpWQUxBUk0NClRSSUdHRVI6LVBUNU0NCkFDVElPTjpESVNQTEFZDQpERVNDUklQVElP TjpSZW1pbmRlcg0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K ------=_Part_1902727_332445217.1594676767744-- ------=_Part_1902726_1773988547.1594676767744 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL1JleWtqYXZpaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96 b25laW5mby1vdXRsb29rL0F0bGFudGljL1JleWtqYXZpaw0KWC1MSUMtTE9DQVRJT046QXRsYW50 aWMvUmV5a2phdmlrDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRGUk9NOiswMDAwDQpUWk9GRlNF VFRPOiswMDAwDQpUWk5BTUU6R01UDQpEVFNUQVJUOjE5NzAwMTAxVDAwMDAwMA0KRU5EOlNUQU5E QVJEDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMDA3MTNUMjE0NjA3 Wg0KQVRURU5ERUU7Q049Im5ldGNvbmZAaWV0Zi5vcmciO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JT VlA9VFJVRTpNQUlMVE86bmV0Y29uZkBpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJORVRDT05GIFdv cmtpbmcgR3JvdXAiOk1BSUxUTzpuZXRjb25mLWNoYWlyc0BpZXRmLm9yZw0KRFRTVEFSVDtUWklE PUF0bGFudGljL1JleWtqYXZpazoyMDIwMDcyOFQxMTAwMDANCkRURU5EO1RaSUQ9QXRsYW50aWMv UmV5a2phdmlrOjIwMjAwNzI4VDEyNDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTFhOGMxOGJjMmY1NjU0MDZhN2Y1MDU2NWJkYTdkN2RkDQpUUkFO U1A6T1BBUVVFDQpTRVFVRU5DRToxNTk0Njc2NzY3DQpVSUQ6YjFjZTkyNDYtYzJjNy00Y2Y0LThh NzktZGNmZWJhMGFlMjQ1DQpERVNDUklQVElPTjpcblxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xu aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTFhOGMxOGJjMmY1NjU0MDZh N2Y1MDU2NWJkYTdkN2RkXG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiAxNjEgMjY4IDM0 NTlcblxuTWVldGluZyBwYXNzd29yZDogdEY1bVZTMm40d2ZcblxuXG5cblRBUCBUTyBKT0lOIEZS T00gQSBNT0JJTEUgREVWSUNFIChBVFRFTkRFRVMgT05MWSlcbisxLTY1MC00NzktMzIwOCwsMTYx MjY4MzQ1OSMjIHRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjE2MTI2ODM0NTklMjMlMjMqMDEq IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1 MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cbkdsb2JhbCBjYWxs LWluIG51bWJlcnNcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhw P01USUQ9bThlYTk3MzJkOTE4OTM0YmI2OWRjMjIwZDFiY2EwMTZmXG5cblxuSk9JTiBGUk9NIEEg VklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDoxNjEyNjgzNDU5QGlldGYud2Vi ZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVl dGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQg U2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDoxNjEyNjgzNDU5LmlldGZAbHluYy53ZWJleC5j b21cblxuXG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nP1xuaHR0cHM6Ly9jb2xsYWJvcmF0 aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTVcblxuXG5JTVBPUlRBTlQgTk9U SUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5k IG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVk LCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5n IHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGlu Z3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3Vy IGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4NClgt QUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3NzIj5cbnRhYmxl IHtcbglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwli b3JkZXItc3BhY2luZzogMDt9XG5cbnRyIHtcbglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRk IHtcbglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdv cmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxu LnRpdGxlIHtcbglmb250LXNpemU6IDI4cHg7fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwlt YXgtd2lkdGg6IGF1dG87fVxuXG4uZm9vdGVyIHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7 XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0 bGUge1xuCQlmb250LXNpemU6IDIycHggIWltcG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRo OiBhdXRvICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290 ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0 YW50XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDog NjA0cHggIWltcG9ydGFudFxuCX1cbn1cbjwvc3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZG RkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAl OyIgYWxpZ249ImxlZnQiPlxuCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90 ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4 OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9y ZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6 IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFs aWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4J CQk8L3RhYmxlPi0tPlxuXG5cblxuXG5cbgkJCTx0YWJsZT5cbgkJCQk8dHI+XG4JCQkJCTx0ZD5c bgkJCQkJCTxGT05UIFNJWkU9IjQiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+V2hlbiBp dCdzIHRpbWUsIGpvaW4gdGhlIFdlYmV4IG1lZXRpbmcgaGVyZS48L0ZPTlQ+XG4JCQkJCTwvdGQ+ XG4JCQkJPC90cj5cbgkJCQk8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxl PSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJ CQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51 bWJlciAoYWNjZXNzIGNvZGUpOiAxNjEgMjY4IDM0NTk8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJ PC90cj5cbgkJCTwvdGFibGU+XG4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRk PjxGT05UIFNJWkU9IjIiICBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPnRGNW1WUzJuNHdm PC9GT05UPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4gICAgICAgIDx0YWJsZT5cbiAgICAgICAgCTx0 ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJz cDs8L3RkPjwvdHI+XG4JCQk8dHI+XG4JCQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFu dDsgIj5cbgkJCQkJPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIwIiBzdHlsZT0id2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDtiYWNrZ3JvdW5kLWNv bG9yOiM0M0E5NDI7IGJvcmRlcjowcHggc29saWQgIzQzQTk0MjsgYm9yZGVyLXJhZGl1czoyNXB4 OyBtaW4td2lkdGg6MTYwcHghaW1wb3J0YW50OyI+XG4JCQkJCQk8dHI+XG4JCQkJCQkJPHRkIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJwYWRkaW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xYThjMThiYzJmNTY1NDA2YTdmNTA1NjVi ZGE3ZDdkZCIgc3R5bGU9ImNvbG9yOiNGRkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29y YXRpb246bm9uZTsiPkpvaW4gbWVldGluZzwvYT48L3RkPlxuCQkJCQkJPC90cj5cbgkJCQkJPC90 YWJsZT5cbgkJCQk8L3RkPlxuCQkJPC90cj5cbgkJPC90YWJsZT5cblxuIDxGT05UIHNpemU9IjIi IENPTE9SPSIjRkYwMDAwIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyI+PC9GT05UPlxuPEZP TlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPlxuXG4m bmJzcDsgPEJSPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPlRhcCB0byBqb2luIGZyb20gYSBtb2JpbGUgZGV2aWNl IChhdHRlbmRlZXMgb25seSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSd0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCow MSoxNjEyNjgzNDU5JTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29y YXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdo dDogMjRweDsnPisxLTY1MC00NzktMzIwOCwsMTYxMjY4MzQ1OSMjPC9hPiBDYWxsLWluIHRvbGwg bnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEJSPjxGT05UIFNJWkU9IjQiIEZB Q0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpv aW4gYnkgcGhvbmU8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9D YW5hZGEpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2dsb2JhbGNh bGxpbi5waHA/TVRJRD1tOGVhOTczMmQ5MTg5MzRiYjY5ZGMyMjBkMWJjYTAxNmYiIHN0eWxlPSJ0 ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTRweDtjb2xvcjojMDBBRkY5Ij5HbG9iYWwg Y2FsbC1pbiBudW1iZXJzPC9hPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48QlI+XG5cbjx0YWJsZT48 dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5i c3A7PC90ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9O VCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gZnJvbSBhIHZpZGVv IHN5c3RlbSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJzaXA6MTYxMjY4MzQ1OUBp ZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFs Ij4xNjEyNjgzNDU5QGlldGYud2ViZXguY29tPC9GT05UPjwvYT4mbmJzcDsgPEJSPjxGT05UIFNJ WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+WW91IGNhbiBhbHNvIGRpYWwgMTcz LjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjwvRk9OVD4gJm5ic3A7IDxC Uj48L0ZPTlQ+Jm5ic3A7IDxCUj5cblxuPHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMCI+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7 Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48 Yj5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5l c3M8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjog IzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0 OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjE2MTI2ODM0NTkuaWV0ZkBseW5jLndlYmV4LmNv bSIgICBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZGOSI+MTYxMjY4MzQ1 OS5pZXRmQGx5bmMud2ViZXguY29tPC9hPjwvdGQ+PC90cj48L3RhYmxlPlxuXG4JPHRhYmxlPjx0 ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNw OzwvdGQ+PC90cj48L3RhYmxlPlxuCVxuXG4JCQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIg YWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9Imhl aWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHls ZT0iaGVpZ2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQt c2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9 Imh0dHA6Ly9oZWxwLndlYmV4LmNvbSIgc3R5bGU9ImNvbG9yOiMwNDlGRDk7IHRleHQtZGVjb3Jh dGlvbjpub25lOyI+aHR0cDovL2hlbHAud2ViZXguY29tPC9hPlxuCQkJCQk8L3RkPlxuCQkJCTwv dHI+XG4gICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDQ0cHgiPjx0ZD4mbmJzcDs8 L3RkPjwvdHI+XG4JCQk8L3RhYmxlPlxuCQk8L3RkPlxuCTwvdHI+XG48L3RhYmxlPlxuDQpTVU1N QVJZOk5FVENPTkYgMTA4IFZpcnR1YWwgTWVldGluZw0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElD DQpCRUdJTjpWQUxBUk0NClRSSUdHRVI6LVBUNU0NCkFDVElPTjpESVNQTEFZDQpERVNDUklQVElP TjpSZW1pbmRlcg0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K ------=_Part_1902726_1773988547.1594676767744-- From nobody Mon Jul 13 15:31:39 2020 Return-Path: <010001734a4dbbe7-637ac888-1065-460e-a3a1-3c33a8c66bc7-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 C34183A07B6; Mon, 13 Jul 2020 15:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ihFszJeSk_Hv; Mon, 13 Jul 2020 15:31:35 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70ECD3A0DC7; Mon, 13 Jul 2020 15:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1594679475; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=XOhshG7fo+fDNTrE6S4uZBr5CfcPbTA0WYqAUeCWUuY=; b=XFL2PrzCTqyZ3Ugj6tdN15DLM39/0PAHj3+66c3L8Snp02zQcQ8WrhnvmrAf2LHC bRFtvcsz9247uMknYTEXiRkfBzWs9+n+Lg/oy5z1tIkJtORKLshVj4EXbP6CzPUjlWp W/QVaj7K3/z+Cf215ijBvlQTfblO+CjTJjnn1fkU= 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: <010001734a4dbbe7-637ac888-1065-460e-a3a1-3c33a8c66bc7-000000@email.amazonses.com> Date: Mon, 13 Jul 2020 22:31:15 +0000 Cc: "netconf-chairs@ietf.org" To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.13-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Preliminary Agenda 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, 13 Jul 2020 22:31:38 -0000 NETCONF WG. The preliminary agenda has been posted. Please send and comments or correction to the chairs (CC-ed) Thanks, NETCONF Chairs Agenda for the NETCONF 108 WG Session ------------------------------------- https://datatracker.ietf.org/meeting/108/materials/agenda-108-netconf Session: Tuesday July 28th UTC: 11:00-12:40 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/108/session/28155.ics Etherpad: https://etherpad.ietf.org/p/notes-ietf-108-netconf Slides: = https://datatracker.ietf.org/meeting/interim-2020-netconf-01/session/netco= nf=20 Jabber: xmpp:netconf@jabber.ietf.org?join MeetEcho Audio: http://mp3.conf.meetecho.com/ietf/ietf1084.m3u MeetEcho Video: http://www.meetecho.com/ietf108/netconf/ JOIN BY WEBEX: URL: = https://ietf.webex.com/ietf/j.php?MTID=3Dm55e3cb6f7775f96e872b86532ff11847= Meeting number (access code): 161 268 3459 Meeting password: tF5mVS2n4wf JOIN BY PHONE Tap to join from a mobile device (attendees only) +1-650-479-3208,,1612683459## Call-in toll number (US/Canada) =20 Global call-in numbers: = https://ietf.webex.com/ietf/globalcallin.php?MTID=3Dm8ea9732d918934bb69dc2= 20d1bca016f =20 Join from a video system or application Dial 1612683459@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. =20 Join using Microsoft Lync or Microsoft Skype for Business Dial 1612683459.ietf@lync.webex.com Available After Session: Recording: WebEx recording be made available after the meeting. Jabber Logs: https://www.ietf.org/jabber/logs/netconf Etherpad: https://etherpad.ietf.org/p/notes-ietf-108-netconf Slides: = https://datatracker.ietf.org/meeting/interim-2020-netconf-01/session/netco= nf Introduction Chairs (10 minutes) Session Intro & WG Status Chartered items: Status and Issues on Client-Server Suite of Drafts (10 min) https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-17 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-12 https://tools.ietf.org/html/draft-ietf-netconf-keystore-19 https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-07 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-21 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-21 https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-04 = https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-20 = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-20 Presenter: Kent Watsen An HTTPS-based Transport for Configured Subscriptions (10 min) https://tools.ietf.org/html/draft-ietf-netconf-https-notif-03 Presenter: Mahesh Jethanandani Non-Chartered items: UDP-based Transport for Configured Subscriptions (10 min) https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-00 Presenter: Pierre Francois =20 Subscription to Distributed Notifications (10 min) = https://datatracker.ietf.org/doc/draft-unyte-netconf-distributed-notif-00 Presenter: Thomas Graf Self-explanation Data Node Tag & Telemetry Data Export Capabilities = (15 min) = https://datatracker.ietf.org/doc/draft-tao-netconf-notif-node-tag-capabili= ties-02 = https://datatracker.ietf.org/doc/draft-tao-netconf-data-export-capabilitie= s-01 Presenter: Qin Wu / Liu Peng Adaptive Subscription to YANG & Bulk Subscription to YANG Event = Notifications (15 min) = https://datatracker.ietf.org/doc/draft-wang-netconf-adaptive-subscription-= 02 = https://datatracker.ietf.org/doc/draft-wang-netconf-bulk-subscribed-notifi= cations-02 Presenter: Qin Wu / Liu Peng =20 Conveying a CSR in a SZTP Bootstrapping Request (10 min) https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr-01 Presenter: Kent Watsen Remaining 10 min. From nobody Tue Jul 14 09:50:59 2020 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 3A88E3A08C0 for ; Tue, 14 Jul 2020 09:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.61 X-Spam-Level: X-Spam-Status: No, score=-9.61 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ik76br77; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=VHK2d3go Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVW5T5zG7yqP for ; Tue, 14 Jul 2020 09:50:56 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9153A0A94 for ; Tue, 14 Jul 2020 09:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27703; q=dns/txt; s=iport; t=1594745455; x=1595955055; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FVoJaCs5h1AWwXM2J0EfGahQKNhhDqYhoWyBpTsduOE=; b=ik76br77G+TZVD3924gq+QzAUFpfatbSPC6RCkAChMKcEIYf3Oj6EvdU ZY7DJ2Fsi5ju6hkKrYnAHM639UsZo9cH3Fzxzz+nJjm/6kQEtRHkh27cL caX1R5qww0dv0BT07nGYJmfkwlkSJ+Deoxqbl6wW02/QgduIz7gZQO7jB Y=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AEIZP+R1rJ347PXBosmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGuadiiVbIWcPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoPk1cGcK4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdBQBn4Q1f/40NJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBIy9RB28rLS8sCodvA41Rh1iRBoFCgREDVQQHAQEBCQM?= =?us-ascii?q?BARgBDAgCBAEBhAhEAoIHAiQ4EwIDAQELAQEFAQEBAgEGBG2FWwyFbwEBAQE?= =?us-ascii?q?CAQEBEBUGEwEBLAsBBAsCAQgOFxMHBwIlCxQRAgQBDQUIBhSDBYF+TQMOEQ8?= =?us-ascii?q?BDp8UAoE5iGF0gQEzgwEBAQWBMgEDAg5Bgy8YggcHCYE4gVOBF4oIGoFBP4F?= =?us-ascii?q?Ugk0+glwBAQIBARWBLRsrEYMLgi2PNIoDgRWZWYEECoJdhDGCV4FLkSiCdoE?= =?us-ascii?q?eiBuTBZFxiiSUUwIEAgQFAg4BAQWBaiOBV3AVGiGCNQEBMglHFwINjh4MF4N?= =?us-ascii?q?OhRSFQnQ3AgYIAQEDCXyOPwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,352,1589241600"; d="p7s'?scan'208,217";a="781585883" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2020 16:50:52 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 06EGoqTt021477 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Jul 2020 16:50:52 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Jul 2020 11:50:52 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Jul 2020 12:50:51 -0400 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 14 Jul 2020 11:50:50 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EZqk/O2VMKhCsZdr0A0fBgHUTiW6Oc/s9BKn4tWSXcLjSpdjvCrd/CP19FpLVlFiOoIaZYSFnt+zZGGsgiwAJmc3NaHsAlvmtO+hOWeKqfu+2Az1y30olXApQBAaqjM8HB8O19nrKtqXegjIQZYEiMpzugPiI/6zlxpfbSvVtg9KOhLrGduBL87OVc01hmc6FEca+ow2Od7uGSoXbWveWcVtSvZTSeYhoekey0lIedRjPdbdmtQsSQRPi8bdVucD1TS27XkKySmLqAMdeKT0Y74iwdrLP0Uza9+qdS/WthvH+3zAx0jRUaOs2B9Znej+14E3EOAJhWUD6h+NuR6KXw== 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=Tydq6Nqk0SJGpDJLXEJpmeFHx3anqKKoJ+2GSi19JXI=; b=SBvSXw0S/IrVoXB8niuw6Qfd+tJN9W6nHOgE9oiNVfP68UJm4arlYxOI/f30yD55EGQxxTINR0CcwZZYLvhk5z3pIoQPlrpcRCASjTw2Du2m5Sv37KBd2ZClo1/H9WEqMLFcJXTeeJD9AFggYCRSm5f64PrAPj8GB0MQdYlNZUJmqxyTpWXfsBfr2rf1RFC/+NImfJWhwIvUu2gjDdrRVqoyq2eBxOvZF1vAuh19x7w6vFtIKm5TTPAlM/FzXQzHNQCThyH3+zIvTZULKdYcpvvKdYA6SWnQbS66vh2IkKikCHLjPO3xSngx8NQpfJEXHtil+2Xcssn5bxaIg1BJTQ== 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=Tydq6Nqk0SJGpDJLXEJpmeFHx3anqKKoJ+2GSi19JXI=; b=VHK2d3goQNT5JCTVEma6uAlbGYBQvBdgMB5Cp+VQQmudnJKcuGi2rp3RbF7wRvsGyrhXlYEVh1a0zQ9r3K7vwVlVNyrIiAk7HCz5EHtnYk+WQarHlQ5FaVcZDAr/WGZmnVwP6s9yUkXXjXjXK55GqIxy0VwrStEi3yVNmeGHoHQ= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4741.namprd11.prod.outlook.com (2603:10b6:208:26a::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.23; Tue, 14 Jul 2020 16:50:41 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2%5]) with mapi id 15.20.3195.017; Tue, 14 Jul 2020 16:50:41 +0000 From: "Eric Voit (evoit)" To: Mahesh Jethanandani , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.txt Thread-Index: AQHWVuGAMhvA4eAgHUC1kvcCfWaYoqkHQQNg Date: Tue, 14 Jul 2020 16:50:40 +0000 Message-ID: References: <159440288260.29660.1882956283740039536@ietfa.amsl.com> In-Reply-To: <159440288260.29660.1882956283740039536@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2c28afd2-9463-4d81-9ef6-08d828160af8 x-ms-traffictypediagnostic: MN2PR11MB4741: 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: f+N2hp8l2OZc+e2Ts79BWnZmIlFd9LFEg5XTYSlLaUoEqMGx0DFCU4DZYmiurtj7OfugOhnG+Gg+Ac4XSP7t4+G/8GJHpFp8cpPRnEezvzkDoTAQDpxZVb40zodXZ+FlkOyssc1m6imw0OrZ4YsIbzqos3VZJGicztn++t2GeULGHh+5z878Y536uZnA/mS1Hbx1Uc1b4JjrmQQbeCXYKZgdsuSOr6MQNhy1Off6XyJ4kZWMlQLeFIifY6eziR4JBUPXTzOhgE0wHWwTo0pz/J4JMfo3eox3e7cGJNzE/YlXAIcnGKu9jam6Y4TzenOP/w+Z+C3+Zp6siRZvgOa1btDZ3chGwWBBNOZlJfjz3+PosK6XMXzqiqC+MrQEuSX9sODMV/V3qVd3WovFXvRQ5Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(376002)(39860400002)(346002)(366004)(9326002)(9686003)(33656002)(7696005)(5660300002)(99936003)(186003)(55016002)(6506007)(26005)(110136005)(52536014)(316002)(66946007)(2906002)(66446008)(76116006)(966005)(66574015)(8676002)(166002)(83380400001)(478600001)(86362001)(4326008)(8936002)(71200400001)(66616009)(66556008)(66476007)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: hO6W0xjVFZSAwTGYqVIo/Z8aRPKT3m3YdiaEJnLvRwZkoE9SUi0fMuvV4/4uRx8aCsv9TB3gv4OW3xNQS3yv6voEILVE5ZwgiQtSevs38XkxXKeZVYpVnup0L/gkajD58Gr7GNCa8KcP2gbUlc+8kn3N9cOeuH+ISyq5K0tMuP6rXSazCXV5DgjY6XXljePBuCYJqDKStdkE8L37Mb+rz6jX5DGEwdWx7ljeUmgiDPEuceB7cKWq1sORPshbhiY1KZ6P9aZoJW1LReeiEAfZ5sZLwi0dTAMj0dgmBlsfgdQhKGNkU7mTxr/X4rYPy2LTxbaURYlJU/Gg6B/EVZXi0RxwKRwsE/dBZTXKd4f3Re9w3FiVVSGEnZYihz3kBGtpTTEfzV3q4dCEwpFos2F4mFM2rbWtgg356xnVB6LfC9//Y71Wz2D+NvCbwcKvyFMAmYi7FdFkyjSkZnMLgU49PUMHgKT7c5lA8hOrwpSH4O2PEqENy3IFRAk25yLkuP2B x-ms-exchange-transport-forked: True Content-Type: multipart/signed; boundary="----=_NextPart_000_0115_01D659DC.C149BA40"; protocol="application/x-pkcs7-signature"; micalg=SHA1 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: 2c28afd2-9463-4d81-9ef6-08d828160af8 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 16:50:40.9003 (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: 1BurOGCs4FwQKD965bw8lFcaY0iDL/wS3a2blsfb4lzarCGReWmRWCfyJ9mxmLCF X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4741 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.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, 14 Jul 2020 16:50:58 -0000 ------=_NextPart_000_0115_01D659DC.C149BA40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0116_01D659DC.C149BA40" ------=_NextPart_001_0116_01D659DC.C149BA40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mahesh, Hi Kent, It is good to see the updates and simplifications made. A few questions / thoughts on the latest: (1) For ietf-https-notif.yang why did you choose "uses x509c2n:cert-to-name" rather than linking to ietf-truststore.yang's grouping truststore-grouping +-- certificate-bags! {certificates}? +-- certificate-bag* [name] +-- name? string +-- certificate* [name] +-- name? string (2) Do you plan any functionality which inter-related with the receiver action 'reset' from SN? Right now this SN action resets the subscription. Whether this actually does anything to any underlying connection is undefined in SN. So I think what you have is fine as you define no actions on receiver-instances. But I figured I would ask: is there anything connection related which you might expose for the receiver as a whole? (3) I have a question on receiver capability discovery prior to sending notifications. Section 2.1 says that a publisher 'can' issue an HTTP GET for the capabilities. This also suggests that it can choose not to send such a request. What is the required behavior for an HTTPS publisher and receiver when the targeted receiver doesn't support the expected capabilities? (4) Extending the question (3), the notification from SN can be used for this functionality. Looking at the example you have in pipelining Section 1.5.1, the second POST of a YANG notification occurs is shown before the "Send 204 (No Content) is returned" for the first notification. Could you explicitly add the notification to section 1.5.1 to disambiguate things? For example: ------------- -------------- | Publisher | | Receiver | ------------- -------------- Establish TCP ------> Establish TLS ------> Send HTTPS POST message with started> notification Send 200 (OK) <------ for Send HTTPS POST message with YANG defined ------> notification #1 Send HTTPS POST message with YANG defined ------> notification #2 Send 204 (No Content) <------ for notification #1 Send 204 (No Content) <------ for notification #2 There were some earlier discussions on these overall interactions in threads like: https://mailarchive.ietf.org/arch/msg/netconf/oUxidvvW95lmxS1LLqyvuivuRcA/ Thanks, Eric > 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-03.txt > Pages : 27 > Date : 2020-07-10 > > Abstract: > 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 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-03 > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-03 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_001_0116_01D659DC.C149BA40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mahesh,

Hi = Kent,

 

It is good to see the updates and simplifications = made.  A few questions / thoughts on the latest:

 

(1) = For ietf-https-notif.yang why did you choose "uses = x509c2n:cert-to-name" rather than linking to = ietf-truststore.yang's

     grouping = truststore-grouping

       +-- = certificate-bags! {certificates}?

     =      +-- certificate-bag* = [name]

       =       +-- = name?          = string

       =       +-- certificate* = [name]

       =          +-- = name?           &n= bsp;           &nb= sp;    string

 

(2) Do = you plan any functionality which inter-related with the receiver action = 'reset' from SN?  Right now this SN action resets the = subscription.  Whether this actually does anything to any = underlying connection is undefined in SN.  So I think what you have = is fine as you define no actions on receiver-instances.  But I = figured I would ask: is there anything connection related which you = might expose for the receiver as a whole?

 

(3) I = have a question on receiver capability discovery prior to sending = notifications.  Section 2.1 says that a publisher 'can' issue an = HTTP GET for the capabilities.  This also suggests that it can = choose not to send such a request.  What is the required behavior = for an HTTPS publisher and receiver when the targeted receiver doesn't = support the expected capabilities?

 

(4) = Extending the question (3), the  <subscription-started> = notification from SN can be used for this functionality.   = Looking at the example you have in pipelining Section 1.5.1, the second = POST of a YANG notification occurs is shown before the "Send 204 = (No Content) is returned" for the first notification.  =  Could you explicitly add the <subscription-started> = notification to section 1.5.1 to disambiguate things?  For = example:  

 

       = -------------          =             &= nbsp;        = --------------

       = | Publisher = |            =             &= nbsp;      | Receiver   = |

       = -------------          =             &= nbsp;        = --------------

 

       Establish = TCP           &nbs= p; ------>

 

       Establish = TLS           &nbs= p; ------>

 

       Send HTTPS POST = message

       with = <subscription-       = ------>

       started> = notification

         = ;            =             &= nbsp;           &n= bsp;     Send 200 (OK)

         = ;            =             = <------           = for <subscription-started>

 

 

       Send HTTPS POST = message

       = with YANG defined         = ------>

       = notification #1

 

       Send HTTPS POST = message

       = with YANG defined         = ------>

       = notification #2

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   Send 204 (No Content)

           &= nbsp;           &n= bsp;         = <------           = for notification #1

 

           &= nbsp;           &n= bsp; =             &= nbsp;           &n= bsp; Send 204 (No Content)

           &= nbsp;           &n= bsp;         = <------           = for notification #2

 

There = were some earlier discussions on these overall interactions in threads = like:

https://mailarchive.ietf.org/arch/msg/netconf/oUxidvvW95lmxS1L= LqyvuivuRcA/

 

Thanks,
Eric

 

> 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   &n= bsp;       : An HTTPS-based Transport for = Configured Subscriptions

> =         Authors   =       : Mahesh Jethanandani

> =             &= nbsp;           &n= bsp; Kent Watsen

> =             = Filename        : = draft-ietf-netconf-https-notif-03.txt

> =             = Pages           : = 27

> =             = Date            : = 2020-07-10

>

> Abstract:

> =    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 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/ht= ml/draft-ietf-netconf-https-notif-03

> https://datatracker.ietf.= org/doc/html/draft-ietf-netconf-https-notif-03

>

> A diff from = the previous version is available at:

> https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-netconf-https-notif-03

>

>

> Please note that it may take a couple of = minutes from the time of

> submission = until the htmlized version and diff are available at = tools.ietf.org.

>

> Internet-Drafts are also available by = anonymous FTP at:

> ftp://ftp.ietf.org/intern= et-drafts/

>

>

> = _______________________________________________

> netconf mailing list

> netconf@ietf.org

> https://www.ietf.org/mail= man/listinfo/netconf

------=_NextPart_001_0116_01D659DC.C149BA40-- ------=_NextPart_000_0115_01D659DC.C149BA40 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNzE0MTY0NjEyWjAjBgkqhkiG 9w0BCQQxFgQUju0uLa80hGiaP8eUxQns8EYMwMswSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAkKD2umtEquaj4sN7SRcF49keE/SdEtGYt43HgaA1qwxknLzhDB2Z2K8P+SUyXSuG1 mC5sSLcc/kU2700+3WrCbE3Ska7BuHtCZPB2YkvjvhPnuGdRZn2Ci7CevT3YalCNNKR9mq4rAaKK TxBZxN+tdth4x9OjPkeYMOlvChDRxefcxT6ChJQPhpxzs15LqoYzaqaghF7vqPukTKEq7lr/Ydqz bxAFHN3essKsTM9E8rvs32WpwGDYqnc5ZxLUHWv4vOv2y8otE5sRQHoO/7UZfmHMbHL137IzXoLY 6aCk6nwQCMAwAZ6Q/x7aW27t8GfDzXMYCmrtk/CStJgvTh80AAAAAAAA ------=_NextPart_000_0115_01D659DC.C149BA40-- From nobody Wed Jul 15 11:23:43 2020 Return-Path: <0100017353b7bf1e-ff6960e2-28be-4651-90a1-4c91fdfcd212-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 65A133A0AF7 for ; Wed, 15 Jul 2020 11:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PattjP8kDX62 for ; Wed, 15 Jul 2020 11:23:39 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D383A0AD9 for ; Wed, 15 Jul 2020 11:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1594837417; h=From:Content-Type:Mime-Version:Subject:Message-Id:References:To:Date:Feedback-ID; bh=TTmC74HucVuMx2TCATq4tndauUBgzxftIJ13vQZLJpY=; b=MbS9U8NFY57hf8mSrlvRBQjMTU8ByfidhRqqmR9FL0riLqwhRPERfkfMlx44tO7j kWSvSSjd/9+ojVR6grDWfNG2VmBNxvCdICBUIyCCglANIk3jvfg7n6NVA+XCll4Lxos JagAUG0uWGko3l7d0mrL9aOB48GHMPmVV55auMMc= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_9582C3CA-F9AA-4143-8FBD-6FC6E6EF8C66" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <0100017353b7bf1e-ff6960e2-28be-4651-90a1-4c91fdfcd212-000000@email.amazonses.com> References: To: "netconf@ietf.org" Date: Wed, 15 Jul 2020 18:23:37 +0000 X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.15-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Fwd: [netconf-wg/trust-anchors] Missing prefixes in typedefs certificate-ref and public-key-ref (#1) 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, 15 Jul 2020 18:23:41 -0000 --Apple-Mail=_9582C3CA-F9AA-4143-8FBD-6FC6E6EF8C66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The following issue was submitted via GitHub issue tracker. I admit that I=E2=80=99ve been lax in prefixing nodes in paths, and it = likely occurs in the entire collection of drafts that we=E2=80=99ve been = working on. Honestly, when a prefix should NOT be used isn=E2=80=99t = entirely clear. The grouping rules allow for local-scope resolution = when a prefix is not specified, but when that might be needed or useful = is unclear to me. Unless there is an objection, I plan to add prefixes to all paths in all = the drafts. K. > Begin forwarded message: >=20 > From: Nick Hancock > Subject: [netconf-wg/trust-anchors] Missing prefixes in typedefs = certificate-ref and public-key-ref (#1) > Date: July 15, 2020 at 4:59:05 AM EDT > To: netconf-wg/trust-anchors > Cc: Subscribed > Reply-To: netconf-wg/trust-anchors = >=20 >=20 > yanglint flags an issue when using the typedefs 'certificate-ref' and = 'public-key-ref'. >=20 > Since the typedef references nodes in ietf-truststore and the node, = 'certficate-bag', defined in another module as a sibling node to the = node where you reference a certificate, you need to use prefixes on all = nodes within ietf-truststore. >=20 > If you change the definition, for example, of certificate-ref as = follows, yanglint, then returns no errors when the typedef is used: >=20 > typedef certificate-ref { > type leafref { > path "/ts:truststore/ts:certificate-bags/ts:certificate-bag" + > "[ts:name =3D current()/../certificate-bag]" + > "/ts:certificate/ts:name"; > } > description > "This typedef define a reference to a specific certificate > in a certificate bag defined in the Truststore. This > typedef requires that there exist a sibling 'leaf' node > called 'certificate-bag' that SHOULD have the typedef > 'certificate-bag-ref'."; > } >=20 > =E2=80=94 > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub = , or unsubscribe = . >=20 --Apple-Mail=_9582C3CA-F9AA-4143-8FBD-6FC6E6EF8C66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = following issue was submitted via GitHub issue tracker.
I admit that I=E2=80=99ve been lax in = prefixing nodes in paths, and it likely occurs in the entire collection = of drafts that we=E2=80=99ve been working on.  Honestly, when a = prefix should NOT be used isn=E2=80=99t entirely clear.  The = grouping rules allow for local-scope resolution when a prefix is not = specified, but when that might be needed or useful is unclear to = me.

Unless = there is an objection, I plan to add prefixes to all paths in all the = drafts.

K.


Begin = forwarded message:

From: = Nick Hancock <notifications@github.com>
Subject: = [netconf-wg/trust-anchors] Missing prefixes in typedefs = certificate-ref and public-key-ref (#1)
Date: = July 15, 2020 at 4:59:05 AM = EDT
To: = netconf-wg/trust-anchors <trust-anchors@noreply.github.com>


yanglint flags an issue when using the typedefs = 'certificate-ref' and 'public-key-ref'.

Since the = typedef references nodes in ietf-truststore and the node, = 'certficate-bag', defined in another module as a sibling node to the = node where you reference a certificate, you need to use prefixes on all = nodes within ietf-truststore.

If you change the = definition, for example, of certificate-ref as follows, yanglint, then = returns no errors when the typedef is used:

typedef = certificate-ref {
type leafref {
path "/ts:truststore/ts:certificate-bags/ts:certificate-bag" +
"[ts:name =3D current()/../certificate-bag]" = +
"/ts:certificate/ts:name";
}
description
"This typedef define a reference to a specific certificate
in a certificate bag defined in the Truststore. This
typedef requires that there exist a sibling 'leaf' node
called 'certificate-bag' that SHOULD have the typedef
'certificate-bag-ref'.";
}

=E2=80=94
You are receiving this because you = are subscribed to this thread.
Reply to this email = directly, view it on GitHub, or unsubscribe.3D""


= --Apple-Mail=_9582C3CA-F9AA-4143-8FBD-6FC6E6EF8C66-- From nobody Wed Jul 15 16:21:36 2020 Return-Path: <0100017354c87c8a-e19d1df5-0113-4b19-b6cd-9394c017b6ff-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 30A6D3A0B4C for ; Wed, 15 Jul 2020 16:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9S_Pssg3TQu for ; Wed, 15 Jul 2020 16:21:33 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C573A0B49 for ; Wed, 15 Jul 2020 16:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1594855292; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=cNCvjEKrDkFWEjS5ajqS80aTJ3Vt+L731Mv5SKOshes=; b=SXtG8zIjEBmr9znOYITTSZq6Gjxbam/smQA9tvkrt42J2UG48oS2ziP6CqzmIBkD vhIU2ama3LHh80mIMGTsPbgdQxpeDGb2yaD4X38weHx6EiTZNSUH3yAIVghyEsYiFup XVhCDEtwGRISz2DImR5isumsaBSGbdMi0RSo/4kI= From: Kent Watsen Message-ID: <0100017354c87c8a-e19d1df5-0113-4b19-b6cd-9394c017b6ff-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BA6C79FF-F084-4BFF-8077-9F437E42DEC3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 15 Jul 2020 23:21:32 +0000 In-Reply-To: Cc: Mahesh Jethanandani , "netconf@ietf.org" To: "Eric Voit (evoit)" References: <159440288260.29660.1882956283740039536@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.15-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.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, 15 Jul 2020 23:21:35 -0000 --Apple-Mail=_BA6C79FF-F084-4BFF-8077-9F437E42DEC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, > (1) For ietf-https-notif.yang why did you choose "uses = x509c2n:cert-to-name" rather than linking to ietf-truststore.yang's > grouping truststore-grouping > +-- certificate-bags! {certificates}? > +-- certificate-bag* [name] > +-- name? string > +-- certificate* [name] > +-- name? string I=E2=80=99m unclear about the issue. Cert-to-name performs a mapping = that doesn't exist anywhere else... > (2) Do you plan any functionality which inter-related with the = receiver action 'reset' from SN? Right now this SN action resets the = subscription. Whether this actually does anything to any underlying = connection is undefined in SN. So I think what you have is fine as you = define no actions on receiver-instances. But I figured I would ask: is = there anything connection related which you might expose for the = receiver as a whole? No SN-relation is planned. I=E2=80=99m unsure exactly what the ask is. = Please advise. =20 > (3) I have a question on receiver capability discovery prior to = sending notifications. Section 2.1 says that a publisher 'can' issue an = HTTP GET for the capabilities. This also suggests that it can choose = not to send such a request. What is the required behavior for an HTTPS = publisher and receiver when the targeted receiver doesn't support the = expected capabilities? IIRC, the encoding MAY be configured in the SN model. If it is not = *and* the publisher doesn=E2=80=99t probe the receiver=E2=80=99s = capabilities, and thus blindly sends whatever it wants, it risks the = receiver returning an HTTP 4xx error. Makes sense? > (4) Extending the question (3), the = notification from SN can be used for this functionality. Looking at = the example you have in pipelining Section 1.5.1, the second POST of a = YANG notification occurs is shown before the "Send 204 (No Content) is = returned" for the first notification. Could you explicitly add the = notification to section 1.5.1 to disambiguate = things? For example: =20 > =20 > ------------- -------------- > | Publisher | | Receiver | > ------------- -------------- > =20 > Establish TCP ------> > =20 > Establish TLS ------> > =20 > Send HTTPS POST message > with > started> notification=20 > Send 200 (OK) > <------ for = > =20 > =20 > Send HTTPS POST message > with YANG defined ------> > notification #1 > =20 > Send HTTPS POST message > with YANG defined ------> > notification #2 > Send 204 (No = Content) > <------ for notification #1 > =20 > Send 204 (No = Content) > <------ for notification #2 I think that this is proper. Guidance welcomed. But not that, beyond = HTTP [N}ACKs, this is a one-way flow of content, so whatever needs to = fit into those HTTP responses. Kent // as co-author > There were some earlier discussions on these overall interactions in = threads like: > = https://mailarchive.ietf.org/arch/msg/netconf/oUxidvvW95lmxS1LLqyvuivuRcA/= = > =20 > Thanks, > Eric --Apple-Mail=_BA6C79FF-F084-4BFF-8077-9F437E42DEC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

(1) For ietf-https-notif.yang = why did you choose "uses x509c2n:cert-to-name" rather than linking to = ietf-truststore.yang's
     grouping truststore-grouping
       +-- certificate-bags! = {certificates}?
          +-- = certificate-bag* [name]
       =       +-- = name?          string
       =       +-- certificate* [name]
       =          +-- = name?           &nb= sp;            = ;    string

I=E2=80=99m unclear about the issue. =  Cert-to-name performs a mapping that doesn't exist anywhere = else...


(2) Do = you plan any functionality which inter-related with the receiver action = 'reset' from SN?  Right now this SN action resets the = subscription.  Whether this actually does anything to any = underlying connection is undefined in SN.  So I think what you have = is fine as you define no actions on receiver-instances.  But I = figured I would ask: is there anything connection related which you = might expose for the receiver as a = whole?

No = SN-relation is planned. I=E2=80=99m unsure exactly what the ask is. =  Please advise.

 
(3) I have a question on = receiver capability discovery prior to sending notifications.  = Section 2.1 says that a publisher 'can' issue an HTTP GET for the = capabilities.  This also suggests that it can choose not to send = such a request.  What is the required behavior for an HTTPS = publisher and receiver when the targeted receiver doesn't support the = expected capabilities?

IIRC, the encoding MAY be configured in the SN = model.  If it is not *and* the publisher doesn=E2=80=99t probe the = receiver=E2=80=99s capabilities, and thus blindly sends whatever it = wants, it risks the receiver returning an HTTP 4xx error.  Makes = sense?


 (4) = Extending the question (3), the  <subscription-started> = notification from SN can be used for this functionality.   = Looking at the example you have in pipelining Section 1.5.1, the second = POST of a YANG notification occurs is shown before the "Send 204 (No = Content) is returned" for the first notification.   Could you = explicitly add the <subscription-started> notification to section = 1.5.1 to disambiguate things?  For = example:   
 
       = -------------          &= nbsp;           &nb= sp;        --------------
       | Publisher = |            &= nbsp;           &nb= sp;      | Receiver   |
       = -------------          &= nbsp;           &nb= sp;        --------------
 
       Establish = TCP            = ; ------>
 
       Establish = TLS            = ; ------>
 
       Send = HTTPS POST message
       with = <subscription-       ------>
       started> = notification 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;   Send 200 (OK)
          &nb= sp;            = ;          = <------           = for <subscription-started>
 
 
       Send HTTPS POST = message
       with YANG = defined         ------>
       notification #1
 
       Send HTTPS POST = message
       with YANG = defined         ------>
       notification #2
          &nb= sp;            = ;            &= nbsp;           &nb= sp;   Send 204 (No Content)
          &nb= sp;            = ;          = <------           = for notification #1
 
          &nb= sp;            = ;  =             &n= bsp;           &nbs= p; Send 204 (No Content)
          &nb= sp;            = ;          = <------           = for notification #2

I think that this is proper.  Guidance = welcomed.  But not that, beyond HTTP [N}ACKs, this is a one-way = flow of content, so whatever needs to fit into those HTTP = responses.

Kent // as = co-author



There were some earlier discussions on these overall = interactions in threads like:
 
Thanks,
Eric


= --Apple-Mail=_BA6C79FF-F084-4BFF-8077-9F437E42DEC3-- From nobody Thu Jul 16 06:21:05 2020 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 EBC4D3A00E4 for ; Thu, 16 Jul 2020 06:21:03 -0700 (PDT) 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_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=P38X1are; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=lojCO8mE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcqIEilb4CyZ for ; Thu, 16 Jul 2020 06:21:00 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948523A003E for ; Thu, 16 Jul 2020 06:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11264; q=dns/txt; s=iport; t=1594905660; x=1596115260; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1UPCy8U4ufMqhUJbiRqG/GeTOhaRT/5Jw9XdMl5GCMM=; b=P38X1areJtqZki4k0OywgbgrT+zB/WdkLUN6pfjvq1yye+FBRZiPU+AK SRwxy1vVDJ1fOHt1rJDZeCrmitjsPv+nUsH81ZpVyptjdYflQ+vCB8fV1 Zpnwxas/fN6gw4LXiQJj1k4JHZ9/h78XsXMeLAFx6IOAymLni6Xdkkq76 I=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3A7y5j9B31xIOeeeWwsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGu6dyhUPSUIOd7f9Y2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YldcBN3zYRvUr2HhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJCACZUxBf/4UNJK1XCR0BAQEBCQE?= =?us-ascii?q?SAQUFAYIKgVJRB28rLS8sCoQpg0YDjUeYXoFCgREDVQQHAQEBCQMBASUIAgQ?= =?us-ascii?q?BAYRMAoITAiQ4EwIDAQELAQEFAQEBAgEGBG2FWwyFbwEBAQECARIRBBkBATA?= =?us-ascii?q?HAQQLAgEIFRAdAgICMCUCBA4NBhSDBYF+TQMOEQ8BDgOfNQKBOYhhdn8zgwE?= =?us-ascii?q?BAQWBMgGEARiCBwcDBoE4gVOBF4NVg2iCSxqBQT+BEUOCTT6CXAKBMxMBGoM?= =?us-ascii?q?UM4ItjzmCWD2GdppxgQQKgl2EMoJYgUuRLIJ4iT2TDJwjlFYCBAIEBQIOAQE?= =?us-ascii?q?FgWojgVdwFYMkUBcCDY4eDBeDToUUhUJ0NwIGAQcBAQMJfI17AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,359,1589241600"; d="p7s'?scan'208";a="524795648" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Jul 2020 13:20:59 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 06GDKxIV016869 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Jul 2020 13:20:59 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jul 2020 08:20:59 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 16 Jul 2020 09:20:58 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 16 Jul 2020 08:20:58 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hZmRxLSE6Zog7pWYSgI29mBarjPXaONGaz9EEUVQ44FpZaVOKBUTGMGA4hjcZOOtImt0wLr93np/55yQaOejAGPEPVIundeOwOh4p4WL9nD7pclGK6SHH2aBjPB1LoycJeqOlsybtnSKwRVgebXOhUhLS5DaeB/wMTAxvRSUpWg5GkwBw2D0YSzlnLwiWA4SapRtMoJrUGfBlYAIHct5ehDm+2UaeIKeTR6nBfD9X1h9On2/lQRCGef7CpLNzt6y29f+NuvMHF/ipbpvzFRjFBLgPDaiYU4cZGhmRlohO6rNfKCJM632vFIZe42vgwnTU9ml5HRG+HMWpETP+w3O+g== 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=3CCGF/epB8+3p1Yq1LHlHBKE0n0FtB0FgHaPmthEFHA=; b=IydjWiOcZNtf6XihMGQaQcz+tdJPPAe6FjCpTpqxsv80ZKxFPOXHHeyaw3CRZYw7RKb5bB+gD76JXwLCvrSjROWYD/SKSh7emsB25yfjyrlP0yr7EdZU06fjIbSUElJvliG2XoooSQFJ4bnsmQXNulG8bhWeJDTuHQ7k74MeU0U5YrNTg4zstlwH3qWovGrIoI8nM4k1DEovY/NiAA20lmXsIY47PYQfeOEzCEZ8lVLpOnyrE+3KTpGoTpqyZKF25k5BiyNPLu+K6KHEltcjQsLBkCG9rdPlSnQUPdDueAL29FMrk+yaU7DUEQAM/1MBrvIMdLuFhll9s4r0S/uSQA== 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=3CCGF/epB8+3p1Yq1LHlHBKE0n0FtB0FgHaPmthEFHA=; b=lojCO8mEvgKhQhkqNIxFRiWdIAFKPfXyNdItQzGLsFufgJzoNh2hPug3ng+NduJz9y0W+uDW/18dnN1CB1gz9XqB/FSrIK6VXpx2zy1X7pT2q5mesCCbW1jkRRTUmbNROjy6Kfo44BXi3gMzahdwYk1ijXDcKqtyJuoSfc1gAaU= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB2946.namprd11.prod.outlook.com (2603:10b6:208:78::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Thu, 16 Jul 2020 13:20:57 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2%5]) with mapi id 15.20.3195.018; Thu, 16 Jul 2020 13:20:57 +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-03.txt Thread-Index: AQHWVuGAMhvA4eAgHUC1kvcCfWaYoqkHQQNggAIOkwCAANYigIAAAF/w Date: Thu, 16 Jul 2020 13:20:56 +0000 Message-ID: References: <159440288260.29660.1882956283740039536@ietfa.amsl.com> <0100017354c87c8a-e19d1df5-0113-4b19-b6cd-9394c017b6ff-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: [173.38.117.77] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 712154a6-82fe-4872-c9e5-08d8298b132a x-ms-traffictypediagnostic: BL0PR11MB2946: 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: /+Hd3MSYpx8COmkh70/q0nTwWS+QxSK7dd7y/AVfbi/Da6sHC2POasmYAjlFSlXBcDiYcbi5SZ1F22qNSoV0whQxDQnzYnLadee1ioU4nam3n0NY9OWY/noO/YGnDSKe2Iet1+dHph5t3feMlpzMCPKt7A0qlgxagXdKP4Pd6FcOdcd1mrUIue/xvY2D1sBoxBMWEsQIxMjQSpTgtx9l7tlTBdhUi6G5xnM3Hy/UsgNapGIGICyohQ2SqVO1GbfCtptTwc8k4UtumYceG08AemJx4TzyedSCnY9BUXhc8D38TVbFddpZb/Myv5t7f237wFmygBNrLWXN3L2ERsd3P1C+bYKx3W7Ud9KPhZWjAAO2Y0StgMww6QWnVKHOMoWNZVllT16kPfosd4dkLd/ZUg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(366004)(136003)(396003)(376002)(2940100002)(66946007)(2906002)(66556008)(76116006)(66476007)(7696005)(5660300002)(52536014)(66616009)(6506007)(99936003)(478600001)(64756008)(33656002)(54906003)(71200400001)(26005)(9686003)(66446008)(55016002)(86362001)(316002)(8676002)(8936002)(4326008)(186003)(83380400001)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Hxfrwv8SsoKPd+IANkQvqkZGF0oxvw4LIoOfXLHae9iPygoLkE8h2My9Ts5pxPrQSQ3l2Gvjcz7wxh9W1ImNhGDUegeLHj8lw5dwkZAFPJ8XcLhr0Dno+bfa+ZAkRx6Wx37TqXV1pJYxoDAbLyoo5H6Lv5FQv5dDsFtxnenOfXNOXTcr+24xbTkgRf4qfUylqDENOHn2kGZequCyCRAuMZQ7T/dx0FAC95848wyO8Q9KtvV89N2OVMgWEn4JrvOOet3Z19iGOAYMoJtUAs0J4jxIzXEIOum1nEAaXlRFmkd/yZKiblC387xj+ku2SuCbMNSI2aWeJvpalmh+/ZPqWTUo+TGCDaSj57Mk1GbK9oEGDsrvjHWsiZTrG4ASwBx4ewbPnN1lO1D9y8qbEES2vPN7pdAzkKUPXGuj9ishsV4PqdpMePgWsLOog8kmLEVai5guPZYgoGuwuwGDVY+hOd8z9SIp4N+1ZBAlb/4wrLRrpWr4I+sPkTADZK5J9Dy0 x-ms-exchange-transport-forked: True Content-Type: multipart/signed; boundary="----=_NextPart_000_049E_01D65B52.67AA0590"; protocol="application/x-pkcs7-signature"; micalg=SHA1 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: 712154a6-82fe-4872-c9e5-08d8298b132a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2020 13:20:56.9910 (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: dUNrxsW485Cqvktp9DdKqKQClVN6/UQawJa+CbPwhTqp5YacmGCVSJ40VHT9TxjD X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2946 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.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: Thu, 16 Jul 2020 13:21:04 -0000 ------=_NextPart_000_049E_01D65B52.67AA0590 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Kent, > From: Kent Watsen, July 15, 2020 7:22 PM >=20 > Hi Eric, >=20 >=20 > (1) For ietf-https-notif.yang why did you choose "uses = x509c2n:cert-to-name" > rather than linking to ietf-truststore.yang's > grouping truststore-grouping > +-- certificate-bags! {certificates}? > +-- certificate-bag* [name] > +-- name? string > +-- certificate* [name] > +-- name? string >=20 > I=E2=80=99m unclear about the issue. Cert-to-name performs a mapping = that doesn't > exist anywhere else... No action is needed on this one, but let me give you my original = thinking. I was trying to understand the relationship between RFC7407 = certificate names=20 (below is an the extract from RFC7405, Appx A.7) 2 11:0A:05:11:00 x509c2n:specified Joe Cool and the certificate name ietf-truststore.yang's certificate name (per = above). It took me a while, but I found the relationship by drilling = down through the client/server drafts to the example of = draft-ietf-netconf-restconf-client-server, Section 3.1.2.1: grouping restconf-server-grouping +-- client-identity-mappings +---u x509c2n:cert-to-name > (2) Do you plan any functionality which inter-related with the = receiver action > 'reset' from SN? Right now this SN action resets the subscription. = Whether > this actually does anything to any underlying connection is undefined = in SN. > So I think what you have is fine as you define no actions on receiver- > instances. But I figured I would ask: is there anything connection = related > which you might expose for the receiver as a whole? >=20 > No SN-relation is planned. I=E2=80=99m unsure exactly what the ask is. = Please advise. SN allows a configured subscription to be reset. Will there be = anything in https-receiver to reset a type of transport connection to a = receiver? Based on the current model, I am assuming no. =20 > (3) I have a question on receiver capability discovery prior to = sending > notifications. Section 2.1 says that a publisher 'can' issue an HTTP = GET for > the capabilities. This also suggests that it can choose not to send = such a > request. What is the required behavior for an HTTPS publisher and = receiver > when the targeted receiver doesn't support the expected capabilities? >=20 > IIRC, the encoding MAY be configured in the SN model. If it is not = *and* the > publisher doesn=E2=80=99t probe the receiver=E2=80=99s capabilities, = and thus blindly sends > whatever it wants, it risks the receiver returning an HTTP 4xx error. = Makes > sense? Let's say that IP addresses change, and there is an unintentionally = targeted receiver which can accept a TLS connection, but cannot/will not = reply with an HTTP error. Are there scenarios where this could be used = as a DOS attack? > (4) Extending the question (3), the = notification from > SN can be used for this functionality. Looking at the example you = have in > pipelining Section 1.5.1, the second POST of a YANG notification = occurs is > shown before the "Send 204 (No Content) is returned" for the first > notification. Could you explicitly add the > notification to section 1.5.1 to disambiguate things? For example: >=20 > ------------- -------------- > | Publisher | | Receiver | > ------------- -------------- >=20 > Establish TCP ------> >=20 > Establish TLS ------> >=20 > Send HTTPS POST message > with > started> notification > Send 200 (OK) > <------ for = >=20 >=20 > Send HTTPS POST message > with YANG defined ------> > notification #1 >=20 > Send HTTPS POST message > with YANG defined ------> > notification #2 > Send 204 (No = Content) > <------ for notification #1 >=20 > Send 204 (No = Content) > <------ for notification #2 >=20 > I think that this is proper. Guidance welcomed. But not that, beyond = HTTP > [N}ACKs, this is a one-way flow of content, so whatever needs to fit = into > those HTTP responses. This works for me. I believe it helpful to show the = in the diagram: SN says that the = needs to be confirmed before other notifications = are pushed. Eric =20 > Kent // as co-author >=20 >=20 >=20 > There were some earlier discussions on these overall interactions in = threads > like: > = https://mailarchive.ietf.org/arch/msg/netconf/oUxidvvW95lmxS1LLqyvuivuRc > A/ >=20 > Thanks, > Eric >=20 ------=_NextPart_000_049E_01D65B52.67AA0590 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNzE2MTMyMDUzWjAjBgkqhkiG 9w0BCQQxFgQU7ksdW8u6iEk6GYgc4xqTwrxedGowSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBaMZM2Yy4LvDVoEpIC/SFxtBOESMCqz1SNZWhDBmGReLju2q7Ent4ASIKb7meCGIwU GW9/1T1BbRNHM4kvhDNYVHYmF7RN/tCflBoYy750X0yjNV6mtF6LbZSpESxkbYaIUlrLZRnhJgTw iqk1vOQ2t9h0ezFcZ1mbziSFPAdGCgO6vIPnu5S3owVFcMaQKacX/9y/Zy7WDL8q+fvduWBuDsTQ GazChp5CzTB2TBilzFebNKhZ4kYDCFApYBm2ZZn7Pr7IP4jvGuWQiQ4730IhHXjQJxCGRyFRZM8V rJvjtGzWZZDp+Hp6lHXR2plXyyjGxbeT2n/NRXU9emAiA1n0AAAAAAAA ------=_NextPart_000_049E_01D65B52.67AA0590-- From nobody Fri Jul 17 03:45:44 2020 Return-Path: <010001735c612e54-5783825b-b9c9-4cc1-8b86-21edf822aaf8-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 B70143A097B for ; Fri, 17 Jul 2020 03:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYUl8MCiGRxX for ; Fri, 17 Jul 2020 03:45:41 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7FF3A097C for ; Fri, 17 Jul 2020 03:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1594982740; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=bpabSUbaZLBFpprHOn+7INbxDd7XLtygc9m2Gk66QFw=; b=fFc7mtWfX03FfA0jwE1j1CVA6+F3e1CA/gATY4/nONhhh1NzzTNkyfplXa6h17TR N2ERmwbft+kKOBfBlj3ZibYJBCwqgJaQaVCz0Y7Ff7Ltop9EDTsadwg1RSPaMxiKVGk gd0bCixu+NJLneVvwGtCHwwCK5YuLY4NevCQfVKo= From: Kent Watsen Message-ID: <010001735c612e54-5783825b-b9c9-4cc1-8b86-21edf822aaf8-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D020FCC2-663C-4353-8A33-9F9FD4CE0D93" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 17 Jul 2020 10:45:39 +0000 In-Reply-To: Cc: Mahesh Jethanandani , "netconf@ietf.org" To: "Eric Voit (evoit)" References: <159440288260.29660.1882956283740039536@ietfa.amsl.com> <0100017354c87c8a-e19d1df5-0113-4b19-b6cd-9394c017b6ff-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.17-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.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: Fri, 17 Jul 2020 10:45:43 -0000 --Apple-Mail=_D020FCC2-663C-4353-8A33-9F9FD4CE0D93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric. Cherry-picking, since the rest resolved. >> (2) Do you plan any functionality which inter-related with the = receiver action >> 'reset' from SN? Right now this SN action resets the subscription. = Whether >> this actually does anything to any underlying connection is undefined = in SN. >> So I think what you have is fine as you define no actions on = receiver- >> instances. But I figured I would ask: is there anything connection = related >> which you might expose for the receiver as a whole? >>=20 >> No SN-relation is planned. I=E2=80=99m unsure exactly what the ask = is. Please advise. >=20 > SN allows a configured subscription to be reset. Will there be = anything in https-receiver to reset a type of transport connection to a = receiver? Based on the current model, I am assuming no.=20 As an SN author and expert, I=E2=80=99m hoping that you can advise us on = the what SHOULD be in the I-D. Happy to accommodate. >> (3) I have a question on receiver capability discovery prior to = sending >> notifications. Section 2.1 says that a publisher 'can' issue an HTTP = GET for >> the capabilities. This also suggests that it can choose not to send = such a >> request. What is the required behavior for an HTTPS publisher and = receiver >> when the targeted receiver doesn't support the expected capabilities? >>=20 >> IIRC, the encoding MAY be configured in the SN model. If it is not = *and* the >> publisher doesn=E2=80=99t probe the receiver=E2=80=99s capabilities, = and thus blindly sends >> whatever it wants, it risks the receiver returning an HTTP 4xx error. = Makes >> sense? >=20 > Let's say that IP addresses change, and there is an unintentionally = targeted receiver which can accept a TLS connection, but cannot/will not = reply with an HTTP error. Are there scenarios where this could be used = as a DOS attack? The receiver can return HTTP 200, which normal operation would require, = but can=E2=80=99t return 4xx? This seems unlikely, given that the = receiver=E2=80=99s TLS cert was configured and thus presumably trusted = (i.e., proofed before deployed). The scenario described seems to be = purely operator error - agreed? Besides, what could this draft define = to defend/detect such a case? >> (4) Extending the question (3), the = notification from >> SN can be used for this functionality. Looking at the example you = have in >> pipelining Section 1.5.1, the second POST of a YANG notification = occurs is >> shown before the "Send 204 (No Content) is returned" for the first >> notification. Could you explicitly add the >> notification to section 1.5.1 to disambiguate things? For example: >>=20 >> ------------- -------------- >> | Publisher | | Receiver | >> ------------- -------------- >>=20 >> Establish TCP ------> >>=20 >> Establish TLS ------> >>=20 >> Send HTTPS POST message >> with >> started> notification >> Send 200 (OK) >> <------ for = >>=20 >>=20 >> Send HTTPS POST message >> with YANG defined ------> >> notification #1 >>=20 >> Send HTTPS POST message >> with YANG defined ------> >> notification #2 >> Send 204 (No = Content) >> <------ for notification #1 >>=20 >> Send 204 (No = Content) >> <------ for notification #2 >>=20 >> I think that this is proper. Guidance welcomed. But not that, = beyond HTTP >> [N}ACKs, this is a one-way flow of content, so whatever needs to fit = into >> those HTTP responses. >=20 > This works for me. I believe it helpful to show the = in the diagram: SN says that the = needs to be confirmed before other notifications = are pushed. Okay. K. --Apple-Mail=_D020FCC2-663C-4353-8A33-9F9FD4CE0D93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric.

Cherry-picking, = since the rest resolved.

(2) Do you plan any functionality = which inter-related with the receiver action
'reset' from = SN?  Right now this SN action resets the subscription. =  Whether
this actually does anything to any = underlying connection is undefined in SN.
So I think what = you have is fine as you define no actions on receiver-
instances.  But I figured I would ask: is there anything = connection related
which you might expose for the receiver = as a whole?

No SN-relation is planned. = I=E2=80=99m unsure exactly what the ask is.  Please advise.

SN allows a configured subscription to be reset. =   Will there be anything in https-receiver to reset a type of = transport connection to a receiver?  Based on the current model, I = am assuming no. 

As an SN author and expert, I=E2=80=99m hoping = that you can advise us on the what SHOULD be in the I-D.  Happy to = accommodate.


(3) I have a question on receiver = capability discovery prior to sending
notifications. =  Section 2.1 says that a publisher 'can' issue an HTTP GET for
the capabilities.  This also suggests that it can choose = not to send such a
request.  What is the required = behavior for an HTTPS publisher and receiver
when the = targeted receiver doesn't support the expected capabilities?

IIRC, the encoding MAY be configured in the SN = model.  If it is not *and* the
publisher doesn=E2=80=99= t probe the receiver=E2=80=99s capabilities, and thus blindly sends
whatever it wants, it risks the receiver returning an HTTP = 4xx error.  Makes
sense?
Let's say that IP addresses = change, and there is an unintentionally targeted receiver which can = accept a TLS connection, but cannot/will not reply with an HTTP error. =  Are there scenarios where this could be used as a DOS = attack?

The = receiver can return HTTP 200, which normal operation would require, but = can=E2=80=99t return 4xx?  This seems unlikely, given that the = receiver=E2=80=99s TLS cert was configured and thus presumably trusted = (i.e., proofed before deployed).  The scenario described seems to = be purely operator error - agreed?   Besides, what could this draft = define to defend/detect such a case?


(4) = Extending the question (3), the  <subscription-started> = notification from
SN can be used for this functionality. =   Looking at the example you have in
pipelining = Section 1.5.1, the second POST of a YANG notification occurs is
shown before the "Send 204 (No Content) is returned" for the = first
notification.   Could you explicitly add = the <subscription-started>
notification to section = 1.5.1 to disambiguate things?  For example:

      ------------- =             &n= bsp;           &nbs= p;     --------------
      | Publisher | =             &n= bsp;           &nbs= p;     | Receiver   |
      ------------- =             &n= bsp;           &nbs= p;     --------------

      Establish TCP =             --= ---->

      Establish TLS =             --= ---->

      Send HTTPS POST = message
      with = <subscription-       ------>
      started> = notification
          &nb= sp;            = ;            &= nbsp;           &nb= sp;  Send 200 (OK)
          &nb= sp;            = ;         <------ =           for = <subscription-started>


      Send HTTPS POST = message
      with YANG = defined         ------>
      notification #1

      Send HTTPS = POST message
      with YANG = defined         ------>
      notification #2
          &nb= sp;            = ;            &= nbsp;           &nb= sp;  Send 204 (No Content)
          &nb= sp;            = ;         <------ =           for = notification #1

          &nb= sp;            = ;            &= nbsp;           &nb= sp;  Send 204 (No Content)
          &nb= sp;            = ;         <------ =           for = notification #2

I think that this is = proper.  Guidance welcomed.  But not that, beyond HTTP
[N}ACKs, this is a one-way flow of content, so whatever needs = to fit into
those HTTP responses.

This works for me.  I believe it helpful to show the = <subscription-started> in the diagram: SN says that the = <subscription-started> needs to be confirmed before other = notifications are pushed.

Okay.

K.


= --Apple-Mail=_D020FCC2-663C-4353-8A33-9F9FD4CE0D93-- From nobody Fri Jul 17 06:40:53 2020 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 E61A73A0932 for ; Fri, 17 Jul 2020 06:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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_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=UrL8FVs8; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=DpN/Vnnf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RGrZVTblE4h for ; Fri, 17 Jul 2020 06:40:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955013A0930 for ; Fri, 17 Jul 2020 06:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24684; q=dns/txt; s=iport; t=1594993248; x=1596202848; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ewYfdPzQm8LJ4scJLLtPsBjZvpOkq42kyTDRSzpl0vk=; b=UrL8FVs8E93NZSwNNERZ4hGqFWiCYNlaZd8vaKY1yMmC+thCR7snmBsg O+rVMUBKMp/ExefvQBfMU2WoRHA8LVgk4kIluYybBED+a3bXHO986mC2y sPutkhzd8uu+zIOyO+AFebvY6y3lcoiJLaCnVgmkC81WILqjLjT3Zuzhp A=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3An5bgGRIBYFrwMqvLF9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKs/k1bVRojdrfRJl7mev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtKEdrlaluUpHCuvnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUCADhqRFf/4YNJK1gHQEBAQEJARI?= =?us-ascii?q?BBQUBggqBIy9RB28rLS8sCoQpg0YDjUaKAolwhGyBQoERA1UEBwEBAQkDAQE?= =?us-ascii?q?tAgQBAYRMAoIZAiQ4EwIDAQELAQEFAQEBAgEGBG2FWwyFbwEBAQQSEQQGEwE?= =?us-ascii?q?BKQcHAQ8CAQgRBAEBDh0CAgIfER0IAgQOBQgGFIMFgX5NAx8PAZ9bAoE5iGF?= =?us-ascii?q?2fzODAQEBBYULDQuCBwcJgTiBU4EXhz2CSxqBQT+BEUOCTT6CGoIKG4MUM4I?= =?us-ascii?q?tjzqCWJJSj1U3TQqCXYQzgliNZoURgniJPZMOnn+RewIEAgQFAg4BAQWBaiO?= =?us-ascii?q?BV3AVgyRQFwINjh6DcYpWdDcCBgEHAQEDCXyNZQGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,362,1589241600"; d="p7s'?scan'208,217";a="782951854" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jul 2020 13:40:47 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 06HDeldZ016721 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jul 2020 13:40:47 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 17 Jul 2020 08:40:46 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 17 Jul 2020 08:40:46 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 17 Jul 2020 08:40:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YsNIi101agRMlJOwxUH1UXEwv5p+SLY03cP8ranqm6AqKLWhNG3dZtMyawdeWnm7/xHBPwDO/RZxtsBBsR1k8jPI6qDkWNL21BuNIggCRPREDf2hCBGAmgu5vPdIXPxhvbocl36kOMeQAf3rnDnxYjWDCbMOHtq+35UoCYSFSwYqIo1v4/TpqLHpK2j818bCK2UdQNUTrcbfajHsDSOmcyhzRYKgZaFXYqVaRDPfrBuDuVAQnL5NZ0WNb3QlOyWMpe4QYB7KzN8butTkRYA9PljlXT72s9eMb5YARf1Tlu+oZgtnJlQJuAsv1ES3IiV7xCiuwj/RRWaj2BdMiB1qnQ== 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=hiqVoEwWm5SzcSRFX0MFn+hvKzbaOUb2eCGKb8jKFvI=; b=bdh0bVRHdB3xheDRG/4Mi+Z/f8Fp9G9V776FeMs+JBYecpoyrUppm2+mINlQyCIAfTIRrt8zAzDFdXIypI8sA1ZEz3c7emyhNwmpwiUw7Dix9VhnpQbs6XvHbi1tbXKGEIE3ep7+lSlOl/TuUYUsE1IEdS/D+/afLL/9uMUmhFUC0Sj+vJrWl5LfBP2AHgtIgWv0mILm+bZlgapiwHA2odFmn3TpEiytjb+rHgGDzVip4r655Y1ZLUfKpnuZaANaJTwu+bBtSVbjleSlnvqqXokuwSIG+Dr250Psl0NZ1Sb/YCotR42PhowNsZ3is1lmqjb0KQqcPRr3mdeiEylWUw== 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=hiqVoEwWm5SzcSRFX0MFn+hvKzbaOUb2eCGKb8jKFvI=; b=DpN/Vnnf26TV77l0G09x0hhUmbmZyCQ1sXi65+SiT/G179ri4SLLQgocc66zBooRLEdV42xyJizyYfPChSkGUVydhMQrh3bKkz2Eg0zSpR8l8BQtmotZAWta9sj8mdNhkIYXqNpyzkURy5l9ws6+5UgWlqBsV3x8bAZcPOY90Uc= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by MN2PR11MB4712.namprd11.prod.outlook.com (2603:10b6:208:264::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.23; Fri, 17 Jul 2020 13:40:44 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2%5]) with mapi id 15.20.3195.022; Fri, 17 Jul 2020 13:40:44 +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-03.txt Thread-Index: AQHWVuGAMhvA4eAgHUC1kvcCfWaYoqkHQQNggAIOkwCAANYigIAAAF/wgAF6+ICAABPw4A== Date: Fri, 17 Jul 2020 13:40:44 +0000 Message-ID: References: <159440288260.29660.1882956283740039536@ietfa.amsl.com> <0100017354c87c8a-e19d1df5-0113-4b19-b6cd-9394c017b6ff-000000@email.amazonses.com> <010001735c612e54-5783825b-b9c9-4cc1-8b86-21edf822aaf8-000000@email.amazonses.com> In-Reply-To: <010001735c612e54-5783825b-b9c9-4cc1-8b86-21edf822aaf8-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cde39ddd-cec5-4e59-887f-08d82a57016c x-ms-traffictypediagnostic: MN2PR11MB4712: 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: nMR/zBjRW4bCG1fVzFDedlepgNxyW8e3rnSFvOhMDxhWZJuwuqWy//cjI/OxXRWzkCsQcpUdJRKCznIXliNnBN3UXPuX/cdM/9cXElEwO5RF5STTuU0K8TKuKTWI65clF6Vg/3/xTs8+Sr5vkAruCuFwAVCXeKJagnukEagbA/C76LOqI+gzT02QFSlPJXLmGByhWjsqHQQeO69+ydTDKECVSzK5stFS09JJouYiBnGuGzYuluyXcNLVK9zILVH0y3grbBza71xU8HqTuEP/1yuNHljDyvPtbAYUAsH+dot9TPkFAnLJgCJWlnAIJ8Fip7Q0l0myPxlutcAVWoIkMg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(39860400002)(366004)(396003)(136003)(55016002)(52536014)(316002)(8936002)(9686003)(33656002)(9326002)(71200400001)(5660300002)(478600001)(2906002)(54906003)(64756008)(4326008)(6506007)(8676002)(66556008)(66446008)(99936003)(66946007)(66476007)(76116006)(66616009)(26005)(83380400001)(186003)(53546011)(7696005)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: tmiIPoegXKUBxfVM2zZ1jliD9avsqPS8aZyulbLXSY5oWsGNntGlASYQMyu18cQvBoEmlhdqAUKhPnrsX/dvJzuT2IiE5FupOMZTHTXdrR52XamGeVEL+QVjtz5mCwOH7z5YQQuaziKLfhfTQgrlPFpGiFj5BfQs7gH0/iUAlAWkbgBU5Y+hzsdAlzX0EDprNfVwkbngDHIL59Oh+42e/ZYAPQRiHySFIHKLLTD+sDieGCDS41aFHvyFl0DW/eOVjdEHRG+nP1T4gGDquJr/4S02oGfGpuNVtBK4cH8T44SwUwAqxjN38250BOLr68YmCleQyVIzBhaQCFeOlC7DmP5U3W2/7GcREOD73xRhYm0lo+E1h7o7pSJcLdwsE4YA5Z4OV7bHEL2KG+QStnzbCXxfo15bBcFQtKC87c0ZDNtPnTfB4uRfbHU+ltYYERgjl7cVhaPi1EBHKhwv2wUD7fzTyBxTGCoGEe+SS+F9sKyIon8bjEFjXcx3JSEcElcZ x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01D5_01D65C1D.E27F2A40" 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: cde39ddd-cec5-4e59-887f-08d82a57016c X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2020 13:40:44.4708 (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: NZCl9/FnmR6GfZ3GGw1cSGoFYAO7G5rPPZIH3wB215WH10x7mhJsGrnagFxUcAPA X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4712 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.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: Fri, 17 Jul 2020 13:40:51 -0000 ------=_NextPart_000_01D5_01D65C1D.E27F2A40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01D6_01D65C1D.E27F2A40" ------=_NextPart_001_01D6_01D65C1D.E27F2A40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kent, =20 From: Kent Watsen =20 Sent: Friday, July 17, 2020 6:46 AM To: Eric Voit (evoit) Cc: Mahesh Jethanandani ; netconf@ietf.org Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-03.txt =20 Hi Eric. =20 Cherry-picking, since the rest resolved. (2) Do you plan any functionality which inter-related with the receiver = action 'reset' from SN? Right now this SN action resets the subscription. = Whether this actually does anything to any underlying connection is undefined in = SN. So I think what you have is fine as you define no actions on receiver- instances. But I figured I would ask: is there anything connection = related which you might expose for the receiver as a whole? No SN-relation is planned. I=E2=80=99m unsure exactly what the ask is. = Please advise. SN allows a configured subscription to be reset. Will there be = anything in https-receiver to reset a type of transport connection to a = receiver? Based on the current model, I am assuming no.=20 =20 As an SN author and expert, I=E2=80=99m hoping that you can advise us on = the what SHOULD be in the I-D. Happy to accommodate. =20 I am fine with receiver-wide subscription resets being undefined = right now. =20 =20 (3) I have a question on receiver capability discovery prior to sending notifications. Section 2.1 says that a publisher 'can' issue an HTTP = GET for the capabilities. This also suggests that it can choose not to send = such a request. What is the required behavior for an HTTPS publisher and = receiver when the targeted receiver doesn't support the expected capabilities? IIRC, the encoding MAY be configured in the SN model. If it is not = *and* the publisher doesn=E2=80=99t probe the receiver=E2=80=99s capabilities, and = thus blindly sends whatever it wants, it risks the receiver returning an HTTP 4xx error. = Makes sense? Let's say that IP addresses change, and there is an unintentionally = targeted receiver which can accept a TLS connection, but cannot/will not = reply with an HTTP error. Are there scenarios where this could be used = as a DOS attack? =20 The receiver can return HTTP 200, which normal operation would require, = but can=E2=80=99t return 4xx? This seems unlikely, given that the = receiver=E2=80=99s TLS cert was configured and thus presumably trusted = (i.e., proofed before deployed). The scenario described seems to be = purely operator error - agreed? Besides, what could this draft define = to defend/detect such a case? =20 Answer combined with the one to (4) below. (4) Extending the question (3), the notification = from SN can be used for this functionality. Looking at the example you have = in pipelining Section 1.5.1, the second POST of a YANG notification occurs = is shown before the "Send 204 (No Content) is returned" for the first notification. Could you explicitly add the notification to section 1.5.1 to disambiguate things? For example: ------------- -------------- | Publisher | | Receiver | ------------- -------------- Establish TCP ------> Establish TLS ------> Send HTTPS POST message with started> notification Send 200 (OK) <------ for = Send HTTPS POST message with YANG defined ------> notification #1 Send HTTPS POST message with YANG defined ------> notification #2 Send 204 (No Content) <------ for notification #1 Send 204 (No Content) <------ for notification #2 I think that this is proper. Guidance welcomed. But not that, beyond = HTTP [N}ACKs, this is a one-way flow of content, so whatever needs to fit = into those HTTP responses. This works for me. I believe it helpful to show the = in the diagram: SN says that the = needs to be confirmed before other notifications = are pushed. =20 Okay. =20 Since you are explicitly acknowledging with an "ok" the = message before doing any notification pipelining, = I am completely good with the answer to (3). In early conversations = with Mahesh, I remember (perhaps incorrectly) that a = might not be sent. With , = we have protections against configured subscriptions being used for DOS = attacks against unwilling receivers which will accept TLS, but for = whatever reason won't/can't send an HTTP 4xx error. =20 Eric =20 K. =20 =20 ------=_NextPart_001_01D6_01D65C1D.E27F2A40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi = Kent,

 

From: Kent = Watsen <kent+ietf@watsen.net>
Sent: Friday, July 17, = 2020 6:46 AM
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-03.txt

 

Hi = Eric.

 

Cherry-picking, since the rest = resolved.



(2) Do you = plan any functionality which inter-related with the receiver = action
'reset' from SN?  Right now this SN action resets the = subscription.  Whether
this actually does anything to any = underlying connection is undefined in SN.
So I think what you have is = fine as you define no actions on receiver-
instances.  But I = figured I would ask: is there anything connection related
which you = might expose for the receiver as a whole?

No SN-relation is = planned. I=E2=80=99m unsure exactly what the ask is.  Please = advise.


SN = allows a configured subscription to be reset.   Will there be = anything in https-receiver to reset a type of transport connection to a = receiver?  Based on the current model, I am assuming = no. 

 

As an SN author and expert, I=E2=80=99m hoping that = you can advise us on the what SHOULD be in the I-D.  Happy to = accommodate.

 

<eric> I am fine = with receiver-wide subscription resets being undefined right now.=C2=A0 =

 



(3) I have = a question on receiver capability discovery prior to = sending
notifications.  Section 2.1 says that a publisher 'can' = issue an HTTP GET for
the capabilities.  This also suggests that = it can choose not to send such a
request.  What is the required = behavior for an HTTPS publisher and receiver
when the targeted = receiver doesn't support the expected capabilities?

IIRC, the = encoding MAY be configured in the SN model.  If it is not *and* = the
publisher doesn=E2=80=99t probe the receiver=E2=80=99s = capabilities, and thus blindly sends
whatever it wants, it risks the = receiver returning an HTTP 4xx error. =  Makes
sense?


Let's = say that IP addresses change, and there is an unintentionally targeted = receiver which can accept a TLS connection, but cannot/will not reply = with an HTTP error.  Are there scenarios where this could be used = as a DOS attack?

 

The receiver can return HTTP 200, which normal = operation would require, but can=E2=80=99t return 4xx?  This seems = unlikely, given that the receiver=E2=80=99s TLS cert was configured and = thus presumably trusted (i.e., proofed before deployed).  The = scenario described seems to be purely operator error - agreed?   = Besides, what could this draft define to defend/detect such a = case?

 

<eric> Answer = combined with the one to (4) = below.

(4) = Extending the question (3), the  <subscription-started> = notification from
SN can be used for this functionality. =   Looking at the example you have in
pipelining Section = 1.5.1, the second POST of a YANG notification occurs is
shown before = the "Send 204 (No Content) is returned" for the = first
notification.   Could you explicitly add the = <subscription-started>
notification to section 1.5.1 to = disambiguate things?  For = example:

      ------------- =             &= nbsp;           &n= bsp;     --------------
   &nb= sp;  | Publisher | =             &= nbsp;           &n= bsp;     | Receiver =   |
      ------------- =             &= nbsp;           &n= bsp;     --------------

   = ;   Establish TCP =             -= ----->

      Establish TLS =             -= ----->

      Send HTTPS = POST message
      with = <subscription- =       ------>
    = ;  started> = notification
         &nb= sp;           &nbs= p;            = ;            =     Send 200 = (OK)
           = ;            =          <------ =           for = <subscription-started>



    &n= bsp; Send HTTPS POST = message
      with YANG defined =         ------>
  = ;    notification = #1

      Send HTTPS POST = message
      with YANG defined =         ------>
  = ;    notification = #2
           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  Send 204 (No = Content)
          &= nbsp;           &n= bsp;         <------ =           for = notification = #1

          &nb= sp;           &nbs= p;            = ;            =    Send 204 (No = Content)
          &= nbsp;           &n= bsp;         <------ =           for = notification #2

I think that this is proper.  Guidance = welcomed.  But not that, beyond HTTP
[N}ACKs, this is a one-way = flow of content, so whatever needs to fit into
those HTTP = responses.


This = works for me.  I believe it helpful to show the = <subscription-started> in the diagram: SN says that the = <subscription-started> needs to be confirmed before other = notifications are = pushed.

 

Okay.

 

<eric> Since you = are explicitly acknowledging with an "ok" the = <subscription-started> message before doing any notification = pipelining, I am completely good with the answer to (3).=C2=A0 =C2=A0In = early conversations with Mahesh, I remember (perhaps incorrectly) that a = <subscription-started> might not be sent.=C2=A0 With = <subscription-started>, we have protections against configured = subscriptions being used for DOS attacks against unwilling receivers = which will accept TLS, but for whatever reason won't/can't send an HTTP = 4xx error.

 

Eric

 

K.

 

 

------=_NextPart_001_01D6_01D65C1D.E27F2A40-- ------=_NextPart_000_01D5_01D65C1D.E27F2A40 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNzE3MTMzNzI3WjAjBgkqhkiG 9w0BCQQxFgQUnhWuWJWs1DUtoRDiLftGrZRsMDwwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAsU7BruFxHscFnJBLdJOHUZ/SNFtKGaXZlSDCeusl176UJuiHALOr+K9BgD8ba5Pzj VKkIAbgkD4ILC5BP/gjgALcdCSg51Oscqfq0v4JC3+tuotXzGpFwRKCiw2ehvHEjuNNefEx7EKiE FQXjUepYnmEC5SNgs5/BwR8AtrIrjqDaOMX3+CTdTigPHIZco1QyN7YhIxX2ZAA+eHJJ+mDjnGEV 6Of1rjbYXr0iM/MLrNwnfRtuEOhazjF1TPYtdm5kIQ9Hxzgn3TfO3Xxq7l8XwLmuspL61UKmOVwZ atlDeLvGintM03IvdNDNvylbwiww8sgcOOXQTltdFepOA9yMAAAAAAAA ------=_NextPart_000_01D5_01D65C1D.E27F2A40-- From nobody Mon Jul 20 16:03:53 2020 Return-Path: <010001736e780da4-a25b3b98-77e8-42a0-b079-531972699bc5-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 2AB793A10B8; Mon, 20 Jul 2020 16:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwXWWjNSMONb; Mon, 20 Jul 2020 16:03:50 -0700 (PDT) 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 2B0C33A10B5; Mon, 20 Jul 2020 16:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1595286229; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=vXfy+kPESulaDvaaahl5WyjWSeu23XmLOzRgKpvr3mE=; b=HxNfw3wq1+uZ2QfNyE6TAVS/K9EiZHb87RFQ2gEWCMJkkjJ0/7HV2MVQPe0ARuqU xIsSBq9JyCJ/XICylxFIcKyWDJDIrR5lN0i3yaBsblK3fQC5TXpm/JMys3ootPg/AY4 QuPU5N5+1Kpms3nmAIx0k7STDspxg3I6+xRbqCeM= From: Kent Watsen Message-ID: <010001736e780da4-a25b3b98-77e8-42a0-b079-531972699bc5-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A493C090-8DFC-4783-8586-6A2986792434" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 20 Jul 2020 23:03:48 +0000 In-Reply-To: <0100017301362bb5-2b075a19-364f-40fa-9ad8-35d161a932fc-000000@email.amazonses.com> Cc: "netconf-chairs@ietf.org" To: "netconf@ietf.org" References: <159321547899.12018.9636080960886369588@ietfa.amsl.com> <0100017301362bb5-2b075a19-364f-40fa-9ad8-35d161a932fc-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.20-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Call for presentations (was: IETF 108 Preliminary Agenda) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 23:03:52 -0000 --Apple-Mail=_A493C090-8DFC-4783-8586-6A2986792434 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 IETF 108 Presenters, Please send a first draft of your presentations by this coming Friday, = and plan to send the final version by Monday. Thanks you, Kent and Mahesh > On Jun 29, 2020, at 1:53 PM, Kent Watsen wrote: >=20 > NETCONF WG, >=20 > According to the preliminary agenda (see below), NETCONF is scheduled = to meet for 100-minutes on Thursday, July 30th from 14:10-15:50 UTC. >=20 > If you are interested in presenting to the WG, please send your = presentation requests to the "netconf-chairs" alias (CC-ed) with the = following information, for each presentation request, if more than one: >=20 > - name of the drafts (if any) > - name of presentation (usually the title of the draft) > - name of the presenter(s) > - desired time request (in minutes) >=20 >=20 > Authors, per the 108 Important Dates page = , the draft = submission cutoff is in two weeks, on Monday July 13th. Please be sure = to update your drafts before then. >=20 > NETCONF Chairs >=20 >=20 >> Begin forwarded message: >>=20 >> From: IETF Agenda > >> Subject: IETF 108 Preliminary Agenda >> Date: June 26, 2020 at 7:51:19 PM EDT >> To: "IETF Announcement List" > >> Cc: 108all@ietf.org , ietf@ietf.org = >> Reply-To: agenda@ietf.org >>=20 >> The IETF 108 Preliminary Agenda has been posted. The final agenda = will be published on Thursday, July 3, 2020. >>=20 >> https://datatracker.ietf.org/meeting/108/agenda.html = >> https://datatracker.ietf.org/meeting/108/agenda.txt >>=20 >> The preliminary agenda includes all planned WG, RG, and ANRW = sessions. We are still finalizing details for a few of our usual = meeting-adjacent events, so please look out for further details about = those. Information about side meeting signups will be available when the = final agenda is posted. >>=20 >> IETF 108 Information: https://www.ietf.org/how/meetings/108/ >> Register online at: https://registration.ietf.org/108/ >>=20 >> Don=E2=80=99t forget to register for these exciting IETF 108 events! >>=20 >>=20 >> Hackathon=20 >> Signup: https://registration.ietf.org/108/new/hackathon/ >> More information: = https://www.ietf.org/how/runningcode/hackathons/108-hackathon/ >> Keep up to date by subscribing to:=20 >> https://www.ietf.org/mailman/listinfo/hackathon >>=20 >>=20 >> Code Sprint >> More details coming soon! >>=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_A493C090-8DFC-4783-8586-6A2986792434 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 IETF = 108 Presenters,

Please= send a first draft of your presentations by this coming Friday, and = plan to send the final version by Monday.

Thanks you,
Kent = and Mahesh



On Jun 29, 2020, at 1:53 PM, Kent Watsen = <kent+ietf@watsen.net> wrote:

NETCONF = WG,

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

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

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


Authors, = per the 108 Important Dates page, the draft submission cutoff is in two = weeks, on Monday July 13th.  Please be sure to update your drafts before = then.

NETCONF Chairs


Begin = forwarded message:

From: IETF Agenda <agenda@ietf.org>
Subject: IETF 108 Preliminary Agenda
Date: June 26, 2020 at 7:51:19 PM EDT
To: "IETF Announcement List" <ietf-announce@ietf.org>
Cc: 108all@ietf.org, ietf@ietf.org
Reply-To: = agenda@ietf.org

The= IETF 108 Preliminary Agenda has been posted. The final agenda will be = published on Thursday, July 3, 2020.

https://datatracker.ietf.org/meeting/108/agenda.html
https://datatracker.ietf.org/meeting/108/agenda.txt

The preliminary agenda includes all planned = WG, RG, and ANRW sessions. We are still finalizing details for a few of = our usual meeting-adjacent events, so please look out for further = details about those. Information about side meeting signups will be = available when the final agenda is posted.

IETF 108 Information: = https://www.ietf.org/how/meetings/108/
Register online at: = https://registration.ietf.org/108/

Don=E2=80=99= t forget to register for these exciting IETF 108 events!

Hackathon
Signup: = https://registration.ietf.org/108/new/hackathon/
More = information: = https://www.ietf.org/how/runningcode/hackathons/108-hackathon/
= Keep up to date by subscribing to:
= https://www.ietf.org/mailman/listinfo/hackathon


Code Sprint
More = details coming soon!


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

= --Apple-Mail=_A493C090-8DFC-4783-8586-6A2986792434-- From nobody Mon Jul 20 16:11:14 2020 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 EF9E73A08FF for ; Mon, 20 Jul 2020 16:11:11 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Ozt9nZodLdar for ; Mon, 20 Jul 2020 16:11:10 -0700 (PDT) Received: from sjmda13.webex.com (sjmda13.webex.com [64.68.124.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA723A08FE for ; Mon, 20 Jul 2020 16:11:10 -0700 (PDT) Received: from rva2rmd102.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda13.webex.com (Postfix) with ESMTP id 5BA113020229 for ; Mon, 20 Jul 2020 23:11:10 +0000 (GMT) Received: from rva2rmd102.webex.com (localhost [127.0.0.1]) by rva2rmd102.webex.com (Postfix) with ESMTP id ED9D81028530 for ; Mon, 20 Jul 2020 23:11:09 +0000 (GMT) Date: Mon, 20 Jul 2020 23:11:09 +0000 (GMT) From: NETCONF Working Group Reply-To: netconf-chairs@ietf.org To: netconf@ietf.org Message-ID: <520169882.483591595286669970.JavaMail.nobody@rva2rmd102.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_96716_1112843144.1595286669970" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=166689491560443829, X-WBX-TID=4ttuw583s3jgjexupb88zpdw7u0er9a4oqkhsmb9pnpbjoo0qa5pbfhv, X-WBX-RID=d4b0f1fa8e124f9db90e4dc3e5e51900, X-WBX-SVC:Web Components, X-WBX-TT:Meeting Cancelled, Date:Mon Jul 20 23:11:09 GMT 2020 reminder-40.7.3-3197 Archived-At: Subject: [netconf] Canceled Webex meeting: NETCONF 108 Virtual Meeting 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, 20 Jul 2020 23:11:12 -0000 ------=_Part_96716_1112843144.1595286669970 Content-Type: multipart/Alternative; boundary="----=_Part_96717_2049290710.1595286669970" ------=_Part_96717_2049290710.1595286669970 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCBuZXRjb25mQGlldGYub3JnLAoKTkVUQ09ORiBXb3JraW5nIEdyb3VwIGNhbmNlbGVkIHRo aXMgV2ViZXggbWVldGluZy4KCgpORVRDT05GIDEwOCBWaXJ0dWFsIE1lZXRpbmcKVHVlc2RheSwg SnVseSAyOCwgMjAyMAoxMTowMCBhbSAgfCAgKFVUQyswMDowMCkgTW9ucm92aWEsIFJleWtqYXZp ayAgfCAgMSBociA0MCBtaW5zCgoKVG8gcmVtb3ZlIHRoZSBtZWV0aW5nIGZyb20geW91ciBjYWxl bmRhciwgb3BlbiB0aGUgYXR0YWNoZWQgLmljcyBmaWxlLiBJZiB0aGUgYXR0YWNobWVudCBpcwog bWlzc2luZywgZG93bmxvYWQgdGhlIC5pY3MgZmlsZSBoZXJlOgpodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvai5waHA/TVRJRD1tNTVkNTJhZGVmNmIyNDA4ZDc4NzgxMjRlMmY0Nzg4OWINCg0K CgoK ------=_Part_96717_2049290710.1595286669970 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9VVRGLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSI+PGJvZHk+PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KKiB7CiAg ICBwYWRkaW5nOiAwOyAgICBtYXJnaW46IDA7fQp0YWJsZSB7Cglib3JkZXItY29sbGFwc2U6IHNl cGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwlib3JkZXItc3BhY2luZzogMDt9Cgp0ciB7 CglsaW5lLWhlaWdodDogMThweDt9CgphLCB0ZCB7Cglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFt aWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdvcmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVh azogbm9ybWFsOwlwYWRkaW5nOiAwO30KCi50aXRsZSB7Cglmb250LXNpemU6IDI4cHg7fQoKLmlt YWdlIHsKCXdpZHRoOiBhdXRvOwltYXgtd2lkdGg6IGF1dG87fQoKLmZvb3RlciB7Cgl3aWR0aDog NjA0cHg7fQoKLm1haW4gewoKfUBtZWRpYSBzY3JlZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4 MDBweCkgewoJLnRpdGxlIHsKCQlmb250LXNpemU6IDIycHggIWltcG9ydGFudDsJfQoJLmltYWdl IHsKCQl3aWR0aDogYXV0byAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7 CX0KCS5mb290ZXIgewoJCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4 ICFpbXBvcnRhbnQKCX0KCS5tYWluIHsKCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdp ZHRoOiA2MDRweCAhaW1wb3J0YW50Cgl9Cn0KPC9zdHlsZT4KCjx0YWJsZSBiZ2NvbG9yPSIjRkZG RkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAl OyIgYWxpZ249ImxlZnQiPgoJPHRyIHN0eWxlPSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3Rk PjwvdHI+Cgk8dHI+CgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBt YXJnaW46IDAiPgoJCQk8IS0tPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6 IDBweDsgd2lkdGg6IDEwMCU7IHBhZGRpbmctbGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBw eDsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+CgkJCQk8dHI+CgkJCQkJPHRkIGFsaWduPSJj ZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPgoJCQkJPC90cj4KCQkJPC90YWJs ZT4tLT4KCgo8dGFibGU+CiAgICAgICA8dHI+CiAgICAgICAgICAgPHRkPgogICAgICAgICAgIAkJ PHA+CiAgICAgICAgICAgCQkJPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZTogMTZweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6IzAwMDAwMDtmb250LXdlaWdodDogYm9sZDtsaW5lLWhlaWdodDogMjJw eDsiPgogICAgICAgICAgICAgICAgCQlORVRDT05GIFdvcmtpbmcgR3JvdXAgY2FuY2VsZWQgdGhp cyBXZWJleCBtZWV0aW5nLgogICAgICAgICAgICAgICAJCTwvZm9udD4KICAgICAgICAgICA8L3Rk PgogICAgICA8L3RyPgo8L3RhYmxlPgoJCSA8IS0tPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWln aHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJs ZT4KCi0tPgoJCQkgIDx0YWJsZT4KCQkJICAJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsi Pjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj4KICAgICAgICAgICAgICAg IDx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CiAgICAgICAgICAgICAgICAgICA8dGQgc3R5bGU9Imhl aWdodDogMjRweDsgIGNvbG9yOiAjMDAwMDAwOwlmb250LWZhbWlseTogQXJpYWw7CWZvbnQtc2l6 ZTogMTZweDsJbGluZS1oZWlnaHQ6IDI0cHg7Ij5UdWVzZGF5LCBKdWx5IDI4LCAyMDIwCiAgICAg ICAgICAgICAgICAgICA8L3RkPgogICAgICAgICAgICAgICAgPC90cj4KICAgICAgICAgICAgICAg IDx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CiAgICAgICAgICAgICAgICAgICA8dGQgc3R5bGU9Imhl aWdodDogMjRweDsgIGNvbG9yOiAjMDAwMDAwOwlmb250LWZhbWlseTogQXJpYWw7CWZvbnQtc2l6 ZTogMTZweDsJbGluZS1oZWlnaHQ6IDI0cHg7Ij4xMTowMCBhbSZuYnNwOyZuYnNwO3wmbmJzcDsm bmJzcDsoVVRDKzAwOjAwKSBNb25yb3ZpYSwgUmV5a2phdmlrJm5ic3A7Jm5ic3A7fCZuYnNwOyZu YnNwOzEgaHIgNDAgbWlucwogICAgICAgICAgICAgICAgICAgPC90ZD4KICAgICAgICAgICAgICAg IDwvdHI+CiAgICAgICAgICAgICA8L3RhYmxlPgoKCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDogMTAw JTsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+CiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9 ImhlaWdodDogNzJweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj4KCQkJCTx0cj4KCQkJCQk8dGQgc3R5 bGU9ImhlaWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFyaWFsOyBmb250 LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0byA8YSBocmVm PSJodHRwOi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0ZXh0LWRlY29y YXRpb246bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT4KCQkJCQk8L3RkPgoJCQkJPC90 cj4KICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90 ZD48L3RyPgoJCQk8L3RhYmxlPgoJCTwvdGQ+Cgk8L3RyPgo8L3RhYmxlPgo8L2JvZHk+ ------=_Part_96717_2049290710.1595286669970 Content-Type: text/calendar;method=CANCEL;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6Q0FOQ0VMDQpCRUdJTjpWVElN RVpPTkUNClRaSUQ6QXRsYW50aWMvUmV5a2phdmlrDQpUWlVSTDpodHRwOi8vdHp1cmwub3JnL3pv bmVpbmZvLW91dGxvb2svQXRsYW50aWMvUmV5a2phdmlrDQpYLUxJQy1MT0NBVElPTjpBdGxhbnRp Yy9SZXlramF2aWsNCkJFR0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZST006KzAwMDANClRaT0ZGU0VU VE86KzAwMDANClRaTkFNRTpHTVQNCkRUU1RBUlQ6MTk3MDAxMDFUMDAwMDAwDQpFTkQ6U1RBTkRB UkQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KRFRTVEFNUDoyMDIwMDcyMFQyMzExMDla DQpBVFRFTkRFRTtDTj0ibmV0Y29uZkBpZXRmLm9yZyI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNW UD1UUlVFOk1BSUxUTzpuZXRjb25mQGlldGYub3JnDQpPUkdBTklaRVI7Q049Ik5FVENPTkYgV29y a2luZyBHcm91cCI6TUFJTFRPOm5ldGNvbmYtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9 QXRsYW50aWMvUmV5a2phdmlrOjIwMjAwNzI4VDExMDAwMA0KRFRFTkQ7VFpJRD1BdGxhbnRpYy9S ZXlramF2aWs6MjAyMDA3MjhUMTI0MDAwDQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29t L2lldGYNClRSQU5TUDpPUEFRVUUNClNFUVVFTkNFOjE1OTUyODY2NjkNClVJRDpiMWNlOTI0Ni1j MmM3LTRjZjQtOGE3OS1kY2ZlYmEwYWUyNDUNCkRFU0NSSVBUSU9OOlxuXG5UaGlzIFdlYmV4IG1l ZXRpbmcgaGFzIGJlZW4gY2FuY2VsZWQuXG5cblRvcGljOiBORVRDT05GIDEwOCBWaXJ0dWFsIE1l ZXRpbmdcbkRhdGU6IFR1ZXNkYXksIEp1bHkgMjgsIDIwMjBcblRpbWU6IDExOjAwIGFtLCAoVVRD KzAwOjAwKSBNb25yb3ZpYSwgUmV5a2phdmlrXG4NClNVTU1BUlk6TkVUQ09ORiAxMDggVmlydHVh bCBNZWV0aW5nDQpQUklPUklUWTo1DQpDTEFTUzpQVUJMSUMNClNUQVRVUzpDQU5DRUxMRUQNCkVO RDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== ------=_Part_96717_2049290710.1595286669970-- ------=_Part_96716_1112843144.1595286669970 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6Q0FOQ0VMDQpCRUdJTjpWVElN RVpPTkUNClRaSUQ6QXRsYW50aWMvUmV5a2phdmlrDQpUWlVSTDpodHRwOi8vdHp1cmwub3JnL3pv bmVpbmZvLW91dGxvb2svQXRsYW50aWMvUmV5a2phdmlrDQpYLUxJQy1MT0NBVElPTjpBdGxhbnRp Yy9SZXlramF2aWsNCkJFR0lOOlNUQU5EQVJEDQpUWk9GRlNFVEZST006KzAwMDANClRaT0ZGU0VU VE86KzAwMDANClRaTkFNRTpHTVQNCkRUU1RBUlQ6MTk3MDAxMDFUMDAwMDAwDQpFTkQ6U1RBTkRB UkQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KRFRTVEFNUDoyMDIwMDcyMFQyMzExMDla DQpBVFRFTkRFRTtDTj0ibmV0Y29uZkBpZXRmLm9yZyI7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UlNW UD1UUlVFOk1BSUxUTzpuZXRjb25mQGlldGYub3JnDQpPUkdBTklaRVI7Q049Ik5FVENPTkYgV29y a2luZyBHcm91cCI6TUFJTFRPOm5ldGNvbmYtY2hhaXJzQGlldGYub3JnDQpEVFNUQVJUO1RaSUQ9 QXRsYW50aWMvUmV5a2phdmlrOjIwMjAwNzI4VDExMDAwMA0KRFRFTkQ7VFpJRD1BdGxhbnRpYy9S ZXlramF2aWs6MjAyMDA3MjhUMTI0MDAwDQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29t L2lldGYNClRSQU5TUDpPUEFRVUUNClNFUVVFTkNFOjE1OTUyODY2NjkNClVJRDpiMWNlOTI0Ni1j MmM3LTRjZjQtOGE3OS1kY2ZlYmEwYWUyNDUNCkRFU0NSSVBUSU9OOlxuXG5UaGlzIFdlYmV4IG1l ZXRpbmcgaGFzIGJlZW4gY2FuY2VsZWQuXG5cblRvcGljOiBORVRDT05GIDEwOCBWaXJ0dWFsIE1l ZXRpbmdcbkRhdGU6IFR1ZXNkYXksIEp1bHkgMjgsIDIwMjBcblRpbWU6IDExOjAwIGFtLCAoVVRD KzAwOjAwKSBNb25yb3ZpYSwgUmV5a2phdmlrXG4NClNVTU1BUlk6TkVUQ09ORiAxMDggVmlydHVh bCBNZWV0aW5nDQpQUklPUklUWTo1DQpDTEFTUzpQVUJMSUMNClNUQVRVUzpDQU5DRUxMRUQNCkVO RDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== ------=_Part_96716_1112843144.1595286669970-- From nobody Mon Jul 20 16:13:16 2020 Return-Path: <010001736e80a2da-a5f17d01-280f-445b-affb-d8630f9c73f4-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 3CDFD3A0917; Mon, 20 Jul 2020 16:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 TGh9AtBZpoZp; Mon, 20 Jul 2020 16:13:12 -0700 (PDT) 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 919953A0914; Mon, 20 Jul 2020 16:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1595286791; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=ckryVfq/7DoPl9EvevgIrZUZUgUcj0zBrno8rz14C1Y=; b=Uo9QUPZkQ4rR0h4s9EurvYUnCTy/a2NvgEEWvxQhoDZ+20jxgzOpMPMbdZ3hqTaC DAjf6XIZiDYiGff5oatlSxhJTRs30LO8zBV8AhBB4lWe7JdnrsP2kOC0Ckua0WOHDGY grveJG/Isz9j7rwuoZn6VWqNUxHFjnF5PMzwL12g= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <010001734a4dbbe7-637ac888-1065-460e-a3a1-3c33a8c66bc7-000000@email.amazonses.com> Date: Mon, 20 Jul 2020 23:13:11 +0000 Cc: "netconf-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001736e80a2da-a5f17d01-280f-445b-affb-d8630f9c73f4-000000@email.amazonses.com> References: <010001734a4dbbe7-637ac888-1065-460e-a3a1-3c33a8c66bc7-000000@email.amazonses.com> To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.20-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Preliminary Agenda 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, 20 Jul 2020 23:13:14 -0000 The agenda has been updated (see below). Please be advised that the NETCONF Chairs plan to use MeetEcho. The = WebEx links that appeared in the earlier version of the agenda have been = removed. Kent and Mahesh Agenda for the NETCONF 108 WG Session ------------------------------------- https://datatracker.ietf.org/meeting/108/materials/agenda-108-netconf Session: Tuesday July 28th UTC: 11:00-12:40 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/108/session/28155.ics MeetEcho: = https://meetings.conf.meetecho.com/ietf108/?group=3Dnetconf Jabber: xmpp:netconf@jabber.ietf.org?join Available During and After Session: Etherpad: https://etherpad.ietf.org/p/notes-ietf-108-netconf Slides (TGZ): = https://datatracker.ietf.org/meeting/108/agenda/netconf-drafts.tgz Slides (PDF): = https://datatracker.ietf.org/meeting/108/agenda/netconf-drafts.pdf Available After Session: Recording: = https://ietf108.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: Status and Issues on Client-Server Suite of Drafts (10 min) https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-17 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-12 https://tools.ietf.org/html/draft-ietf-netconf-keystore-19 https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-07 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-21 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-21 https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-04 = https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-20 = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-20 Presenter: Kent Watsen An HTTPS-based Transport for Configured Subscriptions (10 min) https://tools.ietf.org/html/draft-ietf-netconf-https-notif-03 Presenter: Mahesh Jethanandani Non-Chartered items: UDP-based Transport for Configured Subscriptions (10 min) https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-00 Presenter: Pierre Francois =20 Subscription to Distributed Notifications (10 min) = https://datatracker.ietf.org/doc/draft-unyte-netconf-distributed-notif-00 Presenter: Thomas Graf Self-explanation Data Node Tag & Telemetry Data Export Capabilities = (15 min) = https://datatracker.ietf.org/doc/draft-tao-netconf-notif-node-tag-capabili= ties-02 = https://datatracker.ietf.org/doc/draft-tao-netconf-data-export-capabilitie= s-01 Presenter: Qin Wu / Liu Peng Adaptive Subscription to YANG & Bulk Subscription to YANG Event = Notifications (15 min) = https://datatracker.ietf.org/doc/draft-wang-netconf-adaptive-subscription-= 02 = https://datatracker.ietf.org/doc/draft-wang-netconf-bulk-subscribed-notifi= cations-02 Presenter: Qin Wu / Liu Peng =20 Conveying a CSR in a SZTP Bootstrapping Request (10 min) https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr-01 Presenter: Kent Watsen Remaining 10 min. From nobody Mon Jul 20 16:19:52 2020 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 C7B6C3A0998 for ; Mon, 20 Jul 2020 16:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=NxUDJgJN; dkim=pass (2048-bit key) header.d=gmail.com header.b=fEa5lunU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-d09pDjC4X4 for ; Mon, 20 Jul 2020 16:19:48 -0700 (PDT) Received: from mail-ot1-x34a.google.com (mail-ot1-x34a.google.com [IPv6:2607:f8b0:4864:20::34a]) (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 CF3C63A092F for ; Mon, 20 Jul 2020 16:19:48 -0700 (PDT) Received: by mail-ot1-x34a.google.com with SMTP id x12so8990183oto.19 for ; Mon, 20 Jul 2020 16:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:reply-to:sender:message-id:date:subject:from:to; bh=NcG0oglpobCzLcOXNxNTfsSvbmhpTDAcJho2SRp0G5U=; b=NxUDJgJNSO5HK6SQfU0Xu4Mut431XjcdVZu0l0HwhvqeK3wt7Xfx2uSLq+FjFuEy9k Fl+7lXsBMxHkrQfihmgqAq25LNxD1QVcyn4AAxP+vk/GlH43uCj0+jrUeX8wybbM9SXu WD69x5V8jlcCpBxMN/PgBQP4KHxgY+4kQCxLKyx/jRv35Qky7bXmZ8R6k7pV6+5eJSXv QtbilNS8bbT9tsXYKg0oVtsT+Rbu/RZZU04xgSO8ZVMcbl50lodOvsTVXVQYQyDyZjZl fxWFW++cE4Bb1b/+k8TCWnq8F0XjK2o3azrW1Xg3+zmk9xACsC+jhAp2fFo/SH5qpt/B XweA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:sender:message-id:date:subject:from:to; bh=NcG0oglpobCzLcOXNxNTfsSvbmhpTDAcJho2SRp0G5U=; b=fEa5lunU0GyZtaFIbL2YKffEFtmOoX63OE8t98OrBXhqzPQ1cGHWx4ZtPi8FNgX59p 3mk/EDfF2igD34r7uWR5foKf+lxZbpGePXqk48KFLWgDy1vtqnBQlKaEE/L8Rsq7AicI o3MKtKcIIVUs1MB4riodbj0hdL2pQEyfV8Y8wIEEa6hsLMsP0N+H9z4u4PXABkjcjEF3 qc4OufZgK9FVfWtCPBk5HqOrifTsPpmqWPaLa8vNgjy0Qza+N9ottZufrGv17+/Kbpe5 2Yqshrz0FwSMMwtcr8d5VwkBpiUxVq3lohmorchz4REp1ufo1vBkTyORUBSETwhoTyZb TaxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:sender:message-id:date :subject:from:to; bh=NcG0oglpobCzLcOXNxNTfsSvbmhpTDAcJho2SRp0G5U=; b=hp9G2tSFixacTBpvOZdQjpjAM2sUhjfPJ6Q7SzyLm4/qZEmyBd4O0h4oXwkYnxjagz y0TnuBS6122Knh1+8v94V8z5rmrYqBjh3gM6glxm+7ocKfRRR0l1acyz6FEkGnWTR8aS ug9pO96hqss1AP2VNRBnC5MKNiluCB5SDpBar5nthUH+bdq0GheREuScjQyW3m9ZjP3q G5V/u4/dP9IqY1nyB1A+K4VrIPVHuoO31Au6DWEWPMNq3+uuEneL6B7ZHuA/1h/l/WBM qbevqF6i+53/+JEtim8NrmHSabhBLblQE9pTZFGnqjR9rdff+vbLqmgLPDKAqbz3YUwe H/Fg== X-Gm-Message-State: AOAM530jnczGfGxVooywIdXc3KUD9AYGEIeXAiGLS9/x2SxgQ1ixt/tc Z4k99VrZq548VXLFzqCi2empcoTMD/bYtokRRnx7 X-Google-Smtp-Source: ABdhPJyEJ+m3yFD8INYT86JdbE0JZbxDvBx2uIklWGrCFKc+CqX9iQb4eEBjEHm1bKXOMQl3+s3qYjP6/4RIhPLNAwkg MIME-Version: 1.0 X-Received: by 2002:a05:6830:1ad5:: with SMTP id r21mr20959572otc.181.1595287187927; Mon, 20 Jul 2020 16:19:47 -0700 (PDT) Reply-To: mjethanandani@gmail.com Sender: Google Calendar Message-ID: <00000000000026b86805aae7bef5@google.com> Date: Mon, 20 Jul 2020 23:19:47 +0000 From: mjethanandani@gmail.com To: netconf@ietf.org Content-Type: multipart/mixed; boundary="00000000000026b85505aae7bef4" Archived-At: Subject: [netconf] Invitation: IETF 108 NETCONF Virtual Meeting @ Tue Jul 28, 2020 4am - 5:40am (PDT) (netconf@ietf.org) 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, 20 Jul 2020 23:19:51 -0000 --00000000000026b85505aae7bef4 Content-Type: multipart/alternative; boundary="00000000000026b85305aae7bef2" --00000000000026b85305aae7bef2 Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Content-Transfer-Encoding: base64 WW91IGhhdmUgYmVlbiBpbnZpdGVkIHRvIHRoZSBmb2xsb3dpbmcgZXZlbnQuDQoNClRpdGxlOiBJ RVRGIDEwOCBORVRDT05GIFZpcnR1YWwgTWVldGluZw0KTm90ZSwgd2UgYXJlIG5vIGxvbmdlciB1 c2luZyBXZWJFeCBmb3IgdGhpcyBtZWV0aW5nLiBQbGVhc2UgdXNlIHRoZSAgDQpNZWV0ZWNobyBs aW5rIHRvIGpvaW4gdGhlIG1lZXRpbmcuDQoNCmh0dHBzOi8vbWVldGluZ3MuY29uZi5tZWV0ZWNo by5jb20vaWV0ZjEwOC8/Z3JvdXA9bmV0Y29uZg0KDQpXaGVuOiBUdWUgSnVsIDI4LCAyMDIwIDRh bSDigJMgNTo0MGFtIFBhY2lmaWMgVGltZSAtIExvcyBBbmdlbGVzDQpXaGVyZTogaHR0cHM6Ly9t ZWV0aW5ncy5jb25mLm1lZXRlY2hvLmNvbS9pZXRmMTA4Lz9ncm91cD1uZXRjb25mDQpDYWxlbmRh cjogbmV0Y29uZkBpZXRmLm9yZw0KV2hvOg0KICAgICAqIG1qZXRoYW5hbmRhbmlAZ21haWwuY29t IC0gb3JnYW5pemVyDQogICAgICogbmV0Y29uZkBpZXRmLm9yZw0KDQpFdmVudCBkZXRhaWxzOiAg DQpodHRwczovL3d3dy5nb29nbGUuY29tL2NhbGVuZGFyL2V2ZW50P2FjdGlvbj1WSUVXJmVpZD1Y elk1TWpOalkzRXpObTl2TTJsaU9XbzRZM0pxWTJJNWF6ZzFNbXBuWWpsd05uTnhhMkZpWVRJMloy OHphV2M1YkRjMGNXbzRZekZ3Tm1jZ2JtVjBZMjl1WmtCcFpYUm1MbTl5WncmdG9rPU1qTWpiV3Bs ZEdoaGJtRnVaR0Z1YVVCbmJXRnBiQzVqYjIxaE0yVmtaREZsTmpobE0yWTJNakEyWlRGaE1HSTJO RE0zT0RZNE5XUmpZekptT1dOaU5tTmomY3R6PUFtZXJpY2ElMkZMb3NfQW5nZWxlcyZobD1lbiZl cz0wDQoNCkludml0YXRpb24gZnJvbSBHb29nbGUgQ2FsZW5kYXI6IGh0dHBzOi8vd3d3Lmdvb2ds ZS5jb20vY2FsZW5kYXIvDQoNCllvdSBhcmUgcmVjZWl2aW5nIHRoaXMgY291cnRlc3kgZW1haWwg YXQgdGhlIGFjY291bnQgbmV0Y29uZkBpZXRmLm9yZyAgDQpiZWNhdXNlIHlvdSBhcmUgYW4gYXR0 ZW5kZWUgb2YgdGhpcyBldmVudC4NCg0KVG8gc3RvcCByZWNlaXZpbmcgZnV0dXJlIHVwZGF0ZXMg Zm9yIHRoaXMgZXZlbnQsIGRlY2xpbmUgdGhpcyBldmVudC4gIA0KQWx0ZXJuYXRpdmVseSB5b3Ug Y2FuIHNpZ24gdXAgZm9yIGEgR29vZ2xlIGFjY291bnQgYXQgIA0KaHR0cHM6Ly93d3cuZ29vZ2xl LmNvbS9jYWxlbmRhci8gYW5kIGNvbnRyb2wgeW91ciBub3RpZmljYXRpb24gc2V0dGluZ3MgZm9y ICANCnlvdXIgZW50aXJlIGNhbGVuZGFyLg0KDQpGb3J3YXJkaW5nIHRoaXMgaW52aXRhdGlvbiBj b3VsZCBhbGxvdyBhbnkgcmVjaXBpZW50IHRvIHNlbmQgYSByZXNwb25zZSB0byAgDQp0aGUgb3Jn YW5pemVyIGFuZCBiZSBhZGRlZCB0byB0aGUgZ3Vlc3QgbGlzdCwgb3IgaW52aXRlIG90aGVycyBy ZWdhcmRsZXNzICANCm9mIHRoZWlyIG93biBpbnZpdGF0aW9uIHN0YXR1cywgb3IgdG8gbW9kaWZ5 IHlvdXIgUlNWUC4gTGVhcm4gbW9yZSBhdCAgDQpodHRwczovL3N1cHBvcnQuZ29vZ2xlLmNvbS9j YWxlbmRhci9hbnN3ZXIvMzcxMzUjZm9yd2FyZGluZw0K --00000000000026b85305aae7bef2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--00000000000026b85305aae7bef2 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20200728T110000Z DTEND:20200728T124000Z DTSTAMP:20200720T231947Z ORGANIZER;CN=mjethanandani@gmail.com:mailto:mjethanandani@gmail.com UID:2D63C609-3C76-4AE8-975E-B409A5954094 ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=mjethanandani@gmail.com;X-NUM-GUESTS=0:mailto:mjethanandani@gmail.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=netconf@ietf.org;X-NUM-GUESTS=0:mailto:netconf@ietf.org X-MICROSOFT-CDO-OWNERAPPTID:366307275 CREATED:20200720T231444Z DESCRIPTION:Note\, we are no longer using WebEx for this meeting. Please us e the Meetecho link to join the meeting.\n\nhttps://meetings.conf.meetecho. com/ietf108/?group=netconf\n\n\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~ :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this secti on of the description.\n\nView your event at https://www.google.com/calenda r/event?action=VIEW&eid=XzY5MjNjY3EzNm9vM2liOWo4Y3JqY2I5azg1MmpnYjlwNnNxa2F iYTI2Z28zaWc5bDc0cWo4YzFwNmcgbmV0Y29uZkBpZXRmLm9yZw&tok=MjMjbWpldGhhbmFuZGF uaUBnbWFpbC5jb21hM2VkZDFlNjhlM2Y2MjA2ZTFhMGI2NDM3ODY4NWRjYzJmOWNiNmNj&ctz=A merica%2FLos_Angeles&hl=en&es=1.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~ :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::- LAST-MODIFIED:20200720T231947Z LOCATION:https://meetings.conf.meetecho.com/ietf108/?group=netconf SEQUENCE:0 STATUS:CONFIRMED SUMMARY:IETF 108 NETCONF Virtual Meeting TRANSP:OPAQUE X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:This is an event reminder TRIGGER:-P0DT0H10M0S END:VALARM END:VEVENT END:VCALENDAR --00000000000026b85305aae7bef2-- --00000000000026b85505aae7bef4 Content-Type: application/ics; name="invite.ics" Content-Disposition: attachment; filename="invite.ics" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vR29vZ2xlIEluYy8vR29vZ2xlIENhbGVuZGFyIDcw LjkwNTQvL0VODQpWRVJTSU9OOjIuMA0KQ0FMU0NBTEU6R1JFR09SSUFODQpNRVRIT0Q6UkVRVUVT VA0KQkVHSU46VkVWRU5UDQpEVFNUQVJUOjIwMjAwNzI4VDExMDAwMFoNCkRURU5EOjIwMjAwNzI4 VDEyNDAwMFoNCkRUU1RBTVA6MjAyMDA3MjBUMjMxOTQ3Wg0KT1JHQU5JWkVSO0NOPW1qZXRoYW5h bmRhbmlAZ21haWwuY29tOm1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbQ0KVUlEOjJENjND NjA5LTNDNzYtNEFFOC05NzVFLUI0MDlBNTk1NDA5NA0KQVRURU5ERUU7Q1VUWVBFPUlORElWSURV QUw7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9QUNDRVBURUQ7UlNWUD1UUlVFDQogO0NO PW1qZXRoYW5hbmRhbmlAZ21haWwuY29tO1gtTlVNLUdVRVNUUz0wOm1haWx0bzptamV0aGFuYW5k YW5pQGdtYWlsLmNvbQ0KQVRURU5ERUU7Q1VUWVBFPUlORElWSURVQUw7Uk9MRT1SRVEtUEFSVElD SVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9DQogVFJVRTtDTj1uZXRjb25mQGlldGYu b3JnO1gtTlVNLUdVRVNUUz0wOm1haWx0bzpuZXRjb25mQGlldGYub3JnDQpYLU1JQ1JPU09GVC1D RE8tT1dORVJBUFBUSUQ6MzY2MzA3Mjc1DQpDUkVBVEVEOjIwMjAwNzIwVDIzMTQ0NFoNCkRFU0NS SVBUSU9OOk5vdGVcLCB3ZSBhcmUgbm8gbG9uZ2VyIHVzaW5nIFdlYkV4IGZvciB0aGlzIG1lZXRp bmcuIFBsZWFzZSB1cw0KIGUgdGhlIE1lZXRlY2hvIGxpbmsgdG8gam9pbiB0aGUgbWVldGluZy5c blxuaHR0cHM6Ly9tZWV0aW5ncy5jb25mLm1lZXRlY2hvLg0KIGNvbS9pZXRmMTA4Lz9ncm91cD1u ZXRjb25mXG5cblxuLTo6fjp+Ojp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fg0K IDp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjo6fjp+OjotXG5QbGVhc2UgZG8g bm90IGVkaXQgdGhpcyBzZWN0aQ0KIG9uIG9mIHRoZSBkZXNjcmlwdGlvbi5cblxuVmlldyB5b3Vy IGV2ZW50IGF0IGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vY2FsZW5kYQ0KIHIvZXZlbnQ/YWN0aW9u PVZJRVcmZWlkPVh6WTVNak5qWTNFek5tOXZNMmxpT1dvNFkzSnFZMkk1YXpnMU1tcG5Zamx3Tm5O eGEyRg0KIGlZVEkyWjI4emFXYzViRGMwY1dvNFl6RndObWNnYm1WMFkyOXVaa0JwWlhSbUxtOXla dyZ0b2s9TWpNamJXcGxkR2hoYm1GdVpHRg0KIHVhVUJuYldGcGJDNWpiMjFoTTJWa1pERmxOamhs TTJZMk1qQTJaVEZoTUdJMk5ETTNPRFk0TldSall6Sm1PV05pTm1OaiZjdHo9QQ0KIG1lcmljYSUy Rkxvc19BbmdlbGVzJmhsPWVuJmVzPTEuXG4tOjp+On46On46fjp+On46fjp+On46fjp+On46fjp+ On46fjp+On46fg0KIDp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+Ojp+On46 Oi0NCkxBU1QtTU9ESUZJRUQ6MjAyMDA3MjBUMjMxOTQ3Wg0KTE9DQVRJT046aHR0cHM6Ly9tZWV0 aW5ncy5jb25mLm1lZXRlY2hvLmNvbS9pZXRmMTA4Lz9ncm91cD1uZXRjb25mDQpTRVFVRU5DRTow DQpTVEFUVVM6Q09ORklSTUVEDQpTVU1NQVJZOklFVEYgMTA4IE5FVENPTkYgVmlydHVhbCBNZWV0 aW5nDQpUUkFOU1A6T1BBUVVFDQpYLUFQUExFLVRSQVZFTC1BRFZJU09SWS1CRUhBVklPUjpBVVRP TUFUSUMNCkJFR0lOOlZBTEFSTQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlRoaXMgaXMg YW4gZXZlbnQgcmVtaW5kZXINClRSSUdHRVI6LVAwRFQwSDEwTTBTDQpFTkQ6VkFMQVJNDQpFTkQ6 VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= --00000000000026b85505aae7bef4-- From nobody Tue Jul 21 07:44:55 2020 Return-Path: <0100017371d59ad5-c8aa5683-34d7-4e76-b521-8482f67e33e4-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 E509A3A0934 for ; Tue, 21 Jul 2020 07:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 JN2PL-90Rd5K for ; Tue, 21 Jul 2020 07:44:52 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07623A092E for ; Tue, 21 Jul 2020 07:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1595342691; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=LzFZq+tcbJgpKbEt7ZuFdUYAo7B4B2gmDKgQZ6ZSvRk=; b=Vz1ZGSA2BRS/JNylN7DUS5pSEf5yM8lTeuJO6g6PIqWoBMSsVjxfEdqOL4j8tghr Gvp6W4MEKibdsht3mWp6tX+Ojkwks/0XCC8RlxwreQVF+8xXwePrzRBcrdII2ttubcg gsK/1+EgIh+y5jDHXT58cvnWWyixCPA7KlaI0Wu0= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_B5AD7110-ED08-4D09-9E2D-F2ECC91FFAC6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <0100017371d59ad5-c8aa5683-34d7-4e76-b521-8482f67e33e4-000000@email.amazonses.com> Date: Tue, 21 Jul 2020 14:44:51 +0000 Cc: "netconf@ietf.org" To: Henk Birkholz X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.21-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] type for a PSK's "id" node? 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, 21 Jul 2020 14:44:54 -0000 --Apple-Mail=_B5AD7110-ED08-4D09-9E2D-F2ECC91FFAC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Henk, I=E2=80=99m trying to close a couple issues on list before the = meeting... Below you=E2=80=99ll note the "is this the right type?=E2=80=9D comment. = Currently the =E2=80=9Cid=E2=80=9D node is type =E2=80=9Cstring=E2=80=9D,= what type is used by TLS? case psk { if-feature psk-auth; container psk { description=20 "Specifies the server identity using a PSK (pre-shared or pairwise-symmetric key)."; uses ks:local-or-keystore-symmetric-key-grouping { augment "local-or-keystore/local/local-definition" { if-feature "ks:local-definitions-supported"; description "Adds an 'id' value when the PSK is used by TLS."; leaf id { type string; // FIXME: is this the right type? description "The key id used in the TLS protocol for PSKs."; } =20 }=20 }=20 }=20 }=20 K. --Apple-Mail=_B5AD7110-ED08-4D09-9E2D-F2ECC91FFAC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = Henk,

I=E2=80=99m trying to close a couple issues = on list before the meeting...

Below you=E2=80=99ll note the "is this the right type?=E2=80=9D= comment.  Currently the =E2=80=9Cid=E2=80=9D node is type = =E2=80=9Cstring=E2=80=9D, what type is used by TLS?


        case psk = {
          = if-feature = psk-auth;
          = container = psk = {
          =   description 
      =         "Specifies the server identity using a = PSK (pre-shared
          =     or pairwise-symmetric key).";
      =       uses ks:local-or-keystore-symmetric-key-grouping {
      =         augment "local-or-keystore/local/local-definition" {
      =           if-feature "ks:local-definitions-supported";
          =       description
                =   "Adds an 'id' value when the PSK is used = by TLS.";
                = leaf = id = {
          =         type string// = FIXME: is this the right type?
  =                 description
                =     "The key id used in the TLS protocol for = PSKs.";
  =               }  =  
          =     } 
  =           } 
          } 
        } 


K.


= --Apple-Mail=_B5AD7110-ED08-4D09-9E2D-F2ECC91FFAC6-- From nobody Mon Jul 27 08:39:16 2020 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 1135A3A192F; Mon, 27 Jul 2020 08:39:11 -0700 (PDT) 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.10.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159586435098.29591.15728904593699090813@ietfa.amsl.com> Date: Mon, 27 Jul 2020 08:39:11 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.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, 27 Jul 2020 15:39: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 : An HTTPS-based Transport for Configured Subscriptions Authors : Mahesh Jethanandani Kent Watsen Filename : draft-ietf-netconf-https-notif-04.txt Pages : 27 Date : 2020-07-27 Abstract: 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 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 27 08:46:03 2020 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 258633A1AB7 for ; Mon, 27 Jul 2020 08:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 YUEKOtAB8dIR for ; Mon, 27 Jul 2020 08:45:52 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 9485C3A1AA2 for ; Mon, 27 Jul 2020 08:45:44 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id m22so9817459pgv.9 for ; Mon, 27 Jul 2020 08:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=xD1kKgNuIVtLgK2KJL9JuULdASKHGANzqC+Rn3UCOSo=; b=R/9RGQkeWxbwVi6X2KQOy7rsf48qc33vn7IcUska505M+wMurIO1yrokFJIZj7NYWf 6hhFEIaVRu7t76u0j8bgm3kwjYgF2BdEWqUSCKTSYjRWZfE4WVOET5KaPFCjqxZaK7Lk ol2dc+m/orj7YCos6SbgvG0YMrDxdEkFAMCJOle7sx8DibERQS9X2jryxVT6BWWl2iY2 6TUZ8TEtt46e4ywJGDqVgM2O/G4VKvOOuX7bFN+dbgpDeDc2JaP6BwD2qFEO0SNfZLcT cXXU1VPA0kpZ7bRwWkrTYGHm2EFbkM8CYlq9Af0U2BPPlyQHcV02V+HmIjwmSdZVaINV V8Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=xD1kKgNuIVtLgK2KJL9JuULdASKHGANzqC+Rn3UCOSo=; b=oYWJYjezDBe++l1aFH90yo62IO9HiC1brfbGY8QNkZT7Cs4DVGKu5G8ZebcA6ueuVA usGfunSb5EtwQsW+lTy9JrV/GHfOZFvVKAKz9eO/JdygjS7bSY/7mxlRFn3T+NbrlqNq oZ7syhi8AUOhjL9ab2EGMVCPkPZdJSTugHKvxm6EA/DQauC/CegxTLhnWwEfZL7v1lIc O462R3DZS6ydIKLTDFD6+o3Qtt8u2tWTYa3Nhr3qLEcy/XPNhsd7IaUdnmDj0UdJp4L8 gmj2NBpYJcx7M0eoydTRQSId2OymapTL1bQQeGuI9oOTkFNXWfButukCW56aCC5sbJPC /Mmw== X-Gm-Message-State: AOAM531vUNzroNbdev/JOySWJb0Eqb//6TAXH+w3bq1Qzrg+kqqoQu5o GQL99hRo/IlWQOgNzeHu1i07Xq/S X-Google-Smtp-Source: ABdhPJy4wyn0WgTpQHAYXrVZsf5HcoUHpVMh19Fl5A+pT5C7gOh+/DpicUeoUdiLmvIAQsduV6SeiQ== X-Received: by 2002:a63:690:: with SMTP id 138mr19665612pgg.122.1595864740440; Mon, 27 Jul 2020 08:45:40 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:832:30a0:8e73:f872? ([2601:647:5600:5020:832:30a0:8e73:f872]) by smtp.gmail.com with ESMTPSA id k2sm15219022pgm.11.2020.07.27.08.45.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2020 08:45:39 -0700 (PDT) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\)) Date: Mon, 27 Jul 2020 08:45:37 -0700 References: <159586435098.29591.15728904593699090813@ietfa.amsl.com> To: netconf@ietf.org In-Reply-To: <159586435098.29591.15728904593699090813@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.9.6) Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.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: Mon, 27 Jul 2020 15:46:01 -0000 This version of the document addresses comments received from Eric, and = updates to the ietf-truststore module. > On Jul 27, 2020, at 8:39 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Network Configuration WG of the IETF. >=20 > Title : An HTTPS-based Transport for Configured = Subscriptions > Authors : Mahesh Jethanandani > Kent Watsen > Filename : draft-ietf-netconf-https-notif-04.txt > Pages : 27 > Date : 2020-07-27 >=20 > Abstract: > 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 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04 > = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-https-notif-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani (as co-author) mjethanandani@gmail.com From nobody Mon Jul 27 09:52:50 2020 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 6AD033A1B1B for ; Mon, 27 Jul 2020 09:52:49 -0700 (PDT) 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_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=ZBv6il/s; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=JRWr5LOU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY2XUEahxHKx for ; Mon, 27 Jul 2020 09:52:47 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBE33A1B14 for ; Mon, 27 Jul 2020 09:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9515; q=dns/txt; s=iport; t=1595868767; x=1597078367; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=efGHgdSpqRc5Q3xiICFGWJNpWI7QNYYGB0ouy6sGhoo=; b=ZBv6il/svY4ZNNVXJWXoo7oUjQzrLi7oxm2ITvOQpohxC9gbVJ0crUoq AdCMX89OmQvX9v0ZlNr4fg5hGNVfGsbdv1xaP20cKf6yqsBDUHy6nzZY5 UkjSs0+apa27B2vtCe7afbAXz2VJZLzbtO+Icn5ndnDl4ihfg4R7EQRdj s=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3ACqojJBEhSyFvBbxelwj5gZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QObUoDS6vYCgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8n7blzW5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYBQA0BR9f/5ldJa1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUlEHbystLywKh3ADjViKAo5fglMDVQQHAQEBCQMBARg?= =?us-ascii?q?LCgIEAQGECEQCgicCJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBBAEBEC4?= =?us-ascii?q?BASwMCwQCAQgOAwQBAQENIQIfBgsdCAIEARIIBhSDBYF+TQMfDwEOo1UCgTm?= =?us-ascii?q?IYXSBNIMBAQEFgTcCDkGDJw0LggcHCYE4gVOBGooQGoFBP4FUgk0+ghpCAQE?= =?us-ascii?q?CAQEVgUgVgzKCLY9XiyCaKU4Kgl6EM4JYgUuMI4UWgnuBIYgnkyGSFoougmG?= =?us-ascii?q?SCwIEAgQFAg4BAQWBaiOBV3AVGiGCaQlHFwINjh6DcYUUhUJ0NwIGCAEBAwl?= =?us-ascii?q?8jE8rgQoBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,402,1589241600"; d="p7s'?scan'208";a="794645595" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jul 2020 16:52:46 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 06RGqkOg031441 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jul 2020 16:52:46 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 11:52:46 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 12:52:44 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 27 Jul 2020 12:52:44 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S6tn/62GTeyCjrYrB+wobQfEwzlYESiXuoTjllzV08kjTPTSo/YLmDsGbdryNhB2nEx7pNxWAWxo/H9CeNfLurcsPRL+DbBv0ASsYU2yo+jORX6WIytlGQPZFuUDOF5X6JsPCl+UdVEx95AoxKvwM+uEnpea8vgeweVmSqfpBet1EBlrXBuKg6SmnSA9Imx0MKBJf1F2+Cl5bW+E0G3l0syi8StZQsYYgu3/BSYIMOXL7x8PZIZeADhcZAlID0fCvHiGVNXk7zTz/x2cIvusFi90mq2CdFRk4o4fN0hMvNOBDqpNFDvWMEueRg8A4k12c4GBN48E2fCG/WayqHaPhg== 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=isSADIn81I47MmBMz9YITHHPPVIMEEg6BCsLNIwCOwA=; b=hJ9n0Dy0Dcge4azW+jjh7gdR2Jgb+0iJXtAel/VXfSFpLIpNfeNj2f8MniJPIrzoJW01q5k7IHI5Q+Lbn2ERR7pRSuEwcQmnJLbF2MTTKjcwcV9S3bzbLrYxWGUQEPrXVUQGLOFupvz5Om08oZGdxaIZuhArBdFTCdLkNwsFPEBexXodBVeljyJlH2+Q8mQF9WsYCsqmWTONq3JhBAZzvqeP4r15KAxMGI9WwyqfJCyMOKanr55T+e5G/rR4VF6LlUKzXaGPwLVoi2Q1X9cc++nS11L+0/YoLwceaSfaoTPHTzpJ9e6ApEcKFAfXRAH+U+FT+651jj8axkYlzYX9Pw== 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=isSADIn81I47MmBMz9YITHHPPVIMEEg6BCsLNIwCOwA=; b=JRWr5LOUn5UMkL78l8IyX+eHHhbn1ODK2s8vt/XPEqW5xIimzAthHtMBOAxXVuKYS3ghfeKv2izlRS0UPcBiLJe0nll88Ns/sttdlT1tHFx3EKafrcleTlKEDP/y55rRicSlhbvBVywDclDvRVnGmSA4/FsobchJdC4uf7VqYGI= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB2979.namprd11.prod.outlook.com (2603:10b6:208:7c::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Mon, 27 Jul 2020 16:52:44 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2%5]) with mapi id 15.20.3216.033; Mon, 27 Jul 2020 16:52:43 +0000 From: "Eric Voit (evoit)" To: Mahesh Jethanandani , "netconf@ietf.org" Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt Thread-Index: AQHWZC0s4rGn4H8SgEeN9NnhYjeTUKkboLwg Date: Mon, 27 Jul 2020 16:52:43 +0000 Message-ID: References: <159586435098.29591.15728904593699090813@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.88] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 04fa5270-e85c-40e5-ccc9-08d8324d7b8c x-ms-traffictypediagnostic: BL0PR11MB2979: 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: 8x/DeyfalkpECrFkE0vvcMqjOo/aBy8U5GSKTO5atHJ70PZ89NXZaP1HbmC6HIw4Bras5gqicrRlxnHwrgm2ZPq21PBjqe0+nD+JrBy7oacMmprWYN5y9d6G9XULW99pC8B5a5ZOyEQv/CH0Gige9oCpsBaRFibIwW4FZnBBEZwbGWr9Q4MeXYTsmt05rFFk2tSPRYfPzt9oNC6YA/Md+DtD3GcryuRVw2lqirlWw8fHWO5BEdo360hlpShK05xuO8PAQAzZjLiFdZUQHKoaqJPWDNm9KPScmoyeIQHbgOwpShuZ0fFFGhQ/ZROZprd1dCQ24W6/+GT/QjHqqyhwjCsAGqL5jX+Lcjb75EZq87C+pC8vyTKkI/SHDaw++py3vHmgyZ7tUvtLyb2TE6iy/A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(346002)(39860400002)(366004)(376002)(6506007)(5660300002)(66476007)(99936003)(478600001)(83380400001)(66616009)(53546011)(66556008)(9686003)(66946007)(55016002)(76116006)(316002)(52536014)(66574015)(26005)(7696005)(2906002)(66446008)(71200400001)(33656002)(186003)(8676002)(110136005)(966005)(8936002)(86362001)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ctCY0PFkF3eUyfPmFJoaNn1tVKnndHsgHUqeNiUB7SXXOjh+tAxu6ZGB1FER+i0nIG3ef0T6mGn30+gciWDdVJnroDAVG4BupsNr6FWExx9urlnILSWweLHBvfnKvuMfembFzKlbhQHaAQRAW4xO8XVMWMDEi0b6vcTi0jlB6Nl3NPTVr1ahbH+uWFZZ1u84pExdsADIkG4d14HttIAKZKaStqxcmw6z2gaSu4fZ97OvTMHghXdJmgp8lxfOqODGDeTC1QphOhQg+UwavSq8fwPCXcxyeFE9yu8TZ8Sh1P+49KLvj+9jfthqAgzGfbxunwGrs3D6K0poVFe1DXw0fBlEj0RWaMocqDcVZSmyEUrrpXmKdGMiS7xAgvAowAfFEYwi+7L81ExxuHQTckUTPL/W6MkHlnD8WNleTJgJHvZn/hAZK7Wc83nJq7995mGQ8Nc3TqFJPGmoT0+HOPYEAUQCYXjNGLHJV3EqnFcgGVI= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0A54_01D66414.CF671090" 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: 04fa5270-e85c-40e5-ccc9-08d8324d7b8c X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 16:52:43.8827 (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: 2emRNt0x+LRVk77zdLjNFuGD/EoJtroHCqB0tNVjGQ/hKTk3mlcWaZbKJ3nS9hvB X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2979 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.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: Mon, 27 Jul 2020 16:52:50 -0000 ------=_NextPart_000_0A54_01D66414.CF671090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mahesh, Thanks for updating the text. One question, are you sure you need the statement: This example shows the flow assuming that Subscribed Notifications is used and therefore a 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 . I am guessing that you mean "Subscription State Change Notifications" here rather than "Subscribed Notifications". As RFC-8639 Subscription State Change Notifications are mandatory, is this statement necessary here? Perhaps you could add a non-normative appendix which shows the implications of dropping specific Subscription State Change Notifications If an implementation desires this simplification? E.g., issues with supporting replay, issues with understanding what subscription is sending traffic, no ability to see if the terms of the subscription changed, no awareness of subscription suspend, no way to signal the end/termination of a subscription, etc. All of these might be absolutely ok in an implementation, but it might be worth addressing in aggregate in a place which is outside the bounds of the normative text. Eric > -----Original Message----- > From: netconf On Behalf Of Mahesh > Jethanandani > Sent: Monday, July 27, 2020 11:46 AM > To: netconf@ietf.org > Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt > > This version of the document addresses comments received from Eric, and > updates to the ietf-truststore module. > > > On Jul 27, 2020, at 8:39 AM, 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 Configured Subscriptions > > Authors : Mahesh Jethanandani > > Kent Watsen > > Filename : draft-ietf-netconf-https-notif-04.txt > > Pages : 27 > > Date : 2020-07-27 > > > > Abstract: > > 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 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-04 > > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-0 > > 4 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-04 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > Mahesh Jethanandani (as co-author) > mjethanandani@gmail.com > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_0A54_01D66414.CF671090 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNzI3MTY1MjM5WjAjBgkqhkiG 9w0BCQQxFgQUdA9wfK3VL2ZbQlbP8Iu6M1JwT9YwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAZ13go+lcAEH5IiCEd6DmswVkNFdJwOzKG84J+eZMaOtMP/mAP/VQ4W0NUC/mCYE4L 0cIdJrPOeY+mrAMyN4oJ1zKzgMKQzXpRyOtNaegr68Zrgu9NBq9hpx/mg12ffyqox6yQtLXFzSD5 y+Zclsp4cwTYn1XUXYWwgrDdvwRuUW2DdUdpu8HR0la5tFMq1r6Byx5YPAWUIB3ASQlczVy4R9f4 emn3p/K5hw2wTz2tIOaXKNyjwWdIAPS1+XI9IvIdfyivhlwMQ/QjAn7WX1YSH7GIaRCHrNeR36TR iz+RhmAd3SOtHJwgBE9sL6EW7rvRRFQ7ZOE3CrasGK7wJZKpAAAAAAAA ------=_NextPart_000_0A54_01D66414.CF671090-- From nobody Mon Jul 27 15:37:19 2020 Return-Path: <01000173926c3c2b-d9fb1a5b-c7bf-49d5-b8fe-a84f6522f292-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 EF98E3A0929; Mon, 27 Jul 2020 15:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Nv1OCr80xkeJ; Mon, 27 Jul 2020 15:37:15 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088463A0928; Mon, 27 Jul 2020 15:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1595889433; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=qmVkDx0FAxMdIkvJf3tNqGMaCxY3vl7v1zv98zEgEdU=; b=QiD1H5Dt99VvfoZqXVIkDMHI0qm8nvjGbecJvSusKxTLV3WpNQ8Gh5tFOkFKiU42 qy4F7Nn2ghudm7oK0S+L+ChhemrdpP+A8a9qjyzF3cPMv9A6EV05jtyR5doF4XFhzem CkfLLJztN6mIp8B7zPJVeO/o+GQEBptefkhevQ6w= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <010001736e80a2da-a5f17d01-280f-445b-affb-d8630f9c73f4-000000@email.amazonses.com> Date: Mon, 27 Jul 2020 22:37:13 +0000 Cc: "netconf-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000173926c3c2b-d9fb1a5b-c7bf-49d5-b8fe-a84f6522f292-000000@us-east-1.amazonses.com> References: <010001734a4dbbe7-637ac888-1065-460e-a3a1-3c33a8c66bc7-000000@email.amazonses.com> <010001736e80a2da-a5f17d01-280f-445b-affb-d8630f9c73f4-000000@email.amazonses.com> To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.27-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Preliminary Agenda 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, 27 Jul 2020 22:37:17 -0000 NETCONF WG, The agenda has been updated (see below). The Etherpad link has been = replaced with the CodiMD link for the session. Please note that CodiMD MAY be opened in another browser window or tab, = in addition to the MeetEcho window. Kent and Mahesh Agenda for the NETCONF 108 WG Session ------------------------------------- https://datatracker.ietf.org/meeting/108/materials/agenda-108-netconf Session: Tuesday July 28th UTC: 11:00-12:40 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/108/sessions/netconf.ics MeetEcho: = https://meetings.conf.meetecho.com/ietf108/?group=3Dnetconf Jabber: xmpp:netconf@jabber.ietf.org?join Available During and After Session: CodiMD: https://codimd.ietf.org/notes-ietf-108-netconf Slides (TGZ): = https://datatracker.ietf.org/meeting/108/agenda/netconf-drafts.tgz Slides (PDF): = https://datatracker.ietf.org/meeting/108/agenda/netconf-drafts.pdf Available After Session: Recording: = https://ietf108.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: Status and Issues on Client-Server Suite of Drafts (10 min) https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-17 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-12 https://tools.ietf.org/html/draft-ietf-netconf-keystore-19 https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-07 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-21 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-21 https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-04 = https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-20 = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-20 Presenter: Kent Watsen An HTTPS-based Transport for Configured Subscriptions (10 min) https://tools.ietf.org/html/draft-ietf-netconf-https-notif-03 Presenter: Mahesh Jethanandani Non-Chartered items: UDP-based Transport for Configured Subscriptions (10 min) https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-00 Presenter: Pierre Francois =20 Subscription to Distributed Notifications (10 min) = https://datatracker.ietf.org/doc/draft-unyte-netconf-distributed-notif-00 Presenter: Thomas Graf Self-explanation Data Node Tag & Telemetry Data Export Capabilities = (15 min) = https://datatracker.ietf.org/doc/draft-tao-netconf-notif-node-tag-capabili= ties-02 = https://datatracker.ietf.org/doc/draft-tao-netconf-data-export-capabilitie= s-01 Presenter: Qin Wu / Liu Peng Adaptive Subscription to YANG & Bulk Subscription to YANG Event = Notifications (15 min) = https://datatracker.ietf.org/doc/draft-wang-netconf-adaptive-subscription-= 02 = https://datatracker.ietf.org/doc/draft-wang-netconf-bulk-subscribed-notifi= cations-02 Presenter: Qin Wu / Liu Peng =20 Conveying a CSR in a SZTP Bootstrapping Request (10 min) https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr-01 Presenter: Kent Watsen Remaining 10 min. From nobody Tue Jul 28 02:46:21 2020 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 C003C3A09FD for ; Tue, 28 Jul 2020 02:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 h9gCPgmaBN1J for ; Tue, 28 Jul 2020 02:46:16 -0700 (PDT) Received: from mail-edgeKA24.fraunhofer.de (mail-edgeka24.fraunhofer.de [153.96.1.24]) (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 258753A09FC for ; Tue, 28 Jul 2020 02:46:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FRBQBZ8h9f/xoBYJlXCYEJhGOBMwq?= =?us-ascii?q?EKpEgnAwLAQEBAQEBAQEBBgEBIwoCBAEBAoRKAoIfASQ4EwIQAQEGAQEBAQE?= =?us-ascii?q?GBAIChkUMg1OBAwEBAQEBAQEBAQEBAQEBAQEBAQEWAkNVEgEeAQEBAQIBIw8?= =?us-ascii?q?BBUEFCwkCGAICJgICRxAGDQEHAQGDIgGCXB8FC5MDmwR2gTKFUoNOgToGgQ4?= =?us-ascii?q?qhkaGNw+BTD+BOA+CWj6CXAEBAgGBMBSDLoJgBJJiomgpB4FagQiBCAQLh0G?= =?us-ascii?q?RDAUKHoJ7iUmEfgaOIZxFlGwCBAIJAhWBaoF7TSRPgmpPFwINlyOFRHICNQI?= =?us-ascii?q?GAQcBAQMJfI5rAYEQAQE?= X-IPAS-Result: =?us-ascii?q?A2FRBQBZ8h9f/xoBYJlXCYEJhGOBMwqEKpEgnAwLAQEBA?= =?us-ascii?q?QEBAQEBBgEBIwoCBAEBAoRKAoIfASQ4EwIQAQEGAQEBAQEGBAIChkUMg1OBA?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEWAkNVEgEeAQEBAQIBIw8BBUEFCwkCGAICJ?= =?us-ascii?q?gICRxAGDQEHAQGDIgGCXB8FC5MDmwR2gTKFUoNOgToGgQ4qhkaGNw+BTD+BO?= =?us-ascii?q?A+CWj6CXAEBAgGBMBSDLoJgBJJiomgpB4FagQiBCAQLh0GRDAUKHoJ7iUmEf?= =?us-ascii?q?gaOIZxFlGwCBAIJAhWBaoF7TSRPgmpPFwINlyOFRHICNQIGAQcBAQMJfI5rA?= =?us-ascii?q?YEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,406,1589234400"; d="scan'208";a="23226684" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2020 11:46:12 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7BgB28x9f/1lIDI1XCR4BAQsSDEC?= =?us-ascii?q?DdG9XMCwKhCqRH5wMCwEDAQEBAQEGAQEjCgIEAQGETAKCHQIkOBMCEAEBBQE?= =?us-ascii?q?BAQIBBgRthVwMhXEBAQEDASMPAQVBBQsJAhgCAiYCAkcQBg0BBwEBgyIBglw?= =?us-ascii?q?kC5MEmwR2gTKFUoNQgToGgQ4qhkaGNw+BTD+BOA+CWj6CXAEBAgGBMBSDLoJ?= =?us-ascii?q?gBJJiomgpB4FagQiBCAQLh0GRDAUKHoJ7iUmEfgaOIZxFlGwCBAIJAhWBaiO?= =?us-ascii?q?BV00kT4JqTxcCDZcjhURBMQI1AgYBBwEBAwl8jmsBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,406,1589234400"; d="scan'208";a="87317238" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2020 11:46:09 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 06S9k81M032499 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 28 Jul 2020 11:46:08 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 28 Jul 2020 11:46:03 +0200 To: Kent Watsen CC: "netconf@ietf.org" References: <0100017371d59ad5-c8aa5683-34d7-4e76-b521-8482f67e33e4-000000@email.amazonses.com> From: Henk Birkholz Message-ID: Date: Tue, 28 Jul 2020 11:46:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <0100017371d59ad5-c8aa5683-34d7-4e76-b521-8482f67e33e4-000000@email.amazonses.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [netconf] type for a PSK's "id" node? 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, 28 Jul 2020 09:46:19 -0000 Hi all, this might be pretty much "just in time", but let me elaborate a bit here: After re-exploring the source of PSK Identity (hints), I arrived at PSK Identity Encoding again: > https://tools.ietf.org/html/rfc4279#section-5.1 If that is the PSK "id" that you are looking for, that always involves a conversion to UTF8 encoded bytestrings. If that is interoperable with the type string here, that is fine, I'd say. Interoperability already is a rather painful compromise here in (D)TLS. Please take care to adhere to the encoding guidance, therefore. I am not sure, if you want to cover identity hints, too: > https://tools.ietf.org/html/rfc4279#section-5.2 Viele Grüße, Henk On 21.07.20 16:44, Kent Watsen wrote: > Hi Henk, > > I’m trying to close a couple issues on list before the meeting... > > Below you’ll note the "is this the right type?” comment.  Currently the > “id” node is type “string”, what type is used by TLS? > > > case*psk*{ > if-feature*psk-auth*; > container*psk*{ > description > "Specifies the server identity using a PSK (pre-shared >               or pairwise-symmetric key)."; > uses*ks:local-or-keystore-symmetric-key-grouping*{ > augment"local-or-keystore/local/local-definition"{ > if-feature"ks:local-definitions-supported"; > description > "Adds an 'id' value when the PSK is used by TLS."; > leaf*id*{ > typestring; // FIXME: is this the right type? > description > "The key id used in the TLS protocol for PSKs."; >                 } >               } >             } >           } >         } > > > K. > > From nobody Tue Jul 28 03:40:53 2020 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 014FC3A0AAF for ; Tue, 28 Jul 2020 03:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_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=N/kM4ylW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qgxwT3kh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW6jjtxu7McJ for ; Tue, 28 Jul 2020 03:40:47 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2C23A0AAC for ; Tue, 28 Jul 2020 03:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1759; q=dns/txt; s=iport; t=1595932847; x=1597142447; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=pzBsnFssVwF76dpe+4ACIseR1GpA+cvGEvBMfzk0cOI=; b=N/kM4ylWGOO+nDcxQXw1ZQ/mAtqlIsJdxmXRACLTuQbq60FWeIfAeaNQ a1L+EKYRI8reCXbFBS3kxhF/U1EjfCABm3uuVkIoMtQ6zPYxYJLOB0xtE cLnU159EsJsPlvj3ns+DrdrwyyQ2PnynUHiV4RH8zvDcVR4VV0Vtyh3HO M=; IronPort-PHdr: =?us-ascii?q?9a23=3AUtHxLx1cmBIQ7qDSsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGv6dsgUPHG4LB5KEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK6PFRbXsHkaA6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CACQBBACBf/5xdJa1gHgE8DAILFYM?= =?us-ascii?q?cKSgHb1gvLAqHcAOmOIJTA1ULAQEBDAEBLQIEAQGETAKCHQIkOBMCAwEBCwE?= =?us-ascii?q?BBQEBAQIBBgRthVwMhgooBgEBOBEBPkImAQQBGhqDBYJLAy4BA6NVAoE5iGF?= =?us-ascii?q?0gTSDAQEBBYUzGIIOCYE4gm2KEBqBQT+BVIIYhTKDR4IttXcKgl+aEZ9pkhe?= =?us-ascii?q?fGgIEAgQFAg4BAQWBaiOBV3AVgyRQFwINj0MBCIJDilZ0NwIGCAEBAwl8jms?= =?us-ascii?q?BgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,406,1589241600"; d="scan'208";a="536663675" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jul 2020 10:40:46 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 06SAek4Q010251 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Jul 2020 10:40:46 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 05:40:46 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 05:40:45 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 28 Jul 2020 05:40:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oSELnHGOlO+djD2VM8OMTFZT9k9Sm4mgLw3mS1Oywu/q881byKrXDKRmPZFzSwDFsrwvLw92EewnBFOanHWUTlByZecdsYpcEaFxwTK1px4kJLPOXbvuiiZGcU7TuMF5a3Vt2a8XCYHYCok6zec07P2ck2JP+TTkKvsZ5rnN8U0LdifxckUXAZGgq7TqkI5zszCVa4H8XOduOqTKxfy3H3cyGH1cDeORei1LKLKRz3j/SSeAjuuVXAzA37QLxOjTUxju16s4AQM4CrqRZPQ/UvPTJteLpN6s8g7k93c2O5bSY4abgzveYQ+67QS5ZlgypRc8yyXumf0qLmLj+Zz3CA== 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=O0rPDi8hB6EePSD2xZuCP5Xt50pUtf6gtQmZklTMQwo=; b=LcQe2ocSCQa42nuHv98s3fVeXKVwSumq9l8Fx4ixjKIGNWcrd4QvSwE6Y7YDuHTTvkvGhqZfDuAIwIuGtu21W9olqX/r3/xr/pokdXyzkgiGWtCSTSSvOpgiL6Z2Yd2pnXcHpUTUvvWnj+YHEHOyb/JZNEjEZO8dw6aZZn81QBVxudpJLuHd8fCMPBKpcugmbKsFDSxK0bnTHab9uSoOZ4xTR8hxd6doUX0LEKaZgHG/YlueLnvCcgaya8CZWc+pGuC1AmpO+idaho05kGeFXMPfainxAkP84JBfp8CbIj9PZiobTPXe+JhsvLRKP7C3a0b+eIiScwoZ16MpMLMAmw== 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=O0rPDi8hB6EePSD2xZuCP5Xt50pUtf6gtQmZklTMQwo=; b=qgxwT3khl0cHTukB5gYuN1rCaFJSdu/Rw52R3EjXkn1FSUZNPjQnc4AXiFGx8RGkEaKHDFDWqbJr/Qa26B0+VXqQcoL278F0IvXj6Fu3gDFOFIVZsr3zANx7muyCPIZMc6nXIqAVCDk8qrgOnrp+ulffGKCQxCBj/8CZuxc/tq8= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB2932.namprd11.prod.outlook.com (2603:10b6:208:78::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.22; Tue, 28 Jul 2020 10:40:44 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::4d3f:f3e:add7:dfc1%3]) with mapi id 15.20.3216.033; Tue, 28 Jul 2020 10:40:44 +0000 From: "Rob Wilton (rwilton)" To: "netconf@ietf.org" , Mahesh Jethanandani , Kent Watsen Thread-Topic: draft-ietf-netconf-https-notif-04 Thread-Index: AdZkx87sP73bP8UES6qM57jn3MZ13A== Date: Tue, 28 Jul 2020 10:40:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.15.79.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2a3e5caf-729b-4034-41e5-08d832e2aea4 x-ms-traffictypediagnostic: BL0PR11MB2932: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6NiBP3wJurjJWKBJGv11V6ABGC3voMrgsGtKPp14MPsXJeLieGbPevdX8zwrr+0/gfI5v52YI7mwxYMCRiEkWnkef9jqrNRqllO6v6YPG1e4Nvvq9+bMFWTE/aQbvMijVLWHmqjxtuP/60LIYnDqBrHcqDd60t2wFlGgUzyMuc5A3xAikYZkdxonj4IZq40XoFkoKGrL+cZVjfSlJuU7yjhWJVt181J1rSf0JXX27XJ8AE609lQ2f0A1CeHbg/ZS0+txah+CItFhCYwCdJ8o6hRl8s2gUvz1YHMiuaqZ3DSF+dsJwtaAT+xU9KF8Bit9 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; SFTY:; SFS:(4636009)(136003)(396003)(346002)(366004)(39860400002)(376002)(8936002)(83380400001)(186003)(478600001)(33656002)(52536014)(86362001)(5660300002)(71200400001)(7696005)(26005)(2906002)(110136005)(316002)(9686003)(76116006)(66476007)(8676002)(66946007)(64756008)(66556008)(66446008)(55016002)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: +KMzseaVLs2ouaK7CpCEX60PHn+hX8P756oBTvfbW3CI7x/mHvVHOKUZiYC3xCctRz6LdqM6XTsvSrORQ/bpE4JLinWjgJlJExbISDzjPTavu3dp2J0Mx9nsuuPRkCMpXf0V7ZGvUZkIRX/MJ0s30cb6FKeLamZnUnmD7JCpk0yNYDfACImBgeQerwWgUXRBTrW/5tgyhMx8mMTODpLd0vCYRok24rGiqR4QbZZMjj96nU5pGFgTjaP4PonWXzVfTQaFDtfjQNmU6j+D9oJxBrvtQQnh+i/vgpoCU1HhVYon3oF/YfZgY4fV3q39/ltxRIyTYkzll2NjNV2WiviqCoYtWPkDiLhIQeJfJrRThTa77p+q4dgcJUCen9BdpVn9+3a+EjQfCUDxE6P+FbgZ6ZLTBLf5bQ3yk9RyURVMUIuDUyvI6c5OwwnF3OSE9wFWcQniCqQxW/ySfiw+0QYoegHuAIVF6eedxPDuk7RPV7M= 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: 2a3e5caf-729b-4034-41e5-08d832e2aea4 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 10:40:44.6433 (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: L/4ZMp0/jmTk0QKh7hcdXlwmAW9vTIVBdFoxprHSOqdFy/zMkUoW8oHPda1sxW+pHTsuM1KdPDzWONb3J8PtmA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2932 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: [netconf] draft-ietf-netconf-https-notif-04 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, 28 Jul 2020 10:40:52 -0000 Hi Kent, Mahesh, A few quick comments whilst reviewing draft-ietf-netconf-https-notif-04: 1) The example in section 1.5.1 seems to have a single POST request, but mu= ltiple responses (one per notification). Is that correct, or should there = be a single response for a single post request? 2) Section 2.1: Do you need to specify on what path the GET request is made? Is this a con= figured path described in section 4.1? Otherwise, it is not possible that = the receiver could be running a webserver for other purposes? 3) Section 4.1: The tree diagram doesn't contain the path leaf. Possibly a more expanded t= ree diagram might be helpful. Arguably the tcp part could/should be omitte= d. 4) I'm not a big fan of this construct: uses httpc:http-client-stack-grouping { refine "transport/tcp" { // create the logical impossibility of enabling "tcp" // transport if-feature "not httpc:tcp-supported"; I was wondering if it would be better if the base grouping should be split = (perhaps too late for that)? 5) 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."; } What is this URI relative to? 6) reference "RFC 7407: A YANG Data Model for SNMP Configuration."; It seems strange to have a dependency on SNMP configuration, but perhaps th= is is just a historical aberration. Regards, Rob From nobody Tue Jul 28 05:01:45 2020 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 90E373A0BD7 for ; Tue, 28 Jul 2020 05:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.61 X-Spam-Level: X-Spam-Status: No, score=-9.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hvjqMab1; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=LbgmBZE6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibS9iwx-wGYe for ; Tue, 28 Jul 2020 05:01:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49063A0B9B for ; Tue, 28 Jul 2020 05:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26990; q=dns/txt; s=iport; t=1595937689; x=1597147289; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gyC4Wii3t+6YMNQTwdrW/nl+SGHKT7GZ3cU5Je21cb8=; b=hvjqMab1hok/xyOS70CrjMUEX6UHaxESLmz0uhsZwVn1LetLxDEHNdk7 XMcz/wlDpXeqsu7Pxt5PgyKC07b2+3NZWXoNLpW59nGdoR4UEpLRiStEV ipRycflAhXZz2amyvn+A9IZXG28cx/xNnZ9DHoQCbkg6gFF88f8Fvl7RG E=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AwZFqZR3Q5lbHIogJsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGuadiiVbIWcPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoPk1cGcK4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiBQAqEyBf/4oNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBIy9RB28rLS8sCodwA41Xh1iCKo5fglMDVQQHAQEBCQM?= =?us-ascii?q?BARgBCgoCBAEBhAhEAoIeAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcQEBAQM?= =?us-ascii?q?BAQEQGxMBASwLAQQHBAIBCA4DBAEBDhoHAh8GCxQJCAIEDgUIBhSDBYF+TQM?= =?us-ascii?q?OEQ8BDqNXAoE5iGF0gTSDAQEBBYE3Ag5Bgx8NC4IHBwmBOIFTgRqKEBqBQT+?= =?us-ascii?q?BVIJNPoIaQgEBAgEBFYFIFRYRgwuCLZp+mitOCoJfhDWCWIFLjCOFFoJ7gSK?= =?us-ascii?q?IJ5MlnEWCYZILAgQCBAUCDgEBBYFqI4FXcBUaIYJpCUcXAg2OHoNxhRSFQnQ?= =?us-ascii?q?3AgYIAQEDCXyNNiuBCgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,406,1589241600"; d="p7s'?scan'208,217";a="795071151" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jul 2020 12:00:55 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 06SC0tu0008938 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Jul 2020 12:00:55 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 07:00:55 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 08:00:54 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 28 Jul 2020 08:00:54 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XEbQ9jOuJZakQaY21xo5yq0hWh2GguqnCbv6WT8oyvB1gCBD2ZFJ/xrItSdgeRqQEQRhBI81lTVW15HJch6tNAcmn89DA+tkVY6lwZ12KySAKLNqKUWPnMLQNWoYBvOZDZshJ8nH5m2ch2MZxBc83sNP42fyPpe8lZEJN8CCBeYNpz1oKvBwJRhXRSd2KBw11DIMg46EtxTOtrmwXg5yuPlui9xkJZlroAG4+u3bZ79GrC9miyWJrGkEb3vrP4dMbUSSVbnknMKYiXOy4Dm6d9ZP/gmiVD7iMpXTvNmbWDk5jhgAJ4MV6j8mHdzKVaeI+eAB4qLF/puOOYoUDHR6YQ== 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=/5LoLIf2C/aXhtrPAzEz0naCWTktfpKzlZg/w4KtMZ4=; b=oKFPifAc7Qv592/mYHCs8LwzHzZJkI++I44UsQIX401VfPvenlAeyHpM8OU9iP0G4YDsebiTsqa5fytm/UOm0cPr4XS2b490PZCD5tNsFV0eWEN4X49pI4pwhLxiGWdY5JbTyRl0TzefFeaUdxLNL1eO+01dFy0L7levbVIPt/n8PE65gP3qHVAZkGmagAHOoJIalk1X7Q/IqBATQKGIIl6+AnEOZfizLNOcWCCD1wts7QGOZylQK/SyJUt0uh34XbW55DZZQLx5udKivikKkoBap+ri9IsSjNLzQ43WkoQWIlaZQ59kWRX2oB3aVaHjhC8j/Wril5Atcx7NYm9eeQ== 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=/5LoLIf2C/aXhtrPAzEz0naCWTktfpKzlZg/w4KtMZ4=; b=LbgmBZE6MZ54uwiEI4hTqcnFK9DMI8Qcc6FghMWpkYK/X9CAbcuYEhPj5ZJnNyYDroi2iilE1pDkRa2CXYBtp9BYyGrgdSnpTcxCuh8jFDNTxIBB4FAQdQeJLTa4bevWbLdO8+QnxZLkykmEQSJMQ8e4TuwyMPBitvQTNbTVIcA= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB3316.namprd11.prod.outlook.com (2603:10b6:208:68::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Tue, 28 Jul 2020 12:00:53 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::3496:c7b1:6ba3:ace2%5]) with mapi id 15.20.3216.034; Tue, 28 Jul 2020 12:00:53 +0000 From: "Eric Voit (evoit)" To: Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt Thread-Index: AQHWZC0s4rGn4H8SgEeN9NnhYjeTUKkboLwggAE/rOA= Date: Tue, 28 Jul 2020 12:00:53 +0000 Message-ID: References: <159586435098.29591.15728904593699090813@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 849a6a9a-3b84-470a-bd03-08d832ede0e6 x-ms-traffictypediagnostic: BL0PR11MB3316: 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: P2U7hmHtarBF+oWNaKFNGkGDJw3G8zWmEgv/d/4EbmG5mdRxyipBHA/3/R20CfinaBP1CGhNEuPIIw7iEyjQXSWOfDXgSFPupffHiTRjQHdxwGNGOw76Xn3Fifms+E0/o1q/JQYocL7B3UrM811FoO82Bc6fGAI4f2VWEfWYYHMhYg1uoIdHr3gb4asmmn6Ug0No4zdBQ7muB4rwrjsRE1mbSFwPrGVgnc/I4rKf1nFCIUjMrCwEyTW10CCrr/ZJvMQ7ykyxmrviT0mIz8HBaw9kxUZpbAqEMgwA8dZEQDpDU++fLDPswdESB8jZ8/B/rPXqxPr3PuujnziDXDgkQ692SQpA+WZ4pdbC1hGh5i8P4MajSC3oDXsmU2g6rNY6BfLFqqz/UKgmfBmsO6RKNw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(346002)(39860400002)(366004)(52536014)(9686003)(5660300002)(33656002)(478600001)(83380400001)(4326008)(2906002)(71200400001)(8936002)(55016002)(7696005)(166002)(66574015)(966005)(26005)(99936003)(86362001)(6916009)(64756008)(76116006)(66946007)(66616009)(53546011)(8676002)(186003)(6506007)(316002)(66556008)(66446008)(66476007)(9326002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: LJVEcz/g+qz+A7ukh/VozQrcna3FZxHytIvWgy0Thq6xl9cP6jH6My0u7jduHkJswLGnRnhhOaUr+/5aKqOuP22zwu/UMajwbv7HDBRNVsJp5ajwMgA9cGL/oK17XFQfgfdB7vy9l0kHwKPucK/TUAYqdQq1o8nDMlyS2NN6Ffl2fFqjcT+afIlAKcUlFnXoh51SzcCuqLJY5/B1aYQgPc4M54rBw2OP0vD4EfacHJ6gZrImEsRH/eVU9MB42tgKrXGsL00VhAC83Ot7sgB16pHAi7i/1Wf+znS8Tq04YBq9eqW78T9112R0QxSLsA5cXpl92ONy0prR34y3o7ostdjLjfZXy9lXu4DSQAPxoU7Z+XiT2LQ6+dqRA9xIFTOdpCnvFvSYsfdxe6Usbi6+M4xngVT4a7czsVX+SMKJgcSfIYaQO06/kPbn/GSd0siHFZ+cXaH7R06NanbR6NVOHG+V0unIVXoK/giBMGVv014QLpoKNt3xLY5dGNtNpnl7 x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0BB2_01D664B5.3520F9A0" 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: 849a6a9a-3b84-470a-bd03-08d832ede0e6 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 12:00:53.3683 (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: fRZ9VI/q6spIkb80dXXZ0JdcJDnqZQFnJFnvgp7q/Jj6Bf9hdufgoF6cIUYog0p5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3316 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.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, 28 Jul 2020 12:01:42 -0000 ------=_NextPart_000_0BB2_01D664B5.3520F9A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0BB3_01D664B5.3520F9A0" ------=_NextPart_001_0BB3_01D664B5.3520F9A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mahesh, What I was trying to ask during the IETF session was the following: There are many downsides to *not* including the Subscription State Change Notifications, including the DOS attacks listed below. As several people mentioned during the session, the draft isn't clear on which elements of https-notif require SN, and which do not. Additionally, the intro section of https-notif isn't clear here: 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. The first time I understand all of SN isn't mandatory is Section 8.2. If there are mandatory SN elements which are sometimes optional, could you explicitly list these in the draft? Also could you list what the potential downsides of excluding mandatory might be, and when these potential downsides can be safely discounted? Thanks, Eric > -----Original Message----- > From: netconf On Behalf Of Eric Voit (evoit) > Sent: Monday, July 27, 2020 12:53 PM > To: Mahesh Jethanandani ; netconf@ietf.org > Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt > > Hi Mahesh, > > Thanks for updating the text. One question, are you sure you need the > statement: > > 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 started>. > > I am guessing that you mean "Subscription State Change Notifications" here > rather than "Subscribed Notifications". As RFC-8639 Subscription State > Change Notifications are mandatory, is this statement necessary here? > > Perhaps you could add a non-normative appendix which shows the > implications of dropping specific Subscription State Change Notifications If > an implementation desires this simplification? E.g., issues with supporting > replay, issues with understanding what subscription is sending traffic, no > ability to see if the terms of the subscription changed, no awareness of > subscription suspend, no way to signal the end/termination of a > subscription, etc. > > All of these might be absolutely ok in an implementation, but it might be > worth addressing in aggregate in a place which is outside the bounds of the > normative text. > > Eric > > > > -----Original Message----- > > From: netconf < netconf-bounces@ietf.org> On Behalf Of Mahesh > > Jethanandani > > Sent: Monday, July 27, 2020 11:46 AM > > To: netconf@ietf.org > > Subject: Re: [netconf] I-D Action: > > draft-ietf-netconf-https-notif-04.txt > > > > This version of the document addresses comments received from Eric, > > and updates to the ietf-truststore module. > > > > > On Jul 27, 2020, at 8:39 AM, 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 Configured > Subscriptions > > > Authors : Mahesh Jethanandani > > > Kent Watsen > > > Filename : draft-ietf-netconf-https-notif-04.txt > > > Pages : 27 > > > Date : 2020-07-27 > > > > > > Abstract: > > > 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 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-04 > > > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif > > > -0 > > > 4 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-04 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > Mahesh Jethanandani (as co-author) > > mjethanandani@gmail.com > > > > > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_001_0BB3_01D664B5.3520F9A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mahesh,

 

What I = was trying to ask during the IETF session was the = following:

 

There are many downsides to *not* including the = Subscription State Change Notifications, including the DOS attacks = listed below.   As several people mentioned during the = session, the draft isn't clear on which elements of https-notif require = SN, and which do not.  Additionally, the intro section of = https-notif isn't clear here:

     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.

The first time I understand all of SN isn't = mandatory is Section 8.2.

 

If = there are mandatory SN elements which are sometimes optional, could you = explicitly list these in the draft?   Also could you list what = the potential downsides of excluding mandatory might be, and when these = potential downsides can be safely discounted?

 

Thanks,

Eric

 

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

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

> Sent: Monday, July 27, 2020 12:53 PM

> To: Mahesh Jethanandani = <mjethanandani@gmail.com>; netconf@ietf.org

> Subject: Re: [netconf] I-D Action: = draft-ietf-netconf-https-notif-04.txt

> =

> Hi Mahesh,

>

> Thanks for = updating the text.  One question, are you sure you need the

> statement:

> =

> =             &= nbsp;    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 = <subscription-

> started>.

>

> I am guessing = that you mean "Subscription State Change Notifications" = here

> rather than "Subscribed = Notifications".   As RFC-8639 Subscription State

> Change Notifications are mandatory, is this = statement necessary here?

>

> Perhaps you could add a non-normative appendix = which shows the

> implications of dropping = specific Subscription State Change Notifications If

> an implementation desires this = simplification?  E.g., issues with supporting

> replay, issues with understanding what = subscription is sending traffic, no

> = ability to see if the terms of the subscription changed, no awareness = of

> subscription suspend, no way to = signal the end/termination of a

> = subscription, etc.

>

> All of these might be absolutely ok in an = implementation, but it might be

> worth = addressing in aggregate in a place which is outside the bounds of = the

> normative text.

>

> Eric

>

>

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

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

> > = Jethanandani

> > Sent: Monday, July 27, = 2020 11:46 AM

> > To: netconf@ietf.org

> > Subject: Re: [netconf] I-D = Action:

> > = draft-ietf-netconf-https-notif-04.txt

> = >

> > This version of the document = addresses comments received from Eric,

> = > and updates to the ietf-truststore module.

> >

> > > = On Jul 27, 2020, at 8:39 AM, internet-drafts@ietf.org<= /span> 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 Configured

> = Subscriptions

> > = >        = Authors         : Mahesh = Jethanandani

> > = >           &nb= sp;           &nbs= p;  Kent Watsen

> > > =      = Filename        : = draft-ietf-netconf-https-notif-04.txt

> = > >      = Pages           : = 27

> > >      = Date            : = 2020-07-27

> > >

> > > Abstract:

> > >   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 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/ht= ml/draft-ietf-netconf-https-notif-04

> > > https://datatracker.ietf.= org/doc/html/draft-ietf-netconf-https-notif

> > > -0

> = > > 4

> > >

> > > A diff from the previous version is = available at:

> > > https://www.ietf.org/rfcd= iff?url2=3Ddraft-ietf-netconf-https-notif-04

> > >

> > = >

> > > Please note that it may = take a couple of minutes from the time of

> > > submission until the htmlized = version and diff are available at

> > = tools.ietf.org.

> > >

> > > Internet-Drafts are also available = by anonymous FTP at:

> > > ftp://ftp.ietf.org/intern= et-drafts/

> > >

> > >

> > = > _______________________________________________

> > > netconf mailing list

> > > netconf@ietf.org

> > > https://www.ietf.org/mail= man/listinfo/netconf

> = >

> > Mahesh Jethanandani (as = co-author)

> > mjethanandani@gmail.com

> >

> >

> = >

> > = _______________________________________________

> > netconf mailing list

> > netconf@ietf.org

> > https://www.ietf.org/mail= man/listinfo/netconf

------=_NextPart_001_0BB3_01D664B5.3520F9A0-- ------=_NextPart_000_0BB2_01D664B5.3520F9A0 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNzI4MTIwMDQ5WjAjBgkqhkiG 9w0BCQQxFgQU5ceJuDbZtlArbnk2d7fYYsMfSnowSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQA1md+TncF74ukBJAZu/6pRK+lg04j7MFc8ooItwGy7jUgbRbUHthzH/x+mEceL0H5P ru4BUW2RwjUyQcQCg0ogmqRtM1DcShlFkLDOXNXcUgI8DojAYQpsd/3dqPqB2lZDJNSNHtAb8fZX IwtoXrntBbNVn0fU7ns2x7kXlYwpjajDhFSP0mF3/UUHgwcqQcfhAggLfegvKP/kstjSIlkT+B6e csNU9YPdq+xVQb9A8FJ1J9tLBO1kK6Sled+YB0LAEkz8FRbE8cwkQmsHzTzCGgmgEwsP3dhO6tHo pWux8JJucnmvfKRsRjzmwa7LZjsUrxQXA0QV4Tkh3BdR4toVAAAAAAAA ------=_NextPart_000_0BB2_01D664B5.3520F9A0-- From nobody Tue Jul 28 13:52:34 2020 Return-Path: <010001739732b207-d1f05f7d-170d-436e-8b94-2576a3bb5365-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 BFFD93A0C34 for ; Tue, 28 Jul 2020 13:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CniX8JA3LQH for ; Tue, 28 Jul 2020 13:52:30 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3C13A0C2E for ; Tue, 28 Jul 2020 13:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1595969549; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=RHhcTEIhSxXbeqITC6uIpe7nV3Mvp6cS+TSAaqoRd8s=; b=R+NatMALw+viL9CXY4zpyL1phDzkRatJhFdiK3i7bAVN803C697Qv+xTdki8JO6R sV6LyFcI4xSNi2eWkDdVE0kIBSyv9LaVd8wGUScyH8RLzgc9Uw7HJWHjGxRRSgO9Q35 uktI5ldyQJlmq4FczoOP6SZis5RA5Hji3hqDZQQA= From: Kent Watsen Message-ID: <010001739732b207-d1f05f7d-170d-436e-8b94-2576a3bb5365-000000@us-east-1.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9A78963C-04AD-4732-A0AF-CA32F7C9094C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 28 Jul 2020 20:52:28 +0000 In-Reply-To: Cc: Mahesh Jethanandani , "netconf@ietf.org" To: "Eric Voit (evoit)" References: <159586435098.29591.15728904593699090813@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.28-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.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, 28 Jul 2020 20:52:32 -0000 --Apple-Mail=_9A78963C-04AD-4732-A0AF-CA32F7C9094C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, > There are many downsides to *not* including the Subscription State = Change Notifications, including the DOS attacks listed below. As = several people mentioned during the session, the draft isn't clear on = which elements of https-notif require SN, and which do not.=20 Disagree, as it=E2=80=99s obvious that *implementing* the modules = requires SN, while not implementing them doesn=E2=80=99t. But, per your = comment below, it would be good to float this point towards the = beginning. > Additionally, the intro section of https-notif isn't clear here:=20 > 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. > The first time I understand all of SN isn't mandatory is Section 8.2. Ack, see above. > If there are mandatory SN elements which are sometimes optional, could = you explicitly list these in the draft? This draft does not =E2=80=9Cupdate=E2=80=9D RFC 8639. No change to = RFC8639 normative text exists in the draft. > Also could you list what the potential downsides of excluding = mandatory might be, and when these potential downsides can be safely = discounted? An enumerated list would be overkill. A passing comment is sufficient. = The following seems about right: =20 =E2=80=9CUsing the 'https-notif=E2=80=99 transport outside of RFC 8639 = MAY be desirable in cases where a simple notification-delivery mechanism = is sufficient for the intended use. When advanced delivery features are = needed (e.g., replay, QoS), RFC 8639 is SHOULD be used.=E2=80=9D K. --Apple-Mail=_9A78963C-04AD-4732-A0AF-CA32F7C9094C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

There are = many downsides to *not* including the Subscription State Change = Notifications, including the DOS attacks listed below.   As = several people mentioned during the session, the draft isn't clear on = which elements of https-notif require SN, and which do not.  =

Disagree, = as it=E2=80=99s obvious that *implementing* the modules requires SN, = while not implementing them doesn=E2=80=99t.  But, per your comment = below, it would be good to float this point towards the = beginning.


Additionally, the intro = section of https-notif isn't clear here: 
     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.
The first time I understand all of SN isn't mandatory is = Section 8.2.

Ack, see above.


If there are mandatory SN elements = which are sometimes optional, could you explicitly list these in the = draft?

This = draft does not =E2=80=9Cupdate=E2=80=9D RFC 8639.  No change to = RFC8639 normative text exists in the draft.


Also could you list what the = potential downsides of excluding mandatory might be, and when these = potential downsides can be safely = discounted?

An enumerated list would be overkill.  A = passing comment is sufficient.  The following seems about right: =  

  = =E2=80=9CUsing the 'https-notif=E2=80=99 transport outside of RFC = 8639 MAY be desirable in cases where a simple = notification-delivery mechanism is sufficient for the intended use. =  When advanced delivery features are needed (e.g., replay, QoS), = RFC 8639 is SHOULD be used.=E2=80=9D


K.



= --Apple-Mail=_9A78963C-04AD-4732-A0AF-CA32F7C9094C-- From nobody Tue Jul 28 15:19:34 2020 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 2C02C3A07F0 for ; Tue, 28 Jul 2020 15:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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_H2=-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 (1024-bit key) header.d=futurewei.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 UrtvV264RaKj for ; Tue, 28 Jul 2020 15:19:30 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2112.outbound.protection.outlook.com [40.107.93.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E873A081F for ; Tue, 28 Jul 2020 15:19:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T5sDxf9vtGwH0U72qJK2B6VVn/BnvdtZALARyAihna6SAt+AZBtCVq9SAIUqDCfci6+34yf9noRyDuk8jB2VMAHErXpaTJrW/UqqFxRMU1+daosXy2Wv/YOfjLao4NdAhbC7r6wuLI6UlJUOv6JhLM9toRHsbOoEGFBqljNraPGRLCdAY+hAnEciNGuChbYGjhpSMfr//RUAzxn/GamoExsMc3trJzA15t0IlTseMaXIeHHi+qNlAqkKkhCr8Jzci/f5Z2qn0Po99R9BCIQoZAwQMav/NO/RlwQP9LMJgOU2DWkpmCZPRurRzs/JeO+uDAcR7XkqJkN0mXlpcAthqg== 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=EiMJjnjb4TYYQRZohAPkJ9+WFieTeKOWreO+tFxrxJ4=; b=PKNODhap6x6pKH/oUwLebyLBV+dVDOQfaGJ4VHRCtioGfsHUeLsAVOc9VsBg2QDeo6JYc4tkC0Xyu0qfIE/y6ymBmzEOZE0ruMDFQ2pu49jL8raX+yX7wJ9aBgVDnC2kX/BPoiwYJXrXzjGDX9Xm2Pi1jx8ai3idgZrgU5Ik8WPoKXU5mzEycHGa3+kINhAwrGnNV6yoJPng9iMIobKzM1Jm9EBkCy+uJRcPWQ8bnayM26KF8tekbbwF7esX+Y0D9wgYpq8NurYfarwcuvGCLCE4WGOipDErMKFlrKPXKg5tJBkpWg74lN5sS2r6uAKdETBkG70ZEEdsMWJ+BaWiFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EiMJjnjb4TYYQRZohAPkJ9+WFieTeKOWreO+tFxrxJ4=; b=QKCjf3WqYC9fveVGoCp5m4P0P2Vs4smP3Of3YP6o/Q/o+Ym5SpQjFupMZ8/NlAgrjtVy8SLMgMgFVaI7vCpW92scfOXAj+A3V5jR0nXEfbQa+QxamXwX0gqDWO30Q9Ji5WykZSxNdP6LLjqfyV+jHCxi+T4G0Dg0xzs6D1UPO9Y= Received: from BY5PR13MB3793.namprd13.prod.outlook.com (2603:10b6:a03:226::15) by BYAPR13MB2454.namprd13.prod.outlook.com (2603:10b6:a02:cd::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Tue, 28 Jul 2020 22:19:24 +0000 Received: from BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::2447:df10:38ac:b1d7]) by BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::2447:df10:38ac:b1d7%9]) with mapi id 15.20.3239.016; Tue, 28 Jul 2020 22:19:24 +0000 From: Alexander Clemm To: Kent Watsen , "Eric Voit (evoit)" CC: "netconf@ietf.org" Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt Thread-Index: AQHWZCw/oCd5fHONJ0Cydfo2dr7zuakbkZmAgAASv4CAAUDLgIAAlIYAgAAEHHA= Date: Tue, 28 Jul 2020 22:19:23 +0000 Message-ID: References: <159586435098.29591.15728904593699090813@ietfa.amsl.com> <010001739732b207-d1f05f7d-170d-436e-8b94-2576a3bb5365-000000@us-east-1.amazonses.com> In-Reply-To: <010001739732b207-d1f05f7d-170d-436e-8b94-2576a3bb5365-000000@us-east-1.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=futurewei.com; x-originating-ip: [73.189.160.186] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b9593bf6-262e-46f3-fb5f-08d833444881 x-ms-traffictypediagnostic: BYAPR13MB2454: 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: j3ezCJgH54Rv4IErHtNTJur6SAco2UwZPicgXrPeS5Aug93N5PrdWjpjhiniIR1D8sfmAyxsThyX0tSwGmxremuN+rpXbS4LERtDF4mxPzYCuRvZ6iSSp2SWW5qM0GyWwkQEfYWBVQySMJk7LiNSpzD9XsqNyFEMS0tGQ3SVec2UC41ILZdFIkHrO0eP49R1Fqb8vPaJhUI7C8ZYzFMtpFXhnzTY464oM+s9suNTyE5KYtqvi1ARL8U4qg8IE0F+kkflBKfA4Hm7JatVMizGJKuqwYUUpxx+zV3CMeaivXGegwgNUTlHb//thGcZ79W7 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3793.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(396003)(346002)(136003)(39850400004)(9686003)(33656002)(71200400001)(83380400001)(86362001)(186003)(110136005)(55016002)(64756008)(8676002)(2906002)(316002)(66476007)(66556008)(66446008)(26005)(66946007)(8936002)(53546011)(508600001)(6506007)(9326002)(76116006)(4326008)(52536014)(7696005)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: RljvP9gyEwjKOthkUjzZhkOlWXT8vpwbVkNiz0m3cHN1XPqnRKnWbCxZ0cCUcoGMH4PWokOucUaNb9e6Tncuw2iNNhTKI4YMWnlB2MV7efw6Q939Bn4zI7008N69EPZeGFYck6r8CBxaYKJc04/f035CpS0Jt0gSjMKeeQ8Va/b72mg9pdkOqfU78nfNX7zdRcbiLLlwwR4xvaBPucVQj18wXcPoCpewnFQpWyxn9Ardse+4W3LMVSdLdLqSx3iRiLGbbAcyLxIv39hOEh4+5k5nrF7bofk0znuFTBYpluhf3pQnGONh8XsgZmGag2eJLPfL31eeI/FJrcIUwfB+IGlYajtG1Sw1L0ENSkRxs+OfIrYNIAAgXHF4vcbG/ZbKf2x8xUy9egcAR9ZSCiPs8y7hFmNYTF5rN6vM0Vg1xUy0+6EMujgp0AvkEtQK7HKVuzQVSN+a6mnzpTz7H7Mc8Naunpi0hXeugpxHFvVPDnMLBeLKKHbtwVMDGx5colwDr6WY//QqEwL6LgPlg1Rks1vJ1yMj7Xx4Yoc7p4vYVLMM+92StB5LIEhHj1kFZrc6n7TP2tMG0ekGaDSNq9s5WPN6ID+j3UZgdDDnfbhB4bzyGklONTGaTyxPiJHP/l48Lv9ekU3gRr/AV/CO7i5u6Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB3793085FF4C52CD4B228115CDB730BY5PR13MB3793namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3793.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9593bf6-262e-46f3-fb5f-08d833444881 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 22:19:23.8991 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GStSwzMrVwfkdV65IsF+wn5/jkOlgpojDn8XsZuGPnDEL9g9XuK7R1HE7QT4BG92L2wPoueGG2jZqJyGoq6THA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2454 Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.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, 28 Jul 2020 22:19:32 -0000 --_000_BY5PR13MB3793085FF4C52CD4B228115CDB730BY5PR13MB3793namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCkkgYW0gZ2V0dGluZyBhIGJpdCBjb25mdXNlZCBoZXJlLiAgQXJlIHlvdSBzYXlp bmcgdGhhdCB5b3Ugd291bGQgb25seSBuZWVkIHRvIGltcGxlbWVudCB0aGUgYXVnbWVudGF0aW9u cywgbm90IHRoZSBzdWJzY3JpcHRpb25zIG1vZGVsIGJlaW5nIGF1Z21lbnRlZD8gIFN1YnNjcmlw dGlvbiBTdGF0ZSBDaGFuZ2UgTm90aWZpY2F0aW9ucyBhcmUgYW4gaW50ZWdyYWwgcGFydCBvZiB0 aGUgd2hvbGUgc3Vic2NyaXB0aW9uIGNvbmNlcHQuDQpBbnl3YXksIEkgYWdyZWUgdGhpcyBwb2lu dCBuZWVkcyBjbGFyaWZpY2F0aW9uLg0KLS0tIEFsZXgNCg0KRnJvbTogbmV0Y29uZiA8bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgS2VudCBXYXRzZW4NClNlbnQ6IFR1ZXNk YXksIEp1bHkgMjgsIDIwMjAgMTo1MiBQTQ0KVG86IEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdD00 MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW25ldGNvbmZdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3Rp Zi0wNC50eHQNCg0KSGkgRXJpYywNCg0KVGhlcmUgYXJlIG1hbnkgZG93bnNpZGVzIHRvICpub3Qq IGluY2x1ZGluZyB0aGUgU3Vic2NyaXB0aW9uIFN0YXRlIENoYW5nZSBOb3RpZmljYXRpb25zLCBp bmNsdWRpbmcgdGhlIERPUyBhdHRhY2tzIGxpc3RlZCBiZWxvdy4gICBBcyBzZXZlcmFsIHBlb3Bs ZSBtZW50aW9uZWQgZHVyaW5nIHRoZSBzZXNzaW9uLCB0aGUgZHJhZnQgaXNuJ3QgY2xlYXIgb24g d2hpY2ggZWxlbWVudHMgb2YgaHR0cHMtbm90aWYgcmVxdWlyZSBTTiwgYW5kIHdoaWNoIGRvIG5v dC4NCg0KRGlzYWdyZWUsIGFzIGl04oCZcyBvYnZpb3VzIHRoYXQgKmltcGxlbWVudGluZyogdGhl IG1vZHVsZXMgcmVxdWlyZXMgU04sIHdoaWxlIG5vdCBpbXBsZW1lbnRpbmcgdGhlbSBkb2VzbuKA mXQuICBCdXQsIHBlciB5b3VyIGNvbW1lbnQgYmVsb3csIGl0IHdvdWxkIGJlIGdvb2QgdG8gZmxv YXQgdGhpcyBwb2ludCB0b3dhcmRzIHRoZSBiZWdpbm5pbmcuDQoNCg0KDQpBZGRpdGlvbmFsbHks IHRoZSBpbnRybyBzZWN0aW9uIG9mIGh0dHBzLW5vdGlmIGlzbid0IGNsZWFyIGhlcmU6DQogICAg IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0d28gWUFORyAxLjEgW1JGQzc5NTBdIGRhdGENCiAgICBt b2R1bGVzLCBvbmUgZm9yIGF1Z21lbnRpbmcgdGhlIFN1YnNjcmlwdGlvbiB0byBZQU5HIE5vdGlm aWNhdGlvbnMNCiAgICAgW1JGQzg2MzldIHRvIGFkZCBhIHRyYW5zcG9ydCB0eXBlLCBhbmQgYW5v dGhlciBmb3IgY29uZmlndXJpbmcgYW5kDQogICAgbWFuYWdpbmcgSFRUUFMgYmFzZWQgcmVjZWl2 ZXJzIGZvciB0aGUgbm90aWZpY2F0aW9ucy4NClRoZSBmaXJzdCB0aW1lIEkgdW5kZXJzdGFuZCBh bGwgb2YgU04gaXNuJ3QgbWFuZGF0b3J5IGlzIFNlY3Rpb24gOC4yLg0KDQpBY2ssIHNlZSBhYm92 ZS4NCg0KDQoNCklmIHRoZXJlIGFyZSBtYW5kYXRvcnkgU04gZWxlbWVudHMgd2hpY2ggYXJlIHNv bWV0aW1lcyBvcHRpb25hbCwgY291bGQgeW91IGV4cGxpY2l0bHkgbGlzdCB0aGVzZSBpbiB0aGUg ZHJhZnQ/DQoNClRoaXMgZHJhZnQgZG9lcyBub3Qg4oCcdXBkYXRl4oCdIFJGQyA4NjM5LiAgTm8g Y2hhbmdlIHRvIFJGQzg2Mzkgbm9ybWF0aXZlIHRleHQgZXhpc3RzIGluIHRoZSBkcmFmdC4NCg0K DQoNCkFsc28gY291bGQgeW91IGxpc3Qgd2hhdCB0aGUgcG90ZW50aWFsIGRvd25zaWRlcyBvZiBl eGNsdWRpbmcgbWFuZGF0b3J5IG1pZ2h0IGJlLCBhbmQgd2hlbiB0aGVzZSBwb3RlbnRpYWwgZG93 bnNpZGVzIGNhbiBiZSBzYWZlbHkgZGlzY291bnRlZD8NCg0KQW4gZW51bWVyYXRlZCBsaXN0IHdv dWxkIGJlIG92ZXJraWxsLiAgQSBwYXNzaW5nIGNvbW1lbnQgaXMgc3VmZmljaWVudC4gIFRoZSBm b2xsb3dpbmcgc2VlbXMgYWJvdXQgcmlnaHQ6DQoNCiAg4oCcVXNpbmcgdGhlICdodHRwcy1ub3Rp ZuKAmSB0cmFuc3BvcnQgb3V0c2lkZSBvZiBSRkMgODYzOSBNQVkgYmUgZGVzaXJhYmxlIGluIGNh c2VzIHdoZXJlIGEgc2ltcGxlIG5vdGlmaWNhdGlvbi1kZWxpdmVyeSBtZWNoYW5pc20gaXMgc3Vm ZmljaWVudCBmb3IgdGhlIGludGVuZGVkIHVzZS4gIFdoZW4gYWR2YW5jZWQgZGVsaXZlcnkgZmVh dHVyZXMgYXJlIG5lZWRlZCAoZS5nLiwgcmVwbGF5LCBRb1MpLCBSRkMgODYzOSBpcyBTSE9VTEQg YmUgdXNlZC7igJ0NCg0KDQoNCg0KSy4NCg0KDQoNCg0K --_000_BY5PR13MB3793085FF4C52CD4B228115CDB730BY5PR13MB3793namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgS2VudCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgYW0gZ2V0dGluZyBhIGJpdCBjb25mdXNlZCBoZXJlLiZuYnNwOyBBcmUg eW91IHNheWluZyB0aGF0IHlvdSB3b3VsZCBvbmx5IG5lZWQgdG8gaW1wbGVtZW50IHRoZSBhdWdt ZW50YXRpb25zLCBub3QgdGhlIHN1YnNjcmlwdGlvbnMgbW9kZWwgYmVpbmcgYXVnbWVudGVkPyZu YnNwOyBTdWJzY3JpcHRpb24gU3RhdGUgQ2hhbmdlIE5vdGlmaWNhdGlvbnMgYXJlIGFuIGludGVn cmFsIHBhcnQgb2YgdGhlIHdob2xlIHN1YnNjcmlwdGlvbg0KIGNvbmNlcHQuJm5ic3A7IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW55d2F5LCBJIGFncmVlIHRoaXMgcG9p bnQgbmVlZHMgY2xhcmlmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi0tLSBBbGV4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IG5ldGNv bmYgJmx0O25ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mDQo8L2I+ S2VudCBXYXRzZW48YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAyOCwgMjAyMCAxOjUy IFBNPGJyPg0KPGI+VG86PC9iPiBFcmljIFZvaXQgKGV2b2l0KSAmbHQ7ZXZvaXQ9NDBjaXNjby5j b21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBuZXRjb25mQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1u ZXRjb25mLWh0dHBzLW5vdGlmLTA0LnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGkgRXJpYyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBtYW55IGRvd25z aWRlcyB0byAqbm90KiBpbmNsdWRpbmcgdGhlIFN1YnNjcmlwdGlvbiBTdGF0ZSBDaGFuZ2UgTm90 aWZpY2F0aW9ucywgaW5jbHVkaW5nIHRoZSBET1MgYXR0YWNrcyBsaXN0ZWQgYmVsb3cuICZuYnNw OyZuYnNwO0FzIHNldmVyYWwgcGVvcGxlIG1lbnRpb25lZCBkdXJpbmcgdGhlIHNlc3Npb24sIHRo ZSBkcmFmdCBpc24ndCBjbGVhciBvbiB3aGljaCBlbGVtZW50cyBvZiBodHRwcy1ub3RpZiByZXF1 aXJlDQogU04sIGFuZCB3aGljaCBkbyBub3QuJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRp c2FncmVlLCBhcyBpdOKAmXMgb2J2aW91cyB0aGF0ICppbXBsZW1lbnRpbmcqIHRoZSBtb2R1bGVz IHJlcXVpcmVzIFNOLCB3aGlsZSBub3QgaW1wbGVtZW50aW5nIHRoZW0gZG9lc27igJl0LiAmbmJz cDtCdXQsIHBlciB5b3VyIGNvbW1lbnQgYmVsb3csIGl0IHdvdWxkIGJlIGdvb2QgdG8gZmxvYXQg dGhpcyBwb2ludCB0b3dhcmRzIHRoZSBiZWdpbm5pbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRkaXRpb25hbGx5LCB0aGUgaW50cm8g c2VjdGlvbiBvZiBodHRwcy1ub3RpZiBpc24ndCBjbGVhciBoZXJlOjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOEZBQURDIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGlzIGRvY3VtZW50IGRlZmluZXMgdHdvIFlB TkcgMS4xIFtSRkM3OTUwXSBkYXRhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4RkFBREMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO21vZHVsZXMsIG9uZSBmb3IgYXVnbWVudGluZyB0aGUgU3Vic2Ny aXB0aW9uIHRvIFlBTkcgTm90aWZpY2F0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOEZBQURD Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7W1JGQzg2MzldIHRvIGFkZCBhIHRyYW5zcG9ydCB0 eXBlLCBhbmQgYW5vdGhlciBmb3IgY29uZmlndXJpbmcgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiM4RkFBREMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO21hbmFnaW5nIEhUVFBTIGJhc2VkIHJl Y2VpdmVycyBmb3IgdGhlIG5vdGlmaWNhdGlvbnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGZpcnN0IHRpbWUgSSB1bmRlcnN0 YW5kIGFsbCBvZiBTTiBpc24ndCBtYW5kYXRvcnkgaXMgU2VjdGlvbiA4LjIuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QWNrLCBzZWUgYWJvdmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JZiB0aGVyZSBhcmUgbWFuZGF0b3J5IFNOIGVsZW1lbnRzIHdoaWNo IGFyZSBzb21ldGltZXMgb3B0aW9uYWwsIGNvdWxkIHlvdSBleHBsaWNpdGx5IGxpc3QgdGhlc2Ug aW4gdGhlIGRyYWZ0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRyYWZ0IGRvZXMgbm90IOKAnHVwZGF0ZeKA nSBSRkMgODYzOS4gJm5ic3A7Tm8gY2hhbmdlIHRvIFJGQzg2Mzkgbm9ybWF0aXZlIHRleHQgZXhp c3RzIGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFsc28gY291bGQgeW91IGxpc3Qgd2hhdCB0aGUgcG90ZW50aWFsIGRvd25zaWRl cyBvZiBleGNsdWRpbmcgbWFuZGF0b3J5IG1pZ2h0IGJlLCBhbmQgd2hlbiB0aGVzZSBwb3RlbnRp YWwgZG93bnNpZGVzIGNhbiBiZSBzYWZlbHkgZGlzY291bnRlZD88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW4gZW51 bWVyYXRlZCBsaXN0IHdvdWxkIGJlIG92ZXJraWxsLiAmbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPkEgcGFzc2luZyBjb21tZW50IGlzIHN1ZmZpY2llbnQuJm5ic3A7IFRoZSBmb2xsb3dp bmcgc2VlbXMgYWJvdXQgcmlnaHQ6ICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsg4oCcVXNpbmcmbmJzcDt0aGUgJ2h0dHBzLW5vdGlm4oCZIHRyYW5zcG9ydCBvdXRz aWRlIG9mIFJGQyA4NjM5IE1BWSBiZSBkZXNpcmFibGUgaW4gY2FzZXMgd2hlcmUgYSBzaW1wbGUg bm90aWZpY2F0aW9uLWRlbGl2ZXJ5Jm5ic3A7bWVjaGFuaXNtIGlzIHN1ZmZpY2llbnQgZm9yIHRo ZSBpbnRlbmRlZCB1c2UuICZuYnNwO1doZW4mbmJzcDthZHZhbmNlZCBkZWxpdmVyeSBmZWF0dXJl cyBhcmUgbmVlZGVkDQogKGUuZy4sIHJlcGxheSwgUW9TKSwgUkZDIDg2MzkgaXMgU0hPVUxEIGJl IHVzZWQu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Sy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_BY5PR13MB3793085FF4C52CD4B228115CDB730BY5PR13MB3793namp_-- From nobody Tue Jul 28 15:33:21 2020 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 941B23A09DB for ; Tue, 28 Jul 2020 15:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 VW60zrP3VGvi for ; Tue, 28 Jul 2020 15:33:17 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 B0B1A3A09CF for ; Tue, 28 Jul 2020 15:33:17 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id u185so11843041pfu.1 for ; Tue, 28 Jul 2020 15:33:17 -0700 (PDT) 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=GtnUF6NXvbg1ij+CVoes+3BR2p8Bxy8H9obVbV5l+04=; b=Lg2md1K6H/5QG/lbcCDcEuAVglswOM4bnP4abRKG4yqPZVQa1G2sSGGN63rK+gRaR0 4jN8229xgKyqYhZcXpon3JlpSyhvCyBZZkiQWPzCR5b1tjMIBEi+SGNVaznRSOGnlbVB tgD+tj8t4+uvnxgFxeoknor0r19hE2wqBq62IrBSX7TXEW6bHrGZd+GleAdURCTzUWkZ 5fFfBMD6d2P0j4RxjyXBRY9dLHpqVxj3Zcg9onKMTFusMNAoT03vzVLdCbVcjSiqn/6x fifvXPJRB2WhVaytdkBsetMgpY1xOZYiUzDtrh7OIZdIHBDTEU2q54gS0GLCys6l6zpK Iyvw== 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=GtnUF6NXvbg1ij+CVoes+3BR2p8Bxy8H9obVbV5l+04=; b=ZMRBC11219VEoItOQb+nqOndEOC+k/ESSNzKky36Uy5TfBJdarbuOyqwjmorz6N+ls Y/ZffBYuB5tBkQZp/kuy4B0ibjsTBNVgfC75EQftSxMKQDUg8DQ3pSyoa7pWZOfezMQw IJQQUyAGHKpnNC2QID1LakSrA5+AK1pUjJE8NQ1ihbU8NcbMQS72+8L9TWFPLrJA2Rhk CB3P8Sxz7UlpdRPrpoRQYsuVjGpAhjeSJEbqkS3EHCez75EQjzsqmMAz2Lg0c4z8Dmca 5/XNgYosQ7pmlRcHQlFYw4foXZh8mwrhgOmcxdl91yBBLy+bxqxhyDJxPg47kdyLunjC naZA== X-Gm-Message-State: AOAM532E4pDHQBwPkeuSgBVNWSG5YpBEL4dofNNr+XOlztsAV54h5tBg aPjDxVTmT12+2CgDkzbEKnk= X-Google-Smtp-Source: ABdhPJxCeScSANel7mMr9wAE4QZuADXlE23jXyfMnv27fGyiiXr8SOXIAM8cb+cuMXOrnGZslAU+zw== X-Received: by 2002:a63:441c:: with SMTP id r28mr26611290pga.372.1595975597070; Tue, 28 Jul 2020 15:33:17 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:9c44:e9ff:18d8:c86c? ([2601:647:5600:5020:9c44:e9ff:18d8:c86c]) by smtp.gmail.com with ESMTPSA id w71sm92360pfd.6.2020.07.28.15.33.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 15:33:16 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A65FE228-B5C0-4A04-B8C8-4427CB5E23E5" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\)) Date: Tue, 28 Jul 2020 15:33:14 -0700 In-Reply-To: Cc: Kent Watsen , "Eric Voit (evoit)" , "netconf@ietf.org" To: Alexander Clemm References: <159586435098.29591.15728904593699090813@ietfa.amsl.com> <010001739732b207-d1f05f7d-170d-436e-8b94-2576a3bb5365-000000@us-east-1.amazonses.com> X-Mailer: Apple Mail (2.3445.9.6) Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.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, 28 Jul 2020 22:33:20 -0000 --Apple-Mail=_A65FE228-B5C0-4A04-B8C8-4427CB5E23E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alex, If the implementation calls for a method by which a receiver wants to = subscribe to particular notifications, by all means you need to = implement SN. However, if all you need to implement is a channel by = which notifications can be send from the publisher to the receiver, = however that channel is set up, why would you need to implement SN? Subscription State Change Notification is central to the concept of = being able to subscribe to events. It is not central to how = notifications are sent. M > On Jul 28, 2020, at 3:19 PM, Alexander Clemm = wrote: >=20 > Hi Kent, > I am getting a bit confused here. Are you saying that you would only = need to implement the augmentations, not the subscriptions model being = augmented? Subscription State Change Notifications are an integral part = of the whole subscription concept. =20 > Anyway, I agree this point needs clarification. > --- Alex > =20 > From: netconf > On Behalf Of Kent Watsen > Sent: Tuesday, July 28, 2020 1:52 PM > To: Eric Voit (evoit) > > Cc: netconf@ietf.org > Subject: Re: [netconf] I-D Action: = draft-ietf-netconf-https-notif-04.txt > =20 > Hi Eric, > =20 > There are many downsides to *not* including the Subscription State = Change Notifications, including the DOS attacks listed below. As = several people mentioned during the session, the draft isn't clear on = which elements of https-notif require SN, and which do not. =20 > =20 > Disagree, as it=E2=80=99s obvious that *implementing* the modules = requires SN, while not implementing them doesn=E2=80=99t. But, per your = comment below, it would be good to float this point towards the = beginning. > =20 >=20 >=20 > Additionally, the intro section of https-notif isn't clear here:=20 > 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. > The first time I understand all of SN isn't mandatory is Section 8.2. > =20 > Ack, see above. > =20 >=20 >=20 > If there are mandatory SN elements which are sometimes optional, could = you explicitly list these in the draft? > =20 > This draft does not =E2=80=9Cupdate=E2=80=9D RFC 8639. No change to = RFC8639 normative text exists in the draft. > =20 >=20 >=20 > Also could you list what the potential downsides of excluding = mandatory might be, and when these potential downsides can be safely = discounted? > =20 > An enumerated list would be overkill. A passing comment is = sufficient. The following seems about right: =20 > =20 > =E2=80=9CUsing the 'https-notif=E2=80=99 transport outside of RFC = 8639 MAY be desirable in cases where a simple notification-delivery = mechanism is sufficient for the intended use. When advanced delivery = features are needed (e.g., replay, QoS), RFC 8639 is SHOULD be used.=E2=80= =9D >=20 >=20 >=20 >=20 > K. >=20 >=20 > =20 > =20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = --Apple-Mail=_A65FE228-B5C0-4A04-B8C8-4427CB5E23E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Alex,

If the = implementation calls for a method by which a receiver wants to subscribe = to particular notifications, by all means you need to implement SN. = However, if all you need to implement is a channel by which = notifications can be send from the publisher to the receiver, however = that channel is set up, why would you need to implement SN?

Subscription State = Change Notification is central to the concept of being able to subscribe = to events. It is not central to how notifications are sent.

M

On Jul = 28, 2020, at 3:19 PM, Alexander Clemm <alex@futurewei.com> = wrote:

Hi = Kent,
I am = getting a bit confused here.  Are you saying that you would only = need to implement the augmentations, not the subscriptions model being = augmented?  Subscription State Change Notifications are an integral = part of the whole subscription concept.  
Anyway, I = agree this point needs clarification.
--- Alex
 
From: netconf <netconf-bounces@ietf.org> On Behalf = Of Kent Watsen
Sent: Tuesday, July 28, 2020 1:52 = PM
To: Eric Voit (evoit) <evoit=3D40cisco.com@dmarc.ietf.org>
Cc: netconf@ietf.org
Subject: Re: [netconf] I-D Action: = draft-ietf-netconf-https-notif-04.txt
 
Hi Eric,
 
There are many downsides to *not* including the Subscription = State Change Notifications, including the DOS attacks listed below. =   As several people mentioned during the session, the draft = isn't clear on which elements of https-notif require SN, and which do = not.  
 
Disagree, as it=E2=80=99s obvious that *implementing* the = modules requires SN, while not implementing them doesn=E2=80=99t. =  But, per your comment below, it would be good to float this point = towards the beginning.
 


Additionally, the intro section of = https-notif isn't clear here: 
     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.
The first time I understand all of SN isn't mandatory is = Section 8.2.
 
Ack, see above.
 


If there are mandatory SN elements which are sometimes = optional, could you explicitly list these in the draft?
 
This draft does not =E2=80=9Cupdate=E2=80=9D RFC 8639. =  No change to RFC8639 normative text exists in the draft.
 


Also could you list what the potential downsides of excluding = mandatory might be, and when these potential downsides can be safely = discounted?
 
An enumerated list would be overkill.  A passing comment is sufficient.  The following seems = about right:  
 
  =E2=80=9CUsing the = 'https-notif=E2=80=99 transport outside of RFC 8639 MAY be desirable in = cases where a simple notification-delivery mechanism is sufficient = for the intended use.  When advanced delivery features are = needed (e.g., replay, QoS), RFC 8639 is SHOULD be used.=E2=80=9D




K.


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

= --Apple-Mail=_A65FE228-B5C0-4A04-B8C8-4427CB5E23E5-- From nobody Tue Jul 28 15:35:35 2020 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 802713A087D for ; Tue, 28 Jul 2020 15:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=futurewei.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 hbxuT2USjeUM for ; Tue, 28 Jul 2020 15:35:31 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2104.outbound.protection.outlook.com [40.107.236.104]) (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 3D77F3A09DA for ; Tue, 28 Jul 2020 15:35:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MVXGRqPxKeUyg+1X88U5/k1NLXCoUSomE0hXAY2g3edOB2el/s0Ug9L8aJwrqMdLu61xD6ZnLDKBR7E57PU1I8n3SLpYBQUq8fuxw2cpQuAGC8JMF18SVPNJ0trxmXE4OevSUOsfHRNYNDQ1gnXjk/+6dD4KsOxB3toDmSDKJsltE496cu473C9/Q3lHaVkJYLHvA2Kt+huk9ccsjz55jc8Sgwc/tN+eOvl4F7PAEyBOjldBpVOMhDTP3YQuxOWB1KkI8Q8MS3f12S6QkkSDMQOXHCumBstVYlYXF5zovk/gFi6aSIfz9/bAksDLFOaAR+lxFBUHRwovzv0MeUG0sg== 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=J1jZBjAbZVTCCGK6mkl1JKVfT0n5h7mHyqeeqepbKyk=; b=LzAaGPBCQnqpdhhEpaTqC1naHtxKiGIKheGGUcNFZy/Slx+nQlNxnQRetJyayXdHMyHIwsULcjf8pp7zmHiiAFXZy842ybufJROYTC3d93w/WqLFGiOxLyy7fRGh8sg96VJrcAPGWcZCH8SMVvp8BsgZy/RgX0vuHwLg3hiFuK1+4BcQlcYVHRykVWK58uevVnP+LRmhCcYKH+m8icFAOjyg1tiasnYYehhseuSL6UlXaxXusuSBmHOXBxe2M8x7R2FoOxpTXOpyePKXFtS7T1V8NbTRn11P81C2Z+HXlD0GA/T1YNt+A8OshE8wcf4j2gI0r1v8WIGJ65BJSoMEbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J1jZBjAbZVTCCGK6mkl1JKVfT0n5h7mHyqeeqepbKyk=; b=iMTrHaHQ+fb8r/HUQ7YO/UGbDeTneoWV5Roq7ovXKnPbNPES72ASgr+EU44vDj3SDxk64F/frYrkLAvm0FTgEcrkk6VtPpUHptC/92f2VWIyxTz2o6QRE01Hto9llbRLdWEaR2VMjDK79z/fvG5JLavf9eHbnTwMo+8aajvGjQ8= Received: from BY5PR13MB3793.namprd13.prod.outlook.com (2603:10b6:a03:226::15) by BY5PR13MB3046.namprd13.prod.outlook.com (2603:10b6:a03:184::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Tue, 28 Jul 2020 22:35:28 +0000 Received: from BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::2447:df10:38ac:b1d7]) by BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::2447:df10:38ac:b1d7%9]) with mapi id 15.20.3239.016; Tue, 28 Jul 2020 22:35:28 +0000 From: Alexander Clemm To: Mahesh Jethanandani CC: Kent Watsen , "Eric Voit (evoit)" , "netconf@ietf.org" Thread-Topic: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.txt Thread-Index: AQHWZCw/oCd5fHONJ0Cydfo2dr7zuakbkZmAgAASv4CAAUDLgIAAlIYAgAAEHHCAABgMAIAAAECQ Date: Tue, 28 Jul 2020 22:35:27 +0000 Message-ID: References: <159586435098.29591.15728904593699090813@ietfa.amsl.com> <010001739732b207-d1f05f7d-170d-436e-8b94-2576a3bb5365-000000@us-east-1.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [73.189.160.186] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dd789370-0608-4719-70f1-08d83346872d x-ms-traffictypediagnostic: BY5PR13MB3046: 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: wwEK/MQkkcOeSic+giEzxMfFEMFw1+YgTYw4oG2zPdF+LNBQQGgLILpSC/UQ9dzRQEc9mXiO5pCjBQqVbOyiwWWP645VGizvzxBl20cy5+PZpzU2i+PXTppdkfdPvmK6bsIHRG4OuIi8ualg8ppiNWpfy4B73cBfJlYh37p9l9wUJxopBmeHsVfStSVptPL/R0xVduthT9o7yl/LQ9vn0G0xJbfHHbSWjjlTBH7OGc+3/eOLWI+UKBvS8VoVlDzvf9j3hoq2ksFMFxZdm3eyAde5jcXdLNBBXr6t5cPYIcI/xKmHaNhqO3ZANgeuhAda3MdpMKP0Hq+qRzFXelBfdP0wQI70V2M+eRUqldEKFl1pBiDJXjdobZnZb3E9eDCuCAFccGXnqAKdUaIYhGZu+w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3793.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39850400004)(346002)(136003)(396003)(366004)(4326008)(8676002)(71200400001)(52536014)(5660300002)(316002)(33656002)(8936002)(9326002)(7696005)(83380400001)(9686003)(55016002)(86362001)(6916009)(508600001)(66556008)(66476007)(66446008)(66946007)(54906003)(26005)(2906002)(186003)(64756008)(76116006)(6506007)(166002)(53546011)(966005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: /vA2zCx8A/Nvb/m4N2VgnhtsrI/ag3bIAwlTmbJGNj0p27rs5oAVCsFOZlkYvvxHY91oNIajslVCKBHrJ83HBDsyFwzoGNmsR8BgB/qkjOjos9iu2AAMcWmVybTsH1VevczbumcGKmGp0nShZFFKOXJFihGtgw6S/pXzVzlmPhBZ4SNuCgR+a5skmqucM8V2AoRvjBu2bCWHMjfqp8QFer/fPSsM9WxKa6ADrJQc0fY1rRBoAprbksiIYFqAetbaclldVLE8wtaK5Yl63MUU5fW+IyQJolezi5hY0w7rK0kYTH/Sa8FB9caDRKjLwxuWXqhKD0Xf1K2NMjI/XPM+TRehxwsKqTP8pTKBA24C1NONr/gki2KIFd4oENqUtvgw170k1Jq15O3ERfH4xk2+sm9LxlQBjAGIkXLD1ZcranGSaMlH3NvLPl5ArPLNUJNucOs49cVFmfaKqIotwUBmOS3wS6xZzI8v+E8/uc9MDF60C2VHLxbfhrMje1V7uZ3eEkrUvn1SydbBVhMYfUMOY+FeDI4U+zuE8Qq9o64tw2z1qFAy4QYiaqPeWJw4S5KtWx5UXU4qUcN7xGWOU25RlSWPecMdtGESXd2F1dBBZJOZVZFx3utgXKs5o/e8s09D65TYrhEhr5xtvbvQgMN4fA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB3793B3AFB82CCDA17A53F728DB730BY5PR13MB3793namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3793.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd789370-0608-4719-70f1-08d83346872d X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 22:35:27.8747 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rEbqzAPm8Z9gFYcfK4J2iF2GG01VSHGAbOy47xwIzAcnW+nCd7k1tWbAPvTK2VyAF+sMkgejwCYBHD0tyu+4qg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3046 Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-04.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, 28 Jul 2020 22:35:34 -0000 --_000_BY5PR13MB3793B3AFB82CCDA17A53F728DB730BY5PR13MB3793namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KdGhhbmsgeW91IGZvciB5b3VyIGV4cGxhbmF0aW9uLiAgTGV04oCZcyBwdXQg dGhhdCBzZXBhcmF0aW9uIGFuZCBjbGFyaWZpY2F0aW9uIGluIHRoZSBkcmFmdC4NCi0tLSBBbGV4 DQoNCkZyb206IE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0K U2VudDogVHVlc2RheSwgSnVseSAyOCwgMjAyMCAzOjMzIFBNDQpUbzogQWxleGFuZGVyIENsZW1t IDxhbGV4QGZ1dHVyZXdlaS5jb20+DQpDYzogS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4u bmV0PjsgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3Jn PjsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYtMDQudHh0DQoNCkhpIEFsZXgsDQoNCklmIHRo ZSBpbXBsZW1lbnRhdGlvbiBjYWxscyBmb3IgYSBtZXRob2QgYnkgd2hpY2ggYSByZWNlaXZlciB3 YW50cyB0byBzdWJzY3JpYmUgdG8gcGFydGljdWxhciBub3RpZmljYXRpb25zLCBieSBhbGwgbWVh bnMgeW91IG5lZWQgdG8gaW1wbGVtZW50IFNOLiBIb3dldmVyLCBpZiBhbGwgeW91IG5lZWQgdG8g aW1wbGVtZW50IGlzIGEgY2hhbm5lbCBieSB3aGljaCBub3RpZmljYXRpb25zIGNhbiBiZSBzZW5k IGZyb20gdGhlIHB1Ymxpc2hlciB0byB0aGUgcmVjZWl2ZXIsIGhvd2V2ZXIgdGhhdCBjaGFubmVs IGlzIHNldCB1cCwgd2h5IHdvdWxkIHlvdSBuZWVkIHRvIGltcGxlbWVudCBTTj8NCg0KU3Vic2Ny aXB0aW9uIFN0YXRlIENoYW5nZSBOb3RpZmljYXRpb24gaXMgY2VudHJhbCB0byB0aGUgY29uY2Vw dCBvZiBiZWluZyBhYmxlIHRvIHN1YnNjcmliZSB0byBldmVudHMuIEl0IGlzIG5vdCBjZW50cmFs IHRvIGhvdyBub3RpZmljYXRpb25zIGFyZSBzZW50Lg0KDQpNDQoNCg0KT24gSnVsIDI4LCAyMDIw LCBhdCAzOjE5IFBNLCBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhAZnV0dXJld2VpLmNvbTxtYWlsdG86 YWxleEBmdXR1cmV3ZWkuY29tPj4gd3JvdGU6DQoNCkhpIEtlbnQsDQpJIGFtIGdldHRpbmcgYSBi aXQgY29uZnVzZWQgaGVyZS4gIEFyZSB5b3Ugc2F5aW5nIHRoYXQgeW91IHdvdWxkIG9ubHkgbmVl ZCB0byBpbXBsZW1lbnQgdGhlIGF1Z21lbnRhdGlvbnMsIG5vdCB0aGUgc3Vic2NyaXB0aW9ucyBt b2RlbCBiZWluZyBhdWdtZW50ZWQ/ICBTdWJzY3JpcHRpb24gU3RhdGUgQ2hhbmdlIE5vdGlmaWNh dGlvbnMgYXJlIGFuIGludGVncmFsIHBhcnQgb2YgdGhlIHdob2xlIHN1YnNjcmlwdGlvbiBjb25j ZXB0Lg0KQW55d2F5LCBJIGFncmVlIHRoaXMgcG9pbnQgbmVlZHMgY2xhcmlmaWNhdGlvbi4NCi0t LSBBbGV4DQoNCkZyb206IG5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEtlbnQgV2F0c2VuDQpTZW50 OiBUdWVzZGF5LCBKdWx5IDI4LCAyMDIwIDE6NTIgUE0NClRvOiBFcmljIFZvaXQgKGV2b2l0KSA8 ZXZvaXQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmV2b2l0PTQwY2lzY28uY29t QGRtYXJjLmlldGYub3JnPj4NCkNjOiBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW5l dGNvbmYtaHR0cHMtbm90aWYtMDQudHh0DQoNCkhpIEVyaWMsDQoNClRoZXJlIGFyZSBtYW55IGRv d25zaWRlcyB0byAqbm90KiBpbmNsdWRpbmcgdGhlIFN1YnNjcmlwdGlvbiBTdGF0ZSBDaGFuZ2Ug Tm90aWZpY2F0aW9ucywgaW5jbHVkaW5nIHRoZSBET1MgYXR0YWNrcyBsaXN0ZWQgYmVsb3cuICAg QXMgc2V2ZXJhbCBwZW9wbGUgbWVudGlvbmVkIGR1cmluZyB0aGUgc2Vzc2lvbiwgdGhlIGRyYWZ0 IGlzbid0IGNsZWFyIG9uIHdoaWNoIGVsZW1lbnRzIG9mIGh0dHBzLW5vdGlmIHJlcXVpcmUgU04s IGFuZCB3aGljaCBkbyBub3QuDQoNCkRpc2FncmVlLCBhcyBpdOKAmXMgb2J2aW91cyB0aGF0ICpp bXBsZW1lbnRpbmcqIHRoZSBtb2R1bGVzIHJlcXVpcmVzIFNOLCB3aGlsZSBub3QgaW1wbGVtZW50 aW5nIHRoZW0gZG9lc27igJl0LiAgQnV0LCBwZXIgeW91ciBjb21tZW50IGJlbG93LCBpdCB3b3Vs ZCBiZSBnb29kIHRvIGZsb2F0IHRoaXMgcG9pbnQgdG93YXJkcyB0aGUgYmVnaW5uaW5nLg0KDQoN Cg0KDQpBZGRpdGlvbmFsbHksIHRoZSBpbnRybyBzZWN0aW9uIG9mIGh0dHBzLW5vdGlmIGlzbid0 IGNsZWFyIGhlcmU6DQogICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0d28gWUFORyAxLjEgW1JG Qzc5NTBdIGRhdGENCiAgICBtb2R1bGVzLCBvbmUgZm9yIGF1Z21lbnRpbmcgdGhlIFN1YnNjcmlw dGlvbiB0byBZQU5HIE5vdGlmaWNhdGlvbnMNCiAgICAgW1JGQzg2MzldIHRvIGFkZCBhIHRyYW5z cG9ydCB0eXBlLCBhbmQgYW5vdGhlciBmb3IgY29uZmlndXJpbmcgYW5kDQogICAgbWFuYWdpbmcg SFRUUFMgYmFzZWQgcmVjZWl2ZXJzIGZvciB0aGUgbm90aWZpY2F0aW9ucy4NClRoZSBmaXJzdCB0 aW1lIEkgdW5kZXJzdGFuZCBhbGwgb2YgU04gaXNuJ3QgbWFuZGF0b3J5IGlzIFNlY3Rpb24gOC4y Lg0KDQpBY2ssIHNlZSBhYm92ZS4NCg0KDQoNCg0KSWYgdGhlcmUgYXJlIG1hbmRhdG9yeSBTTiBl bGVtZW50cyB3aGljaCBhcmUgc29tZXRpbWVzIG9wdGlvbmFsLCBjb3VsZCB5b3UgZXhwbGljaXRs eSBsaXN0IHRoZXNlIGluIHRoZSBkcmFmdD8NCg0KVGhpcyBkcmFmdCBkb2VzIG5vdCDigJx1cGRh dGXigJ0gUkZDIDg2MzkuICBObyBjaGFuZ2UgdG8gUkZDODYzOSBub3JtYXRpdmUgdGV4dCBleGlz dHMgaW4gdGhlIGRyYWZ0Lg0KDQoNCg0KDQpBbHNvIGNvdWxkIHlvdSBsaXN0IHdoYXQgdGhlIHBv dGVudGlhbCBkb3duc2lkZXMgb2YgZXhjbHVkaW5nIG1hbmRhdG9yeSBtaWdodCBiZSwgYW5kIHdo ZW4gdGhlc2UgcG90ZW50aWFsIGRvd25zaWRlcyBjYW4gYmUgc2FmZWx5IGRpc2NvdW50ZWQ/DQoN CkFuIGVudW1lcmF0ZWQgbGlzdCB3b3VsZCBiZSBvdmVya2lsbC4gIEEgcGFzc2luZyBjb21tZW50 IGlzIHN1ZmZpY2llbnQuICBUaGUgZm9sbG93aW5nIHNlZW1zIGFib3V0IHJpZ2h0Og0KDQogIOKA nFVzaW5nIHRoZSAnaHR0cHMtbm90aWbigJkgdHJhbnNwb3J0IG91dHNpZGUgb2YgUkZDIDg2Mzkg TUFZIGJlIGRlc2lyYWJsZSBpbiBjYXNlcyB3aGVyZSBhIHNpbXBsZSBub3RpZmljYXRpb24tZGVs aXZlcnkgbWVjaGFuaXNtIGlzIHN1ZmZpY2llbnQgZm9yIHRoZSBpbnRlbmRlZCB1c2UuICBXaGVu IGFkdmFuY2VkIGRlbGl2ZXJ5IGZlYXR1cmVzIGFyZSBuZWVkZWQgKGUuZy4sIHJlcGxheSwgUW9T KSwgUkZDIDg2MzkgaXMgU0hPVUxEIGJlIHVzZWQu4oCdDQoNCg0KDQoNCg0KDQpLLg0KDQoNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRj b25mIG1haWxpbmcgbGlzdA0KbmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjxodHRwczov L25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZuZXRjb25mJmRhdGE9MDIlN0Mw MSU3Q2FsZXglNDBmdXR1cmV3ZWkuY29tJTdDOTQ0ZTU5Y2NlY2ZmNDE1YmZhZjYwOGQ4MzM0NjM5 YTYlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM3MzE1NzI0 MDExNzIyMTgyJnNkYXRhPTBsa094R3BaVmZNTk82YWUzSlhwekhEMjZJbTVQbmkyVUdzcFAlMkJF bXRmcyUzRCZyZXNlcnZlZD0wPg0KDQo= --_000_BY5PR13MB3793B3AFB82CCDA17A53F728DB730BY5PR13MB3793namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBNYWhlc2gsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj50aGFuayB5b3UgZm9yIHlvdXIgZXhwbGFuYXRpb24uJm5ic3A7IExldOKAmXMg cHV0IHRoYXQgc2VwYXJhdGlvbiBhbmQgY2xhcmlmaWNhdGlvbiBpbiB0aGUgZHJhZnQuJm5ic3A7 DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLSBBbGV4PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1haGVzaCBKZXRoYW5hbmRhbmkgJmx0O21q ZXRoYW5hbmRhbmlAZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVs eSAyOCwgMjAyMCAzOjMzIFBNPGJyPg0KPGI+VG86PC9iPiBBbGV4YW5kZXIgQ2xlbW0gJmx0O2Fs ZXhAZnV0dXJld2VpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEtlbnQgV2F0c2VuICZsdDtrZW50 K2lldGZAd2F0c2VuLm5ldCZndDs7IEVyaWMgVm9pdCAoZXZvaXQpICZsdDtldm9pdD00MGNpc2Nv LmNvbUBkbWFyYy5pZXRmLm9yZyZndDs7IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtuZXRjb25mXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMt bm90aWYtMDQudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBB bGV4LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhl IGltcGxlbWVudGF0aW9uIGNhbGxzIGZvciBhIG1ldGhvZCBieSB3aGljaCBhIHJlY2VpdmVyIHdh bnRzIHRvIHN1YnNjcmliZSB0byBwYXJ0aWN1bGFyIG5vdGlmaWNhdGlvbnMsIGJ5IGFsbCBtZWFu cyB5b3UgbmVlZCB0byBpbXBsZW1lbnQgU04uIEhvd2V2ZXIsIGlmIGFsbCB5b3UgbmVlZCB0byBp bXBsZW1lbnQgaXMgYSBjaGFubmVsIGJ5IHdoaWNoIG5vdGlmaWNhdGlvbnMgY2FuIGJlIHNlbmQg ZnJvbQ0KIHRoZSBwdWJsaXNoZXIgdG8gdGhlIHJlY2VpdmVyLCBob3dldmVyIHRoYXQgY2hhbm5l bCBpcyBzZXQgdXAsIHdoeSB3b3VsZCB5b3UgbmVlZCB0byBpbXBsZW1lbnQgU04/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1YnNjcmlwdGlv biBTdGF0ZSBDaGFuZ2UgTm90aWZpY2F0aW9uIGlzIGNlbnRyYWwgdG8gdGhlIGNvbmNlcHQgb2Yg YmVpbmcgYWJsZSB0byBzdWJzY3JpYmUgdG8gZXZlbnRzLiBJdCBpcyBub3QgY2VudHJhbCB0byBo b3cgbm90aWZpY2F0aW9ucyBhcmUgc2VudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gSnVsIDI4LCAyMDIwLCBhdCAzOjE5IFBNLCBBbGV4YW5kZXIgQ2xl bW0gJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4QGZ1dHVyZXdlaS5jb20iPmFsZXhAZnV0dXJld2Vp LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGkgS2VudCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgYW0gZ2V0dGluZyBhIGJpdCBjb25mdXNlZCBoZXJlLiZuYnNwOyBBcmUg eW91IHNheWluZyB0aGF0IHlvdSB3b3VsZCBvbmx5IG5lZWQgdG8gaW1wbGVtZW50IHRoZSBhdWdt ZW50YXRpb25zLCBub3QgdGhlIHN1YnNjcmlwdGlvbnMgbW9kZWwgYmVpbmcgYXVnbWVudGVkPyZu YnNwOyBTdWJzY3JpcHRpb24gU3RhdGUgQ2hhbmdlIE5vdGlmaWNhdGlvbnMgYXJlIGFuIGludGVn cmFsIHBhcnQgb2YgdGhlIHdob2xlIHN1YnNjcmlwdGlvbg0KIGNvbmNlcHQuJm5ic3A7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW55d2F5LCBJIGFncmVlIHRo aXMgcG9pbnQgbmVlZHMgY2xhcmlmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLSBBbGV4PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm5ldGNvbmYgJmx0OzxhIGhyZWY9 Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L2I+S2VudA0KIFdhdHNlbjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBKdWx5IDI4LCAyMDIw IDE6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPkVyaWMgVm9pdCAoZXZvaXQpICZsdDs8YSBocmVmPSJtYWlsdG86ZXZv aXQ9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciPmV2b2l0PTQwY2lzY28uY29tQGRtYXJjLmll dGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5u ZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW25ldGNvbmZdIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0wNC50eHQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEVy aWMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVy ZSBhcmUgbWFueSBkb3duc2lkZXMgdG8gKm5vdCogaW5jbHVkaW5nIHRoZSBTdWJzY3JpcHRpb24g U3RhdGUgQ2hhbmdlIE5vdGlmaWNhdGlvbnMsIGluY2x1ZGluZyB0aGUgRE9TIGF0dGFja3MgbGlz dGVkIGJlbG93LiAmbmJzcDsmbmJzcDtBcyBzZXZlcmFsIHBlb3BsZSBtZW50aW9uZWQgZHVyaW5n IHRoZSBzZXNzaW9uLCB0aGUgZHJhZnQgaXNuJ3QgY2xlYXIgb24gd2hpY2ggZWxlbWVudHMgb2Yg aHR0cHMtbm90aWYgcmVxdWlyZQ0KIFNOLCBhbmQgd2hpY2ggZG8gbm90LiZuYnNwOzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EaXNhZ3JlZSwgYXMgaXTigJlzIG9i dmlvdXMgdGhhdCAqaW1wbGVtZW50aW5nKiB0aGUgbW9kdWxlcyByZXF1aXJlcyBTTiwgd2hpbGUg bm90IGltcGxlbWVudGluZyB0aGVtIGRvZXNu4oCZdC4gJm5ic3A7QnV0LCBwZXIgeW91ciBjb21t ZW50IGJlbG93LCBpdCB3b3VsZCBiZSBnb29kIHRvIGZsb2F0IHRoaXMgcG9pbnQgdG93YXJkcyB0 aGUgYmVnaW5uaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFkZGl0aW9uYWxseSwgdGhlIGludHJvIHNlY3Rpb24gb2YgaHR0cHMtbm90aWYgaXNu J3QgY2xlYXIgaGVyZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzhGQUFEQyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBZQU5HIDEuMSBbUkZD Nzk1MF0gZGF0YTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOEZBQURDIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDttb2R1bGVzLCBvbmUgZm9yIGF1Z21lbnRpbmcgdGhlIFN1 YnNjcmlwdGlvbiB0byBZQU5HIE5vdGlmaWNhdGlvbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzhGQUFEQyI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO1tSRkM4NjM5XSB0 byBhZGQgYSB0cmFuc3BvcnQgdHlwZSwgYW5kIGFub3RoZXIgZm9yIGNvbmZpZ3VyaW5nIGFuZDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOEZBQURDIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDttYW5hZ2luZyBIVFRQUyBiYXNlZCByZWNlaXZlcnMgZm9yIHRoZSBub3RpZmlj YXRpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBmaXJzdCB0aW1lIEkgdW5kZXJzdGFuZCBhbGwg b2YgU04gaXNuJ3QgbWFuZGF0b3J5IGlzIFNlY3Rpb24gOC4yLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFjaywgc2VlIGFib3ZlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlcmUgYXJlIG1hbmRhdG9yeSBT TiBlbGVtZW50cyB3aGljaCBhcmUgc29tZXRpbWVzIG9wdGlvbmFsLCBjb3VsZCB5b3UgZXhwbGlj aXRseSBsaXN0IHRoZXNlIGluIHRoZSBkcmFmdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhpcyBkcmFmdCBkb2VzIG5vdCDigJx1cGRhdGXigJ0gUkZDIDg2Mzku ICZuYnNwO05vIGNoYW5nZSB0byBSRkM4NjM5IG5vcm1hdGl2ZSB0ZXh0IGV4aXN0cyBpbiB0aGUg ZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvIGNv dWxkIHlvdSBsaXN0IHdoYXQgdGhlIHBvdGVudGlhbCBkb3duc2lkZXMgb2YgZXhjbHVkaW5nIG1h bmRhdG9yeSBtaWdodCBiZSwgYW5kIHdoZW4gdGhlc2UgcG90ZW50aWFsIGRvd25zaWRlcyBjYW4g YmUgc2FmZWx5IGRpc2NvdW50ZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFuIGVudW1lcmF0ZWQgbGlzdCB3b3VsZCBiZSBvdmVya2lsbC4gJm5ic3A7QSBwYXNz aW5nIGNvbW1lbnQgaXMgc3VmZmljaWVudC4mbmJzcDsgVGhlIGZvbGxvd2luZyBzZWVtcyBhYm91 dCByaWdodDogJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyDigJxVc2lu ZyZuYnNwO3RoZSAnaHR0cHMtbm90aWbigJkgdHJhbnNwb3J0IG91dHNpZGUgb2YgUkZDIDg2Mzkg TUFZIGJlIGRlc2lyYWJsZSBpbiBjYXNlcyB3aGVyZSBhIHNpbXBsZSBub3RpZmljYXRpb24tZGVs aXZlcnkmbmJzcDttZWNoYW5pc20gaXMgc3VmZmljaWVudCBmb3IgdGhlIGludGVuZGVkIHVzZS4g Jm5ic3A7V2hlbiZuYnNwO2FkdmFuY2VkIGRlbGl2ZXJ5IGZlYXR1cmVzIGFyZSBuZWVkZWQgKGUu Zy4sIHJlcGxheSwgUW9TKSwgUkZDIDg2MzkNCiBpcyBTSE9VTEQgYmUgdXNlZC7igJ08bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5LLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRjb25mIG1haWxpbmcg bGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+bmV0Y29uZkBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZs aXN0aW5mbyUyRm5ldGNvbmYmYW1wO2RhdGE9MDIlN0MwMSU3Q2FsZXglNDBmdXR1cmV3ZWkuY29t JTdDOTQ0ZTU5Y2NlY2ZmNDE1YmZhZjYwOGQ4MzM0NjM5YTYlN0MwZmVlOGZmMmEzYjI0MDE4OWM3 NTNhMWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM3MzE1NzI0MDExNzIyMTgyJmFtcDtzZGF0YT0wbGtP eEdwWlZmTU5PNmFlM0pYcHpIRDI2SW01UG5pMlVHc3BQJTJCRW10ZnMlM0QmYW1wO3Jlc2VydmVk PTAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0Y29uZjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY5PR13MB3793B3AFB82CCDA17A53F728DB730BY5PR13MB3793namp_--

You have been invited to the f= ollowing event.

IETF 108 NETCONF Virtual Meeting

=
When
Tue Jul 28, 2020 4am =E2=80=93 5:40am Pacific Time - Los Angeles
Where
https://meetings= .conf.meetecho.com/ietf108/?group=3Dnetconf (map)
Calendar
netconf@ietf.org
Who
•<= /span>
mj= ethanandani@gmail.com - organizer
<= /td>
netconf@ietf.or= g
Note, we are no longer using= WebEx for this meeting. Please use the Meetecho link to join the meeting.<= p>https://meeti= ngs.conf.meetecho.com/ietf108/?group=3Dnetconf

Going (netconf@ietf.org)?   Yes - Maybe - = No&n= bsp;   more options »

Invitation from Googl= e Calendar

You are receiving this courtesy email at the account n= etconf@ietf.org because you are an attendee of this event.

To stop re= ceiving future updates for this event, decline this event. Alternatively yo= u can sign up for a Google account at https://www.google.com/calendar/ and = control your notification settings for your entire calendar.

Forwardi= ng this invitation could allow any recipient to send a response to the orga= nizer and be added to the guest list, or invite others regardless of their = own invitation status, or to modify your RSVP. Learn More.