From nobody Mon Nov 2 03:57:23 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 6B8463A0E79; Mon, 2 Nov 2020 03:57:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <160431824240.22476.7189294382555060641@ietfa.amsl.com> Date: Mon, 02 Nov 2020 03:57:22 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-udp-notif-01.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, 02 Nov 2020 11:57:22 -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 : UDP-based Transport for Configured Subscriptions Authors : Guangying Zheng Tianran Zhou Thomas Graf Pierre Francois Paolo Lucente Filename : draft-ietf-netconf-udp-notif-01.txt Pages : 16 Date : 2020-11-02 Abstract: This document describes an UDP-based notification mechanism to collect data from networking devices. A shim header is proposed to facilitate the streaming of data directly from line cards to a collector. The objective is to rely on a lightweight approach to allow for higher frequency and better transit performance compared to already established notification mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-notif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-udp-notif-01 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-udp-notif-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 2 04:03:26 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 388AD3A0E75; Mon, 2 Nov 2020 04:03:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <160431860519.22641.8004630507328846015@ietfa.amsl.com> Date: Mon, 02 Nov 2020 04:03:25 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-distributed-notif-01.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, 02 Nov 2020 12:03:25 -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 : Subscription to Distributed Notifications Authors : Tianran Zhou Guangying Zheng Eric Voit Thomas Graf Pierre Francois Filename : draft-ietf-netconf-distributed-notif-01.txt Pages : 20 Date : 2020-11-02 Abstract: This documents describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-distributed-notif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-distributed-notif-01 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-distributed-notif-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 2 14:15: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 92D4F3A11D9; Mon, 2 Nov 2020 14:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ln8_iGI2Tj2; Mon, 2 Nov 2020 14:15:46 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 5E39D3A1326; Mon, 2 Nov 2020 14:15:34 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id w11so7540078pll.8; Mon, 02 Nov 2020 14:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BrfmBEZ1Ie/m63zGau7EGxidNvCMrGOg3x+X+pFyRWI=; b=U4NOC+GQx7ncNtgmwvNVZbWaRqi+gzwEBOJo1ihVeMO0w+pzdCniGkZWo6iwOv3yMC qThvaNZH6bu0WQwK2AIsGEisVg0ah2/K4aUiayRUiB2Iw+4bcaNua1ZaMoIH5p4eQTGG OZrSdCKqE6hnyfjS34HpjdUee0aM45or/9P9qw/zN7hqlRU1/RMAIiWDaDVoYOJfQbH9 8h8nFfgCmXMiG5S1fXkKtnO1JhhhJrONFOuBhQTKlNSIEPZRcxgI+FI2ib28GwA01a31 EB9QstHh1ZRyaz6ZLLVZomTMs0XplQoUfPmkP52G4YOrcq7LME1zkuPCuE+ZcPcVfnwf zgrQ== 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=BrfmBEZ1Ie/m63zGau7EGxidNvCMrGOg3x+X+pFyRWI=; b=gb1KbYd1s37lEJRMvalUU6mGAbSicZnB1VgchjnkqUsQOv37mt4TXJYkBzSM2wUNpn c3hiD78Y3WeiemOwWDVy3r96EYd07YdQbDUOKcK9H8L47oQjdzoznCu4QHgFSyHsmk3L 4LrofA0lietPUPzuwzIPjZPO+6nUcfhWe8fE5quzgEXFfGD5al/FjmvYEL4Z8k3PR5jQ TbwzwdwLasdkb3I5Lb/A+b6inoPMM6iRX4hPEwpvqPXS9WhLOFseVlLubrs4pEPszRKs f/vqNbE9VMny2alZR+2OfowIbmCriyH6Yq+KLGS87gBxZLYtDRukn8b6szvgR8MwJvHZ TZbA== X-Gm-Message-State: AOAM530YSpFfUJb5NvL8kgglMC/gop+ujwb/4NTi+MOYcAtDMp5t63lz xuoLIjk9lOTtzKZG6RY/bHHVyZAh19c= X-Google-Smtp-Source: ABdhPJwSftVYCvdBkQEpjQooB0IO9nkNjq/9u8rxnzXMkJFZ522SatRjXBdFyu5NdFUrDpMnChx3wA== X-Received: by 2002:a17:902:c412:b029:d6:2939:1b75 with SMTP id k18-20020a170902c412b02900d629391b75mr22988462plk.80.1604355333820; Mon, 02 Nov 2020 14:15:33 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:11d5:e42d:2142:9281? ([2601:647:5600:5020:11d5:e42d:2142:9281]) by smtp.gmail.com with ESMTPSA id e10sm320813pfl.162.2020.11.02.14.15.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2020 14:15:32 -0800 (PST) From: Mahesh Jethanandani Message-Id: <30C2E765-3BA6-43B9-AEE7-23B820AA041C@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_06DC9B03-1DF6-4673-819B-C8658BDB11FE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 2 Nov 2020 14:15:31 -0800 In-Reply-To: <010001754d122531-31e209be-eef2-4a70-bdcd-05ff3c821656-000000@email.amazonses.com> Cc: "netconf@ietf.org" , "netconf-chairs@ietf.org" To: Kent Watsen References: <010001754d122531-31e209be-eef2-4a70-bdcd-05ff3c821656-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] Call for 109 discussion topics 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, 02 Nov 2020 22:15:51 -0000 --Apple-Mail=_06DC9B03-1DF6-4673-819B-C8658BDB11FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [As a contributor] Please see request inline. Thanks. > On Oct 21, 2020, at 2:30 PM, Kent Watsen wrote: >=20 > NETCONF WG, >=20 > According to the preliminary agenda [1], NETCONF is scheduled to meet = for 2-hours on Wednesday, November 18th from 12:00-14:00 Bangkok time = (UTC +7). >=20 > If you are interested in discussing one or more topics with the WG, = please send requests to the "netconf-chairs" alias (CC-ed) with the = following information, for each discussion, if more than one: >=20 > - name of the drafts (if any) - draft-ietf-netconf-https-notif > - name of discussion topic (usually the title of the draft) - = draft-ietf-netconf-https-notif > - name of the person(s) leading the discussion - Mahesh Jethanandani > - desired time request (in minutes): 10 >=20 > Authors, per the 109 Important Dates page [2], the draft submission = cutoff is in two weeks, on Monday November 2nd. Please be sure to = update your drafts before then. >=20 > [1] = https://datatracker.ietf.org/meeting/109/agenda.html#2020-11-18-110000 > [2] https://datatracker.ietf.org/meeting/109/important-dates >=20 > NETCONF Chairs Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_06DC9B03-1DF6-4673-819B-C8658BDB11FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [As = a contributor]

Please = see request inline. Thanks.

On Oct 21, 2020, at 2:30 PM, = Kent Watsen <kent+ietf@watsen.net> wrote:

NETCONF WG,

According to the = preliminary agenda [1], NETCONF is scheduled to meet for 2-hours on = Wednesday, November 18th from 12:00-14:00 Bangkok time (UTC +7).

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

- name of the drafts (if = any) - draft-ietf-netconf-https-notif
- name of = discussion topic (usually the title of the draft) - = draft-ietf-netconf-https-notif
- name of the = person(s) leading the discussion - Mahesh Jethanandani
- = desired time request (in minutes): 10

Authors, per the 109 Important Dates page [2], the draft = submission cutoff is in two weeks, on Monday November 2nd.  Please = be sure to update your drafts before then.

[1] https://datatracker.ietf.org/meeting/109/agenda.html#2020-11-18= -110000
[2] https://datatracker.ietf.org/meeting/109/important-dates
NETCONF = Chairs

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_06DC9B03-1DF6-4673-819B-C8658BDB11FE-- From nobody Tue Nov 3 11:33:18 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 CF59F3A10FE; Tue, 3 Nov 2020 11:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Nv8jGMNBEjsh; Tue, 3 Nov 2020 11:33:10 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0227A3A10FD; Tue, 3 Nov 2020 11:33:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BDB0938983; Tue, 3 Nov 2020 14:33:08 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QLdOaT7JMyjY; Tue, 3 Nov 2020 14:33:07 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5F19138982; Tue, 3 Nov 2020 14:33:07 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 164E9134A; Tue, 3 Nov 2020 12:05:35 -0500 (EST) From: Michael Richardson To: anima@ietf.org, netconf@ietf.org cc: iotops@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [netconf] what to call different RFC8366 format artifacts 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, 03 Nov 2020 19:33:12 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, RF8366 specifies a YANG module for a voucher, and the format as serialized to JSON, and signed by CMS. In section 5.4, it is written: 5.4. CMS Format Voucher Artifact The IETF evolution of PKCS#7 is CMS [RFC5652]. A **CMS-signed voucher*= *, In section 8.3, it is written: Encoding considerations: *CMS-signed JSON* vouchers are ASN.1/DER encoded. So it became natural for me to write "CMS-signed-JSON". In development of RFC8366, we argued for using JOSE rather than CMS, but there were, at the time (2016) lack of familiarity with JOSE, and concerns about having FIPS-140 validation of that code. In draft-ietf-anima-constrained-voucher, we introduce two new things: 1) signing with COSE 2) encoding with CBOR. A number of people have written, rather than "CMS-signed-JSON", instead, "JSON in CMS". I wondered at the BRSKI design team call last Thursday if perhaps that order of words translates better into Dutch or German, or ??? So to bikeshed the whole thing, please comment on preference in naming: 1) RFC8366: CMS-signed-JSON vs JSON-in-CMS. 2) CV: CMS-signed-CBOR vs CBOR-in-CMS. 3) CV: COSE-signed-CBOR vs CBOR-in-COSE. 4) future ID: JWS-signed-JSON vs JSON-in-JOSE. I note that for some of these "signed" is redundant. We do not have COSE-signed-JSON, or JWS-signed-CBOR. Which feels more natural to you? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+hjd4ACgkQgItw+93Q 3WVvXwf/cqY6msnbIXpyZ0TXSM1tMCdtZfo+rS2avcu9bIiX1hCiSgdUZMf2LOiq 1NnYksEU20j7TweEAwofBIxu0xxiARJSTCrxQzNBsobEJo7j6eiYgcokJUBvz6Cp Tfs24ZkTS+EFR4Rkq21RweLcNgWWp/kFS3E7k/Bw1uwkhtpu7O2P6xDLxCg3U/lc dQO2znTV/N+KJbE8it+R9+Wy2YY7hy0QFgacmmmHEP/fBf7dQXCEa5brW9uWpMdV zgl9iIWsmFTiyd0dg0DBShMvWT0Q+Umyka50OMqSnKSR2f4wbzC45o77FaFOgf6V HyI3riIx0XblJuoc9fayxMcc9+a0IQ== =pxj+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 3 12:24:31 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 A564C3A1135; Tue, 3 Nov 2020 12:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wtsTLUmfx8k4; Tue, 3 Nov 2020 12:24:21 -0800 (PST) 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 D1D413A113B; Tue, 3 Nov 2020 12:23:59 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 749C4854; Tue, 3 Nov 2020 21:23:57 +0100 (CET) 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 ObAntJ8Bx1Sk; Tue, 3 Nov 2020 21:23:57 +0100 (CET) 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; Tue, 3 Nov 2020 21:23:57 +0100 (CET) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id E831A20156; Tue, 3 Nov 2020 21:23:56 +0100 (CET) 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 Ds3g93OWxgX9; Tue, 3 Nov 2020 21:23:56 +0100 (CET) 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 569BE20154; Tue, 3 Nov 2020 21:23:55 +0100 (CET) Date: Tue, 3 Nov 2020 21:23:55 +0100 From: Juergen Schoenwaelder To: Michael Richardson Cc: anima@ietf.org, netconf@ietf.org, iotops@ietf.org Message-ID: <20201103202355.c4nnbsb5eiu6ga3y@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michael Richardson , anima@ietf.org, netconf@ietf.org, iotops@ietf.org References: <19352.1604423135@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19352.1604423135@localhost> Archived-At: Subject: Re: [netconf] what to call different RFC8366 format artifacts 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, 03 Nov 2020 20:24:23 -0000 On Tue, Nov 03, 2020 at 12:05:35PM -0500, Michael Richardson wrote: > > So to bikeshed the whole thing, please comment on preference in naming: > > 1) RFC8366: CMS-signed-JSON vs JSON-in-CMS. > 2) CV: CMS-signed-CBOR vs CBOR-in-CMS. > 3) CV: COSE-signed-CBOR vs CBOR-in-COSE. > 4) future ID: JWS-signed-JSON vs JSON-in-JOSE. > > I note that for some of these "signed" is redundant. > We do not have COSE-signed-JSON, or JWS-signed-CBOR. > > Which feels more natural to you? > For me, all the $foo-signed-$bar expansions make sense and they stress the signature aspect: CMS-signed-JSON = Cryptographic Message Syntax signed JavaScript Object Notation CMS-signed-CBOR = Cryptographic Message Syntax signed Concise Binary Object Representation COSE-signed-CBOR = CBOR Object Signing and Encryption signed Concise Binary Object Representation JWS-signed-JSON = JSON Web Signature signed JavaScript Object Notation The $foo-in-$bar alternative somehow stresses containment but I assume the primary reason for using CMS / COSE / JWS is for signatures, not for containment. /js (German, in case that matters.) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Nov 3 22:22:46 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 9C2733A096B; Tue, 3 Nov 2020 22:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnvU9PFTynUL; Tue, 3 Nov 2020 22:22:31 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D41E3A0966; Tue, 3 Nov 2020 22:22:31 -0800 (PST) Received: from fraeml740-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CQxP83FlHz67HRW; Wed, 4 Nov 2020 14:21:16 +0800 (CST) Received: from fraeml794-chm.china.huawei.com (10.206.15.15) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 4 Nov 2020 07:22:29 +0100 Received: from fraeml794-chm.china.huawei.com (10.206.15.15) by fraeml794-chm.china.huawei.com (10.206.15.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 4 Nov 2020 07:22:29 +0100 Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by fraeml794-chm.china.huawei.com (10.206.15.15) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 4 Nov 2020 07:22:29 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.33]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Wed, 4 Nov 2020 14:22:26 +0800 From: Qin Wu To: Juergen Schoenwaelder , "Michael Richardson" CC: "netconf@ietf.org" , "anima@ietf.org" , "iotops@ietf.org" Thread-Topic: [Iotops] [netconf] what to call different RFC8366 format artifacts Thread-Index: AdaycqUnE+dI0q33R0aqGlmGJZ5ZdA== Date: Wed, 4 Nov 2020 06:22:25 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.101.103] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] [Iotops] what to call different RFC8366 format artifacts 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, 04 Nov 2020 06:22:34 -0000 QWdyZWUgd2l0aCBKdWVyZ2VuLCB0aGVzZSBhcnRpZmFjdHMgYXJlIGFsbCBDTVMgc2lnbmVkLWRh dGEgY29udGVudA0KVHlwZSwgc28gQ09TRSBzaWduZWQgQ0JPUiwgSldTIHNpZ25lZCBKU09OIGlz IG1vcmUgbmF0dXJlIHRvIG1lLg0KDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzog SW90b3BzIFttYWlsdG86aW90b3BzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSnVlcmdlbiBTY2hv ZW53YWVsZGVyDQq3osvNyrG85DogMjAyMMTqMTHUwjTI1SA0OjI0DQrK1bz+yMs6IE1pY2hhZWwg UmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPg0Ks63LzTogbmV0Y29uZkBpZXRmLm9y ZzsgYW5pbWFAaWV0Zi5vcmc7IGlvdG9wc0BpZXRmLm9yZw0K1vfM4jogUmU6IFtJb3RvcHNdIFtu ZXRjb25mXSB3aGF0IHRvIGNhbGwgZGlmZmVyZW50IFJGQzgzNjYgZm9ybWF0IGFydGlmYWN0cw0K DQpPbiBUdWUsIE5vdiAwMywgMjAyMCBhdCAxMjowNTozNVBNIC0wNTAwLCBNaWNoYWVsIFJpY2hh cmRzb24gd3JvdGU6DQo+IA0KPiBTbyB0byBiaWtlc2hlZCB0aGUgd2hvbGUgdGhpbmcsIHBsZWFz ZSBjb21tZW50IG9uIHByZWZlcmVuY2UgaW4gbmFtaW5nOg0KPiANCj4gMSkgUkZDODM2NjogICAg Q01TLXNpZ25lZC1KU09OICB2cyBKU09OLWluLUNNUy4NCj4gMikgQ1Y6ICAgICAgICAgQ01TLXNp Z25lZC1DQk9SICB2cyBDQk9SLWluLUNNUy4NCj4gMykgQ1Y6ICAgICAgICAgQ09TRS1zaWduZWQt Q0JPUiB2cyBDQk9SLWluLUNPU0UuDQo+IDQpIGZ1dHVyZSBJRDogIEpXUy1zaWduZWQtSlNPTiAg dnMgSlNPTi1pbi1KT1NFLg0KPiANCj4gSSBub3RlIHRoYXQgZm9yIHNvbWUgb2YgdGhlc2UgInNp Z25lZCIgaXMgcmVkdW5kYW50Lg0KPiBXZSBkbyBub3QgaGF2ZSBDT1NFLXNpZ25lZC1KU09OLCBv ciBKV1Mtc2lnbmVkLUNCT1IuDQo+IA0KPiBXaGljaCBmZWVscyBtb3JlIG5hdHVyYWwgdG8geW91 Pw0KPg0KDQpGb3IgbWUsIGFsbCB0aGUgJGZvby1zaWduZWQtJGJhciBleHBhbnNpb25zIG1ha2Ug c2Vuc2UgYW5kIHRoZXkgc3RyZXNzIHRoZSBzaWduYXR1cmUgYXNwZWN0Og0KDQpDTVMtc2lnbmVk LUpTT04gID0gQ3J5cHRvZ3JhcGhpYyBNZXNzYWdlIFN5bnRheCBzaWduZWQNCiAgICAgICAgICAg ICAgICAgICBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiBDTVMtc2lnbmVkLUNCT1IgID0gQ3J5 cHRvZ3JhcGhpYyBNZXNzYWdlIFN5bnRheCBzaWduZWQNCiAgICAgICAgICAgICAgICAgICBDb25j aXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gQ09TRS1zaWduZWQtQ0JPUiA9IENCT1Ig T2JqZWN0IFNpZ25pbmcgYW5kIEVuY3J5cHRpb24gc2lnbmVkDQogICAgICAgICAgICAgICAgICAg Q29uY2lzZSBCaW5hcnkgT2JqZWN0IFJlcHJlc2VudGF0aW9uIEpXUy1zaWduZWQtSlNPTiAgPSBK U09OIFdlYiBTaWduYXR1cmUgc2lnbmVkDQogICAgICAgICAgICAgICAgICAgSmF2YVNjcmlwdCBP YmplY3QgTm90YXRpb24NCg0KVGhlICRmb28taW4tJGJhciBhbHRlcm5hdGl2ZSBzb21laG93IHN0 cmVzc2VzIGNvbnRhaW5tZW50IGJ1dCBJIGFzc3VtZSB0aGUgcHJpbWFyeSByZWFzb24gZm9yIHVz aW5nIENNUyAvIENPU0UgLyBKV1MgaXMgZm9yIHNpZ25hdHVyZXMsIG5vdCBmb3IgY29udGFpbm1l bnQuDQoNCi9qcyAoR2VybWFuLCBpbiBjYXNlIHRoYXQgbWF0dGVycy4pDQoNCi0tIA0KSnVlcmdl biBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgN ClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJy ZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8v d3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KLS0NCklvdG9wcyBtYWlsaW5nIGxpc3QNCklv dG9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pb3Rv cHMNCg== From nobody Wed Nov 4 09:09:02 2020 Return-Path: <01000175943b8fa6-b54bce58-6e09-4759-9d19-1bc4c85ce8cf-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 2CBC53A13EC; Wed, 4 Nov 2020 09:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhA7RqqDB818; Wed, 4 Nov 2020 09:08:54 -0800 (PST) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1594F3A13AC; Wed, 4 Nov 2020 09:08:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1604509732; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=GBvDbrWcJwg/RYVVCBXirFitlCzayv0KvnJiI0evED0=; b=exS8RQwFq8yWHSxwUviGDceRyJjpR0R9LBDZPHEOvGW6gFPyp6c50TnkW3OmO/iW MDlGhQyqu5QTBdBfh45lbeMgiPqAb6ZAKn1tETzAwNMPE/tQihifh5HOzGXDeOWd1Lx 0uUIc7l4JdM9SbQgvO9M1VidVqJOAyFNVuwv5V/Y= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_31E92BC6-D9DF-4D13-ABC7-D81AD6FF00F1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000175943b8fa6-b54bce58-6e09-4759-9d19-1bc4c85ce8cf-000000@email.amazonses.com> Date: Wed, 4 Nov 2020 17:08:52 +0000 Cc: "netconf-chairs@ietf.org" To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.11.04-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Draft 109 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: Wed, 04 Nov 2020 17:09:01 -0000 --Apple-Mail=_31E92BC6-D9DF-4D13-ABC7-D81AD6FF00F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The following draft 109 agenda has been posted [1]. Please send any = modification requests to the "netconf-chairs=E2=80=9D alias (CC-ed). [1] https://www.ietf.org/proceedings/109/agenda/agenda-109-netconf-00 = Thanks, NETCONF Chairs Agenda for the NETCONF 109 WG Session ------------------------------------- https://datatracker.ietf.org/meeting/109/materials/agenda-109-netconf Session: Wednesday, November 18 UTC+07: 12:00-14:00 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/109/sessions/netconf.ics MeetEcho: = https://meetings.conf.meetecho.com/ietf109/?group=3Dnetconf Jabber: xmpp:netconf@jabber.ietf.org?join Available During and After Session: CodiMD: https://codimd.ietf.org/notes-ietf-109-netconf Slides (TGZ): = https://datatracker.ietf.org/meeting/109/agenda/netconf-drafts.tgz Slides (PDF): = https://datatracker.ietf.org/meeting/109/agenda/netconf-drafts.pdf Available After Session: Recording: = https://ietf109.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-18 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13 https://tools.ietf.org/html/draft-ietf-netconf-keystore-20 https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-08 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-22 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-22 https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-05 = https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-21 = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-21 Discussion Leader: Kent Watsen Conveying a CSR in a SZTP Bootstrapping Request (10 min) https://tools.ietf.org/html/draft-ietf-netconf-sztp-csr-00 Discussion Leader: Kent Watsen An HTTPS-based Transport for Configured Subscriptions (10 min) https://tools.ietf.org/html/draft-ietf-netconf-https-notif-05 Discussion Leader: Mahesh Jethanandani UDP-based Transport for Configured Subscriptions (10 min) https://tools.ietf.org/html/draft-ietf-netconf-udp-notif-01 Discussion Leader: Pierre Francois Subscription to Distributed Notifications (10 min) https://tools.ietf.org/html/draft-ietf-netconf-distributed-notif-01 Discussion Leader: Thomas Graf Non-Chartered items: Self-explanation Data Node Tag & Telemetry Data Export Capabilities = (10 min) = https://tools.ietf.org/html/draft-tao-netconf-notif-node-tag-capabilities-= 02 = https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities-01 Discussion Leader: Peng Liu Adaptive Subscription to YANG & Bulk Subscription to YANG Event = Notifications (10 min) = https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscription-02 = https://tools.ietf.org/html/draft-wang-netconf-bulk-subscribed-notificatio= ns-02 Discussion Leader: Qin Wu Transaction ID Mechanism for NETCONF (10 min) Discussion Leader: Jan Lindblad List Pagination Mechanisms for NETCONF and RESTCONF (20 min) Discussion Leader: Kent Watsen and Qin Wu Remaining 10 min. --Apple-Mail=_31E92BC6-D9DF-4D13-ABC7-D81AD6FF00F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

The following draft 109 = agenda has been posted [1].  Please send any modification requests = to the "netconf-chairs=E2=80=9D alias (CC-ed).

[1] https://www.ietf.org/proceedings/109/agenda/agenda-109-netconf-= 00

Thanks,
NETCONF Chairs



Agenda for the NETCONF = 109 WG Session
-------------------------------------
https://datatracker.ietf.org/meeting/109/materials/agenda-109-n= etconf


Session:
  =  Wednesday, November 18
   UTC+07: = 12:00-14:00


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/109/sessions/netconf.ics
  MeetEcho:       https://meetings.conf.meetecho.com/ietf109/?group=3Dnetconf=
  Jabber:         xmpp:netconf@jabber.ietf.org?join


Available During and After Session:

  CodiMD:       =   https://codimd.ietf.org/notes-ietf-109-netconf
  Slides (TGZ):   https://datatracker.ietf.org/meeting/109/agenda/netconf-drafts.= tgz
  Slides (PDF):   https://datatracker.ietf.org/meeting/109/agenda/netconf-drafts.= pdf


Available After Session:

   Recording: =     https://ietf109.conf.meetecho.com/index.php/Recordings#NETCONF<= /a>
   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-18<= /a>
   https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13=
   https://tools.ietf.org/html/draft-ietf-netconf-keystore-20<= /div>
   https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-serve= r-08
   https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-serve= r-22
   https://tools.ietf.org/html/draft-ietf-netconf-tls-client-serve= r-22
   https://tools.ietf.org/html/draft-ietf-netconf-http-client-serv= er-05
   https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-s= erver-21
   https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-= server-21
   Discussion Leader: Kent = Watsen

  =  Conveying a CSR in a SZTP Bootstrapping Request (10 min)
   https://tools.ietf.org/html/draft-ietf-netconf-sztp-csr-00<= /div>
   Discussion Leader: Kent = Watsen

  =  An HTTPS-based Transport for Configured Subscriptions (10 = min)
   https://tools.ietf.org/html/draft-ietf-netconf-https-notif-05
   Discussion Leader: Mahesh = Jethanandani

   UDP-based Transport for Configured Subscriptions = (10 min)
   https://tools.ietf.org/html/draft-ietf-netconf-udp-notif-01=
   Discussion Leader: Pierre = Francois

  =  Subscription to Distributed Notifications (10 min)
   https://tools.ietf.org/html/draft-ietf-netconf-distributed-noti= f-01
   Discussion Leader: Thomas = Graf


Non-Chartered items:

  =  Self-explanation Data Node Tag & Telemetry Data Export = Capabilities (10 min)
   https://tools.ietf.org/html/draft-tao-netconf-notif-node-tag-ca= pabilities-02
   https://tools.ietf.org/html/draft-tao-netconf-data-export-capab= ilities-01
   Discussion Leader: Peng = Liu

  =  Adaptive Subscription to YANG & Bulk Subscription to YANG = Event Notifications (10 min)
   https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscri= ption-02
   https://tools.ietf.org/html/draft-wang-netconf-bulk-subscribed-= notifications-02
   Discussion = Leader: Qin Wu

   Transaction ID Mechanism for NETCONF (10 = min)
   Discussion Leader: Jan = Lindblad

  =  List Pagination Mechanisms for NETCONF and RESTCONF (20 = min)
   Discussion Leader: Kent Watsen = and Qin Wu


Remaining 10 min.


= --Apple-Mail=_31E92BC6-D9DF-4D13-ABC7-D81AD6FF00F1-- From nobody Wed Nov 4 17:21:27 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 C331B3A1232 for ; Wed, 4 Nov 2020 17:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz1aob2yBLpv for ; Wed, 4 Nov 2020 17:21:23 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878913A1230 for ; Wed, 4 Nov 2020 17:21:23 -0800 (PST) Received: from fraeml741-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CRQg44V4Pz67J8g for ; Thu, 5 Nov 2020 09:20:00 +0800 (CST) Received: from dggeme717-chm.china.huawei.com (10.1.199.113) by fraeml741-chm.china.huawei.com (10.206.15.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Thu, 5 Nov 2020 02:21:21 +0100 Received: from dggeme770-chm.china.huawei.com (10.3.19.116) by dggeme717-chm.china.huawei.com (10.1.199.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 5 Nov 2020 09:21:19 +0800 Received: from dggeme770-chm.china.huawei.com ([10.8.68.58]) by dggeme770-chm.china.huawei.com ([10.8.68.58]) with mapi id 15.01.1913.007; Thu, 5 Nov 2020 09:21:19 +0800 From: "maqiufang (A)" To: "netconf@ietf.org" Thread-Topic: New Version Notification for draft-ma-netconf-with-system-01.txt Thread-Index: AQHWsRNqAgqstejkz0iKR0y9i7pDmqm4vyaw Date: Thu, 5 Nov 2020 01:21:19 +0000 Message-ID: References: <160431998681.22434.18443332903566523384@ietfa.amsl.com> In-Reply-To: <160431998681.22434.18443332903566523384@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.100.25] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] New Version Notification for draft-ma-netconf-with-system-01.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, 05 Nov 2020 01:21:26 -0000 SGksIGFsbDoNCldlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQ6IGh0dHBzOi8vd3d3LmlldGYub3Jn L2FyY2hpdmUvaWQvZHJhZnQtbWEtbmV0Y29uZi13aXRoLXN5c3RlbS0wMS50eHQNCg0KSnVzdCBh IGxpdHRsZSBiaXQgYmFja2dyb3VuZCB3aHkgd2Ugd3JvdGUgdGhpcyBkcmFmdC4NCkluIG1hbnkg c2l0dWF0aW9ucywgdGhlIGNsaWVudCBuZWVkcyB0byBnZXQgc3lzdGVtIGNvbmZpZ3VyYXRpb24u IA0KSG93ZXZlciwgbm90IGFsbCBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIHRyZWF0IHN5c3RlbSBj b25maWd1cmF0aW9uIGRhdGEgdGhlIHNhbWUgd2F5LiANCkJlc2lkZXMsIHRoZSBkdXBsaWNhdGVk IHN5c3RlbSBjb25maWd1cmVkIGRhdGEgaXRlbSBuZWVkcyB0byBiZSBjcmVhdGVkIGFuZCBvdmVy cmlkZGVuIGJ5IHRoZSBjbGllbnQgZXZlcnkgdGltZSAgdGhlIGNsaWVudCB3YW50cyBhIHJlZmVy ZW5jZSwgd2hpY2ggY2FuIGJlIHF1aXRlIGluY29udmVuaWVudC4NCg0KVGhlcmVmb3JlLCB3ZSBk ZWZpbmUgYSAgY2FwYWJpbGl0eS1iYXNlZCBleHRlbnNpb24gdG8gdGhlIE5FVENPTkYgcHJvdG9j b2wgdGhhdCBhbGxvd3MgdGhlIGNsaWVudCB0byBpZGVudGlmeSBob3cgc3lzdGVtIGNvbmZpZ3Vy YXRpb24gYXJlIHByb2Nlc3NlZCBieSB0aGUgc2VydmVyLCBhbmQgYWxzbyBkZWZpbmUgYSBuZXcg bWVjaGFuaXNtIGZvciBjbGllbnQgY29udHJvbCBvZiBzZXJ2ZXIgcHJvY2Vzc2luZyBvZiBzeXN0 ZW0gY29uZmlndXJhdGlvbiBkYXRhLg0KDQpGb3IgbW9yZSBkZXRhaWxzIHBsZWFzZSByZXZpZXcg dGhlIGRyYWZ0LCBhbnkgc3VnZ2VzdGlvbnMgYW5kIGNvbW1lbnRzIHdvdWxkIGJlIHdlbGNvbWUu DQoNClFpdWZhbmcgTWEob24gYmVoYWxmIG9mIGF1dGhvcnMpDQoNCg0KLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDIw5bm0MTHmnIgy5pelIDIw OjI2DQrmlLbku7bkuro6IEZlbmdjaG9uZyAoZnJhbmspIDxmcmFuay5mZW5nY2hvbmdAaHVhd2Vp LmNvbT47IEZlbmdjaG9uZyAoZnJhbmspIDxmcmFuay5mZW5nY2hvbmdAaHVhd2VpLmNvbT47IG1h cWl1ZmFuZyAoQSkgPG1hcWl1ZmFuZzFAaHVhd2VpLmNvbT4NCuS4u+mimDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1tYS1uZXRjb25mLXdpdGgtc3lzdGVtLTAxLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYS1uZXRjb25mLXdpdGgtc3lzdGVtLTAxLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBRaXVmYW5nIE1hIGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LW1hLW5ldGNvbmYtd2l0 aC1zeXN0ZW0NClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlXaXRoIFN5c3RlbSBDYXBhYmlsaXR5IGZv ciBORVRDT05GDQpEb2N1bWVudCBkYXRlOgkyMDIwLTExLTAyDQpHcm91cDoJCUluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6CQkyMw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL2FyY2hpdmUvaWQvZHJhZnQtbWEtbmV0Y29uZi13aXRoLXN5c3RlbS0wMS50eHQNClN0YXR1 czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYS1uZXRj b25mLXdpdGgtc3lzdGVtLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbWEtbmV0Y29uZi13aXRoLXN5c3RlbQ0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYS1uZXRjb25mLXdpdGgtc3lz dGVtLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LW1hLW5ldGNvbmYtd2l0aC1zeXN0ZW0tMDENCg0KQWJzdHJhY3Q6DQogICBUaGUgTkVU Q09ORiBwcm90b2NvbCBbUkZDNjI0MV0gZGVmaW5lcyB3YXlzIHRvIHJlYWQgY29uZmlndXJhdGlv biBhbmQNCiAgIHN0YXRlIGRhdGEgZnJvbSBhIE5FVENPTkYgc2VydmVyLiAgSW4gc29tZSBjYXNl cywgYSBjbGllbnQtY29uZmlndXJlZA0KICAgZGF0YSBpdGVtIHJlZmVycyB0byBhIG5vbi1leGlz dGVudCBzeXN0ZW0gZ2VuZXJhdGVkIGRhdGEgaXRlbQ0KICAgKGUuZy4sdGhlIGF1dG8tY3JlYXRl IGludGVyZmFjZXMgKCJldGgxIikgaXMgbm90IHlldCBwcmVzZW50KS4gIEluDQogICBtYW55IHNp dHVhdGlvbnMsIHRoZSBzeXN0ZW0gY29uZmlndXJlZCBkYXRhIGl0ZW0gZG9lc24ndCBuZWVkIHRv IGJlDQogICBrbm93IHRvIHRoZSBjbGllbnQgYW5kIGNsaWVudC1jb25maWd1cmVkIGRhdGEgaXRl bSB3aWxsIGF1dG9tYXRpY2FsbHkNCiAgIGJlIHJlbW92ZWQgZnJvbSB0aGUgb3BlcmF0aW9uYWwg c3RhdGUgZGF0YXN0b3JlIGFuZCB0aHVzIG9ubHkgYXBwZWFyDQogICBpbiB0aGUgaW50ZW5kZWQg ZGF0YXN0b3JlIGlmIGNsaWVudC1jb25maWd1cmVkIGRhdGEgaXRlbSBkb2Vzbid0DQogICBleGlz dC4gIEluIG90aGVyIHNpdHVhdGlvbnMgc3lzdGVtIGNvbmZpZ3VyZWQgZGF0YSBpdGVtIG5lZWRz IHRvIGJlDQogICBrbm93biBhbmQgb3ZlcnJpZGVuIGJ5IHRoZSBjbGllbnQuICBOb3QgYWxsIHNl cnZlciBpbXBsZW1lbnRhdGlvbnMNCiAgIHRyZWF0IHRoZSBzeXN0ZW0gY29uZmlndXJhdGlvbiBk YXRhIGluIHRoZSBzYW1lIHdheS4gIFRoaXMgZG9jdW1lbnQNCiAgIGRlZmluZXMgYSBjYXBhYmls aXR5LWJhc2VkIGV4dGVuc2lvbiB0byB0aGUgTkVUQ09ORiBwcm90b2NvbCB0aGF0DQogICBhbGxv d3MgdGhlIE5FVENPTkYgY2xpZW50IHRvIGlkZW50aWZ5IGhvdyBzeXN0ZW0gY29uZmlndXJhdGlv biBhcmUNCiAgIHByb2Nlc3NlZCBieSB0aGUgc2VydmVyLCBhbmQgYWxzbyBkZWZpbmVzIGEgbmV3 IG1lY2hhbmlzbSBmb3IgY2xpZW50DQogICBjb250cm9sIG9mIHNlcnZlciBwcm9jZXNzaW5nIG9m IHN5c3RlbSBjb25maWd1cmF0aW9uIGRhdGEuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg0K From nobody Fri Nov 6 08:06:11 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 CF21E3A07CE; Fri, 6 Nov 2020 08:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ_HbrNohsJc; Fri, 6 Nov 2020 08:06:05 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E4B3A07C4; Fri, 6 Nov 2020 08:06:03 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 58ED8548658; Fri, 6 Nov 2020 17:05:58 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 502E7440059; Fri, 6 Nov 2020 17:05:58 +0100 (CET) Date: Fri, 6 Nov 2020 17:05:58 +0100 From: Toerless Eckert To: Michael Richardson Cc: anima@ietf.org, netconf@ietf.org, iotops@ietf.org Message-ID: <20201106160558.GA48249@faui48f.informatik.uni-erlangen.de> References: <19352.1604423135@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <19352.1604423135@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [netconf] [Anima] what to call different RFC8366 format artifacts 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, 06 Nov 2020 16:06:07 -0000 I like FOO-signed-BAR better because it reminds readers whose life does not enter around FOO or BAR what this is about (signed object). Maybe some time there are different options how FOO can sign BAR, then we may need to add additional distinctions On Tue, Nov 03, 2020 at 12:05:35PM -0500, Michael Richardson wrote: > > Hi, RF8366 specifies a YANG module for a voucher, and the format as > serialized to JSON, and signed by CMS. > > In section 5.4, it is written: > > 5.4. CMS Format Voucher Artifact > The IETF evolution of PKCS#7 is CMS [RFC5652]. A **CMS-signed voucher**, > > In section 8.3, it is written: > Encoding considerations: *CMS-signed JSON* vouchers are ASN.1/DER > encoded. > > So it became natural for me to write "CMS-signed-JSON". > In development of RFC8366, we argued for using JOSE rather than CMS, but > there were, at the time (2016) lack of familiarity with JOSE, and concerns > about having FIPS-140 validation of that code. > > In draft-ietf-anima-constrained-voucher, we introduce two new things: > 1) signing with COSE > 2) encoding with CBOR. > > A number of people have written, rather than "CMS-signed-JSON", instead, > "JSON in CMS". I wondered at the BRSKI design team call last Thursday if > perhaps that order of words translates better into Dutch or German, or ??? > > So to bikeshed the whole thing, please comment on preference in naming: > > 1) RFC8366: CMS-signed-JSON vs JSON-in-CMS. > 2) CV: CMS-signed-CBOR vs CBOR-in-CMS. > 3) CV: COSE-signed-CBOR vs CBOR-in-COSE. > 4) future ID: JWS-signed-JSON vs JSON-in-JOSE. > > I note that for some of these "signed" is redundant. > We do not have COSE-signed-JSON, or JWS-signed-CBOR. > > Which feels more natural to you? > > -- > Michael Richardson . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Nov 9 00:39:02 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 33A163A0CC3 for ; Mon, 9 Nov 2020 00:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 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, 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=MgIqv5jf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ICv7yB/s Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMbp9DeUzV4M for ; Mon, 9 Nov 2020 00:38:58 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580323A0CC1 for ; Mon, 9 Nov 2020 00:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4249; q=dns/txt; s=iport; t=1604911138; x=1606120738; h=from:to:subject:date:message-id:mime-version; bh=cQk5xbeT3+BseTK+6vZlEmQwDfee65jSYi/zGYcEbgI=; b=MgIqv5jfsBZzDQWzU5NOIwDCwsy+Cu1C+JJGkqRNePOsdWi+HrstLaIT JZL6fBdTqGM7d5A3TE6FC45bu2rHs7ypvcSc3dppfuQWDzdkqZY5A6wpj MsnRzs1biFNlRnO55is6FfbnwHHjWax1qfEeFOwyv9VuksQKM5bCbusic c=; X-IPAS-Result: =?us-ascii?q?A0CvCAAN/6hffZxdJa1igQmDISMue1kvLgqHfAOhZ4Rvg?= =?us-ascii?q?lMDVAsBAQENAQEjCgIEAQGESoIUAiU4EwIDAQEBAwIDAQEBAQUBAQECAQYEF?= =?us-ascii?q?AEBhjwMhgsuAQE4EQEMdCcENYMEAYF+VwMuAQMLoiICgTuIaHSBNIMEAQEFg?= =?us-ascii?q?UdBRIJBGIIQAwaBOIJzikwbgUE/gTgcgk+DGwIDAYFDRYMdgiybAYwNkRwKg?= =?us-ascii?q?m0EiQmKUYcvAx+hcJ5HkWuDYgIEAgQFAg4BAQWBayGBWXAVZQGCPj4SFwINk?= =?us-ascii?q?hCFFIVEdDgCBgoBAQMJfIw7AYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3ALJr/ixNYKZMeVs42pCgl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw33l7EQYud7OhL2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YklYBMi4YEfd8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,463,1596499200"; d="scan'208,217";a="621061823" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2020 08:38:57 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A98cvaD000999 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Nov 2020 08:38:57 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 02:38:56 -0600 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; Mon, 9 Nov 2020 03:38:55 -0500 Received: from NAM04-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; Mon, 9 Nov 2020 03:38:55 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WFaJCIlkfqhfqQfzAZ0zL1N1CfZ015P/zjCs+z7pS8P6yGPwqgRJXPxSJ/w+IgIdEmy9qCM6p8V5eS/sL7fbxeMyq8mfY1KsJ/+B48Kbn5bSLIvZa//u+x64M6A7DMniwbwFoFg4eQVicmTiln6Eh8oM/nJi3kGxmdUb7wG6KV5uHo0gs6mPtZhY2KUjABvZIJo8Q96Cacyaj4YrSfn9dhiE2SAY0Lf7S67z+6jnVhAON6FFHQKvUiVQzNEoNkQfM3YRaMHdTniJiDfTbnbGGMI4ngRUYPwJ+oHMUNXZlN9LG4vjB0XzvVh88MJJFvD2KEmD3QzSfqQMGgXAHzuI0g== 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=NDS8F7vGeRI9uWm5ugO9sJ7U/WRqsAPJ+D5Z+RW6Eds=; b=BtKyExymNL1F+OwTxNXnTkK2Hk+TRVdChI18axQb3dlG0qL4prCed7OpTLRehA/+dGmisMZo0KyPyjWigcyK3VvhOWS9Wbt13YwidjNZJGlyKh/bs3klYKWR+/OUOuo0tWcKnuhKOvZbcOl4on4ZEvMr7KxPDclbpFEAPiUEMyV4f86PTeC5bRYvxgfNGuizxqtZPKg+ZBJhg8mOvycxptgMiiUzMXUHiOjSwcKG13KHs8Mpdl1LpWGqLp5QPddmyMf/Fh70+FDGRTImqQae8+0d3G43qXFZNYIyNYgMsR91YcFIZ8OvIfx1M/uv7BEDhhqKj1SBNtoFgFeJ6DarDA== 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=NDS8F7vGeRI9uWm5ugO9sJ7U/WRqsAPJ+D5Z+RW6Eds=; b=ICv7yB/sCAN59JPzQVKhAg+OKb6I6L5brwK77wta7gPCik5t90I2yKnkTW1V/9kYjR2iVjxe7PpwNGGPo7zr2h40Ddr1cUPZfUcwlvYWGn6uxX86GFzBKP0qY8LFPmvsWa0PObm42BtZ9knH9Z/axb0H/Zb4tIa0F4pb3axrzMU= Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by DM6PR11MB2874.namprd11.prod.outlook.com (2603:10b6:5:c9::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Mon, 9 Nov 2020 08:38:53 +0000 Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::6d8e:9b06:ef72:2a]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::6d8e:9b06:ef72:2a%5]) with mapi id 15.20.3541.022; Mon, 9 Nov 2020 08:38:53 +0000 From: "Jan Lindblad (jlindbla)" To: Netconf Thread-Topic: New draft draft-lindblad-netconf-transaction-id-00 Thread-Index: AQHWtnPB/gjKDCS5X0CD8qtneqcrKA== Date: Mon, 9 Nov 2020 08:38:53 +0000 Message-ID: <3BC1F76B-400E-44AB-909F-49A5420858C2@cisco.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.4) 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: [83.209.47.40] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d8f1e88-054b-4947-9128-08d8848ae396 x-ms-traffictypediagnostic: DM6PR11MB2874: 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: 9itLPZBeiOuxlJaJ3MlNMZoP8f7rFUv8uvHnLghRn4/GvbhT47/6oi+u9bNFdobooVBsUhYBUHW+srSkxggmFtCwwMR1t9RWApwHOR81sNHzTlYV5a0KHkuLaYEsfhR1cm/kd6W1i1oMrQHwxxoLIfXd+9HOSQiz94L1ecvtBWt0XkZdRiIBKrYDBVggclAAmdSKEjT1KKfe5VwjXWYua9+FHfKwPcw8KSh15C4oxF4Ds+HQuQVILZNATkxNFS7XGGNHRCdPD6lIhgCwF3XXDAa/TNZDLueVz5pBo7nVWP10kgu0sRLX8z1BxzJ+iF+31ajOQLCtcbkbVnxszl6KIqG1v4tfgfaaLXY1h9+TkJ8BBYa0PYAMG0/BdnjC1U2bH/guimqB9Ibn0pRGUwTsLQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB2841.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(376002)(346002)(136003)(39860400002)(8936002)(91956017)(76116006)(66946007)(6916009)(2616005)(8676002)(166002)(186003)(6506007)(71200400001)(6512007)(33656002)(6486002)(5660300002)(26005)(2906002)(478600001)(966005)(66556008)(66446008)(66476007)(64756008)(4744005)(316002)(86362001)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: FlzG6HbqA/ub6VoPr6J8MeO/7TmJ73tWSAUQN6h4k6mN2+iVzhZAxRWp/2jY3puyBm/rSc7PAx3uO1iIi1F/KHdIFCXDCT3YAN/n8V0vRI/0dvkX0eH1T1IzkVj8JbEyZgD1kwwwCXpU2qV8m6dWs6DhdQM+XZ16j8nzNGBuJIovDCLOyFXDtwXSV1Qz3aJyFTZXBNSlrzmmCcTHh6xHDrD6cLyOqlNRyXchILkdBqo/RGYG5k+425pMkPeoAtV9KOBTK8P/FlhTrcAOSr/12u9pOMFlfIFlH4UdGy+oMEBxmFKu44q80/Iis98wPLZ+hHAmOnHEAuur7ZM3bV9y7RmGeuOWtCB6BilhqqXgA5WCgzPsUyqgGhddyVCArL01pLqAMII+IqwhUU/zRf67mmLWvNpmc5YJRyP+IWJqWz/4A2eEHS5XCibE2u+pEKnaujUJHXPFIiBIbtwhgjbrtLRTv7tFYo0roE/WowWksBTnm9fmAbV+NIQCySMy7sCwee3ZDB1uaPVs/PA3LibBoTBHIYQpYLKi1JV9+OFCTPoBBXWZ373lLa9kcLRbQbtbyS7Ge0vfUrn1g2V/rW/1Xjr0vRGCrbULZvFl5qh/tzqUQB/L1vQ6RXSesiz6HSod26nd0aCq7quqYsFtzlZPKw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3BC1F76B400E44AB909F49A5420858C2ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB2841.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d8f1e88-054b-4947-9128-08d8848ae396 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2020 08:38:53.0854 (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: +ESiY9/Cyclv4/C5KJuD1jHn3TGb3uxpKFRj0x/XKxg+7zHTa4HDE5CXzUNFHl3vI+mDVu5HWnXEpRW2KU/XXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2874 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: [netconf] New draft draft-lindblad-netconf-transaction-id-00 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, 09 Nov 2020 08:39:00 -0000 --_000_3BC1F76B400E44AB909F49A5420858C2ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, A few days ago I submitted a draft on a NETCONF extension for more efficient client-server synchronization. Link below. Unfortunately, I forgot to fill in the abstract in the submission, so it follows here: NETCONF clients and servers often need to have a synchronized view of the server's configuration data stores. The volume of configuration data in a server may be very large, while data store changes typically are small when observed at typical client resynchronization intervals. Rereading the entire data store and analyzing the response for changes is a an inefficient mechanism for synchronization. This document specifies an extension to NETCONF that allows clients and servers to keep synchronized with a much smaller data exchange and without any need for servers to store information about the clients. https://datatracker.ietf.org/doc/draft-lindblad-netconf-transaction-id/ Feel free to discuss here as well as on the IETF109 NETCONF meeting on Nov 18th. Best Regards, /jan --_000_3BC1F76B400E44AB909F49A5420858C2ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8D24BCDC5DC49B4A9D16FF7501F8FEB0@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi all,

A few days ago I submitted a draft on a NETCONF extension f= or
more efficient client-server synchronization. Link below. U= nfortunately,
I forgot to fill in the abstract in the submission, so it f= ollows here:

NET= CONF clients and servers often need to have a synchronized view of
the server's configuration data stores.  The volume of configuration&n= bsp;
data in a server may be very large, while data store changes typically
are small when observed at typical client resynchronization intervals.

Rereading the entire data store and analyzing the response for changes
is a an inefficient mechanism for synchronization.  This document = ;
specifies an extension to NETCONF that allows clients and servers to
keep synchronized with a much smaller data exchange and without any
need for servers to store information about the clients.



Feel free to= discuss here as well as on the IETF109 NETCONF meeting 
on Nov 18th.=

Best Regards= ,
/jan<= /div>

--_000_3BC1F76B400E44AB909F49A5420858C2ciscocom_-- From nobody Mon Nov 9 09:17:04 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 084983A1242 for ; Mon, 9 Nov 2020 09:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] 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 gYHjreiBEJku for ; Mon, 9 Nov 2020 09:17:02 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67FA73A1139 for ; Mon, 9 Nov 2020 09:17:02 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id 11so11304426ljf.2 for ; Mon, 09 Nov 2020 09:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ngrk5jmge4dSmZQC5p+uhnRYDMcIdu3oBAp1sRJTQPY=; b=OD225KEY8PxexVx9C/LNNmnZ1qEfYH1bc2bYhVWX5iUFPg0svbFEivUNPD4AJZFnQI BAi3JJSMlKt1O1x8SONBRn0etXOVQuoVnzn8xSWeJ75fmlOr0hZI6Kq2SqpOmeHWEKXD zV6F0/tknyQcVAOYZPikXw2Qh2ShH5O/qtT4maMqiuyqJ8yuWqz6OQqEkiroSfIiPHNd I6HAtLTtUZ+jqYOz2fJWc+zpjUNc4qeTFz12vfv9cnlAA2GwUT3HucukUtOy132dhnsZ hTcT9g7UuOHRn16E0YIkPsRkr1mI9nFVfwFaCxQk34lfciWpTty35yx75feoC1A6mg3V ma7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ngrk5jmge4dSmZQC5p+uhnRYDMcIdu3oBAp1sRJTQPY=; b=k8iTtSrq7JqcZevwM6xcIq4cZOO+l+rYkE66NnZI58RAAYEBbYTNpOAO8cVf16yDmY 0pddNUs7iuQlTU3s/uQPOKkeSuRiWMIhYUnm/VYmfRIG310ub9s62g4n//uztrabi3E4 /B1MHF1vR18oRnzNxNXN8szpGE7K6xiSvd9wyDquyjW7YQ2qSBEF9njRKqnUzyr/+uqg vnl8IIef8fkR61quS+U/IHaN24JrW7XUWNNM0gffB465Hu5yLH5Ho2PV8+rc9bL2P7SH ZreNEucUKaC0edWYpT9vlbNn7mULhbUiyn4R+28feFTIgl0jzentTZ0NXbtmOYBI2nbr VIzQ== X-Gm-Message-State: AOAM530gzjkwae4tHjvRf51ZICmV9JzWX5nMrtMVGGkLeCz6jQHQfFjU fC/Y/wYWZe3BALOyajvbmeQS6+9z8UdIjZnoO9NOcDoGKj3rGg== X-Google-Smtp-Source: ABdhPJz+1qgPB/Snoc9k54l53bvg8nwE+uyZ5KiV4zbF0XyzrEAhoM7CG9Zqd2eKomYcmMJ1+AHvoM0dwWrdJ4qZyFo= X-Received: by 2002:a2e:a54c:: with SMTP id e12mr2731002ljn.220.1604942220222; Mon, 09 Nov 2020 09:17:00 -0800 (PST) MIME-Version: 1.0 From: Andy Bierman Date: Mon, 9 Nov 2020 09:16:49 -0800 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary="000000000000ebff6105b3afba7f" Archived-At: Subject: [netconf] comments on draft-ietf-netconf-udp-notif-01 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, 09 Nov 2020 17:17:04 -0000 --000000000000ebff6105b3afba7f Content-Type: text/plain; charset="UTF-8" Hi, I have some comments and questions about this draft. sec 3.1: * [I-D.ietf-netconf-notification-messages] describes the structure of the Notification Message for single notifications and bundled notifications.* - The new notification header is very complex, not implemented by anybody, and therefore unproven. The RFC 5277 notification message is widely deployed and should be supported. sec 3.2 * * S represents the space of encoding type specified in the ET field. When S is unset, ET represents the standard encoding types as defined in this document. When S is set, ET represents a private space to be freely used for non standard encodings.* - This new "S bit" payload encoding is not interoperable A) different vendors can pick whatever values they want for the ET field B) There is no reliable way to identify the vendor (or publisher software details) in this protocol * * Observation-Domain-ID is a 32-bit identifier of the Observation Domain that led to the production of the notification message, as defined in [I-D.ietf-netconf-notification-messages]. * - Why is this field needed if it is already in the new notification message? * * The Message ID is generated continuously by the sender of UDP- Notif messages. Different subscribers share the same Message ID sequence.* - It is not clear why the Message-ID field is present. This seems to be all the text about it. The field is OK, but needs clarification A) What is the receiver supposed to do to validate a Message-ID? This implies that some state is maintained by the receiver B) Does this field increment by 1 for every message? Or increment by 1 for every message from the same Observation-Domain-ID? C) How is this field used if the Segmentation Option is used? Suggest: all multi-PDU messages MUST have the same Message-ID in each PDU. D) The 2nd sentence is confusing (subscribers?) Maybe you mean that different subscriptions supported by the same Observation-Domain-ID share the same Message-ID sec 3.3.1: * An implementation of this specification MUST NOT rely on IP fragmentation by default to carry large messages. An implementation of this specification MUST either restrict the size of individual messages carried over this protocol, or support the segmentation option.* - This appears to be the only normative text about the application-level fragmentation and reassembly procedures. A) Is the sender required to finish a multi-PDU message (i.e. send segment 0 through N, in order) before sending a different Message-ID? B) Is it legal to use the option if only 1 segment is sent (i.e., L bit set for Segment 0) C) Is it illegal to send any more segments for the same Message-ID after the L bit has been sent? Andy --000000000000ebff6105b3afba7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have some comments and questions = about this draft.

sec 3.1:

=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-netconf-notification-messa= ges] describes the structure
=C2=A0 =C2=A0 =C2=A0 of the Notification Me= ssage for single notifications and bundled
=C2=A0 =C2=A0 =C2=A0 notifica= tions.

=C2=A0- The new notification header is very comple= x, not implemented by anybody,
=C2=A0 =C2=A0and therefore unproven. The = RFC 5277 notification message is widely deployed
=C2=A0 =C2=A0and should= be supported.


sec 3.2

=C2=A0 =C2=A0* =C2=A0S represen= ts the space of encoding type specified in the ET field.
=C2=A0 =C2=A0 = =C2=A0 When S is unset, ET represents the standard encoding types as
=C2= =A0 =C2=A0 =C2=A0 defined in this document.=C2=A0 When S is set, ET represe= nts a private
=C2=A0 =C2=A0 =C2=A0 space to be freely used for non stand= ard encodings.

=C2=A0- This new "S bit" payload encodi= ng is not interoperable
=C2=A0 =C2=A0 A) different vendors can pick what= ever values they want for the ET field
=C2=A0 =C2=A0 B) There is no reli= able way to identify the vendor (or publisher software details)
=C2=A0 = =C2=A0 in this protocol

=C2=A0 =C2=A0* =C2=A0Observation-Domain-I= D is a 32-bit identifier of the Observation
=C2=A0 =C2=A0 =C2=A0 Domain = that led to the production of the notification message, as
=C2=A0 =C2=A0= =C2=A0 defined in [I-D.ietf-netconf-notification-messages].=C2=A0
<= br>=C2=A0- Why is this field needed if it is already in the new notificatio= n message?

=C2=A0 =C2=A0* =C2=A0The Message ID is generated conti= nuously by the sender of UDP-
=C2=A0 =C2=A0 =C2=A0 Notif messages.=C2=A0= Different subscribers share the same Message ID
=C2=A0 =C2=A0 =C2=A0 se= quence.

=C2=A0- It is not clear why the Message-ID field is pres= ent.=C2=A0 This seems to be all
=C2=A0 =C2=A0the text about it.=C2=A0 Th= e field is OK, but needs clarification

=C2=A0 =C2=A0A) What is the r= eceiver supposed to do to validate a Message-ID?
=C2=A0 =C2=A0 =C2=A0 Th= is implies that some state is maintained by the receiver
=C2=A0 =C2=A0B)= Does this field increment by 1 for every message? Or increment by 1
=C2= =A0 =C2=A0 =C2=A0 for every message from the same Observation-Domain-ID?=C2=A0 =C2=A0C) How is this field used if the Segmentation Option is used?=
=C2=A0 =C2=A0 =C2=A0 Suggest: all multi-PDU messages MUST have the same= Message-ID in each PDU.
=C2=A0 =C2=A0D) The 2nd sentence is confusing (= subscribers?) Maybe you mean that different
=C2=A0 =C2=A0 =C2=A0 subscri= ptions supported by the same Observation-Domain-ID share
=C2=A0 =C2=A0 = =C2=A0 the same Message-ID

sec 3.3.1:

=C2=A0 =C2=A0An impl= ementation of this specification MUST NOT rely on IP
=C2=A0 =C2=A0fragme= ntation by default to carry large messages.=C2=A0 An implementation
=C2= =A0 =C2=A0of this specification MUST either restrict the size of individual=
=C2=A0 =C2=A0messages carried over this protocol, or support the segmen= tation
=C2=A0 =C2=A0option.

=C2=A0- This appears to be the on= ly normative text about the application-level fragmentation
=C2=A0 =C2= =A0and reassembly procedures.
=C2=A0 =C2=A0A) Is the sender required to = finish a multi-PDU message (i.e. send
=C2=A0 =C2=A0 =C2=A0 segment 0 thr= ough N, in order) before sending a different Message-ID?
=C2=A0 =C2=A0B)= Is it legal to use the option if only 1 segment is sent (i.e., L bit
= =C2=A0 =C2=A0 =C2=A0 set for Segment 0)
=C2=A0 =C2=A0C) Is it illegal to= send any more segments for the same Message-ID after
=C2=A0 =C2=A0 =C2= =A0 the L bit has been sent?


An= dy


--000000000000ebff6105b3afba7f-- From nobody Mon Nov 9 18:14: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 B3C0E3A1598 for ; Mon, 9 Nov 2020 18:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnEit3TSKlBU for ; Mon, 9 Nov 2020 18:14:18 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 09E803A1311 for ; Mon, 9 Nov 2020 18:14:18 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id r10so8789773pgb.10 for ; Mon, 09 Nov 2020 18:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wMqicCkkVzxw3rpVI3po48Plie2lvej0zAK27Fa0xvQ=; b=mVu8pnFkCav7SZA1UX3gzeCDeqN+ExFQQdK0cav12ooY6ChbU891OEXy9Te8IEbuI5 /YNeZMbZnXS+8apnlyDuAOcl8k9GAlX0uw44xZUIDBeB9WKXUdExX9K6s4ESAUFsKC8b vn1TyCXpSzWkclSFiTUH2FGlZnNIIs/HuAOjU0hI8oEOvhSkoSvaE2yo58c2xFDl24ZT 1T7CTFE+n19bVOCs03UrFtOo5zz/0MYH4L6nuw/MAxjhAsMHnUK1HNrKtVRQTTyYsv22 g+LP0MYNuAChAoUpQNV/egkZDx7Pf2Z/w1YxLi4pd5JRqW/9TuZWeSyYRUc3RocsZmxz Q7WA== 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=wMqicCkkVzxw3rpVI3po48Plie2lvej0zAK27Fa0xvQ=; b=rz39XeZOAVDTS7pZWoaQF546p4pCq1Yr/Tej+QIYcKl3G/XPYmAfHs/MPXAMe565K+ k0noMVZjBvD4RNRSsmHIB0mnD0B+wE7n7wY08eA7VdkI5RI9GnIGwtD6wErw2omBHYD/ S0XEqUXruTCiZUWqfM5wmh8iu9H4mX4dzS+byIRK+6Tgmro3z5ZBODVXKM4IfDQvh0Tj jVnKpmPZJh2t3TNoA53I2VgaoUVOaisi9JTLdYYLaijUu90O1kzOmo1uWT7vZCe0SoqI 92kHOC4fu8kSxh0eLlhklBiwvnINumdK7GUXJJeOCAPWJxeLYqDQP8SlBqHtn1ecPQV7 kCPA== X-Gm-Message-State: AOAM530bcvmRuwtEN7fXT+hSJ+hvojrSXkwIAbUL1GVvNwszNsHXIYcD rZNxIvkN/irpIb7bkceQQ5QorZkLkDo= X-Google-Smtp-Source: ABdhPJzdfFWtUdJCZvayk4SqDpcucyQfbb76qLw1bT/G6ENNywlmt/uWaiK7nw6489qKOpphSPK+6g== X-Received: by 2002:a17:90a:f492:: with SMTP id bx18mr194782pjb.123.1604974456961; Mon, 09 Nov 2020 18:14:16 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:4533:862b:a684:b838? ([2601:647:5600:5020:4533:862b:a684:b838]) by smtp.gmail.com with ESMTPSA id f16sm10878494pgk.48.2020.11.09.18.14.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2020 18:14:16 -0800 (PST) From: Mahesh Jethanandani Message-Id: <646CC099-EEA9-4FAC-BAA4-777BB67D0712@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7D919344-61C8-402A-9EC2-025834E246B3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 9 Nov 2020 18:14:14 -0800 In-Reply-To: To: Netconf References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] comments on draft-ietf-netconf-udp-notif-01 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, 10 Nov 2020 02:14:20 -0000 --Apple-Mail=_7D919344-61C8-402A-9EC2-025834E246B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 most of these comments. Also please fix all the indentation and max = length of 72 in the YANG model. > On Nov 9, 2020, at 9:16 AM, Andy Bierman wrote: >=20 > Hi, >=20 > I have some comments and questions about this draft. >=20 > sec 3.1: >=20 > [I-D.ietf-netconf-notification-messages] describes the structure > of the Notification Message for single notifications and bundled > notifications. >=20 > - The new notification header is very complex, not implemented by = anybody, > and therefore unproven. The RFC 5277 notification message is widely = deployed > and should be supported. >=20 >=20 > sec 3.2 Would suggest that the version field start with a value which is = non-zero. A zero does not indicate if the value was set or the field was = uninitialized. Same for ET field. >=20 > * S represents the space of encoding type specified in the ET = field. > When S is unset, ET represents the standard encoding types as > defined in this document. When S is set, ET represents a = private > space to be freely used for non standard encodings. >=20 > - This new "S bit" payload encoding is not interoperable > A) different vendors can pick whatever values they want for the ET = field > B) There is no reliable way to identify the vendor (or publisher = software details) > in this protocol +1 Is there a method by which the other end will learn the encoding that is = going to be sent or does the publisher just start sending a given = encoding whether the other end supports or not? Would suggest that you = pick a default encoding that both ends have to support, and then come up = with a method by which the other encodings can be learnt. >=20 > * Observation-Domain-ID is a 32-bit identifier of the Observation > Domain that led to the production of the notification message, = as > defined in [I-D.ietf-netconf-notification-messages].=20 >=20 > - Why is this field needed if it is already in the new notification = message? >=20 > * The Message ID is generated continuously by the sender of UDP- > Notif messages. Different subscribers share the same Message ID > sequence. >=20 > - It is not clear why the Message-ID field is present. This seems to = be all > the text about it. The field is OK, but needs clarification >=20 > A) What is the receiver supposed to do to validate a Message-ID? > This implies that some state is maintained by the receiver > B) Does this field increment by 1 for every message? Or increment = by 1 > for every message from the same Observation-Domain-ID? > C) How is this field used if the Segmentation Option is used? > Suggest: all multi-PDU messages MUST have the same Message-ID in = each PDU. > D) The 2nd sentence is confusing (subscribers?) Maybe you mean that = different > subscriptions supported by the same Observation-Domain-ID share > the same Message-ID >=20 > sec 3.3.1: >=20 > An implementation of this specification MUST NOT rely on IP > fragmentation by default to carry large messages. An = implementation > of this specification MUST either restrict the size of individual > messages carried over this protocol, or support the segmentation > option. >=20 > - This appears to be the only normative text about the = application-level fragmentation > and reassembly procedures. > A) Is the sender required to finish a multi-PDU message (i.e. send > segment 0 through N, in order) before sending a different = Message-ID? > B) Is it legal to use the option if only 1 segment is sent (i.e., L = bit > set for Segment 0) > C) Is it illegal to send any more segments for the same Message-ID = after > the L bit has been sent? >=20 >=20 > Andy Section 7 The draft requests a port assignment for UDP notification. Not sure that = it is needed. The YANG model already defines a way to configure a port, = and it is mandatory. Thanks. >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_7D919344-61C8-402A-9EC2-025834E246B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1 = most of these comments. Also please fix all the indentation and max = length of 72 in the YANG model.

On Nov = 9, 2020, at 9:16 AM, Andy Bierman <andy@yumaworks.com> = wrote:

Hi,

I have some comments and questions about this draft.

sec = 3.1:

      = [I-D.ietf-netconf-notification-messages] describes the structure
      of the Notification Message for single = notifications and bundled
      = notifications.

 - The new = notification header is very complex, not implemented by anybody,
   and therefore unproven. The RFC 5277 = notification message is widely deployed
   and = should be supported.


sec = 3.2

Would suggest that the version field start with a value = which is non-zero. A zero does not indicate if the value was set or the = field was uninitialized. Same for ET field.


   *  S represents the space of = encoding type specified in the ET field.
    =   When S is unset, ET represents the standard encoding types as
      defined in this document.  When S = is set, ET represents a private
      space = to be freely used for non standard = encodings.

 - This new "S bit" = payload encoding is not interoperable
    A) = different vendors can pick whatever values they want for the ET field
    B) There is no reliable way to identify the = vendor (or publisher software details)
    in = this protocol

+1

Is there a = method by which the other end will learn the encoding that is going to = be sent or does the publisher just start sending a given encoding = whether the other end supports or not? Would suggest that you pick a = default encoding that both ends have to support, and then come up with a = method by which the other encodings can be learnt.


   * =  Observation-Domain-ID is a 32-bit identifier of the Observation
      Domain that led to the production of the = notification message, as
      defined in = [I-D.ietf-netconf-notification-messages]. 

 - Why is this field needed if it is already in the new = notification message?

  =  *  The Message ID is generated continuously by the sender of = UDP-
      Notif messages.  Different = subscribers share the same Message ID
      = sequence.

 - It is not clear why = the Message-ID field is present.  This seems to be all
   the text about it.  The field is OK, but = needs clarification

   A) What is = the receiver supposed to do to validate a Message-ID?
 =     This implies that some state is maintained by the = receiver
   B) Does this field increment by 1 = for every message? Or increment by 1
      = for every message from the same Observation-Domain-ID?
   C) How is this field used if the Segmentation = Option is used?
      Suggest: all = multi-PDU messages MUST have the same Message-ID in each PDU.
   D) The 2nd sentence is confusing (subscribers?) = Maybe you mean that different
      = subscriptions supported by the same Observation-Domain-ID share
      the same Message-ID

sec 3.3.1:

  =  An implementation of this specification MUST NOT rely on IP
   fragmentation by default to carry large = messages.  An implementation
   of this = specification MUST either restrict the size of individual
   messages carried over this protocol, or support = the segmentation
   option.

 - This appears to be the only normative text about the = application-level fragmentation
   and = reassembly procedures.
   A) Is the sender = required to finish a multi-PDU message (i.e. send
  =     segment 0 through N, in order) before sending a different = Message-ID?
   B) Is it legal to use the option = if only 1 segment is sent (i.e., L bit
    =   set for Segment 0)
   C) Is it illegal to = send any more segments for the same Message-ID after
  =     the L bit has been sent?


Andy

Section 7

The draft = requests a port assignment for UDP notification. Not sure that it is = needed. The YANG model already defines a way to configure a port, and it = is mandatory.

Thanks.



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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_7D919344-61C8-402A-9EC2-025834E246B3-- From nobody Tue Nov 10 04:05:46 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 1FDD23A09F5 for ; Tue, 10 Nov 2020 04:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fX0mbI2mDNgd for ; Tue, 10 Nov 2020 04:05:42 -0800 (PST) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 3DC533A09F0 for ; Tue, 10 Nov 2020 04:05:42 -0800 (PST) Received: by mail-ua1-x932.google.com with SMTP id k12so1359145uae.13 for ; Tue, 10 Nov 2020 04:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xXeh9PEBndbE/0qq3cYyfhhkB17iqCuKA1SVrT40mVw=; b=g8nAMsVXKy2RCryoWGmhFq8l44Q4MdFmf7V/vy64WkfL5StdB2nHbokU213A6WoEDN +2cQSFc5Z993Mt9T9tSyS5arJYm63loBDGwNPe4RQUlc9HbCqiOaWVvAOe4BGfjZ5WKw NjCN++K2bSzS50lbTyhs2/effcx17ztDW3m2dLEJsUmyCLSu+Bdfw98x9G0gG4bnXjPY Pa0Yar8FFftm6YEKhcOmRWCacL8++j2llXZIuKEId/XR7cuF17P6bRXq7woOm3l9656l pVYx4zJifIv7lmPQDMnCtuUVN1+Lx5eR3VEQSTnqD76UW9hDior2REJ5rxff6D0tCLRG qtLQ== 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=xXeh9PEBndbE/0qq3cYyfhhkB17iqCuKA1SVrT40mVw=; b=goXj1FOjgGyCXLTphbuYANCao3BB6iLyrwt0DwABA++bGkxp/sM6dnO4tKGGiaGUU1 HYw2uTKhqyEQWA/Ubn1I6KEJP55HBICq371vIQFYUexHq8HwBHLXXr+lK8LdPfWoOUVg SkXPYRxbXEOE3lVgfyssN0492mrhFVAz9qMicrepwMQOnNpv2DJnD8NqMAgOXiF5+HJL iCOmjodvpkj02SHOjmzP79QGTASTG+WsxT6vNqGM6OqcwXJZJYD4lB8tsfBs3SY7V4K+ WUnrZ1XrLz1xzUaaSVXS97DkWXDdXAqprts31swXlghRl7vJF4kigzT1Izqg7nLEzedR hbAA== X-Gm-Message-State: AOAM533/QvcvXINJvT+RVHDItvg1RxvoCym+QO0CdkpWGAPGs+MS1Aj7 L1GoqbuBH9ooKM3Ayx2R6K2jWlLUMMDD3zFSAjg= X-Google-Smtp-Source: ABdhPJxWNRHGoueC5WqL21JlgVUTCHeY3ijbZ4b4omtsNfns9LVSh5zUPS8nfhgL84fNwmsTLOVI37ulr/56aUv2iOY= X-Received: by 2002:ab0:6cb6:: with SMTP id j22mr8902604uaa.82.1605009941242; Tue, 10 Nov 2020 04:05:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pierre Francois Date: Tue, 10 Nov 2020 13:05:30 +0100 Message-ID: To: Andy Bierman Cc: Netconf Content-Type: multipart/alternative; boundary="00000000000068a85205b3bf7fae" Archived-At: Subject: Re: [netconf] comments on draft-ietf-netconf-udp-notif-01 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, 10 Nov 2020 12:05:44 -0000 --00000000000068a85205b3bf7fae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy, Thank you for the thorough review. I agree with everything, mostly. I'll cover your questions during the meeting. Cheers, Pierre. Le lun. 9 nov. 2020 =C3=A0 18:17, Andy Bierman a =C3= =A9crit : > Hi, > > I have some comments and questions about this draft. > > sec 3.1: > > > > * [I-D.ietf-netconf-notification-messages] describes the structure > of the Notification Message for single notifications and bundled > notifications.* > > - The new notification header is very complex, not implemented by anybod= y, > and therefore unproven. The RFC 5277 notification message is widely > deployed > and should be supported. > > > sec 3.2 > > > > > > * * S represents the space of encoding type specified in the ET field. > When S is unset, ET represents the standard encoding types as > defined in this document. When S is set, ET represents a private > space to be freely used for non standard encodings.* > - This new "S bit" payload encoding is not interoperable > A) different vendors can pick whatever values they want for the ET > field > B) There is no reliable way to identify the vendor (or publisher > software details) > in this protocol > > > > * * Observation-Domain-ID is a 32-bit identifier of the Observation > Domain that led to the production of the notification message, as > defined in [I-D.ietf-netconf-notification-messages]. * > > - Why is this field needed if it is already in the new notification > message? > > > > > * * The Message ID is generated continuously by the sender of UDP- > Notif messages. Different subscribers share the same Message ID > sequence.* > - It is not clear why the Message-ID field is present. This seems to be > all > the text about it. The field is OK, but needs clarification > > A) What is the receiver supposed to do to validate a Message-ID? > This implies that some state is maintained by the receiver > B) Does this field increment by 1 for every message? Or increment by 1 > for every message from the same Observation-Domain-ID? > C) How is this field used if the Segmentation Option is used? > Suggest: all multi-PDU messages MUST have the same Message-ID in > each PDU. > D) The 2nd sentence is confusing (subscribers?) Maybe you mean that > different > subscriptions supported by the same Observation-Domain-ID share > the same Message-ID > > sec 3.3.1: > > > > > > * An implementation of this specification MUST NOT rely on IP > fragmentation by default to carry large messages. An implementation o= f > this specification MUST either restrict the size of individual messages > carried over this protocol, or support the segmentation option.* > > - This appears to be the only normative text about the application-level > fragmentation > and reassembly procedures. > A) Is the sender required to finish a multi-PDU message (i.e. send > segment 0 through N, in order) before sending a different Message-I= D? > B) Is it legal to use the option if only 1 segment is sent (i.e., L bi= t > set for Segment 0) > C) Is it illegal to send any more segments for the same Message-ID aft= er > the L bit has been sent? > > > Andy > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --00000000000068a85205b3bf7fae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Andy,=C2=A0

Thank you for the thorough = review.=C2=A0
I agree with everything, mostly. I'll cover you= r questions during the meeting.=C2=A0

Cheers,=C2= =A0

Pierre.




Le=C2=A0lun. 9 nov. 2020 =C3=A0=C2=A018:17, Andy Bierman <andy@yumaworks.com> a =C3=A9crit= =C2=A0:
Hi,

I= have some comments and questions about this draft.

= sec 3.1:

=C2=A0 =C2=A0 =C2=A0 [I= -D.ietf-netconf-notification-messages] describes the structure
=C2=A0 = =C2=A0 =C2=A0 of the Notification Message for single notifications and bund= led
=C2=A0 =C2=A0 =C2=A0 notifications.

=C2=A0- The ne= w notification header is very complex, not implemented by anybody,
=C2= =A0 =C2=A0and therefore unproven. The RFC 5277 notification message is wide= ly deployed
=C2=A0 =C2=A0and should be supported.


sec 3.2
=
=C2=A0 =C2=A0* =C2=A0S represents the space of encoding type specifi= ed in the ET field.
=C2=A0 =C2=A0 =C2=A0 When S is unset, ET represents = the standard encoding types as
=C2=A0 =C2=A0 =C2=A0 defined in this docu= ment.=C2=A0 When S is set, ET represents a private
=C2=A0 =C2=A0 =C2=A0 = space to be freely used for non standard encodings.

=C2=A0- This= new "S bit" payload encoding is not interoperable
=C2=A0 =C2= =A0 A) different vendors can pick whatever values they want for the ET fiel= d
=C2=A0 =C2=A0 B) There is no reliable way to identify the vendor (or p= ublisher software details)
=C2=A0 =C2=A0 in this protocol

=C2= =A0 =C2=A0* =C2=A0Observation-Domain-ID is a 32-bit identifier of the Obser= vation
=C2=A0 =C2=A0 =C2=A0 Domain that led to the production of the not= ification message, as
=C2=A0 =C2=A0 =C2=A0 defined in [I-D.ietf-netconf-= notification-messages].=C2=A0

=C2=A0- Why is this field needed i= f it is already in the new notification message?

=C2=A0 =C2=A0* = =C2=A0The Message ID is generated continuously by the sender of UDP-
=C2= =A0 =C2=A0 =C2=A0 Notif messages.=C2=A0 Different subscribers share the sam= e Message ID
=C2=A0 =C2=A0 =C2=A0 sequence.

=C2=A0- It is not= clear why the Message-ID field is present.=C2=A0 This seems to be all
= =C2=A0 =C2=A0the text about it.=C2=A0 The field is OK, but needs clarificat= ion

=C2=A0 =C2=A0A) What is the receiver supposed to do to validate = a Message-ID?
=C2=A0 =C2=A0 =C2=A0 This implies that some state is maint= ained by the receiver
=C2=A0 =C2=A0B) Does this field increment by 1 for= every message? Or increment by 1
=C2=A0 =C2=A0 =C2=A0 for every message= from the same Observation-Domain-ID?
=C2=A0 =C2=A0C) How is this field = used if the Segmentation Option is used?
=C2=A0 =C2=A0 =C2=A0 Suggest: a= ll multi-PDU messages MUST have the same Message-ID in each PDU.
=C2=A0 = =C2=A0D) The 2nd sentence is confusing (subscribers?) Maybe you mean that d= ifferent
=C2=A0 =C2=A0 =C2=A0 subscriptions supported by the same Observ= ation-Domain-ID share
=C2=A0 =C2=A0 =C2=A0 the same Message-ID

se= c 3.3.1:

=C2=A0 =C2=A0An implementation of this specification MUS= T NOT rely on IP
=C2=A0 =C2=A0fragmentation by default to carry large me= ssages.=C2=A0 An implementation
=C2=A0 =C2=A0of this specification MUST = either restrict the size of individual
=C2=A0 =C2=A0messages carried ove= r this protocol, or support the segmentation
=C2=A0 =C2=A0option.
=C2=A0- This appears to be the only normative text about the applicati= on-level fragmentation
=C2=A0 =C2=A0and reassembly procedures.
=C2=A0= =C2=A0A) Is the sender required to finish a multi-PDU message (i.e. send=C2=A0 =C2=A0 =C2=A0 segment 0 through N, in order) before sending a diff= erent Message-ID?
=C2=A0 =C2=A0B) Is it legal to use the option if only = 1 segment is sent (i.e., L bit
=C2=A0 =C2=A0 =C2=A0 set for Segment 0)=C2=A0 =C2=A0C) Is it illegal to send any more segments for the same Mess= age-ID after
=C2=A0 =C2=A0 =C2=A0 the L bit has been sent?


Andy


_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--00000000000068a85205b3bf7fae-- From nobody Tue Nov 10 04:09:13 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 E0FCF3A09FC for ; Tue, 10 Nov 2020 04:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 2SuAAVFA1tVT for ; Tue, 10 Nov 2020 04:09:10 -0800 (PST) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 210C93A09F6 for ; Tue, 10 Nov 2020 04:09:10 -0800 (PST) Received: by mail-ua1-x92d.google.com with SMTP id q68so3853131uaq.3 for ; Tue, 10 Nov 2020 04:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=77cX9arbzNdXkDE8eSlz/0hxBjg/B5jgU66DLYPCzVw=; b=YSFmdFoMvI/NgEtnzaNoJ03nX2HQAjZWARywVHnJZKEjK54E1E6D9X/eMflPfaKDxS IjSIhOA8uTjyJewd/wGLvJbug3hSZpdyHPbmCU7Pd0qXmMvzhzg4qQuZoGESPMyp7i1N ZPJgV11JBKatIZH1OOO17e6st6zm+BLvlOYAnEd7E/2IWcemtYIsi+h8yyUVT4WoKMAu LUk6RKXMoMQNyyv9SApL9bXJ8JZKTecN11S12P7FmOK9Oh2YO2mfY/urYyEvgb271a9e awZP9+hu9B/vDsGfxUTfvYDdsW3t83N5Orbo6V6YdF/8vn1tjzKKsZX/5iy1EOWftYZy wOAQ== 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=77cX9arbzNdXkDE8eSlz/0hxBjg/B5jgU66DLYPCzVw=; b=PlhPXtNK+j6sm5DRZbl84n3jhGt3H8RXWtQFlF2meiQRqoycgJJKmY6y6O7ywRDvLA eHposUeTrQijlSGxcIS40OZYcUNFfpHmSkxIrppjQxMwL+537HunLjGo66NYFg+3WOiC p8GMd75k+UW0MmRX0Kq7QADybcYaRvWbfm+uLHjohqU8iEu4+kGYO0CRALcsaEQX/j53 lDuf1Ks2sNfV9ptCXFvwnli09koLGBFhOwT/2dgcp+obw9kMbfzKCp93McrMVxLUUEmN FZYRfihrOWvk6tXbbdVhlIspmlcR0QFXYMOGF4OHt1bHDfv26PSI8D1NJsG9C6p+N4oS Bs3g== X-Gm-Message-State: AOAM5339d6uRY4g2CmYTL46AAsfn3AQFVOkHykIuO5vymTEIeyJ4e/v2 8iGMlnUJBxWGcUDmB+EUgHvdQyCWNq0o9spMwNQ= X-Google-Smtp-Source: ABdhPJxGWHykD3vKJmCMOBpWuaOWuq9gMzqr2l1Ce8t09FmQPFS3Ta/syV+znHjP/POpKJJzkVdvp3mddcjtGJdXeoE= X-Received: by 2002:a9f:2a87:: with SMTP id z7mr4959906uai.133.1605010149077; Tue, 10 Nov 2020 04:09:09 -0800 (PST) MIME-Version: 1.0 References: <646CC099-EEA9-4FAC-BAA4-777BB67D0712@gmail.com> In-Reply-To: <646CC099-EEA9-4FAC-BAA4-777BB67D0712@gmail.com> From: Pierre Francois Date: Tue, 10 Nov 2020 13:08:58 +0100 Message-ID: To: Mahesh Jethanandani Cc: Netconf Content-Type: multipart/alternative; boundary="000000000000cbf49d05b3bf8bd6" Archived-At: Subject: Re: [netconf] comments on draft-ietf-netconf-udp-notif-01 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, 10 Nov 2020 12:09:12 -0000 --000000000000cbf49d05b3bf8bd6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mahesh, Le mar. 10 nov. 2020 =C3=A0 03:14, Mahesh Jethanandani a =C3=A9crit : > +1 most of these comments. > Same :) > Also please fix all the indentation and max length of 72 in the YANG mode= l. > Done. Will be included in the -02. > > On Nov 9, 2020, at 9:16 AM, Andy Bierman wrote: > > Hi, > > I have some comments and questions about this draft. > > sec 3.1: > > > > * [I-D.ietf-netconf-notification-messages] describes the structure > of the Notification Message for single notifications and bundled > notifications.* > > - The new notification header is very complex, not implemented by anybod= y, > and therefore unproven. The RFC 5277 notification message is widely > deployed > and should be supported. > > > sec 3.2 > > > Would suggest that the version field start with a value which is non-zero= . > A zero does not indicate if the value was set or the field was > uninitialized. Same for ET field. > ok. > > > > > > * * S represents the space of encoding type specified in the ET field. > When S is unset, ET represents the standard encoding types as > defined in this document. When S is set, ET represents a private > space to be freely used for non standard encodings.* > > > - This new "S bit" payload encoding is not interoperable > A) different vendors can pick whatever values they want for the ET > field > B) There is no reliable way to identify the vendor (or publisher > software details) > in this protocol > > > +1 > > Is there a method by which the other end will learn the encoding that is > going to be sent or does the publisher just start sending a given encodin= g > whether the other end supports or not? Would suggest that you pick a > default encoding that both ends have to support, and then come up with a > method by which the other encodings can be learnt. > I think this requires a discussion. During the meeting ok? > > > > > * * Observation-Domain-ID is a 32-bit identifier of the Observation > Domain that led to the production of the notification message, as > defined in [I-D.ietf-netconf-notification-messages]. * > > - Why is this field needed if it is already in the new notification > message? > > > > > * * The Message ID is generated continuously by the sender of UDP- > Notif messages. Different subscribers share the same Message ID > sequence.* > - It is not clear why the Message-ID field is present. This seems to be > all > the text about it. The field is OK, but needs clarification > > A) What is the receiver supposed to do to validate a Message-ID? > This implies that some state is maintained by the receiver > B) Does this field increment by 1 for every message? Or increment by 1 > for every message from the same Observation-Domain-ID? > C) How is this field used if the Segmentation Option is used? > Suggest: all multi-PDU messages MUST have the same Message-ID in > each PDU. > D) The 2nd sentence is confusing (subscribers?) Maybe you mean that > different > subscriptions supported by the same Observation-Domain-ID share > the same Message-ID > > sec 3.3.1: > > > > > > * An implementation of this specification MUST NOT rely on IP > fragmentation by default to carry large messages. An implementation o= f > this specification MUST either restrict the size of individual messages > carried over this protocol, or support the segmentation option.* > > - This appears to be the only normative text about the application-level > fragmentation > and reassembly procedures. > A) Is the sender required to finish a multi-PDU message (i.e. send > segment 0 through N, in order) before sending a different Message-I= D? > B) Is it legal to use the option if only 1 segment is sent (i.e., L bi= t > set for Segment 0) > C) Is it illegal to send any more segments for the same Message-ID aft= er > the L bit has been sent? > > > Andy > > > Section 7 > > The draft requests a port assignment for UDP notification. Not sure that > it is needed. The YANG model already defines a way to configure a port, a= nd > it is mandatory. > Agreed. Thank you, Pierre. > > Thanks. > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000cbf49d05b3bf8bd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mahesh,=C2=A0

Le=C2=A0mar. 10 n= ov. 2020 =C3=A0=C2=A003:14, Mahesh Jethanandani <mjethanandani@gmail.com> a =C3=A9crit=C2=A0:
=
+1 most of these comments.

<= div>Same :)
=C2=A0
Also please fix all the indentat= ion and max length of 72 in the YANG model.

=
Done. Will be included in the -02.
=C2=A0
=

On Nov 9, 2020, at 9:16 AM, Andy Bi= erman <andy@yuma= works.com> wrote:

Hi,

<= div>I have some comments and questions about this draft.

=
sec 3.1:

=C2=A0 =C2=A0 =C2= =A0 [I-D.ietf-netconf-notification-messages] describes the structure
=C2= =A0 =C2=A0 =C2=A0 of the Notification Message for single notifications and = bundled
=C2=A0 =C2=A0 =C2=A0 notifications.

=C2=A0- Th= e new notification header is very complex, not implemented by anybody,
= =C2=A0 =C2=A0and therefore unproven. The RFC 5277 notification message is w= idely deployed
=C2=A0 =C2=A0and should be supported.


sec 3.2<= br>

Would suggest that t= he version field start with a value which is non-zero. A zero does not indi= cate if the value was set or the field was uninitialized. Same for ET field= .

ok.=C2=A0
=C2=A0


=C2=A0 =C2=A0* =C2=A0S represents the space of encoding type speci= fied in the ET field.
=C2=A0 =C2=A0 =C2=A0 When S is unset, ET represent= s the standard encoding types as
=C2=A0 =C2=A0 =C2=A0 defined in this do= cument.=C2=A0 When S is set, ET represents a private
=C2=A0 =C2=A0 =C2= =A0 space to be freely used for non standard encodings.

=C2=A0- This new "S bit" payload encoding is n= ot interoperable
=C2=A0 =C2=A0 A) different vendors can pick whatever va= lues they want for the ET field
=C2=A0 =C2=A0 B) There is no reliable wa= y to identify the vendor (or publisher software details)
=C2=A0 =C2=A0 i= n this protocol

+1

Is there a method by which the other end will = learn the encoding that is going to be sent or does the publisher just star= t sending a given encoding whether the other end supports or not? Would sug= gest that you pick a default encoding that both ends have to support, and t= hen come up with a method by which the other encodings can be learnt.
=

I think this requires a discus= sion. During the meeting ok?

=C2=A0


=C2=A0 =C2=A0* =C2=A0Observation-Domain-= ID is a 32-bit identifier of the Observation
=C2=A0 =C2=A0 =C2=A0 Domain= that led to the production of the notification message, as
=C2=A0 =C2= =A0 =C2=A0 defined in [I-D.ietf-netconf-notification-messages].=C2=A0
=C2=A0- Why is this field needed if it is already in the new notifica= tion message?

=C2=A0 =C2=A0* =C2=A0The Message ID is generated co= ntinuously by the sender of UDP-
=C2=A0 =C2=A0 =C2=A0 Notif messages.=C2= =A0 Different subscribers share the same Message ID
=C2=A0 =C2=A0 =C2=A0= sequence.

=C2=A0- It is not clear why the Message-ID field is p= resent.=C2=A0 This seems to be all
=C2=A0 =C2=A0the text about it.=C2=A0= The field is OK, but needs clarification

=C2=A0 =C2=A0A) What is th= e receiver supposed to do to validate a Message-ID?
=C2=A0 =C2=A0 =C2=A0= This implies that some state is maintained by the receiver
=C2=A0 =C2= =A0B) Does this field increment by 1 for every message? Or increment by 1=C2=A0 =C2=A0 =C2=A0 for every message from the same Observation-Domain-I= D?
=C2=A0 =C2=A0C) How is this field used if the Segmentation Option is = used?
=C2=A0 =C2=A0 =C2=A0 Suggest: all multi-PDU messages MUST have the= same Message-ID in each PDU.
=C2=A0 =C2=A0D) The 2nd sentence is confus= ing (subscribers?) Maybe you mean that different
=C2=A0 =C2=A0 =C2=A0 su= bscriptions supported by the same Observation-Domain-ID share
=C2=A0 =C2= =A0 =C2=A0 the same Message-ID

sec 3.3.1:

=C2=A0 =C2=A0An = implementation of this specification MUST NOT rely on IP
=C2=A0 =C2=A0fr= agmentation by default to carry large messages.=C2=A0 An implementation
= =C2=A0 =C2=A0of this specification MUST either restrict the size of individ= ual
=C2=A0 =C2=A0messages carried over this protocol, or support the seg= mentation
=C2=A0 =C2=A0option.

=C2=A0- This appears to be the= only normative text about the application-level fragmentation
=C2=A0 = =C2=A0and reassembly procedures.
=C2=A0 =C2=A0A) Is the sender required = to finish a multi-PDU message (i.e. send
=C2=A0 =C2=A0 =C2=A0 segment 0 = through N, in order) before sending a different Message-ID?
=C2=A0 =C2= =A0B) Is it legal to use the option if only 1 segment is sent (i.e., L bit<= br>=C2=A0 =C2=A0 =C2=A0 set for Segment 0)
=C2=A0 =C2=A0C) Is it illegal= to send any more segments for the same Message-ID after
=C2=A0 =C2=A0 = =C2=A0 the L bit has been sent?


Andy

Section 7

The draft requests a port assignment for UDP notification.= Not sure that it is needed. The YANG model already defines a way to config= ure a port, and it is mandatory.


Agreed.

Thank you,=C2=A0

Pierre.
=C2=A0

= Thanks.

=


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

Mahesh Jethanandani
=





_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000cbf49d05b3bf8bd6-- From nobody Wed Nov 11 10:49:07 2020 Return-Path: <01000175b8a3c5ec-f9d61e60-8032-4f03-86dc-b5fb62d4b47e-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 22AE83A0C8E; Wed, 11 Nov 2020 10:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 KWKHqtzOMi2U; Wed, 11 Nov 2020 10:49:03 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833EC3A0BB3; Wed, 11 Nov 2020 10:49:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1605120542; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=FaXxZ2s69W/Beiuq98PnZ3FvVLagfbSriwCAQs7g4tg=; b=IZrZKkIqGDf7W+ZqZiz5jiWSZv0n9HbrSSpAlj4USCicqfg6VCrTo6ByR7AyvUeV akmzUswsgN5sYE/I17mOKj2qHsr2GXpIvWKqUlrb621VpOkpjiMaTOvm/NOJxWsM7PV mwwMGiTwlmXD8gOsTUI3ATdQw8zp4SAWw6x8r7DY= 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: <01000175943b8fa6-b54bce58-6e09-4759-9d19-1bc4c85ce8cf-000000@email.amazonses.com> Date: Wed, 11 Nov 2020 18:49:02 +0000 Cc: "netconf-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000175b8a3c5ec-f9d61e60-8032-4f03-86dc-b5fb62d4b47e-000000@email.amazonses.com> References: <01000175943b8fa6-b54bce58-6e09-4759-9d19-1bc4c85ce8cf-000000@email.amazonses.com> To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.11.11-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Draft 109 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: Wed, 11 Nov 2020 18:49:05 -0000 The agenda has been updated. The update adds the URL for the draft "Transaction ID Mechanism for = NETCONF=E2=80=9D. Thanks, NETCONF Chairs Agenda for the NETCONF 109 WG Session ------------------------------------- https://datatracker.ietf.org/meeting/109/materials/agenda-109-netconf Session: Wednesday, November 18 UTC+07: 12:00-14:00 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/109/sessions/netconf.ics MeetEcho: = https://meetings.conf.meetecho.com/ietf109/?group=3Dnetconf Jabber: xmpp:netconf@jabber.ietf.org?join Available During and After Session: CodiMD: https://codimd.ietf.org/notes-ietf-109-netconf Slides (TGZ): = https://datatracker.ietf.org/meeting/109/agenda/netconf-drafts.tgz Slides (PDF): = https://datatracker.ietf.org/meeting/109/agenda/netconf-drafts.pdf Available After Session: Recording: = https://ietf109.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-18 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13 https://tools.ietf.org/html/draft-ietf-netconf-keystore-20 https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-08 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-22 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-22 https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-05 = https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-21 = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-21 Discussion Leader: Kent Watsen Conveying a CSR in a SZTP Bootstrapping Request (10 min) https://tools.ietf.org/html/draft-ietf-netconf-sztp-csr-00 Discussion Leader: Kent Watsen An HTTPS-based Transport for Configured Subscriptions (10 min) https://tools.ietf.org/html/draft-ietf-netconf-https-notif-05 Discussion Leader: Mahesh Jethanandani UDP-based Transport for Configured Subscriptions (10 min) https://tools.ietf.org/html/draft-ietf-netconf-udp-notif-01 Discussion Leader: Pierre Francois Subscription to Distributed Notifications (10 min) https://tools.ietf.org/html/draft-ietf-netconf-distributed-notif-01 Discussion Leader: Thomas Graf Non-Chartered items: Self-explanation Data Node Tag & Telemetry Data Export Capabilities = (10 min) = https://tools.ietf.org/html/draft-tao-netconf-notif-node-tag-capabilities-= 02 = https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities-01 Discussion Leader: Peng Liu Adaptive Subscription to YANG & Bulk Subscription to YANG Event = Notifications (10 min) = https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscription-02 = https://tools.ietf.org/html/draft-wang-netconf-bulk-subscribed-notificatio= ns-02 Discussion Leader: Qin Wu Transaction ID Mechanism for NETCONF (10 min) https://tools.ietf.org/html/draft-lindblad-netconf-transaction-id-00 Discussion Leader: Jan Lindblad List Pagination Mechanisms for NETCONF and RESTCONF (20 min) Discussion Leader: Kent Watsen and Qin Wu Remaining 10 min. From nobody Thu Nov 12 09:19:01 2020 Return-Path: <01000175bd779984-76f28ee2-5cb8-430d-826f-2c3d78ec4e4c-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 B23FC3A1420; Thu, 12 Nov 2020 09:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 yDoLm5FILjtT; Thu, 12 Nov 2020 09:18:55 -0800 (PST) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B862A3A1427; Thu, 12 Nov 2020 09:18:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1605201533; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=1CmYtfF3zCMPhQB9R8H/yICw5Q0fIAjE/O8lWy+gc2c=; b=Sns/Zir8+Z+zkfqktTNBmThxnsNYyJ4YoYGIA6mp/QbLyNggFhCJEIYFYnROlY7r /g2zdpp/qNi3Dz31GOKTaVVlam4xNjaDXlyj4tkkVEO7DAqN6BuqxOq+MTUx/fchydM djzpB6DWNKhkY4fJDCYMBFGEip8o/BHhNlCDNexo= 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: <01000175b8a3c5ec-f9d61e60-8032-4f03-86dc-b5fb62d4b47e-000000@email.amazonses.com> Date: Thu, 12 Nov 2020 17:18:53 +0000 Cc: "netconf-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000175bd779984-76f28ee2-5cb8-430d-826f-2c3d78ec4e4c-000000@email.amazonses.com> References: <01000175943b8fa6-b54bce58-6e09-4759-9d19-1bc4c85ce8cf-000000@email.amazonses.com> <01000175b8a3c5ec-f9d61e60-8032-4f03-86dc-b5fb62d4b47e-000000@email.amazonses.com> To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.11.12-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Draft 109 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: Thu, 12 Nov 2020 17:19:00 -0000 The agenda has been updated. The update removes a couple drafts from the discussion as follows: OLD: Self-explanation Data Node Tag & Telemetry Data Export Capabilities = (10 min) = https://tools.ietf.org/html/draft-tao-netconf-notif-node-tag-capabilities-= 02 = https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities-01 Discussion Leader: Peng Liu Adaptive Subscription to YANG & Bulk Subscription to YANG Event = Notifications (10 min) = https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscription-02 = https://tools.ietf.org/html/draft-wang-netconf-bulk-subscribed-notificatio= ns-02 Discussion Leader: Qin Wu NEW: Telemetry Data Export Capabilities (10 min) = https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities-01 Discussion Leader: Peng Liu Adaptive Subscription to YANG (10 min) = https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscription-02 Discussion Leader: Qin Wu Thanks, NETCONF Chairs Agenda for the NETCONF 109 WG Session ------------------------------------- https://datatracker.ietf.org/meeting/109/materials/agenda-109-netconf Session: Wednesday, November 18 UTC+07: 12:00-14:00 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/109/sessions/netconf.ics MeetEcho: = https://meetings.conf.meetecho.com/ietf109/?group=3Dnetconf Jabber: xmpp:netconf@jabber.ietf.org?join Available During and After Session: CodiMD: https://codimd.ietf.org/notes-ietf-109-netconf Slides (TGZ): = https://datatracker.ietf.org/meeting/109/agenda/netconf-drafts.tgz Slides (PDF): = https://datatracker.ietf.org/meeting/109/agenda/netconf-drafts.pdf Available After Session: Recording: = https://ietf109.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-18 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13 https://tools.ietf.org/html/draft-ietf-netconf-keystore-20 https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-08 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-22 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-22 https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-05 = https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-21 = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-21 Discussion Leader: Kent Watsen Conveying a CSR in a SZTP Bootstrapping Request (10 min) https://tools.ietf.org/html/draft-ietf-netconf-sztp-csr-00 Discussion Leader: Kent Watsen An HTTPS-based Transport for Configured Subscriptions (10 min) https://tools.ietf.org/html/draft-ietf-netconf-https-notif-05 Discussion Leader: Mahesh Jethanandani UDP-based Transport for Configured Subscriptions (10 min) https://tools.ietf.org/html/draft-ietf-netconf-udp-notif-01 Discussion Leader: Pierre Francois Subscription to Distributed Notifications (10 min) https://tools.ietf.org/html/draft-ietf-netconf-distributed-notif-01 Discussion Leader: Thomas Graf Non-Chartered items: Telemetry Data Export Capabilities (10 min) = https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities-01 Discussion Leader: Peng Liu Adaptive Subscription to YANG (10 min) = https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscription-02 Discussion Leader: Qin Wu Transaction ID Mechanism for NETCONF (10 min) https://tools.ietf.org/html/draft-lindblad-netconf-transaction-id-00 Discussion Leader: Jan Lindblad List Pagination Mechanisms for NETCONF and RESTCONF (20 min) Discussion Leader: Kent Watsen and Qin Wu Remaining 10 min. From nobody Fri Nov 13 11:55:47 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 45E723A0147 for ; Fri, 13 Nov 2020 11:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAPqpMgkwTif for ; Fri, 13 Nov 2020 11:55:43 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87563A0141 for ; Fri, 13 Nov 2020 11:55:42 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id b17so12207996ljf.12 for ; Fri, 13 Nov 2020 11:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RLjWpkqwCY2h27sOHNeREMhPNCWxd67wBJHWZspvr/A=; b=CbOBDLjj80cMUQlL1ROnym8ZpztMHqMo9vRlJWmRAXEGynLXiUJbxKm3bYoOEu2QJ8 DQZh/tWU521ox5Uaq5hk7zN4ftjnUDToyk7NmbIU4UPlTgbdkiAMJ50s+kHoMIsCs3AA /aVXh+50Aa1mwiqAyXxv31LzAZrJUKBjz4r1B3RWaVs7f2hPJ8f6IOXIydqz1F7dPHlZ jILwwBM3AV5fBpfL0ulH/A25mp0FdEXoP3UBcoQxHHAC4wNkPUIR+pDLgMX2UtpLZrcG 1rwL52Hy19s1fvcHIMkc2F+lz4UWRPxudhAZKDECm7YL0RXwr1a1ccdiHrYm8XfuIkaO E4MA== 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=RLjWpkqwCY2h27sOHNeREMhPNCWxd67wBJHWZspvr/A=; b=BQW5pZmJHaIglqQGr1uXcUPiiAi7B+ERmY/ytR8wRXPfpmx+CadUoE8D/UBQehOe7l BE9xvMfrIYFnLrY/YCoHgQkfH97R09pUTvqq596h4N5ceILnefry1Fuwxw8ob0L3uH1D J+faCNE4DEwoL9OWiLn0AO5gxlS0Qx1TobBcG5McvFm7r4+Kgg5qhBY+EeZP2hbn+BLQ NGeV9kwhKW6RBwMlU7WBzXeJs9jmDTgpc1DH71GhgtzQbZyTt3rlcXRhG6LVRY/fso0B 5icOXGEnGWpQXeTM5GwCFDASOxZx6Q9xWxhXsqFUky0OoXNFyw0KB611yXw2XMHzVe0M ns5g== X-Gm-Message-State: AOAM53032pYOWfi8NhotqJvuyrD6jxwiYe0Un2pY0WWp6nNpLgv8QZm0 Y8nWckXAqNKs87CRj3X+nHeUIKxWVrjVNyaz6Lgslw== X-Google-Smtp-Source: ABdhPJxbq6DnTOX/7/34KgLtlN1Nd4ta76I/edSZhnVCKVttlqJeOMVLYWfzswPoTXp1v80uRQ7ZWoT1bE0bKvqyMf4= X-Received: by 2002:a2e:9616:: with SMTP id v22mr1640176ljh.120.1605297340798; Fri, 13 Nov 2020 11:55:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Fri, 13 Nov 2020 11:55:30 -0800 Message-ID: To: Pierre Francois Cc: Netconf Content-Type: multipart/alternative; boundary="000000000000c1ed1f05b40269e2" Archived-At: Subject: Re: [netconf] comments on draft-ietf-netconf-udp-notif-01 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, 13 Nov 2020 19:55:46 -0000 --000000000000c1ed1f05b40269e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 10, 2020 at 4:05 AM Pierre Francois < pierre.francois.ietf@gmail.com> wrote: > Andy, > > Thank you for the thorough review. > I agree with everything, mostly. I'll cover your questions during the > meeting. > > thanks. It appears that both Observation-Domain-ID and Message-ID are needed in the header, if Message-ID is only unique within a specific domain. Andy > Cheers, > > Pierre. > > > > > Le lun. 9 nov. 2020 =C3=A0 18:17, Andy Bierman a =C3= =A9crit : > >> Hi, >> >> I have some comments and questions about this draft. >> >> sec 3.1: >> >> >> >> * [I-D.ietf-netconf-notification-messages] describes the structure >> of the Notification Message for single notifications and bundled >> notifications.* >> >> - The new notification header is very complex, not implemented by >> anybody, >> and therefore unproven. The RFC 5277 notification message is widely >> deployed >> and should be supported. >> >> >> sec 3.2 >> >> >> >> >> >> * * S represents the space of encoding type specified in the ET field. >> When S is unset, ET represents the standard encoding types as >> defined in this document. When S is set, ET represents a private >> space to be freely used for non standard encodings.* >> - This new "S bit" payload encoding is not interoperable >> A) different vendors can pick whatever values they want for the ET >> field >> B) There is no reliable way to identify the vendor (or publisher >> software details) >> in this protocol >> >> >> >> * * Observation-Domain-ID is a 32-bit identifier of the Observation >> Domain that led to the production of the notification message, as >> defined in [I-D.ietf-netconf-notification-messages]. * >> >> - Why is this field needed if it is already in the new notification >> message? >> >> >> >> >> * * The Message ID is generated continuously by the sender of UDP- >> Notif messages. Different subscribers share the same Message ID >> sequence.* >> - It is not clear why the Message-ID field is present. This seems to b= e >> all >> the text about it. The field is OK, but needs clarification >> >> A) What is the receiver supposed to do to validate a Message-ID? >> This implies that some state is maintained by the receiver >> B) Does this field increment by 1 for every message? Or increment by = 1 >> for every message from the same Observation-Domain-ID? >> C) How is this field used if the Segmentation Option is used? >> Suggest: all multi-PDU messages MUST have the same Message-ID in >> each PDU. >> D) The 2nd sentence is confusing (subscribers?) Maybe you mean that >> different >> subscriptions supported by the same Observation-Domain-ID share >> the same Message-ID >> >> sec 3.3.1: >> >> >> >> >> >> * An implementation of this specification MUST NOT rely on IP >> fragmentation by default to carry large messages. An implementation = of >> this specification MUST either restrict the size of individual message= s >> carried over this protocol, or support the segmentation option.* >> >> - This appears to be the only normative text about the application-leve= l >> fragmentation >> and reassembly procedures. >> A) Is the sender required to finish a multi-PDU message (i.e. send >> segment 0 through N, in order) before sending a different >> Message-ID? >> B) Is it legal to use the option if only 1 segment is sent (i.e., L b= it >> set for Segment 0) >> C) Is it illegal to send any more segments for the same Message-ID >> after >> the L bit has been sent? >> >> >> Andy >> >> >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > --000000000000c1ed1f05b40269e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 10, 2020 at 4:05 AM Pierr= e Francois <pierre.fra= ncois.ietf@gmail.com> wrote:
Andy,=C2=A0

Thank y= ou for the thorough review.=C2=A0
I agree with everything, mostly= . I'll cover your questions during the meeting.=C2=A0


thanks.

= It appears that both Observation-Domain-ID and Message-ID are needed in the= header,
if Message-ID is only unique within a specific domain.


Andy

=C2=A0=
Cheers,=C2=A0

Pierre.

=



Le=C2=A0lun. 9 nov. 2020 =C3=A0=C2=A018= :17, Andy Bierman <andy@yumaworks.com> a =C3=A9crit=C2=A0:
Hi,

I= have some comments and questions about this draft.

= sec 3.1:

=C2=A0 =C2=A0 =C2=A0 [I= -D.ietf-netconf-notification-messages] describes the structure
=C2=A0 = =C2=A0 =C2=A0 of the Notification Message for single notifications and bund= led
=C2=A0 =C2=A0 =C2=A0 notifications.

=C2=A0- The ne= w notification header is very complex, not implemented by anybody,
=C2= =A0 =C2=A0and therefore unproven. The RFC 5277 notification message is wide= ly deployed
=C2=A0 =C2=A0and should be supported.


sec 3.2
=
=C2=A0 =C2=A0* =C2=A0S represents the space of encoding type specifi= ed in the ET field.
=C2=A0 =C2=A0 =C2=A0 When S is unset, ET represents = the standard encoding types as
=C2=A0 =C2=A0 =C2=A0 defined in this docu= ment.=C2=A0 When S is set, ET represents a private
=C2=A0 =C2=A0 =C2=A0 = space to be freely used for non standard encodings.

=C2=A0- This= new "S bit" payload encoding is not interoperable
=C2=A0 =C2= =A0 A) different vendors can pick whatever values they want for the ET fiel= d
=C2=A0 =C2=A0 B) There is no reliable way to identify the vendor (or p= ublisher software details)
=C2=A0 =C2=A0 in this protocol

=C2= =A0 =C2=A0* =C2=A0Observation-Domain-ID is a 32-bit identifier of the Obser= vation
=C2=A0 =C2=A0 =C2=A0 Domain that led to the production of the not= ification message, as
=C2=A0 =C2=A0 =C2=A0 defined in [I-D.ietf-netconf-= notification-messages].=C2=A0

=C2=A0- Why is this field needed i= f it is already in the new notification message?

=C2=A0 =C2=A0* = =C2=A0The Message ID is generated continuously by the sender of UDP-
=C2= =A0 =C2=A0 =C2=A0 Notif messages.=C2=A0 Different subscribers share the sam= e Message ID
=C2=A0 =C2=A0 =C2=A0 sequence.

=C2=A0- It is not= clear why the Message-ID field is present.=C2=A0 This seems to be all
= =C2=A0 =C2=A0the text about it.=C2=A0 The field is OK, but needs clarificat= ion

=C2=A0 =C2=A0A) What is the receiver supposed to do to validate = a Message-ID?
=C2=A0 =C2=A0 =C2=A0 This implies that some state is maint= ained by the receiver
=C2=A0 =C2=A0B) Does this field increment by 1 for= every message? Or increment by 1
=C2=A0 =C2=A0 =C2=A0 for every message= from the same Observation-Domain-ID?
=C2=A0 =C2=A0C) How is this field = used if the Segmentation Option is used?
=C2=A0 =C2=A0 =C2=A0 Suggest: a= ll multi-PDU messages MUST have the same Message-ID in each PDU.
=C2=A0 = =C2=A0D) The 2nd sentence is confusing (subscribers?) Maybe you mean that d= ifferent
=C2=A0 =C2=A0 =C2=A0 subscriptions supported by the same Observ= ation-Domain-ID share
=C2=A0 =C2=A0 =C2=A0 the same Message-ID

se= c 3.3.1:

=C2=A0 =C2=A0An implementation of this specification MUS= T NOT rely on IP
=C2=A0 =C2=A0fragmentation by default to carry large me= ssages.=C2=A0 An implementation
=C2=A0 =C2=A0of this specification MUST = either restrict the size of individual
=C2=A0 =C2=A0messages carried ove= r this protocol, or support the segmentation
=C2=A0 =C2=A0option.
=C2=A0- This appears to be the only normative text about the applicati= on-level fragmentation
=C2=A0 =C2=A0and reassembly procedures.
=C2=A0= =C2=A0A) Is the sender required to finish a multi-PDU message (i.e. send=C2=A0 =C2=A0 =C2=A0 segment 0 through N, in order) before sending a diff= erent Message-ID?
=C2=A0 =C2=A0B) Is it legal to use the option if only = 1 segment is sent (i.e., L bit
=C2=A0 =C2=A0 =C2=A0 set for Segment 0)=C2=A0 =C2=A0C) Is it illegal to send any more segments for the same Mess= age-ID after
=C2=A0 =C2=A0 =C2=A0 the L bit has been sent?


Andy


_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000c1ed1f05b40269e2-- From nobody Mon Nov 16 12:05:14 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 1BF793A1422; Mon, 16 Nov 2020 12:05:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <160555710203.16707.8436094838622708350@ietfa.amsl.com> Date: Mon, 16 Nov 2020 12:05:02 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-sztp-csr-01.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, 16 Nov 2020 20:05:06 -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 : Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request Authors : Kent Watsen Russ Housley Sean Turner Filename : draft-ietf-netconf-sztp-csr-01.txt Pages : 29 Date : 2020-11-16 Abstract: This draft extends the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 16 21:00:15 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 9F4833A0D81; Mon, 16 Nov 2020 21:00:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <160558921359.28558.14971754411212925803@ietfa.amsl.com> Date: Mon, 16 Nov 2020 21:00:13 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-https-notif-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 05:00:14 -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-06.txt Pages : 27 Date : 2020-11-16 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-https-notif-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 16 21:36:44 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 1DC583A0E25 for ; Mon, 16 Nov 2020 21:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFMXKC6dPQjt for ; Mon, 16 Nov 2020 21:36:41 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7695A3A0E2C for ; Mon, 16 Nov 2020 21:36:41 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id h16so11273082pgb.7 for ; Mon, 16 Nov 2020 21:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=kok4lGSRuJGuELy1VoKgBxhBeVMmbx+1h2ASGSVdrus=; b=ZafryWpJQ/6uvrhS2yMnqxXzy5elOAZJKMenDc3iVlpD/PH+YjpKJ7To/QO6lSMSAt zWEJWUy3nMsUUB26oFLrGk8hpVA0FPOvyhhyuBGB/CkOgz5E0b/X8vc6dk7+OXotOYnU f9R9UPowNDZF8l1afIxsKybIIScdD4TGkqWOzBMpYdUqm3W0FHqiPk9GCWgmlo3CN+cr fvzHd/XpOJJlX9D/3VgeedhhyWngvp+Kt9T19rkTBVmrzot7mkgUBmkyOKwjdefUPgLV UCBGAq6mQttoMk79HCt/4fJDkEIvia9y5acwcVmmCfTNQx4Gqj1T9J9hzoQ9ihAEuq1n 0yNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=kok4lGSRuJGuELy1VoKgBxhBeVMmbx+1h2ASGSVdrus=; b=M3+xRPvYpSqYfLakPkoVvytynWUhJ7WMc7Cig803nT2hxtFDXvnrQVikqsll/DywL4 pOQ2XccvLMpSX2VMGpMZW/qzzK60Ug8c2b2qdlNyh5CQoCj14F5WwZmHEqrpF5bPEaZF cirSFX0FLCzkDPyX0+lD1cyDeykTNF2UWRWq8cgwidY56I2OBEBt4CnZ7ydIWi67gPP2 XsB5PY6Car2+I90zuLlTP/bmJP/ninRGM9dRw4r8gVJmFBU8pvKbTck+OpMKpiv9n/Nc rhu9UMBsNhpKscIy8GhUylfcYTNdxx+UMaQtQZnw9TOSX2+33wdNoAfNsIk6Ti4w2zyh X5cw== X-Gm-Message-State: AOAM532ekhlfBXgLgqx317xxmW0Tp1CCfN/G9keGi3TjY9IH/dD1b1E9 SXOJffqjR+PpO53ZWIp2CorAeXk5P08= X-Google-Smtp-Source: ABdhPJwCVha1nKOUe2NHkuZsWTNiWOVluYdZxSOqR5XjBunbiJFzLed4bdn17mwhuvZH4XFwpGj2Pg== X-Received: by 2002:a63:380d:: with SMTP id f13mr2262529pga.105.1605591400561; Mon, 16 Nov 2020 21:36:40 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:7ccc:9da3:4bfb:4f47? ([2601:647:5600:5020:7ccc:9da3:4bfb:4f47]) by smtp.gmail.com with ESMTPSA id y16sm20558718pfl.144.2020.11.16.21.36.39 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2020 21:36:39 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_6DAA9480-7E18-4BFC-A5EF-7D4E466C65BD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 16 Nov 2020 21:36:38 -0800 References: <160558921359.28558.14971754411212925803@ietfa.amsl.com> To: Netconf In-Reply-To: <160558921359.28558.14971754411212925803@ietfa.amsl.com> Message-Id: <4A6D94A5-1EE2-4875-8F0A-DA6644089D97@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [netconf] I-D Action: draft-ietf-netconf-https-notif-06.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, 17 Nov 2020 05:36:43 -0000 --Apple-Mail=_6DAA9480-7E18-4BFC-A5EF-7D4E466C65BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [As contributor] This version of the draft updates the Security Considerations section to = bring it into compliance with guidelines in RFC 8407. > On Nov 16, 2020, at 9:00 PM, 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-06.txt > Pages : 27 > Date : 2020-11-16 >=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-06 > = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-https-notif-06 >=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 mjethanandani@gmail.com --Apple-Mail=_6DAA9480-7E18-4BFC-A5EF-7D4E466C65BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [As = contributor]

This = version of the draft updates the Security Considerations section to = bring it into compliance with guidelines in RFC 8407.

On Nov 16, 2020, at 9:00 PM, internet-drafts@ietf.org wrote:


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

=        Title =           : An = HTTPS-based Transport for Configured Subscriptions
=        Authors =         : Mahesh Jethanandani
=             &n= bsp;           &nbs= p;Kent Watsen
Filename =        : = draft-ietf-netconf-https-notif-06.txt
Pages =           : 27
= Date =            : = 2020-11-16

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-06https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-= notif-06

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


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

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


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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_6DAA9480-7E18-4BFC-A5EF-7D4E466C65BD-- From nobody Wed Nov 18 20:07:16 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 D394C3A09EE for ; Wed, 18 Nov 2020 20:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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] 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 4FYP9yxEQKo3 for ; Wed, 18 Nov 2020 20:07:13 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E163A0A08 for ; Wed, 18 Nov 2020 20:07:12 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id p12so4757382ljc.9 for ; Wed, 18 Nov 2020 20:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=EqkFUGiACKSkEVNz8hwcnnM9gI1IsngBewZ99hiNitw=; b=CTuHFXzF09PiaP49h3uhlD9HYELKdMnDcH2DZtM8j3JXxdHM0B1SGdY7qE2HtfIGGv fXCiW9tDalNDgjxCv5ZVBfDLeH4lePO2wT5Ar2Ww3Xw1mOqIixgQXtCChkdga7phTvZO KHw76oiCS1Q+bLKgAIBinBrQpD1F/SRMWrFoSUHuysPTYau1SudgOatXOFlWe2RvcmLv F1fWl55nRAASMv+yCIogGdjhwzRlSfDkQI/LRviCnvQgdsqCGv6XVOzjU46/S5UdxIZG Ok58l+JQjtLkYCKlcyE9xHnB7+L2jtk0OS9BAP+UTZ6gEe5BVsh5rae2nStbebauKBob 6Jiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EqkFUGiACKSkEVNz8hwcnnM9gI1IsngBewZ99hiNitw=; b=UZR8PbCdMQorD56mQKqf0YIGfS3ctSj5aXNOgF8AKbrGEOWnfHZ9kJhU/TWFo5bIn2 pYDpWb8xskSBHKEYqYC5Y+dOKC2CNTjv0rsTM1vJ5e4qhAX2fLXo+E1Ga9k8KGEjL0fT GpUIp97FL1rr+YwlBIQzGa6z40/vdzmiaasqeZeZ1qyjXoVLOi5c/Jp/8gmq6RRkcg38 eYXj/WyDKmIGoP4dmZl4MlYy3vb5yz8b/ZL/aFg12CKtZW9BPEd8xHpnyi2b0xjN2VA0 2sg+eb0TMVXbkH34j4B3gClDl7zdIpQ8eH9cHuExYjgbdL8JW37ltRFVPg6u9p7IRAox bDTg== X-Gm-Message-State: AOAM5319vGSrpvivFCCEfYfbvC8zNZbzOG1myaPFIkEwI55XQYckLI+5 einIK05+td1loEingSGYM6w7DutXOlRq8tXUAuYxht4FpJcINA== X-Google-Smtp-Source: ABdhPJzvnRNCQiD56CfjnQSwxHeHwBisBpZQBA31L/r1wnOFwOO83/1PgvpMTErRjnOfc78K3sYtIaa5Q2qwR38ZZSE= X-Received: by 2002:a05:651c:2111:: with SMTP id a17mr5492718ljq.220.1605758830830; Wed, 18 Nov 2020 20:07:10 -0800 (PST) MIME-Version: 1.0 From: Andy Bierman Date: Wed, 18 Nov 2020 20:07:00 -0800 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary="000000000000b5034605b46ddc14" Archived-At: Subject: [netconf] draft-ietf-netconf-udp-notif encoding option 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, 19 Nov 2020 04:07:15 -0000 --000000000000b5034605b46ddc14 Content-Type: text/plain; charset="UTF-8" Hi, There was a suggestion to assign an encoding enumeration to represent "other". I think this could work, if it meant that the receiver should check the options for an "Encoding ID Option", Type = to be assigned Length = 2 + length of variable data Variable data = some string identifying the encoding type IMO this allows a good balance between message size and interoperability, and it is very extensible. Andy --000000000000b5034605b46ddc14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

There was a suggestion to assign an= encoding enumeration to
represent "other".=C2=A0 I thi= nk this could work, if it meant that the
receiver should check th= e options for an "Encoding ID Option",

= =C2=A0 Type =3D to be assigned
=C2=A0 Length =3D 2=C2=A0+ length = of variable data
=C2=A0 Variable data =3D some string identifying= the encoding type

IMO this allows a good balance = between message size and interoperability,
and it is very extensi= ble.


Andy

=
--000000000000b5034605b46ddc14-- From nobody Thu Nov 19 00:01:43 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 C43CC3A10CC for ; Thu, 19 Nov 2020 00:01:42 -0800 (PST) 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 dmXWIOCFvVMd for ; Thu, 19 Nov 2020 00:01:41 -0800 (PST) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 6676D3A0D4A for ; Thu, 19 Nov 2020 00:01:41 -0800 (PST) Received: by mail-vk1-xa36.google.com with SMTP id s135so1143058vkh.6 for ; Thu, 19 Nov 2020 00:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nSaSQ7lBXo2iyti9ofTWsSO0OsaGy1410VXnBAN4iRs=; b=nxmzqFj3f+U/7hXUoti3dX5Ht7iP6xbDfUIs2JbeK+FukphMZsnkJ7rVrCd84UbS+h Y1ipoNUMEju2/1YqbEvEhtbXN3bkadMDDFqUBthHwTxuSa1v7SHPjqyK/qU8Bp/c4Ndh MVr66SFbIT7UNIWRtofFn/j3BcWYdte41e2uE7fnSVgDcZUXNaWeKMT8lm8ujkGSOn/Q oC1dfkKsXn/kRKaSioJLaYoWDDFy0WA1IndBuUlsoaf0hsH3Otxs/mFlPSxG2DKjq4k5 SKnEFpK/2oNI64l04WDg2Z5VRKmXcy0KApRZ4E/lhk9fvzUkFyJ5RwSDUSmV2JJB1brh ArYA== 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=nSaSQ7lBXo2iyti9ofTWsSO0OsaGy1410VXnBAN4iRs=; b=InTwfWZedKLtTRenT6t1SeHSosKwjJEVZQkeznsrBRPT15vvxnoQn4fpW26NCEFzpE +no9yfhdTB2lbhqwArvSSzgu032yNeWrdSVZWW6h14AnWiku3HH19hTfnzf75KBQZGAC HFvfvWS6hCYRnA/Ny6oKv78vmflfmQy39/0cCyxX5TtjHOqqu8c+FU8t37/IN8fHtOCM ZWjyBpPB3AJmts1F9pcsKNyTmF/hIa49W1YaTthgASHZ0AjznuYa6/L8HeGpoE4SkTDD 9b4uOn+/PsUhfDTBORkZjR/295bsOJyKYsG/P9tqLSq4TeRBBxgNMLcJxtK30JpFZj3w aiMg== X-Gm-Message-State: AOAM532+eNjKrrMkx7DN6YbWEV172XIRgLDUqujEYtB2iYpVZcxOICBH StuEERqs+rf7VFP9rWUIoxm9klx8z1xxZNV688bzFdE0 X-Google-Smtp-Source: ABdhPJzgyk5QE9ZxBSPSf60QOex3VYqmnTqWC9cT3Zupfmx9fAIn2gqRZJPxsb4NJ+oIbSfO49leVGA/gTs/hQxGvUk= X-Received: by 2002:a1f:4593:: with SMTP id s141mr7789420vka.4.1605772900263; Thu, 19 Nov 2020 00:01:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pierre Francois Date: Thu, 19 Nov 2020 09:01:30 +0100 Message-ID: To: Andy Bierman Cc: Netconf Content-Type: multipart/alternative; boundary="0000000000004f694405b4712320" Archived-At: Subject: Re: [netconf] draft-ietf-netconf-udp-notif encoding option 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, 19 Nov 2020 08:01:43 -0000 --0000000000004f694405b4712320 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Andy, I like this. Let me check around and get back to you. Cheers, Pierre. Le jeu. 19 nov. 2020 =C3=A0 05:07, Andy Bierman a =C3= =A9crit : > Hi, > > There was a suggestion to assign an encoding enumeration to > represent "other". I think this could work, if it meant that the > receiver should check the options for an "Encoding ID Option", > > Type =3D to be assigned > Length =3D 2 + length of variable data > Variable data =3D some string identifying the encoding type > > IMO this allows a good balance between message size and interoperability, > and it is very extensible. > > > Andy > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --0000000000004f694405b4712320 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Andy,=C2=A0

I like this. Let me che= ck around and=C2=A0get back to you.

Cheers,=C2=A0<= /div>

Pierre.

=
Le=C2=A0jeu. 19 nov. 2020 =C3=A0=C2= =A005:07, Andy Bierman <andy@yumaw= orks.com> a =C3=A9crit=C2=A0:
Hi,

There was a su= ggestion to assign an encoding enumeration to
represent "oth= er".=C2=A0 I think this could work, if it meant that the
rec= eiver should check the options for an "Encoding ID Option",
=

=C2=A0 Type =3D to be assigned
=C2=A0 Length = =3D 2=C2=A0+ length of variable data
=C2=A0 Variable data =3D som= e string identifying the encoding type

IMO this al= lows a good balance between message size and interoperability,
an= d it is very extensible.


Andy
=


_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--0000000000004f694405b4712320-- From nobody Thu Nov 19 08:47:26 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 9F5603A0AD3 for ; Thu, 19 Nov 2020 08:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKnC9WEKXRdI for ; Thu, 19 Nov 2020 08:47:22 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CC83A0ADE for ; Thu, 19 Nov 2020 08:47:22 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id 11so6971378ljf.2 for ; Thu, 19 Nov 2020 08:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=whuqSQ9Tn95BZuXmiHIQaepgLFS8952ahcOZPxTj+bU=; b=TQCcWvr/4SOemin8CyBNrcNTs9xC+oz22xy9GCjKvWlTWGel9gQdM6X0kt798HBnh9 usiV6QMOKLzArSZwTevjpAtImk6gpEN7BaBIDHTmtEL6tW9hgtThdB2KmhBPiNwatJCx qcYdoSwfL9dAZnmuJLUSdjFT75S4Has2LBXXe8agI/k+XPgOQtvdaSo+21sJOjdBNtjY GvGqpMxusnnLZWXyMzJTS6J8cQBeeCguG9umzV2m2roGP+LTmMCkuGz5GKeVoCmOn3bi rfgbcbuNSKyeGR1w2xMp6/5Yd8aphgzuPMzwXkg893qXyu3OzRXOHDP/qROYZkLKAe8Y uPRw== 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=whuqSQ9Tn95BZuXmiHIQaepgLFS8952ahcOZPxTj+bU=; b=pRLh2cmxX32r8Ut97C5VRmEKYuf9h10sPbHP0ieYxrhkDU8FviIChPhGrmmCcYJPw9 7/z13CBFw9DSzUOsi6BRLe64rmlSiwt/T+5BJ4D/al9v46OrBZw9mJ38nLUZz52Taa+f Uh8BZEOkp5lZY0aT7fzJ/YCnwqTmI7tVOMxCJStclIBe2f/tTvlqQCx5RzWzmWf2x4cc 0o1FylFZ+moS73vMsio0j2ffW1LBTjmvGEWC4G69yqaPRf2/nDf6bsLEnUbLq8hLByLg 3/L4qz/rIvSG1ewz0QqRxqg4Lt0pnuVB/8UMVZyZLX3J3LHu5Y3eIDntNXVju8g3G1Tr E2gw== X-Gm-Message-State: AOAM532d07WFPH+CGu5YfQZQAH9qnS4LZ+tKi0i0WEA+pq7oRA0xfKd3 mL6s7syrjj96vrbCXB+fbI8nz2zwpjXBM8RgLgM2Sg== X-Google-Smtp-Source: ABdhPJyN6a+DsPDD513tq421fMGYXy2ujoj3u0qM2VctxgU8Sd5rWwjGGRosuspXWPxw/IPPBMBSE3stDKR8cYPcyH0= X-Received: by 2002:a2e:8546:: with SMTP id u6mr6486365ljj.125.1605804439312; Thu, 19 Nov 2020 08:47:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Thu, 19 Nov 2020 08:47:08 -0800 Message-ID: To: Pierre Francois Cc: Netconf Content-Type: multipart/alternative; boundary="0000000000002f379205b4787b2c" Archived-At: Subject: Re: [netconf] draft-ietf-netconf-udp-notif encoding option 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, 19 Nov 2020 16:47:25 -0000 --0000000000002f379205b4787b2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 19, 2020 at 12:01 AM Pierre Francois < pierre.francois.ietf@gmail.com> wrote: > Hey Andy, > > I like this. Let me check around and get back to you. > > There are some details like padding (to maintain quad alignment), but this completely decouples the encoding politics from the transport layer. Remember the content-id field I asked about awhile back? This can be used for that. Rob touched on the $64 question in the meeting that got ignored How do you know which protobuff it is? Is it gNMI? OC-telemetry? vendor gRPC data? Perhaps: encoding-id =3D gpb/gnmi =3D gpb/openconfig-telemetry =3D gpb/example-bgp-state Cheers, > > Pierre. > Andy > > Le jeu. 19 nov. 2020 =C3=A0 05:07, Andy Bierman a = =C3=A9crit : > >> Hi, >> >> There was a suggestion to assign an encoding enumeration to >> represent "other". I think this could work, if it meant that the >> receiver should check the options for an "Encoding ID Option", >> >> Type =3D to be assigned >> Length =3D 2 + length of variable data >> Variable data =3D some string identifying the encoding type >> >> IMO this allows a good balance between message size and interoperability= , >> and it is very extensible. >> >> >> Andy >> >> >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > --0000000000002f379205b4787b2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 19, 2020 at 12:01 AM Pier= re Francois <pierre.fr= ancois.ietf@gmail.com> wrote:
Hey Andy,=C2=A0

I = like this. Let me check around and=C2=A0get back to you.



There are some deta= ils like padding (to maintain quad alignment), but
this completel= y decouples the encoding politics from the transport layer.

<= /div>
Remember the content-id field I asked about awhile back?
This can be used for that.

Rob touched on the $6= 4 question in the meeting that got ignored

How do = you know which protobuff=C2=A0it is? Is it gNMI? OC-telemetry? vendor gRPC = data?

Perhaps:

=C2=A0 enc= oding-id =3D gpb/gnmi=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D gpb/openconfig-telemetry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =3D gpb/example-bgp-state


Cheers,=C2=A0

Pierre.

Andy
=C2=A0

Le=C2=A0jeu. 19 nov. 2020 =C3=A0=C2=A005:07, Andy Bierman &= lt;andy@yumaworks.c= om> a =C3=A9crit=C2=A0:
Hi,

There was a suggesti= on to assign an encoding enumeration to
represent "other&quo= t;.=C2=A0 I think this could work, if it meant that the
receiver = should check the options for an "Encoding ID Option",
<= br>
=C2=A0 Type =3D to be assigned
=C2=A0 Length =3D 2= =C2=A0+ length of variable data
=C2=A0 Variable data =3D some str= ing identifying the encoding type

IMO this allows = a good balance between message size and interoperability,
and it = is very extensible.


Andy
=

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--0000000000002f379205b4787b2c-- From nobody Sun Nov 22 14:14:47 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 414153A0E48 for ; Sun, 22 Nov 2020 14:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 q7BWDvrKX55L for ; Sun, 22 Nov 2020 14:14:45 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19AAC3A0E43 for ; Sun, 22 Nov 2020 14:14:45 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1E11FF4071F; Sun, 22 Nov 2020 14:14:45 -0800 (PST) To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: muly_i@rad.com, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20201122221445.1E11FF4071F@rfc-editor.org> Date: Sun, 22 Nov 2020 14:14:45 -0800 (PST) Archived-At: Subject: [netconf] [Technical Errata Reported] RFC8040 (6342) 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: Sun, 22 Nov 2020 22:14:46 -0000 The following errata report has been submitted for RFC8040, "RESTCONF Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6342 -------------------------------------- Type: Technical Reported by: Muly Ilan Section: 4.6.1 Original Text ------------- To replace just the "year" field in the "album" resource (instead of replacing the entire resource with the PUT method), the client might send a plain patch as follows: PATCH /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com If-Match: "b8389233a4c" Content-Type: application/yang-data+xml 2011 Corrected Text -------------- To replace just the "year" field in the "album" resource (instead of replacing the entire resource with the PUT method), the client might send a plain patch as follows: PATCH /restconf/data/example-jukebox:jukebox/\ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com If-Match: "b8389233a4c" Content-Type: application/yang-data+xml Wasting Light 2011 Notes ----- Missing key leaf value in the message-body (Wasting Light) Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8040 (draft-ietf-netconf-restconf-18) -------------------------------------- Title : RESTCONF Protocol Publication Date : January 2017 Author(s) : A. Bierman, M. Bjorklund, K. Watsen Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Nov 23 00:37:38 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 7BBE53A1737 for ; Mon, 23 Nov 2020 00:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.779 X-Spam-Level: * X-Spam-Status: No, score=1.779 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=dBieKQaE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hgwQt9xQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmsY__-IOmq3 for ; Mon, 23 Nov 2020 00:37:34 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1B83A1736 for ; Mon, 23 Nov 2020 00:37:34 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 8BF55E22; Mon, 23 Nov 2020 03:37:33 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 23 Nov 2020 03:37:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= 74hN7S7Fwjl5+goVYp8iagHbKVKJ6e+Rr0IG1jSVXX4=; b=dBieKQaEJ7HdB5mP CDl4Tqs/QMc9BY8weyD5QzzgIyceuXk5fsBnykBhVGLi6OoAlo3LNg6qB/LFWEnA 6Ls4ftQYPd9I7fOJ17yV9vqz5aEqKu7WNDhapVScttVZbPJK2TMZOxgFMGgerhF7 C/BmtEzc4mVix6uUW7Q1QzbMCzpV8/gHWUom8HGHWBR2fpF1xs6nEjLjL/1afsRO tgmzaDBCweM/Eb3YarJalvokn0VRhpxtHz8CYF6OckwVsC/g3n8c9k6Pi2+C0bim 8GXlS/ZLkFn6p+Uu6fxqd9L4/kn5pIUQ+k/a88ZKFs1LRokIw20KqJn8oXEf5O71 ZBvDTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=74hN7S7Fwjl5+goVYp8iagHbKVKJ6e+Rr0IG1jSVX X4=; b=hgwQt9xQjOKIzvBIsY1OcBPAMmfAmBnRUw8MiLqz16PD7O12fG+BjNCrl 6eF4w8J61KpdSc3mEhlYHHIHi0xRypwe72gPasIR2tRf9eDw6gV2MNxTYVh0twpl CfaCV2enPIXUeq4qaSEtynO33ewwqA0qsiOucREP4jZjglCqgXHzPxXqfY3nyhK7 AJIsOZbC7TaVYYwiKGr/njmzWx3Hma3TIEGSBbeaD/M8O9M0ulNwBj3IkxQ6EnOQ BP7A3Hn5uSTB+5qzxJcUHEj5A8HCwZRkvzQITdW4swi6XMmvlxWDkcSJ5ck9OtaQ vtiqgFnhbb4LlZDdqwPBZptSQ2SJw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeghedguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesth ejredtredtvdenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeekudeuheduvdejtdduke eiheejleffvefhheffuefgueevhedvvdevieduheehgeenucffohhmrghinheprhhftgdq vgguihhtohhrrdhorhhgpdduhhhoshhtvgigrghmphhlvgdrtghomhdpvgigrghmphhlvg drtghomhdpihgvthhfrdhorhhgnecukfhppeduheekrddujeegrdegrddvudehnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgsjhdoihgvth hfseegieeikedrshgv X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 1745A3280064; Mon, 23 Nov 2020 03:37:30 -0500 (EST) Date: Mon, 23 Nov 2020 09:37:29 +0100 (CET) Message-Id: <20201123.093729.325420538444196813.id@4668.se> To: rfc-editor@rfc-editor.org Cc: andy@yumaworks.com, kwatsen@juniper.net, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <20201122221445.1E11FF4071F@rfc-editor.org> References: <20201122221445.1E11FF4071F@rfc-editor.org> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) 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, 23 Nov 2020 08:37:36 -0000 Hi, The issue boils down to if list keys are required in a plain patch. Unfortunately, the RFC doesn't specifucy this. From a technical pow, list keys are not necessary. In fact, if they are present in the payload, they are redundant (since they are part of the URL) (this is actually mentioned in the RFC). Since it isn't clearly specified, I think we must assume that the keys are not required. Hence I think that this errata should be rejected. In a future version of this document, the behaviour should be clarified. /martin RFC Errata System wrote: > The following errata report has been submitted for RFC8040, > "RESTCONF Protocol". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6342 > > -------------------------------------- > Type: Technical > Reported by: Muly Ilan > > Section: 4.6.1 > > Original Text > ------------- > To replace just the "year" field in the "album" resource (instead of > replacing the entire resource with the PUT method), the client might > send a plain patch as follows: > PATCH /restconf/data/example-jukebox:jukebox/\ > library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 > Host: example.com > If-Match: "b8389233a4c" > Content-Type: application/yang-data+xml > > 2011 > > > Corrected Text > -------------- > To replace just the "year" field in the "album" resource (instead of > replacing the entire resource with the PUT method), the client might > send a plain patch as follows: > PATCH /restconf/data/example-jukebox:jukebox/\ > library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 > Host: example.com > If-Match: "b8389233a4c" > Content-Type: application/yang-data+xml > > Wasting Light > 2011 > > > Notes > ----- > Missing key leaf value in the message-body (Wasting Light) > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8040 (draft-ietf-netconf-restconf-18) > -------------------------------------- > Title : RESTCONF Protocol > Publication Date : January 2017 > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Nov 23 03:31: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 955E23A08BD for ; Mon, 23 Nov 2020 03:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rad365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNGqSRoEr6BD for ; Mon, 23 Nov 2020 03:31:46 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2072.outbound.protection.outlook.com [40.107.21.72]) (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 11DE53A0820 for ; Mon, 23 Nov 2020 03:31:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BacFpbBMVgufGlOl6qEJv1S6LK2NrGi1g68kjgCWYIkBKTq1WtA4UUvJG1z7MaabyG6QYycSeP3zl8hrPv47dQ0TtQgD3MoNW575sQz2DjqrjJH+r5sZfGCgt6n3oSZM+n7E51/HVC+UYkcBBWrZayvCTkIY6/N477qRZedLt7aDJ0v7HtuEcJvVdILYgarkp85UTk52pn3VC6ZseXjXEMlLbI3AXwudhTiZVh9GBQa7iObWYZtpPSgkbdghE8k1ak4r4SrfbGm0JUzwVKUpfNOarbeVek4WNEHghyZgJZ5gKkeV3BLfZPi1zfPy0OgsY8+ZPg9yf1yfQJiaNEBjMQ== 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=XbkFBRmxuk6UcmVP9pfoHwHwpybuitnywrA3E9nf9TM=; b=ips3qez95CkR9eLDicbDODsB171DHzeyMBE5gRlRpwJfx7DILNAhkzrq2Pbsi7RqnaDVwYzrBvhWqXbTYjHawLymElYrT+w9fAvuFSn4GM1Xx6WxQu3wQ0MdBCHFBoN7j4yFX9Fby2vWNY3j0g6OpS1edFzKDmoU+5JJbYgzxyR810yzHxCVVSQXa28Ic/woqozL1RrBOSjeQStzN7UG87CEEmjjGd+mn27u6zZWml+bkJs7FxLJmB0Jw/cmBpCmPATjPxkxAmkqgU3fzkyruBSvP6yibsDQRzPnvJ2ix/qF0REGVpCaysxSumMzUbOn5Vi5W9rynGxdPjf2w2bNsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rad.com; dmarc=pass action=none header.from=rad.com; dkim=pass header.d=rad.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rad365.onmicrosoft.com; s=selector1-rad365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XbkFBRmxuk6UcmVP9pfoHwHwpybuitnywrA3E9nf9TM=; b=HhVhfYNZ+0Z1rDKJOadRQOP5JvU+ksN88yihEixaxBIiNI/YIYgbAUohCbEwxjOS9bo/FrrCJKtG2FGoeVIXRshbVy7nlQO4JeRUkkL0pkN2Mf9Zd9lgb6LW9T8uoxZAcsaPtz9NJOP/+RFMsr6ttnFcX3JC/C4yQOYzFaCtCfI= Received: from AM0PR0302MB3348.eurprd03.prod.outlook.com (2603:10a6:208:b::19) by AM9PR03MB6787.eurprd03.prod.outlook.com (2603:10a6:20b:286::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Mon, 23 Nov 2020 11:31:43 +0000 Received: from AM0PR0302MB3348.eurprd03.prod.outlook.com ([fe80::eccb:ec09:89e2:cd70]) by AM0PR0302MB3348.eurprd03.prod.outlook.com ([fe80::eccb:ec09:89e2:cd70%5]) with mapi id 15.20.3589.025; Mon, 23 Nov 2020 11:31:43 +0000 From: Muly Ilan To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= , "rfc-editor@rfc-editor.org" CC: "kwatsen@juniper.net" , "netconf@ietf.org" Thread-Topic: [netconf] [Technical Errata Reported] RFC8040 (6342) Thread-Index: AQHWwRzkciHC9EbDXEyiRm/auJwoyqnVZYeAgAAuWgA= Date: Mon, 23 Nov 2020 11:31:43 +0000 Message-ID: References: <20201122221445.1E11FF4071F@rfc-editor.org> <20201123.093729.325420538444196813.id@4668.se> In-Reply-To: <20201123.093729.325420538444196813.id@4668.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: 4668.se; dkim=none (message not signed) header.d=none;4668.se; dmarc=none action=none header.from=rad.com; x-originating-ip: [185.223.3.181] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6937bfb1-f793-4c79-c702-08d88fa35a93 x-ms-traffictypediagnostic: AM9PR03MB6787: 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: Wqgm4FyRRxKXpdb+2pCfewKvsN0KFfu2coEK7Wu/+VeaJk7aHMed5Lh0duIoCtLduFj6FcUgVsxn07V2XVWUshy9WZJDyCSjVIVKT47gL5/y+HzX9trrufrSYeo48Ctv8D9WgryvFOaknZuXq2+5SlcIgayT9uONpP5EmhtIC2gGKw/OGUc0qgYS7gp6BVfVmy37MRAHwiH7/PKyppY5OfTsLANa9qZfJGYjmxp9I116r/FcIzufuPfau1SziSjBxccr0aTyyLIIuAwEOnXkz1BcSzkcwRaErONqpkvBP4GnnB1eBzRoqvL7Zwqnqip+xMka4RzQbuv/LV6TaGEO2UmwQSrUwrTSwwC3vzwvn314RUlehsGlhxh9EaUM0LDHdxTPVSmq7gttiwdL8WopUw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0302MB3348.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39850400004)(136003)(346002)(366004)(376002)(2906002)(4326008)(8676002)(110136005)(66446008)(66556008)(66476007)(64756008)(76116006)(71200400001)(54906003)(66946007)(45080400002)(52536014)(55016002)(316002)(83380400001)(9686003)(186003)(26005)(7696005)(478600001)(86362001)(33656002)(5660300002)(8936002)(966005)(6506007)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: RoBsz1KbdrJxMxPoCGV8HhSbrqvca2PX4pfaGeszqA3bjVGsrcSL6Vfa/YPDqumang8ljD/+7lvSzUpmM7Ni0L5CbpKcKAq/5ydYscZ/auXsT31s2W9pB8PzC2T3f1MguvoTQ8y4YhMNdTLXEC8H+XPmP3S0ViybGwuDkrMlT6uwbg9B1IifouVncqKu4ESeobUlqI963jp2QqQ9w2HUpD7Db3ifw6eNGEFMKeIffHY9Q/ljn9gisRZpi2oFrGPj7yiD3KOzwbGJ6KEcqEjQXwsTlLB18aP2Ukt+tuRPi4MAIrdmeHr9FS2ElAAYDA3XtAjNjcwtE7qgBg4gjERRa7MY44dLQSTc+uzqz/XpH9/9BxcKGYDwtR2hpdO8UKyicHnjFW/4zqIrYYOsqEg/oPi6DvFAHj7AiZBFBeIIcAFtHVxD4N+49EuHDQ2woWlKdpjytNdeHDx4KVpDOBdmxCuCk18H1TTPTVu59NQs2y7nw/32EDjeoA+oJbJosjQ7TSMineAUpiQqxFmU/qLMoASOFV97dmZanM+SLGO2sdLV6FFaJm2X39TyDG7C0V3oOKbJQTw7LQKAxNaL0326Hp1WM9hf4ofU6UAVI++sff388fQ1dtzrWLo/acinVmcXoC8y8Ftjfj+sbh9GikZ8xf4+gvJi5TSKhviMjbs2d/66ZBbFl7iFT7iO0mg/h9GKDnv55nFYVgTUFe6xv7V881JmFVcZ4Nhp01CD2eurcgkBLBptBSDhBpsH4MVeX3KncqiXTfoWs78SIXQjcjzabbWbgWi/50KeZ5Hfe5l9JaDEaSfVgwIF7LysA/9/PHt1Wgi4eHMFLX++B3hgzd4kZXGI42F/1bef3vglvY4gjupm8/s//gZQz5ZyCOdCd93dv+7zBeyW6fqJglPc+rbuzQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rad.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0302MB3348.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6937bfb1-f793-4c79-c702-08d88fa35a93 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 11:31:43.3802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0hjQL5S8EXpRhsMLp+QYPXPAO0pwDOSSiCEgQcwnkC5b9/cPKNNBBKpwv0UpKSpU X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB6787 Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) 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, 23 Nov 2020 11:31:49 -0000 Hi, If list keys are not required in message body for plain PATCH then they are= also not required for the PUT method. But the example for PUT in section 4.5 is: PUT /restconf/data/example-jukebox:jukebox/\ library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 Host: example.com Content-Type: application/yang-data+json { "example-jukebox:album" : [ { "name" : "Wasting Light", "genre" : "example-jukebox:alternative", "year" : 2011 } ] } So, do we want consistency between PUT and plain PATCH? I believe consistency is important and currently the RFC contains two incon= sistent examples. Best, Muly -----Original Message----- From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin Bj?rklu= nd Sent: 23/11/2020 10:37 To: rfc-editor@rfc-editor.org Cc: kwatsen@juniper.net; netconf@ietf.org Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) Hi, The issue boils down to if list keys are required in a plain patch. Unfortunately, the RFC doesn't specifucy this. From a technical pow, list = keys are not necessary. In fact, if they are present in the payload, they = are redundant (since they are part of the URL) (this is actually mentioned = in the RFC). Since it isn't clearly specified, I think we must assume that the keys are = not required. Hence I think that this errata should be rejected. In a future version of this document, the behaviour should be clarified. /martin RFC Errata System wrote: > The following errata report has been submitted for RFC8040, "RESTCONF=20 > Protocol". >=20 > -------------------------------------- > You may review the report below and at: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > rfc-editor.org%2Ferrata%2Feid6342&data=3D04%7C01%7Cmuly_i%40rad.com% > 7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf9d% > 7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D2nm > LthW5HkwRvJZi%2F2Pj6%2B9qkLV9gV55wiBpIoiC%2FD4%3D&reserved=3D0 >=20 > -------------------------------------- > Type: Technical > Reported by: Muly Ilan >=20 > Section: 4.6.1 >=20 > Original Text > ------------- > To replace just the "year" field in the "album" resource (instead of=20 > replacing the entire resource with the PUT method), the client might=20 > send a plain patch as follows: > PATCH /restconf/data/example-jukebox:jukebox/\ > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > Host: example.com > If-Match: "b8389233a4c" > Content-Type: application/yang-data+xml xmlns=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F= % > 2Fexample.com%2Fns%2Fexample-jukebox&data=3D04%7C01%7Cmuly_i%40rad.c > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D > hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserved=3D0"> > 2011 > >=20 > Corrected Text > -------------- > To replace just the "year" field in the "album" resource (instead of=20 > replacing the entire resource with the PUT method), the client might=20 > send a plain patch as follows: > PATCH /restconf/data/example-jukebox:jukebox/\ > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > Host: example.com > If-Match: "b8389233a4c" > Content-Type: application/yang-data+xml xmlns=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F= % > 2Fexample.com%2Fns%2Fexample-jukebox&data=3D04%7C01%7Cmuly_i%40rad.c > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D > hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserved=3D0"> > Wasting Light > 2011 > >=20 > Notes > ----- > Missing key leaf value in the message-body (Wasting=20 > Light) >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party can log in to change=20 > the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC8040 (draft-ietf-netconf-restconf-18) > -------------------------------------- > Title : RESTCONF Protocol > Publication Date : January 2017 > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D04%7C01%7Cmuly_i%40ra > d.com%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b > 3bf9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda > ta=3DGOd8xUYLJ9C69r7aN6rujBhsYFJd05CxiHNXT9YXOZ0%3D&reserved=3D0 _______________________________________________ netconf mailing list netconf@ietf.org https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D04%7C01%7Cmuly_i%40rad.com%= 7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf9d%7C1%7= C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo= iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DGOd8xUYLJ9C69r7a= N6rujBhsYFJd05CxiHNXT9YXOZ0%3D&reserved=3D0 From nobody Mon Nov 23 04:14: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 43C383A099E for ; Mon, 23 Nov 2020 04:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.779 X-Spam-Level: * X-Spam-Status: No, score=1.779 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=hV73DbDL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WzRz6YsD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qHE8uyri97k for ; Mon, 23 Nov 2020 04:14:56 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603DD3A0997 for ; Mon, 23 Nov 2020 04:14:56 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 873D55C0121; Mon, 23 Nov 2020 07:14:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 23 Nov 2020 07:14:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= aUYUuQEEP6Imk8D2iEslXIQVd2C4bL/z+w2XBbFDczo=; b=hV73DbDLGuvaA44k L18GHy1jtLE9PvT70nH51VYwQCwQ8uA74e+oNCbmg+CJ84G3iExb6jQxIeG8chMI 3falBEQuYr/zH/nA4ii60mrUfivD1+M+El0ZOdDA+UdxfgR0qhkwB0rkC3yZtMqh Y33cVoDA7aP2lfkcckN7GL38pIG+N/TMCCA/dL5NoKADc5N0zbBNyuIp5tN53fMm u73F+65qPQe3XTgTBd5lXiabYF9tQuCKh9gt8ewrQdnx31uQhBxmcfBcv/uWS0B0 VYRF9oMJkMOn4pGBl4Z85Bj5PVzt7Am4mQxPKeEE5mOHd2lbqEuXATPBFHRqsKYX vzC3Og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=aUYUuQEEP6Imk8D2iEslXIQVd2C4bL/z+w2XBbFDc zo=; b=WzRz6YsD08WPMu65W+zadRpvPE44vVY865ezBjEPo0bmif0UAFcepMg69 xnu8SCZxKreEaqHyG65sTvY0hsfecCGc4Ol1+CPl+FmcQRwn3Mp0txzksd+n2LcQ Ln5grlWWr3LJ3cmKM6og2p86tbncETjEw/bAL0eX6FSQzPz604/e+74NlfxIVksi vXuc8JMqyeT0XTRMbe2OkOqvASYviRVL5fYxoFVb58vRQPzpp8oUaPiSYWdP2Kkx wwlR3zfnPDP+Tx4Ykoq1lqEABOB0oSUq7zsRhG6iBqNFnZaa2EKZpHALspN9cl7V XbNhWeIaXNTM1mTiMyKf/2QWsOUsA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegiedgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtje ertdertddvnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepieehvdfhkeeivdefleelgf duudeftdetjeegjeegudetuedujefgtdetfffhvdfhnecuffhomhgrihhnpeduhhhoshht vgigrghmphhlvgdrtghomhdpohhuthhlohhokhdrtghomhdprhhftgdqvgguihhtohhrrd horhhgpdhivghtfhdrohhrghenucfkphepudehkedrudejgedrgedrvdduheenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfh esgeeiieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 724C33280059; Mon, 23 Nov 2020 07:14:54 -0500 (EST) Date: Mon, 23 Nov 2020 13:14:52 +0100 (CET) Message-Id: <20201123.131452.2154616412508504559.id@4668.se> To: muly_i@rad.com Cc: rfc-editor@rfc-editor.org, kent+ietf@watsen.net, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: References: <20201122221445.1E11FF4071F@rfc-editor.org> <20201123.093729.325420538444196813.id@4668.se> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) 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, 23 Nov 2020 12:14:58 -0000 Hi, Muly Ilan wrote: > Hi, > > If list keys are not required in message body for plain PATCH then > they are also not required for the PUT method. You are right that the keys are redundant also in PUT. However, PUT means completely replace or create the resource, but plain PATCH modifies only the given fields. /martin > But the example for PUT in section 4.5 is: > > PUT /restconf/data/example-jukebox:jukebox/\ > library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 > Host: example.com > Content-Type: application/yang-data+json > { > "example-jukebox:album" : [ > { > "name" : "Wasting Light", > "genre" : "example-jukebox:alternative", > "year" : 2011 > } > ] > } > > So, do we want consistency between PUT and plain PATCH? > > I believe consistency is important and currently the RFC contains two > inconsistent examples. > > > Best, > > Muly > > > -----Original Message----- > From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin > Bj?rklund > Sent: 23/11/2020 10:37 > To: rfc-editor@rfc-editor.org > Cc: kwatsen@juniper.net; netconf@ietf.org > Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) > > Hi, > > The issue boils down to if list keys are required in a plain patch. > Unfortunately, the RFC doesn't specifucy this. From a technical pow, > list keys are not necessary. In fact, if they are present in the > payload, they are redundant (since they are part of the URL) (this is > actually mentioned in the RFC). > > Since it isn't clearly specified, I think we must assume that the keys > are not required. Hence I think that this errata should be rejected. > > In a future version of this document, the behaviour should be > clarified. > > > /martin > > > RFC Errata System wrote: > > The following errata report has been submitted for RFC8040, "RESTCONF > > Protocol". > > > > -------------------------------------- > > You may review the report below and at: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc-editor.org%2Ferrata%2Feid6342&data=04%7C01%7Cmuly_i%40rad.com% > > 7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf9d% > > 7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2nm > > LthW5HkwRvJZi%2F2Pj6%2B9qkLV9gV55wiBpIoiC%2FD4%3D&reserved=0 > > > > -------------------------------------- > > Type: Technical > > Reported by: Muly Ilan > > > > Section: 4.6.1 > > > > Original Text > > ------------- > > To replace just the "year" field in the "album" resource (instead of > > replacing the entire resource with the PUT method), the client might > > send a plain patch as follows: > > PATCH /restconf/data/example-jukebox:jukebox/\ > > library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 > > Host: example.com > > If-Match: "b8389233a4c" > > Content-Type: application/yang-data+xml > xmlns="https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F% > > 2Fexample.com%2Fns%2Fexample-jukebox&data=04%7C01%7Cmuly_i%40rad.c > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata= > > hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserved=0"> > > 2011 > > > > > > Corrected Text > > -------------- > > To replace just the "year" field in the "album" resource (instead of > > replacing the entire resource with the PUT method), the client might > > send a plain patch as follows: > > PATCH /restconf/data/example-jukebox:jukebox/\ > > library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 > > Host: example.com > > If-Match: "b8389233a4c" > > Content-Type: application/yang-data+xml > xmlns="https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F% > > 2Fexample.com%2Fns%2Fexample-jukebox&data=04%7C01%7Cmuly_i%40rad.c > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata= > > hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserved=0"> > > Wasting Light > > 2011 > > > > > > Notes > > ----- > > Missing key leaf value in the message-body (Wasting > > Light) > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party can log in to change > > the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8040 (draft-ietf-netconf-restconf-18) > > -------------------------------------- > > Title : RESTCONF Protocol > > Publication Date : January 2017 > > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > > Category : PROPOSED STANDARD > > Source : Network Configuration > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=04%7C01%7Cmuly_i%40ra > > d.com%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b > > 3bf9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda > > ta=GOd8xUYLJ9C69r7aN6rujBhsYFJd05CxiHNXT9YXOZ0%3D&reserved=0 > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=04%7C01%7Cmuly_i%40rad.com%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GOd8xUYLJ9C69r7aN6rujBhsYFJd05CxiHNXT9YXOZ0%3D&reserved=0 From nobody Mon Nov 23 04:26: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 0819C3A0A27 for ; Mon, 23 Nov 2020 04:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rad365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVvdCBa9zNom for ; Mon, 23 Nov 2020 04:26:47 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80057.outbound.protection.outlook.com [40.107.8.57]) (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 EA7953A0CEB for ; Mon, 23 Nov 2020 04:26:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PeNNt2ohsNWlZ9mqi7j/eUI8O6NnlYVv0rD64yJKZyAPFPq5oWVzXjVCIzGatKmzNzuhte8ws5EJZHVzhFMZea+LUSmpIsDeZgQzc8s5sdt6s2ByG2qmdG8NNcMctaonq+itFNHZODgz498bnE+5x6EKV3Q84BGH0Pl1S9UZVyevs8nwXkYMdeFUTgoWT48Zsij5YP1D0p5YLAds+1W9YOZ4UHqRE9CWSocyqsXC7f9kMUku8L2LU3bXeqgbjAv8QlfcfTMg3TDXVPcnemrhMjFJ8qwoDS1N4BowrhnURjgbThc2cXga7hy+qeey/BbDkMb20qaTWTCNiifpXB1FJQ== 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=dER0kToEnxcEH/paeL0aavGwP8ZptPvuhj0oq+Hw7e8=; b=E1p5ciObDRMyc+mP0hcrVjSXNjrqeSc2HKax2Hp4KlhUT57o4RpDf2ymz71N6Nf0ITv+a6IVOEoCNl9q6XtNe/jmEAb0hFzsa4h4JbJDqxEvvSA4UEc6UcmTogpXe8M4p+XhMU4c+KYtZ3HPMjezdoeMNdM8ZYXJJHrPyxHzBWTAa1BC3vssQmTQnVO/bAiQ9svrgBO+IjXyRV9kiyU8jFlnAZTFRR49yFaAaAmNRkkXTSCQdNi1HqFbD9CRT0kK2jbyUVFZQQDUntsbEa7izHh60+3avTqwyi98tNA2qO81V7Ka9zIIM9MHBa0LqSr5LCeRH9tDaOXhfKI+ZMpzbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rad.com; dmarc=pass action=none header.from=rad.com; dkim=pass header.d=rad.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rad365.onmicrosoft.com; s=selector1-rad365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dER0kToEnxcEH/paeL0aavGwP8ZptPvuhj0oq+Hw7e8=; b=WdpI75O3B0yTRY9ApvPJ/3ns30vaMfWFPSjWz3A1QmA5GNwD7VTWtr+0xc/zv2xLEimJqOlYvDSMweiBQTyT3ZvrYtxZTZRebAniFmIgvan9UpfmLFZXZiCBpRm/eImo2MkW43PlCfYoqV4FXUe0QP2v7owPUSNnW4CB37c0f0o= Received: from AM0PR0302MB3348.eurprd03.prod.outlook.com (2603:10a6:208:b::19) by AM9PR03MB7092.eurprd03.prod.outlook.com (2603:10a6:20b:2da::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Mon, 23 Nov 2020 12:26:15 +0000 Received: from AM0PR0302MB3348.eurprd03.prod.outlook.com ([fe80::eccb:ec09:89e2:cd70]) by AM0PR0302MB3348.eurprd03.prod.outlook.com ([fe80::eccb:ec09:89e2:cd70%5]) with mapi id 15.20.3589.025; Mon, 23 Nov 2020 12:26:15 +0000 From: Muly Ilan To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= CC: "rfc-editor@rfc-editor.org" , "kent+ietf@watsen.net" , "netconf@ietf.org" Thread-Topic: [netconf] [Technical Errata Reported] RFC8040 (6342) Thread-Index: AQHWwRzkciHC9EbDXEyiRm/auJwoyqnVZYeAgAAuWgCAAA5jAIAAAXDw Date: Mon, 23 Nov 2020 12:26:14 +0000 Message-ID: References: <20201122221445.1E11FF4071F@rfc-editor.org> <20201123.093729.325420538444196813.id@4668.se> <20201123.131452.2154616412508504559.id@4668.se> In-Reply-To: <20201123.131452.2154616412508504559.id@4668.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: 4668.se; dkim=none (message not signed) header.d=none;4668.se; dmarc=none action=none header.from=rad.com; x-originating-ip: [185.223.3.181] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 99fa3115-3604-442d-e660-08d88faaf894 x-ms-traffictypediagnostic: AM9PR03MB7092: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: o4YWXDSoVffNaTfLGLcxe5Ac1PKAR8lEJvifwJC3/Cza1czPkJZhkwCVONgfe638LfcylA0n5EjS1/zKXXmFC6h2TO9jT5LtnGJMF7rnGymaZx87Rtty9VUbZjJQ3VTs43UOFq4XkP+lqGjwB+VECJTRkP6cA1gfGv9RuVi+v+ABoyV5utc1zunYA5hlxSSon1+DKZRfn+4aaJIfqfvZRLLrjZ8/OHbEqabfjwzfx77wSgpBxynQSs4I68n9jGC5Une3MBC00UAwhEoQUPJmTTGeA0vJsN/0eE+5WxoQNNjZJpZhV2S4BAbXfwVpvV4Y8wA4PlbWjHk/itbZ9UPJjw2YKkopdDqHWpzhyD/nHwfj7VAYgEDP5zr7LLoTh3C5prtlxVPMa7QFKGtvd07vVA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0302MB3348.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(366004)(39850400004)(396003)(136003)(8676002)(66574015)(55016002)(186003)(76116006)(966005)(316002)(26005)(7696005)(54906003)(2906002)(9686003)(71200400001)(5660300002)(66946007)(83380400001)(86362001)(478600001)(4326008)(53546011)(66476007)(6506007)(33656002)(8936002)(45080400002)(66446008)(52536014)(66556008)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: RPL0EIaJQQopBCkGpCHPgdPXmwacW0lrnvfDO/vxlzxh+Gvrs8PGNCRmdMIGKvkbgAapUG7I1hIn5UoZ7okpN9JSOjnounAVxZw37NaqVejaLdYk2k13nET0t9QSl6KAEKPOl8nAFpzZXJbfhVd4d2rRiu5oR5uFwAhgPJ0nhaDAjmrqPq/I3zWVP4VIp1+T8LXcQhFp7vkt7ICdIIkB54lFpvHEklflxO4nWROVa/2maeQHP/8nNyHGHlhqLPyhfk4g66HIZDOoDTfZMk8RpCVdlMLd1nRRhB8p/Sie7bP/lBm5ZMtmrWmAIi9Aj00+eFDpB4CZyS4TQaTxiplRMhzyZ7Wif4LkSBKcbhwfvKgkpxepjlFkSAzudNxqQ2rh2zzS3Y++J8GF6dzDskD7jNiDPnRxdYli6hmM/eKfCwDxvq//otRl4cbm5xNxeGAgIygiLaaq2iDhTUbj1HCmd2ggNl+LecG5JIEQPZnjyP1ZaCr3+6gDvnDvUHKyJf/FtPfLe5Dac0mgJK5xxE8OwzgWGBzPm1vBWtus1sIE3DXkGJBU+vGocZ+O+bloe3f+R5vX6WVVaxQKDiu8AfpdNN+KZh+2FowNw5FZB3FUYgu3wWUuXZvg4flKNS5hH2ZOUlSD7CgwxBnnqJjrOpQSfSM1bqcjmfImsQ2hrcqvMK0Gg6i8bfu+os4Jz6EJs8IQo/97l7LOLFjO8kv2x21HneKJW6gaIc8ae9aS79NcX1ubV97dKnGfMOzjxvzXUwy1XZO2NeAlgzlHfpz8oXAYtn3XUJuji5RGnLJQN2nB0Sgb1YDBe5aJxHIwz6JRAhbWk7iJbxjJIz6vcUGc8hkZIxJ/YuJCCMLENQlBVwqpqkizx/bhrM213vQ1joWli9rUiXzEQRSq5PGAX0r8MVYzKw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rad.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0302MB3348.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99fa3115-3604-442d-e660-08d88faaf894 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 12:26:15.0106 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NaOefuZkLDKmBWwi++4JsmmCv5TK8IypeIooNXRnO1PIGkZgnbcmubLfFJkamGQ7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB7092 Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) 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, 23 Nov 2020 12:26:49 -0000 Hi Martin, Plain PATCH is defined as a merge operation i.e. it can create a resource. It's not limited to editing of existing resources. >From section 4.6.1: " The plain patch mechanism merges the contents of the message-body with the target resource." " Plain patch can be used to create or update, but not delete, a child resource within the target resource." It's better to have consistent examples. I suggest either to modify the plain PATCH example or the PUT example. Best, Muly -----Original Message----- From: Martin Bj=F6rklund [mailto:mbj+ietf@4668.se]=20 Sent: 23/11/2020 14:15 To: Muly Ilan Cc: rfc-editor@rfc-editor.org; kent+ietf@watsen.net; netconf@ietf.org Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) Hi, Muly Ilan wrote: > Hi, >=20 > If list keys are not required in message body for plain PATCH then=20 > they are also not required for the PUT method. You are right that the keys are redundant also in PUT. However, PUT means = completely replace or create the resource, but plain PATCH modifies only th= e given fields. /martin > But the example for PUT in section 4.5 is: >=20 > PUT /restconf/data/example-jukebox:jukebox/\ > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > Host: example.com > Content-Type: application/yang-data+json { "example-jukebox:album" : [=20 > { "name" : "Wasting Light", "genre" : "example-jukebox:alternative",=20 > "year" : 2011 } ] } >=20 > So, do we want consistency between PUT and plain PATCH? >=20 > I believe consistency is important and currently the RFC contains two=20 > inconsistent examples. >=20 >=20 > Best, >=20 > Muly >=20 >=20 > -----Original Message----- > From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin=20 > Bj?rklund > Sent: 23/11/2020 10:37 > To: rfc-editor@rfc-editor.org > Cc: kwatsen@juniper.net; netconf@ietf.org > Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) >=20 > Hi, >=20 > The issue boils down to if list keys are required in a plain patch. > Unfortunately, the RFC doesn't specifucy this. From a technical pow,=20 > list keys are not necessary. In fact, if they are present in the=20 > payload, they are redundant (since they are part of the URL) (this is=20 > actually mentioned in the RFC). >=20 > Since it isn't clearly specified, I think we must assume that the keys=20 > are not required. Hence I think that this errata should be rejected. >=20 > In a future version of this document, the behaviour should be=20 > clarified. >=20 >=20 > /martin >=20 >=20 > RFC Errata System wrote: > > The following errata report has been submitted for RFC8040,=20 > > "RESTCONF Protocol". > >=20 > > -------------------------------------- > > You may review the report below and at: > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > rfc-editor.org%2Ferrata%2Feid6342&data=3D04%7C01%7Cmuly_i%40rad.co > > m%=20 > > 7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf9 > > d%=20 > > 7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > > wM=20 > > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D2 > > nm > > LthW5HkwRvJZi%2F2Pj6%2B9qkLV9gV55wiBpIoiC%2FD4%3D&reserved=3D0 > >=20 > > -------------------------------------- > > Type: Technical > > Reported by: Muly Ilan > >=20 > > Section: 4.6.1 > >=20 > > Original Text > > ------------- > > To replace just the "year" field in the "album" resource (instead of=20 > > replacing the entire resource with the PUT method), the client might=20 > > send a plain patch as follows: > > PATCH /restconf/data/example-jukebox:jukebox/\ > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > Host: example.com > > If-Match: "b8389233a4c" > > Content-Type: application/yang-data+xml > xmlns=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%= 2 > > F%25=20 > > 2Fexample.com%2Fns%2Fexample-jukebox&data=3D04%7C01%7Cmuly_i%40rad > > .c=20 > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3 > > bf=20 > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w > > Lj=20 > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat > > a=3D hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserved=3D0"= > > > 2011 > > > >=20 > > Corrected Text > > -------------- > > To replace just the "year" field in the "album" resource (instead of=20 > > replacing the entire resource with the PUT method), the client might=20 > > send a plain patch as follows: > > PATCH /restconf/data/example-jukebox:jukebox/\ > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > Host: example.com > > If-Match: "b8389233a4c" > > Content-Type: application/yang-data+xml > xmlns=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%= 2 > > F%25=20 > > 2Fexample.com%2Fns%2Fexample-jukebox&data=3D04%7C01%7Cmuly_i%40rad > > .c=20 > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3 > > bf=20 > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w > > Lj=20 > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat > > a=3D hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserved=3D0"= > > > Wasting Light > > 2011 > > > >=20 > > Notes > > ----- > > Missing key leaf value in the message-body (Wasting > > Light) > >=20 > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please=20 > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party can log in to change=20 > > the status and edit the report, if necessary. > >=20 > > -------------------------------------- > > RFC8040 (draft-ietf-netconf-restconf-18) > > -------------------------------------- > > Title : RESTCONF Protocol > > Publication Date : January 2017 > > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > > Category : PROPOSED STANDARD > > Source : Network Configuration > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > >=20 > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D04%7C01%7Cmuly_i%40 > > ra=20 > > d.com%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad > > 1b > > 3bf9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > C4=20 > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s > > da > > ta=3DGOd8xUYLJ9C69r7aN6rujBhsYFJd05CxiHNXT9YXOZ0%3D&reserved=3D0 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D04%7C01%7Cmuly_i%40ra > d.com%7Cf5c6b052c9fe4dd9c64308d88fa96449%7Cf9047108cc2c4e4897a343fad1b > 3bf9d%7C1%7C0%7C637417304990448682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda > ta=3DSOPMijRWiUHA%2BpJnmxGJ4%2FLWqneTaFwfyIpdpuFl5yU%3D&reserved=3D0 From nobody Mon Nov 23 04:52:40 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 80E503A0A3D for ; Mon, 23 Nov 2020 04:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rad365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0k54goc4i75S for ; Mon, 23 Nov 2020 04:52:36 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2058.outbound.protection.outlook.com [40.107.20.58]) (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 355B93A0A3B for ; Mon, 23 Nov 2020 04:52:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IU2nS0xcRD8EpvbROOnuPO90cc6usakZN6G0m5mcMP9gO71sl8h7U/4Rp8Vn8394RUpNaZ5sfpHZiehOKD/xsGbKRfiKqBUp2sHniSkyDYDnQkMHVVxqwPLvaXaZBiaX3axbSRJ0H/N7t1dwBcFle/aiv8Qf0bLAm/he0Kod7OQB3+/MxvUe2fyhEom7XfH7GU2S4ZANy5cbh5qzr820bcq0aKGt94QucaU8+035DDLyJmfknfIRhRU2erKQRk90ik/QRkXCFJ5XOmDv5tvufZgpAwAQAnTgZ04Lc4I2dPpbs1YN6/hfOtmem3Rc9S0W5rTgHpsKP7bjMBhZxKBsuA== 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=OLVbmbMG61Q2Xmg2XTeYJ3NMO+VjAxop4xJKMoJHBqY=; b=g2RwnzcHGs09BwbfmvxmUZ5P15dErEHW/p6AzdApCfAXgix3n7cpP+Q/VL5Ni+hTd7ngZVa9ZBIfAQt4NhrDzYFQiOMvQ0I7hSuEIG8eN7giM19OODdVpJCcit+Db0onD3K6FyrIj8uLx2fqLRwBukMLOnpesjdot9Zfz4qCUr3YxeWs7vPN/LAKFGko8DHQOUNBeQyRXqfCM9ujDsmxikDMAC5LFR2iZjqnpsHC5XeELuCxYokTDib9IWiw3ccCDugEw7qnur/z4kcTVRh/cFnHsGb5dRt6hOTF3G6NR1dQnwVffP5WDvs9+DLMGY8qfZka17u/tL43du1+EEqP0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rad.com; dmarc=pass action=none header.from=rad.com; dkim=pass header.d=rad.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rad365.onmicrosoft.com; s=selector1-rad365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OLVbmbMG61Q2Xmg2XTeYJ3NMO+VjAxop4xJKMoJHBqY=; b=WPf1J2g/j+uRRUEMwQBTeJJhro57xJIkZBIP/H3G9Gl9EfC3HW3Xqlxue5qNTIpTXr6U/6OpDjVwxU/7reUjkVqaFo4s4mHFHlYt9GNyU8E60c0gBnc37xOtUyIdRup85eM+lw3j263xFJTY7ozIzYUomYvF06SjGnHqP1ajhvk= Received: from AM0PR0302MB3348.eurprd03.prod.outlook.com (2603:10a6:208:b::19) by AM9PR03MB6835.eurprd03.prod.outlook.com (2603:10a6:20b:281::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Mon, 23 Nov 2020 12:52:31 +0000 Received: from AM0PR0302MB3348.eurprd03.prod.outlook.com ([fe80::eccb:ec09:89e2:cd70]) by AM0PR0302MB3348.eurprd03.prod.outlook.com ([fe80::eccb:ec09:89e2:cd70%5]) with mapi id 15.20.3589.025; Mon, 23 Nov 2020 12:52:31 +0000 From: Muly Ilan To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= CC: "rfc-editor@rfc-editor.org" , "kent+ietf@watsen.net" , "netconf@ietf.org" Thread-Topic: [netconf] [Technical Errata Reported] RFC8040 (6342) Thread-Index: AQHWwRzkciHC9EbDXEyiRm/auJwoyqnVZYeAgAAuWgCAAA5jAIAAAXDwgAAF0AA= Date: Mon, 23 Nov 2020 12:52:31 +0000 Message-ID: References: <20201122221445.1E11FF4071F@rfc-editor.org> <20201123.093729.325420538444196813.id@4668.se> <20201123.131452.2154616412508504559.id@4668.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: 4668.se; dkim=none (message not signed) header.d=none;4668.se; dmarc=none action=none header.from=rad.com; x-originating-ip: [185.223.3.181] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c616969b-fb13-4ec8-2c16-08d88faea479 x-ms-traffictypediagnostic: AM9PR03MB6835: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aXFgL5B2dH1AKFGd9E8vnBTxXR1fsTjrJsLJUVcpTkcAlzam1lSQR3sOWtp2xQ4QIwABQ7r+0VLij+QXj5Yn5Wl3aVVhrihEH78EdzfLMFQq0JOAMpCH9ZFgjRWqUC145+99BuejDxT0iExN8y5unASfvCGbVBcglS5aVPLN91g7hbEc8IA0Ly6FWrMofXOgbERPn8ybyuMC5wpCq6zLmQGPSb1CpBADvW4Yw8Hu5RX7Pdp8pjQRje5gbbRZFjaPqUrnRVWOcW2Wml7alrRo+p90YMVyYdpLejmhnvEFodClIWGy0R9hy2wGeZDR+gu9DktZKRirWsuF5hqlVQPbdTsTq+CDc4SrNtZ1Ebd5ThtUXU9VtHJjbeNsYX6fbvw/zWhovueFXXESZZtrofkpVA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0302MB3348.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(346002)(396003)(366004)(39850400004)(8936002)(966005)(71200400001)(66946007)(76116006)(4326008)(2940100002)(9686003)(55016002)(33656002)(478600001)(26005)(64756008)(66446008)(66556008)(316002)(2906002)(83380400001)(66574015)(54906003)(86362001)(8676002)(45080400002)(7696005)(6506007)(52536014)(66476007)(186003)(5660300002)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: TbBMfR6LOPtSAX8nPinwrb/14p090K26e0mgjlC5/XiJnX6SXD59qp6Xds1UR9b+2VedSamYrPFiMvMVQIW8W2u8OIylc+leCOTaeQs1b0OPuxNnA+KdHoHlm//kt5ENHSjaxCVsj/nDqcJp6AKOaVx4QC5Mk9o/zHjrQriKPIbqnoFP1o0NBI5Rf9lleaoMJNGWuf56nDhJCbMcNpUcheFhr0pfsBzj+rYkAAY8OE/zd8Xr4NzbWFS8FvEHSt7AdecE0m6sc4WWi7EtQoQBrWaH28GRMYapj5slFhRcnK+aWCerbZLAsnvXL38TuY7Wv5/+0zLnK2pOJnbr9abwyB3sJWLsaKzyDtCYdLRZ6wQXRF93vsEQsYmFTzk+fqTTJmUv1OPqtqyR4fnYwVQGA9IIBf3EgxpxcnTFOgiwYDyhJAYCJ8BmRs18CTbk+CgCa+ApxnBBWVOptVBBMdUUSikmPpsEkvDsQpDB9/9jOWjwpjZ9hJvOA4+a2ITcyGSZEQaC5kaG4Q01SXcwggGecNnN7OG1I59OP++yqUiaRBweYwjf9LwzbJMo+2WlqxxMtMwiJ+7GQzxEwuq3jZIwj6RB6NZFjXuLrs9EAHGgSH3Ox1irw5TxyfhLX+4MvkUVPgEURyYeYyVW6LPsdGeGI4qmRSrrElQ2hDcSp0hbavxZa+LHtvqF1fnRgk4HxzWWFqDH522r0UEKQiofyzJ/7WoCnZcIvKlN+Lun/R2/oeSYktcwCUP0KcHdoIBGlKw3xL9Q5C/Y0S2i9O7dYxZQta0f2GygPZ9PS0pPgCZSAzmkYnhcNg/b0TsFdFDYAxQsaLWqfqRgC1Ct7WoOTMI4maPzEe04XcPAEhOImbfkaP7RkWMKBvXE3Xugw83qFV38t23ZVjzKryfDewIVuQDkQw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rad.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0302MB3348.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c616969b-fb13-4ec8-2c16-08d88faea479 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 12:52:31.8652 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: c3aixk10bKAKjSm5H4D52Z3F/mfe/jk+Y7DruzapHcbGZR4sdndxr1LQ8o0XfMUQ X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB6835 Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) 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, 23 Nov 2020 12:52:39 -0000 Hi Martin, Putting aside the similarity or not between plain PATCH and PUT, there's an= other example of inconsistency with plain PATCH in the RFC. Please check the plain PATCH example in appendix B.2.5. " Edit a Data Resou= rce". This example has keys both in the message header and message body. This means that either the example in 4.6.1 or the example in B.2.5 should = be modified.=20 Section 4.6.1 includes the following text: " If the target resource represents a YANG list instance, then the key leaf values, in message-body representation, MUST be the same as the key leaf values in the request URI. " If keys are not needed in the message body so this "warning text" is not ne= eded either. Moreover, since the above "warning text" is part of the RFC, it suggests to= me that the RFC assumes that there are keys in both header URI and body. = =20 Best, Muly -----Original Message----- From: Muly Ilan=20 Sent: 23/11/2020 14:26 To: Martin Bj=F6rklund Cc: rfc-editor@rfc-editor.org; kent+ietf@watsen.net; netconf@ietf.org Subject: RE: [netconf] [Technical Errata Reported] RFC8040 (6342) Hi Martin, Plain PATCH is defined as a merge operation i.e. it can create a resource. It's not limited to editing of existing resources. >From section 4.6.1: " The plain patch mechanism merges the contents of the message-body with th= e target resource." " Plain patch can be used to create or update, but not delete, a child reso= urce within the target resource." It's better to have consistent examples. I suggest either to modify the plain PATCH example or the PUT example. Best, Muly -----Original Message----- From: Martin Bj=F6rklund [mailto:mbj+ietf@4668.se] Sent: 23/11/2020 14:15 To: Muly Ilan Cc: rfc-editor@rfc-editor.org; kent+ietf@watsen.net; netconf@ietf.org Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) Hi, Muly Ilan wrote: > Hi, >=20 > If list keys are not required in message body for plain PATCH then=20 > they are also not required for the PUT method. You are right that the keys are redundant also in PUT. However, PUT means = completely replace or create the resource, but plain PATCH modifies only th= e given fields. /martin > But the example for PUT in section 4.5 is: >=20 > PUT /restconf/data/example-jukebox:jukebox/\ > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > Host: example.com > Content-Type: application/yang-data+json { "example-jukebox:album" : [=20 > { "name" : "Wasting Light", "genre" : "example-jukebox:alternative",=20 > "year" : 2011 } ] } >=20 > So, do we want consistency between PUT and plain PATCH? >=20 > I believe consistency is important and currently the RFC contains two=20 > inconsistent examples. >=20 >=20 > Best, >=20 > Muly >=20 >=20 > -----Original Message----- > From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin=20 > Bj?rklund > Sent: 23/11/2020 10:37 > To: rfc-editor@rfc-editor.org > Cc: kwatsen@juniper.net; netconf@ietf.org > Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) >=20 > Hi, >=20 > The issue boils down to if list keys are required in a plain patch. > Unfortunately, the RFC doesn't specifucy this. From a technical pow,=20 > list keys are not necessary. In fact, if they are present in the=20 > payload, they are redundant (since they are part of the URL) (this is=20 > actually mentioned in the RFC). >=20 > Since it isn't clearly specified, I think we must assume that the keys=20 > are not required. Hence I think that this errata should be rejected. >=20 > In a future version of this document, the behaviour should be=20 > clarified. >=20 >=20 > /martin >=20 >=20 > RFC Errata System wrote: > > The following errata report has been submitted for RFC8040,=20 > > "RESTCONF Protocol". > >=20 > > -------------------------------------- > > You may review the report below and at: > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > rfc-editor.org%2Ferrata%2Feid6342&data=3D04%7C01%7Cmuly_i%40rad.co > > m% > > 7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf9 > > d% > > 7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > > wM > > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D2 > > nm > > LthW5HkwRvJZi%2F2Pj6%2B9qkLV9gV55wiBpIoiC%2FD4%3D&reserved=3D0 > >=20 > > -------------------------------------- > > Type: Technical > > Reported by: Muly Ilan > >=20 > > Section: 4.6.1 > >=20 > > Original Text > > ------------- > > To replace just the "year" field in the "album" resource (instead of=20 > > replacing the entire resource with the PUT method), the client might=20 > > send a plain patch as follows: > > PATCH /restconf/data/example-jukebox:jukebox/\ > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > Host: example.com > > If-Match: "b8389233a4c" > > Content-Type: application/yang-data+xml > xmlns=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%= 2 > > F%25 > > 2Fexample.com%2Fns%2Fexample-jukebox&data=3D04%7C01%7Cmuly_i%40rad > > .c > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3 > > bf > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w > > Lj > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat > > a=3D hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserved=3D0"= > > > 2011 > > > >=20 > > Corrected Text > > -------------- > > To replace just the "year" field in the "album" resource (instead of=20 > > replacing the entire resource with the PUT method), the client might=20 > > send a plain patch as follows: > > PATCH /restconf/data/example-jukebox:jukebox/\ > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > Host: example.com > > If-Match: "b8389233a4c" > > Content-Type: application/yang-data+xml > xmlns=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%= 2 > > F%25 > > 2Fexample.com%2Fns%2Fexample-jukebox&data=3D04%7C01%7Cmuly_i%40rad > > .c > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3 > > bf > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w > > Lj > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat > > a=3D hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserved=3D0"= > > > Wasting Light > > 2011 > > > >=20 > > Notes > > ----- > > Missing key leaf value in the message-body (Wasting > > Light) > >=20 > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please=20 > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party can log in to change=20 > > the status and edit the report, if necessary. > >=20 > > -------------------------------------- > > RFC8040 (draft-ietf-netconf-restconf-18) > > -------------------------------------- > > Title : RESTCONF Protocol > > Publication Date : January 2017 > > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > > Category : PROPOSED STANDARD > > Source : Network Configuration > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > >=20 > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D04%7C01%7Cmuly_i%40 > > ra > > d.com%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad > > 1b > > 3bf9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > C4 > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s > > da > > ta=3DGOd8xUYLJ9C69r7aN6rujBhsYFJd05CxiHNXT9YXOZ0%3D&reserved=3D0 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D04%7C01%7Cmuly_i%40ra > d.com%7Cf5c6b052c9fe4dd9c64308d88fa96449%7Cf9047108cc2c4e4897a343fad1b > 3bf9d%7C1%7C0%7C637417304990448682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda > ta=3DSOPMijRWiUHA%2BpJnmxGJ4%2FLWqneTaFwfyIpdpuFl5yU%3D&reserved=3D0 From nobody Mon Nov 23 05:03: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 4FD7E3A0A6A for ; Mon, 23 Nov 2020 05:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[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 P81oa6TYhUXz for ; Mon, 23 Nov 2020 05:03:02 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 760E13A0A50 for ; Mon, 23 Nov 2020 05:03:02 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id u18so23582151lfd.9 for ; Mon, 23 Nov 2020 05:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YMR/ol6pA2gJsAOSohx0/5IJthQJyKsSTwJqCZrbOZA=; b=khrrpSI0tvyOUsxrDNzXz74Me59BB8nh8fhsJASUYba/lmbfCgxqGkSRCA1tKU2cID eoQ4tQb3eIUKsFBUr83fERr3iIAi0f1iDAkKulhKSMR+7UXp3JdLiQ5FchmI2DmSMVCu MJAO/Ommed648u3/ClRAwAHtGlg/MQ0leGbJkIG3gVjAEeGZ6aPtmDKeCd3FIzWQ+Lg+ G42r2YmscewKJ1EcgiWxG8SRFwPXJLyDKGWW0lSoH3894a8LKi09u3hsJwHcbysETwNs Hgz0znKKr2Fp26gYoKE+yf7RHWlaqxlC7spEOYU1X/K+fRwIHuyM26NzoofmH8EHm2tD j1Bg== 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=YMR/ol6pA2gJsAOSohx0/5IJthQJyKsSTwJqCZrbOZA=; b=UvEac6c8h0TsSgu0V47lmniqNw+s9PA7WABXQmOAtOlNdv7eAQ2WqNl7/tnWjoUer6 L/cGrwIu6izeTGSpaayLdFaTAjJkWVdQmFvwURJ+0pcUFAHkPcV6vwhNDccE9ZpqVClq fXxWvissRicE28GGKQa9HymG2HFNFPXWpvCg3DRKPdkBwTmm0gGbbrhrpqWfvmQ7Zo1W Oj6Ajc11Kcz4eAYD7mE6zuegQzP2DWyUb4s8F1dTJp94U73S7rQM0bUR7nYWahaAQwoF YYDwOIWQQ1XNIMfGv7xy67eBpbhOffHy5Kn2uOHdHAMD/SH0BhDt6fksTRhk7oGlayKa emGw== X-Gm-Message-State: AOAM532ThfmYcVY2RV9ZuSZcwnz/dNrBCP5YB1L+szE0ZiOXuEzR55k1 eQgo7wn3aMToShxcChK1uwV0HdQ1dyJCtgbqIfpV0g== X-Google-Smtp-Source: ABdhPJzRutCJQJfkw+vnDimI6d/FcdwicHTuFdlb5bP4cKy5v7RRnG/G8zjw9BAjdz36CpsM/gOJmU/1vF5Gk1Npu58= X-Received: by 2002:a19:ec09:: with SMTP id b9mr14571755lfa.178.1606136580240; Mon, 23 Nov 2020 05:03:00 -0800 (PST) MIME-Version: 1.0 References: <20201122221445.1E11FF4071F@rfc-editor.org> <20201123.093729.325420538444196813.id@4668.se> In-Reply-To: <20201123.093729.325420538444196813.id@4668.se> From: Andy Bierman Date: Mon, 23 Nov 2020 05:02:49 -0800 Message-ID: To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= Cc: RFC Editor , Kent Watsen , Warren Kumari , Robert Wilton , Kent Watsen , Mahesh Jethanandani , Netconf Content-Type: multipart/alternative; boundary="00000000000053928605b4c5d009" Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) 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, 23 Nov 2020 13:03:04 -0000 --00000000000053928605b4c5d009 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2020 at 12:37 AM Martin Bj=C3=B6rklund w= rote: > Hi, > > The issue boils down to if list keys are required in a plain patch. > Unfortunately, the RFC doesn't specifucy this. From a technical pow, > list keys are not necessary. In fact, if they are present in the > payload, they are redundant (since they are part of the URL) (this is > actually mentioned in the RFC). > > Since it isn't clearly specified, I think we must assume that the keys > are not required. Hence I think that this errata should be rejected. > > In a future version of this document, the behaviour should be > clarified. > > +1 reject this errata > > /martin > > Andy > > RFC Errata System wrote: > > The following errata report has been submitted for RFC8040, > > "RESTCONF Protocol". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6342 > > > > -------------------------------------- > > Type: Technical > > Reported by: Muly Ilan > > > > Section: 4.6.1 > > > > Original Text > > ------------- > > To replace just the "year" field in the "album" resource (instead of > > replacing the entire resource with the PUT method), the client might > > send a plain patch as follows: > > PATCH /restconf/data/example-jukebox:jukebox/\ > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > Host: example.com > > If-Match: "b8389233a4c" > > Content-Type: application/yang-data+xml > > > > 2011 > > > > > > Corrected Text > > -------------- > > To replace just the "year" field in the "album" resource (instead of > > replacing the entire resource with the PUT method), the client might > > send a plain patch as follows: > > PATCH /restconf/data/example-jukebox:jukebox/\ > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > Host: example.com > > If-Match: "b8389233a4c" > > Content-Type: application/yang-data+xml > > > > Wasting Light > > 2011 > > > > > > Notes > > ----- > > Missing key leaf value in the message-body (Wasting Light) > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8040 (draft-ietf-netconf-restconf-18) > > -------------------------------------- > > Title : RESTCONF Protocol > > Publication Date : January 2017 > > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > > Category : PROPOSED STANDARD > > Source : Network Configuration > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > --00000000000053928605b4c5d009 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 23, 2020 at 12:37 AM Mart= in Bj=C3=B6rklund <mbj+ietf@4668.s= e> wrote:
Hi,

The issue boils down to if list keys are required in a plain patch.
Unfortunately, the RFC doesn't specifucy this.=C2=A0 From a technical p= ow,
list keys are not necessary.=C2=A0 In fact, if they are present in the
payload, they are redundant (since they are part of the URL) (this is
actually mentioned in the RFC).

Since it isn't clearly specified, I think we must assume that the keys<= br> are not required.=C2=A0 Hence I think that this errata should be rejected.<= br>
In a future version of this document, the behaviour should be
clarified.



+1

=
reject this errata

=C2=A0

/martin


Andy
=C2=A0

RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> The following errata report has been submitted for RFC8040,
> "RESTCONF Protocol".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6342
>
> --------------------------------------
> Type: Technical
> Reported by: Muly Ilan <muly_i@rad.com>
>
> Section: 4.6.1
>
> Original Text
> -------------
> To replace just the "year" field in the "album" re= source (instead of
> replacing the entire resource with the PUT method), the client might > send a plain patch as follows:
> PATCH /restconf/data/example-jukebox:jukebox/\
> library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1
> Host: example.com
> If-Match: "b8389233a4c"
> Content-Type: application/yang-data+xml
> <album xmlns=3D"http://example.com/ns/example-juke= box">
> <year>2011</year>
> </album>
>
> Corrected Text
> --------------
> To replace just the "year" field in the "album" re= source (instead of
> replacing the entire resource with the PUT method), the client might > send a plain patch as follows:
> PATCH /restconf/data/example-jukebox:jukebox/\
> library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1
> Host: example.com
> If-Match: "b8389233a4c"
> Content-Type: application/yang-data+xml
> <album xmlns=3D"http://example.com/ns/example-juke= box">
> <name>Wasting Light</name>
> <year>2011</year>
> </album>
>
> Notes
> -----
> Missing key leaf value in the message-body (<name>Wasting Light&= lt;/name>)
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party=C2=A0
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC8040 (draft-ietf-netconf-restconf-18)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: RESTCONF= Protocol
> Publication Date=C2=A0 =C2=A0 : January 2017
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A. Bierman, M. Bjo= rklund, K. Watsen
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Confi= guration
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operatio= ns and Management
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf<= br>
--00000000000053928605b4c5d009-- From nobody Mon Nov 23 05:34:56 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 3C0BC3A0B04 for ; Mon, 23 Nov 2020 05:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rad365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIeoEBHOOy-n for ; Mon, 23 Nov 2020 05:34:53 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130050.outbound.protection.outlook.com [40.107.13.50]) (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 BA2E73A0AFA for ; Mon, 23 Nov 2020 05:34:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kQrSVlc6uvrG/n/+ch7qK/y5soa0BENZue/CTEb/JuQMXrrGtU4CKw1/fxiqIBsCmlxqKtCBNDkhA9aiGut0xKa4JdnwIB6Wcq2bn+p9VAT+Suu10YeDh55a/QJBjqG2XPUT0hnb/aRsRHy0TmI3A/TOObS4YtZS7u7GDRhqK9xQMBHnFq2/ysKMh+4lIf5xXrkQJWc7KFnjQ9sggSG1+BupNT0jJ0PMUrdEfYNNh7e3BwMVySO+Nfwrr1Ln4CggOe07VtW3yXgxLJICgnmdzuq3eJwI4lVLiHVLwIT43u6zvDhb1nTWCJzqsezaPeUpF3Sv5k1TDfqjTQ6CJBoPyw== 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=Lx7YIX7mCTwfyPApW9E2F0oDl4i6o+VVMdh7Dt3ObsY=; b=mDGxrIlg4Vhh+QrmUki+5VZ8op4eRSqQKkN6kb90FjyMtqtSQlBYH/qM/CL3XZUoo6MXRq9DZuyv+5Lm/xW6sInn4AWsSvs6Vt9Hrf8v3NOWx6fIEL+L65sNCXgp6q+Wm3zCsrnxEuXhTtxDMcFPOmY7soX8NMNCzh0DZjVPgZSNU2WY0/UOfyi77AjswLaf6p+i40RyX1mf4eif72tZljrAGyncouWGci5Nve11ArArkVI6RMgE1oUHFWbQD0mgz09tboKdLANIYVcQNQyiaYLbao4Eg/dPPvjiX1JDdBpvQkio8RktTHU1Rak9fBTJOCbzotalNmQTTPb9SEkeYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rad.com; dmarc=pass action=none header.from=rad.com; dkim=pass header.d=rad.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rad365.onmicrosoft.com; s=selector1-rad365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Lx7YIX7mCTwfyPApW9E2F0oDl4i6o+VVMdh7Dt3ObsY=; b=XIY9SEAsuRM3t+Dha4qhOgDnS73dxjZep0BrkV8E+qZ8iSmWLHp0KLdtHyZshnLXXCl/uUixbh6DWrEB/CBkZy7K6AWp7UfPM+D+OiUmLpfyBEc7F3+ZP0HIB2CnCmt+RaoGGBSXYeHx1VKqtY48LnHX3PeqKMnnIjo2rXPu+bY= Received: from AM0PR0302MB3348.eurprd03.prod.outlook.com (2603:10a6:208:b::19) by AM0PR03MB3538.eurprd03.prod.outlook.com (2603:10a6:208:42::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Mon, 23 Nov 2020 13:34:50 +0000 Received: from AM0PR0302MB3348.eurprd03.prod.outlook.com ([fe80::eccb:ec09:89e2:cd70]) by AM0PR0302MB3348.eurprd03.prod.outlook.com ([fe80::eccb:ec09:89e2:cd70%5]) with mapi id 15.20.3589.025; Mon, 23 Nov 2020 13:34:50 +0000 From: Muly Ilan To: Andy Bierman , =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= CC: Kent Watsen , Netconf , RFC Editor Thread-Topic: [netconf] [Technical Errata Reported] RFC8040 (6342) Thread-Index: AQHWwRzkciHC9EbDXEyiRm/auJwoyqnVZYeAgABKIoCAAAg2YA== Date: Mon, 23 Nov 2020 13:34:49 +0000 Message-ID: References: <20201122221445.1E11FF4071F@rfc-editor.org> <20201123.093729.325420538444196813.id@4668.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=rad.com; x-originating-ip: [185.223.3.181] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f7ba25df-4a93-43b8-3c23-08d88fb48d49 x-ms-traffictypediagnostic: AM0PR03MB3538: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: palmmFGD2YpRVXD9aJDWMy3QVvG/ALTXLXE+n3aB5KuHnivKFz5htEMEbyNlgbyWh2Z1NGNtlP0bSuMqUBsTEdkgGBm5XxRg7f6mmut1drYQSPNGYkC7W/Da4hnYczdp9ktyO7w8QF/30GTNkqZkzyTaq5CE6tyyFhw9/N0wqFlN9FSEXnkNkNUnXulpexuBrDZ1Ltx+Y59A3ABYQ1+DIKJ//CcTX04dURzDUDGv/cogZPIVYFxI3rGyLX0CbTChY4XLZjDGkfe8i2VQ+0kWMaG+Bt3v2emaegn0McAz452WfMXGZUtx44QmaUCKMDV33kzIDetQcUiOrqatN3AtmMGfycBCIc6HOFZO0NxzE62Sm+pZPdFtNYKmxTjwVr5lkK+l020DNdN7qNAtEvzwrQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0302MB3348.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(39850400004)(346002)(376002)(366004)(6506007)(64756008)(316002)(966005)(9326002)(478600001)(66574015)(8936002)(4326008)(86362001)(2906002)(166002)(71200400001)(66476007)(66946007)(8676002)(52536014)(5660300002)(83380400001)(66446008)(55016002)(9686003)(53546011)(66556008)(7696005)(33656002)(76116006)(110136005)(26005)(54906003)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: e/VuCj7pFJlrW3O47deivqovdfADhymrRU2CKXV3u/uo3xyPLzG+sQpguz20J2yVH6KpX2aP9nhrDpBBtXxPibjD8Ws4QPJais4cYmV5ZGmCcR3v7KalX6Pr1PavZUrEViXpi28bLLPOarZWta+Py6H0WH2k5rLCgK1ga8z85p7VaBjOFaxCKgi3RSHGHqPjAXFc8UXUevQ7szYySE5SwfXBFbGmifUzs1068h8hl+YNGrWEX1+bPGw3AwTRsSpcNbZYJLEfWdRBU/HYgVh+8PSboRpH2CcNNJV+BqrAh+fF7QR+Nm/M5Vvylic39J6FmwX/4lIjUquiWnSY9/e7gWxQ3Oj048Zz+sFvTKCWvj2cNvSyCLWt9fPxXYAFPgBY6amWbUMQJbNwtEXALz4G+IhYczD0l2zPLLGU7zyP0noi/rzedVlEmrq/U0WxQg7Knd3Yf1TnsITGWv6MoKn4TOEDnEVidlo6fozKiKoKZB2EKdMy2lmzPuCSja5yyHbrkuPi+BKjNZXV7PNtbxH+co321nd2v/hfCTg9I/mwAqHXY+sSW9UYypcb9Z/L3Tyg/XT/EnaJs5+8YwREJGNRC5t7HIrfWuUu7/TJPt1iZt7cLrpc///d0Smk4qU9feV6IIoh0z6+5l0XjBrUfTKP3EeX9JAheL5f3+hMqr2ee1QdLDYYa6+BhQuWfzGIT5OmHXdirkAapMQg5hPzl+WdbNU3LsPAay4SvA+dJtW5VC1chDI17l+m3rh+sEbVSRWOs3SF13fNRFl4xIEK/NDt1hVzk3YKG+ekn0Txg/OzureYvyK3GKWlSt3zsB2xQvaXVFO75dQh6vBinzg+X15OGo6KsBwO5WXt5C59LNPVtKzlpdaR+epbmCGH6kcUW1B5XiMdHmxdYvIxPSYepioPUQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR0302MB3348B74B591E5D85C4A88FBCF9FC0AM0PR0302MB3348_" MIME-Version: 1.0 X-OriginatorOrg: rad.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0302MB3348.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f7ba25df-4a93-43b8-3c23-08d88fb48d49 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 13:34:49.9618 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JwmcIpr/nBYdiWUe8qqUynLdC1B2DItMdl3VJpnt9Mt03az1ETaDL6IZYHBJwvVV X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB3538 Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) 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, 23 Nov 2020 13:34:55 -0000 --_000_AM0PR0302MB3348B74B591E5D85C4A88FBCF9FC0AM0PR0302MB3348_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhlIGV4YW1wbGUgZm9yIHBsYWluIFBBVENIIGluIGFwcGVuZGl4IEIuMi41 IGhhcyBrZXlzIGluIGJvdGggdGhlIFVSSSBhbmQgYm9keS4NCldoZXJlYXMgdGhlIGV4YW1wbGUg aW4gc2VjdGlvbiA0LjYuMSBoYXMga2V5cyBvbmx5IGluIHRoZSBVUkkuDQoNCkNsZWFybHkgb25l IG9mIHRoZSBleGFtcGxlcyBpcyB3cm9uZy4NCg0KQmVzdCwNCg0KTXVseQ0KDQoNCkZyb206IG5l dGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5 IEJpZXJtYW4NClNlbnQ6IDIzLzExLzIwMjAgMTU6MDMNClRvOiBNYXJ0aW4gQmrDtnJrbHVuZCA8 bWJqK2lldGZANDY2OC5zZT4NCkNjOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD47 IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+OyBSRkMgRWRpdG9yIDxyZmMtZWRpdG9yQHJmYy1l ZGl0b3Iub3JnPg0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBv cnRlZF0gUkZDODA0MCAoNjM0MikNCg0KDQoNCk9uIE1vbiwgTm92IDIzLCAyMDIwIGF0IDEyOjM3 IEFNIE1hcnRpbiBCasO2cmtsdW5kIDxtYmoraWV0ZkA0NjY4LnNlPG1haWx0bzptYmolMkJpZXRm QDQ2Njguc2U+PiB3cm90ZToNCkhpLA0KDQpUaGUgaXNzdWUgYm9pbHMgZG93biB0byBpZiBsaXN0 IGtleXMgYXJlIHJlcXVpcmVkIGluIGEgcGxhaW4gcGF0Y2guDQpVbmZvcnR1bmF0ZWx5LCB0aGUg UkZDIGRvZXNuJ3Qgc3BlY2lmdWN5IHRoaXMuICBGcm9tIGEgdGVjaG5pY2FsIHBvdywNCmxpc3Qg a2V5cyBhcmUgbm90IG5lY2Vzc2FyeS4gIEluIGZhY3QsIGlmIHRoZXkgYXJlIHByZXNlbnQgaW4g dGhlDQpwYXlsb2FkLCB0aGV5IGFyZSByZWR1bmRhbnQgKHNpbmNlIHRoZXkgYXJlIHBhcnQgb2Yg dGhlIFVSTCkgKHRoaXMgaXMNCmFjdHVhbGx5IG1lbnRpb25lZCBpbiB0aGUgUkZDKS4NCg0KU2lu Y2UgaXQgaXNuJ3QgY2xlYXJseSBzcGVjaWZpZWQsIEkgdGhpbmsgd2UgbXVzdCBhc3N1bWUgdGhh dCB0aGUga2V5cw0KYXJlIG5vdCByZXF1aXJlZC4gIEhlbmNlIEkgdGhpbmsgdGhhdCB0aGlzIGVy cmF0YSBzaG91bGQgYmUgcmVqZWN0ZWQuDQoNCkluIGEgZnV0dXJlIHZlcnNpb24gb2YgdGhpcyBk b2N1bWVudCwgdGhlIGJlaGF2aW91ciBzaG91bGQgYmUNCmNsYXJpZmllZC4NCg0KDQorMQ0KDQpy ZWplY3QgdGhpcyBlcnJhdGENCg0KDQoNCi9tYXJ0aW4NCg0KQW5keQ0KDQoNClJGQyBFcnJhdGEg U3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzpyZmMtZWRpdG9yQHJmYy1l ZGl0b3Iub3JnPj4gd3JvdGU6DQo+IFRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVl biBzdWJtaXR0ZWQgZm9yIFJGQzgwNDAsDQo+ICJSRVNUQ09ORiBQcm90b2NvbCIuDQo+DQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFlvdSBtYXkgcmV2aWV3IHRo ZSByZXBvcnQgYmVsb3cgYW5kIGF0Og0KPiBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJh dGEvZWlkNjM0MjxodHRwczovL2V1cjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cucmZjLWVkaXRvci5vcmclMkZlcnJhdGElMkZlaWQ2MzQy JmRhdGE9MDQlN0MwMSU3Q211bHlfaSU0MHJhZC5jb20lN0M1NTZkYzEwY2NlNjM0OGQ4NTBlODA4 ZDg4ZmIwMjRlMCU3Q2Y5MDQ3MTA4Y2MyYzRlNDg5N2EzNDNmYWQxYjNiZjlkJTdDMSU3QzAlN0M2 Mzc0MTczMzM5ODk5MTA2OTMlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpB d01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAw MCZzZGF0YT1BaDhxN1JiOUd3T3A0Q2s2JTJGRXJOTERrOTJQcFNBNktQYm5yeEolMkZIWXBqYyUz RCZyZXNlcnZlZD0wPg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiBUeXBlOiBUZWNobmljYWwNCj4gUmVwb3J0ZWQgYnk6IE11bHkgSWxhbiA8bXVseV9pQHJh ZC5jb208bWFpbHRvOm11bHlfaUByYWQuY29tPj4NCj4NCj4gU2VjdGlvbjogNC42LjENCj4NCj4g T3JpZ2luYWwgVGV4dA0KPiAtLS0tLS0tLS0tLS0tDQo+IFRvIHJlcGxhY2UganVzdCB0aGUgInll YXIiIGZpZWxkIGluIHRoZSAiYWxidW0iIHJlc291cmNlIChpbnN0ZWFkIG9mDQo+IHJlcGxhY2lu ZyB0aGUgZW50aXJlIHJlc291cmNlIHdpdGggdGhlIFBVVCBtZXRob2QpLCB0aGUgY2xpZW50IG1p Z2h0DQo+IHNlbmQgYSBwbGFpbiBwYXRjaCBhcyBmb2xsb3dzOg0KPiBQQVRDSCAvcmVzdGNvbmYv ZGF0YS9leGFtcGxlLWp1a2Vib3g6anVrZWJveC9cDQo+IGxpYnJhcnkvYXJ0aXN0PUZvbyUyMEZp Z2h0ZXJzL2FsYnVtPVdhc3RpbmclMjBMaWdodCBIVFRQLzEuMQ0KPiBIb3N0OiBleGFtcGxlLmNv bTxodHRwczovL2V1cjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cCUzQSUyRiUyRmV4YW1wbGUuY29tJTJGJmRhdGE9MDQlN0MwMSU3Q211bHlfaSU0MHJhZC5jb20l N0M1NTZkYzEwY2NlNjM0OGQ4NTBlODA4ZDg4ZmIwMjRlMCU3Q2Y5MDQ3MTA4Y2MyYzRlNDg5N2Ez NDNmYWQxYjNiZjlkJTdDMSU3QzAlN0M2Mzc0MTczMzM5ODk5MjA2ODMlN0NVbmtub3duJTdDVFdG cGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFo YVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZzZGF0YT1SNGlxRnRuSXclMkZrdEdjUWQxVXpkclk1 Z1Q2TFlGMmNsMHElMkJmTmc2M3NXcyUzRCZyZXNlcnZlZD0wPg0KPiBJZi1NYXRjaDogImI4Mzg5 MjMzYTRjIg0KPiBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3lhbmctZGF0YSt4bWwNCj4gPGFs YnVtIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vbnMvZXhhbXBsZS1qdWtlYm94PGh0dHBzOi8v ZXVyMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJG ZXhhbXBsZS5jb20lMkZucyUyRmV4YW1wbGUtanVrZWJveCZkYXRhPTA0JTdDMDElN0NtdWx5X2kl NDByYWQuY29tJTdDNTU2ZGMxMGNjZTYzNDhkODUwZTgwOGQ4OGZiMDI0ZTAlN0NmOTA0NzEwOGNj MmM0ZTQ4OTdhMzQzZmFkMWIzYmY5ZCU3QzElN0MwJTdDNjM3NDE3MzMzOTg5OTIwNjgzJTdDVW5r bm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxD SkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmc2RhdGE9VDhOdEZPUlVHU1JrNkhq TiUyRjM4MlUwdmtCJTJGVkYlMkZKNVl2S0RrQk1FVEZ1QSUzRCZyZXNlcnZlZD0wPiI+DQo+IDx5 ZWFyPjIwMTE8L3llYXI+DQo+IDwvYWxidW0+DQo+DQo+IENvcnJlY3RlZCBUZXh0DQo+IC0tLS0t LS0tLS0tLS0tDQo+IFRvIHJlcGxhY2UganVzdCB0aGUgInllYXIiIGZpZWxkIGluIHRoZSAiYWxi dW0iIHJlc291cmNlIChpbnN0ZWFkIG9mDQo+IHJlcGxhY2luZyB0aGUgZW50aXJlIHJlc291cmNl IHdpdGggdGhlIFBVVCBtZXRob2QpLCB0aGUgY2xpZW50IG1pZ2h0DQo+IHNlbmQgYSBwbGFpbiBw YXRjaCBhcyBmb2xsb3dzOg0KPiBQQVRDSCAvcmVzdGNvbmYvZGF0YS9leGFtcGxlLWp1a2Vib3g6 anVrZWJveC9cDQo+IGxpYnJhcnkvYXJ0aXN0PUZvbyUyMEZpZ2h0ZXJzL2FsYnVtPVdhc3Rpbmcl MjBMaWdodCBIVFRQLzEuMQ0KPiBIb3N0OiBleGFtcGxlLmNvbTxodHRwczovL2V1cjAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRmV4YW1wbGUuY29t JTJGJmRhdGE9MDQlN0MwMSU3Q211bHlfaSU0MHJhZC5jb20lN0M1NTZkYzEwY2NlNjM0OGQ4NTBl ODA4ZDg4ZmIwMjRlMCU3Q2Y5MDQ3MTA4Y2MyYzRlNDg5N2EzNDNmYWQxYjNiZjlkJTdDMSU3QzAl N0M2Mzc0MTczMzM5ODk5MzA2NzglN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3 TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdD MTAwMCZzZGF0YT02M1Rka1daUm5yWWFTYUhTSE1EYkFseEhUa0lEUDRadTdZUHJ6bjk2UmdFJTNE JnJlc2VydmVkPTA+DQo+IElmLU1hdGNoOiAiYjgzODkyMzNhNGMiDQo+IENvbnRlbnQtVHlwZTog YXBwbGljYXRpb24veWFuZy1kYXRhK3htbA0KPiA8YWxidW0geG1sbnM9Imh0dHA6Ly9leGFtcGxl LmNvbS9ucy9leGFtcGxlLWp1a2Vib3g8aHR0cHM6Ly9ldXIwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZleGFtcGxlLmNvbSUyRm5zJTJGZXhhbXBs ZS1qdWtlYm94JmRhdGE9MDQlN0MwMSU3Q211bHlfaSU0MHJhZC5jb20lN0M1NTZkYzEwY2NlNjM0 OGQ4NTBlODA4ZDg4ZmIwMjRlMCU3Q2Y5MDQ3MTA4Y2MyYzRlNDg5N2EzNDNmYWQxYjNiZjlkJTdD MSU3QzAlN0M2Mzc0MTczMzM5ODk5MzA2NzglN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lq b2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4w JTNEJTdDMTAwMCZzZGF0YT1neXNLVEpOOTVmNTl3NTglMkJOV01WcDVaRzZON1YxSXIwbTZkTDhK RzZxSTAlM0QmcmVzZXJ2ZWQ9MD4iPg0KPiA8bmFtZT5XYXN0aW5nIExpZ2h0PC9uYW1lPg0KPiA8 eWVhcj4yMDExPC95ZWFyPg0KPiA8L2FsYnVtPg0KPg0KPiBOb3Rlcw0KPiAtLS0tLQ0KPiBNaXNz aW5nIGtleSBsZWFmIHZhbHVlIGluIHRoZSBtZXNzYWdlLWJvZHkgKDxuYW1lPldhc3RpbmcgTGln aHQ8L25hbWU+KQ0KPg0KPiBJbnN0cnVjdGlvbnM6DQo+IC0tLS0tLS0tLS0tLS0NCj4gVGhpcyBl cnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4gSWYgbmVjZXNzYXJ5LCBw bGVhc2UNCj4gdXNlICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBzaG91bGQgYmUg dmVyaWZpZWQgb3INCj4gcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0aGUg dmVyaWZ5aW5nIHBhcnR5DQo+IGNhbiBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVk aXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5Lg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiBSRkM4MDQwIChkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYt MTgpDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRpdGxlICAg ICAgICAgICAgICAgOiBSRVNUQ09ORiBQcm90b2NvbA0KPiBQdWJsaWNhdGlvbiBEYXRlICAgIDog SmFudWFyeSAyMDE3DQo+IEF1dGhvcihzKSAgICAgICAgICAgOiBBLiBCaWVybWFuLCBNLiBCam9y a2x1bmQsIEsuIFdhdHNlbg0KPiBDYXRlZ29yeSAgICAgICAgICAgIDogUFJPUE9TRUQgU1RBTkRB UkQNCj4gU291cmNlICAgICAgICAgICAgICA6IE5ldHdvcmsgQ29uZmlndXJhdGlvbg0KPiBBcmVh ICAgICAgICAgICAgICAgIDogT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudA0KPiBTdHJlYW0gICAg ICAgICAgICAgIDogSUVURg0KPiBWZXJpZnlpbmcgUGFydHkgICAgIDogSUVTRw0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRjb25mIG1h aWxpbmcgbGlzdA0KPiBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8aHR0cHM6Ly9l dXIwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG d3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGbmV0Y29uZiZkYXRhPTA0JTdDMDEl N0NtdWx5X2klNDByYWQuY29tJTdDNTU2ZGMxMGNjZTYzNDhkODUwZTgwOGQ4OGZiMDI0ZTAlN0Nm OTA0NzEwOGNjMmM0ZTQ4OTdhMzQzZmFkMWIzYmY5ZCU3QzElN0MwJTdDNjM3NDE3MzMzOTg5OTQw Njc2JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lW Mmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmc2RhdGE9UlR5SFdP YlZSRXVtQVUzaTNwYjBRMGM4dEpWVUVjRzF2MEQwb2xVbTFMQSUzRCZyZXNlcnZlZD0wPg0K --_000_AM0PR0302MB3348B74B591E5D85C4A88FBCF9FC0AM0PR0302MB3348_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQW5keSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBleGFtcGxlIGZvciBwbGFpbiBQQVRDSCBp biBhcHBlbmRpeCBCLjIuNSBoYXMga2V5cyBpbiBib3RoIHRoZSBVUkkgYW5kIGJvZHkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPldoZXJlYXMgdGhlIGV4YW1wbGUgaW4gc2VjdGlvbiA0LjYuMSBoYXMga2V5 cyBvbmx5IGluIHRoZSBVUkkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5DbGVhcmx5IG9uZSBvZiB0aGUgZXhhbXBsZXMgaXMgd3JvbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+TXVseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+QW5keSBCaWVybWFuPGJyPg0KPGI+U2VudDo8L2I+IDIzLzExLzIwMjAgMTU6MDM8 YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBCasO2cmtsdW5kICZsdDttYmoraWV0ZkA0NjY4LnNlJmd0 Ozxicj4NCjxiPkNjOjwvYj4gS2VudCBXYXRzZW4gJmx0O2t3YXRzZW5AanVuaXBlci5uZXQmZ3Q7 OyBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0OzsgUkZDIEVkaXRvciAmbHQ7cmZjLWVk aXRvckByZmMtZWRpdG9yLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25m XSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDODA0MCAoNjM0Mik8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE5vdiAyMywgMjAyMCBhdCAxMjoz NyBBTSBNYXJ0aW4gQmrDtnJrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaiUyQmlldGZANDY2 OC5zZSI+bWJqK2lldGZANDY2OC5zZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5IaSw8YnI+DQo8YnI+DQpUaGUgaXNzdWUgYm9pbHMgZG93biB0byBpZiBsaXN0 IGtleXMgYXJlIHJlcXVpcmVkIGluIGEgcGxhaW4gcGF0Y2guPGJyPg0KVW5mb3J0dW5hdGVseSwg dGhlIFJGQyBkb2Vzbid0IHNwZWNpZnVjeSB0aGlzLiZuYnNwOyBGcm9tIGEgdGVjaG5pY2FsIHBv dyw8YnI+DQpsaXN0IGtleXMgYXJlIG5vdCBuZWNlc3NhcnkuJm5ic3A7IEluIGZhY3QsIGlmIHRo ZXkgYXJlIHByZXNlbnQgaW4gdGhlPGJyPg0KcGF5bG9hZCwgdGhleSBhcmUgcmVkdW5kYW50IChz aW5jZSB0aGV5IGFyZSBwYXJ0IG9mIHRoZSBVUkwpICh0aGlzIGlzPGJyPg0KYWN0dWFsbHkgbWVu dGlvbmVkIGluIHRoZSBSRkMpLjxicj4NCjxicj4NClNpbmNlIGl0IGlzbid0IGNsZWFybHkgc3Bl Y2lmaWVkLCBJIHRoaW5rIHdlIG11c3QgYXNzdW1lIHRoYXQgdGhlIGtleXM8YnI+DQphcmUgbm90 IHJlcXVpcmVkLiZuYnNwOyBIZW5jZSBJIHRoaW5rIHRoYXQgdGhpcyBlcnJhdGEgc2hvdWxkIGJl IHJlamVjdGVkLjxicj4NCjxicj4NCkluIGEgZnV0dXJlIHZlcnNpb24gb2YgdGhpcyBkb2N1bWVu dCwgdGhlIGJlaGF2aW91ciBzaG91bGQgYmU8YnI+DQpjbGFyaWZpZWQuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPisxPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlamVjdCB0 aGlzIGVycmF0YTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KL21hcnRp bjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQpSRkMgRXJyYXRhIFN5c3RlbSAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmciIHRhcmdldD0iX2JsYW5rIj5yZmMtZWRpdG9yQHJm Yy1lZGl0b3Iub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBUaGUgZm9sbG93aW5nIGVycmF0 YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM4MDQwLDxicj4NCiZndDsgJnF1b3Q7 UkVTVENPTkYgUHJvdG9jb2wmcXVvdDsuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBZb3UgbWF5IHJldmlldyB0aGUg cmVwb3J0IGJlbG93IGFuZCBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZXVyMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5yZmMt ZWRpdG9yLm9yZyUyRmVycmF0YSUyRmVpZDYzNDImYW1wO2RhdGE9MDQlN0MwMSU3Q211bHlfaSU0 MHJhZC5jb20lN0M1NTZkYzEwY2NlNjM0OGQ4NTBlODA4ZDg4ZmIwMjRlMCU3Q2Y5MDQ3MTA4Y2My YzRlNDg5N2EzNDNmYWQxYjNiZjlkJTdDMSU3QzAlN0M2Mzc0MTczMzM5ODk5MTA2OTMlN0NVbmtu b3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENK QlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9QWg4cTdSYjlHd09w NENrNiUyRkVyTkxEazkyUHBTQTZLUGJucnhKJTJGSFlwamMlM0QmYW1wO3Jlc2VydmVkPTAiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YS9laWQ2MzQy PC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxicj4NCiZndDsgVHlwZTogVGVjaG5pY2FsPGJyPg0KJmd0OyBSZXBvcnRlZCBieTog TXVseSBJbGFuICZsdDs8YSBocmVmPSJtYWlsdG86bXVseV9pQHJhZC5jb20iIHRhcmdldD0iX2Js YW5rIj5tdWx5X2lAcmFkLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNlY3Rpb246 IDQuNi4xPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9yaWdpbmFsIFRleHQ8YnI+DQomZ3Q7IC0tLS0t LS0tLS0tLS08YnI+DQomZ3Q7IFRvIHJlcGxhY2UganVzdCB0aGUgJnF1b3Q7eWVhciZxdW90OyBm aWVsZCBpbiB0aGUgJnF1b3Q7YWxidW0mcXVvdDsgcmVzb3VyY2UgKGluc3RlYWQgb2Y8YnI+DQom Z3Q7IHJlcGxhY2luZyB0aGUgZW50aXJlIHJlc291cmNlIHdpdGggdGhlIFBVVCBtZXRob2QpLCB0 aGUgY2xpZW50IG1pZ2h0PGJyPg0KJmd0OyBzZW5kIGEgcGxhaW4gcGF0Y2ggYXMgZm9sbG93czo8 YnI+DQomZ3Q7IFBBVENIIC9yZXN0Y29uZi9kYXRhL2V4YW1wbGUtanVrZWJveDpqdWtlYm94L1w8 YnI+DQomZ3Q7IGxpYnJhcnkvYXJ0aXN0PUZvbyUyMEZpZ2h0ZXJzL2FsYnVtPVdhc3RpbmclMjBM aWdodCBIVFRQLzEuMTxicj4NCiZndDsgSG9zdDogPGEgaHJlZj0iaHR0cHM6Ly9ldXIwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZleGFtcGxlLmNv bSUyRiZhbXA7ZGF0YT0wNCU3QzAxJTdDbXVseV9pJTQwcmFkLmNvbSU3QzU1NmRjMTBjY2U2MzQ4 ZDg1MGU4MDhkODhmYjAyNGUwJTdDZjkwNDcxMDhjYzJjNGU0ODk3YTM0M2ZhZDFiM2JmOWQlN0Mx JTdDMCU3QzYzNzQxNzMzMzk4OTkyMDY4MyU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpv aU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAl M0QlN0MxMDAwJmFtcDtzZGF0YT1SNGlxRnRuSXclMkZrdEdjUWQxVXpkclk1Z1Q2TFlGMmNsMHEl MkJmTmc2M3NXcyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KZXhhbXBsZS5j b208L2E+PGJyPg0KJmd0OyBJZi1NYXRjaDogJnF1b3Q7YjgzODkyMzNhNGMmcXVvdDs8YnI+DQom Z3Q7IENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veWFuZy1kYXRhK3htbDxicj4NCiZndDsgJmx0 O2FsYnVtIHhtbG5zPSZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZXVyMDEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGZXhhbXBsZS5jb20lMkZucyUyRmV4 YW1wbGUtanVrZWJveCZhbXA7ZGF0YT0wNCU3QzAxJTdDbXVseV9pJTQwcmFkLmNvbSU3QzU1NmRj MTBjY2U2MzQ4ZDg1MGU4MDhkODhmYjAyNGUwJTdDZjkwNDcxMDhjYzJjNGU0ODk3YTM0M2ZhZDFi M2JmOWQlN0MxJTdDMCU3QzYzNzQxNzMzMzk4OTkyMDY4MyU3Q1Vua25vd24lN0NUV0ZwYkdac2Iz ZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENK WFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1UOE50Rk9SVUdTUms2SGpOJTJGMzgyVTB2a0Il MkZWRiUyRko1WXZLRGtCTUVURnVBJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL2V4YW1wbGUuY29tL25zL2V4YW1wbGUtanVrZWJveDwvYT4mcXVvdDsmZ3Q7PGJyPg0K Jmd0OyAmbHQ7eWVhciZndDsyMDExJmx0Oy95ZWFyJmd0Ozxicj4NCiZndDsgJmx0Oy9hbGJ1bSZn dDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgQ29ycmVjdGVkIFRleHQ8YnI+DQomZ3Q7IC0tLS0tLS0t LS0tLS0tPGJyPg0KJmd0OyBUbyByZXBsYWNlIGp1c3QgdGhlICZxdW90O3llYXImcXVvdDsgZmll bGQgaW4gdGhlICZxdW90O2FsYnVtJnF1b3Q7IHJlc291cmNlIChpbnN0ZWFkIG9mPGJyPg0KJmd0 OyByZXBsYWNpbmcgdGhlIGVudGlyZSByZXNvdXJjZSB3aXRoIHRoZSBQVVQgbWV0aG9kKSwgdGhl IGNsaWVudCBtaWdodDxicj4NCiZndDsgc2VuZCBhIHBsYWluIHBhdGNoIGFzIGZvbGxvd3M6PGJy Pg0KJmd0OyBQQVRDSCAvcmVzdGNvbmYvZGF0YS9leGFtcGxlLWp1a2Vib3g6anVrZWJveC9cPGJy Pg0KJmd0OyBsaWJyYXJ5L2FydGlzdD1Gb28lMjBGaWdodGVycy9hbGJ1bT1XYXN0aW5nJTIwTGln aHQgSFRUUC8xLjE8YnI+DQomZ3Q7IEhvc3Q6IDxhIGhyZWY9Imh0dHBzOi8vZXVyMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGZXhhbXBsZS5jb20l MkYmYW1wO2RhdGE9MDQlN0MwMSU3Q211bHlfaSU0MHJhZC5jb20lN0M1NTZkYzEwY2NlNjM0OGQ4 NTBlODA4ZDg4ZmIwMjRlMCU3Q2Y5MDQ3MTA4Y2MyYzRlNDg5N2EzNDNmYWQxYjNiZjlkJTdDMSU3 QzAlN0M2Mzc0MTczMzM5ODk5MzA2NzglN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lN QzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNE JTdDMTAwMCZhbXA7c2RhdGE9NjNUZGtXWlJucllhU2FIU0hNRGJBbHhIVGtJRFA0WnU3WVByem45 NlJnRSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KZXhhbXBsZS5jb208L2E+ PGJyPg0KJmd0OyBJZi1NYXRjaDogJnF1b3Q7YjgzODkyMzNhNGMmcXVvdDs8YnI+DQomZ3Q7IENv bnRlbnQtVHlwZTogYXBwbGljYXRpb24veWFuZy1kYXRhK3htbDxicj4NCiZndDsgJmx0O2FsYnVt IHhtbG5zPSZxdW90OzxhIGhyZWY9Imh0dHBzOi8vZXVyMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGZXhhbXBsZS5jb20lMkZucyUyRmV4YW1wbGUt anVrZWJveCZhbXA7ZGF0YT0wNCU3QzAxJTdDbXVseV9pJTQwcmFkLmNvbSU3QzU1NmRjMTBjY2U2 MzQ4ZDg1MGU4MDhkODhmYjAyNGUwJTdDZjkwNDcxMDhjYzJjNGU0ODk3YTM0M2ZhZDFiM2JmOWQl N0MxJTdDMCU3QzYzNzQxNzMzMzk4OTkzMDY3OCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpX SWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZN bjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1neXNLVEpOOTVmNTl3NTglMkJOV01WcDVaRzZON1YxSXIw bTZkTDhKRzZxSTAlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZXhh bXBsZS5jb20vbnMvZXhhbXBsZS1qdWtlYm94PC9hPiZxdW90OyZndDs8YnI+DQomZ3Q7ICZsdDtu YW1lJmd0O1dhc3RpbmcgTGlnaHQmbHQ7L25hbWUmZ3Q7PGJyPg0KJmd0OyAmbHQ7eWVhciZndDsy MDExJmx0Oy95ZWFyJmd0Ozxicj4NCiZndDsgJmx0Oy9hbGJ1bSZndDs8YnI+DQomZ3Q7IDxicj4N CiZndDsgTm90ZXM8YnI+DQomZ3Q7IC0tLS0tPGJyPg0KJmd0OyBNaXNzaW5nIGtleSBsZWFmIHZh bHVlIGluIHRoZSBtZXNzYWdlLWJvZHkgKCZsdDtuYW1lJmd0O1dhc3RpbmcgTGlnaHQmbHQ7L25h bWUmZ3Q7KTxicj4NCiZndDsgPGJyPg0KJmd0OyBJbnN0cnVjdGlvbnM6PGJyPg0KJmd0OyAtLS0t LS0tLS0tLS0tPGJyPg0KJmd0OyBUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBvc3RlZCBhcyAm cXVvdDtSZXBvcnRlZCZxdW90Oy4gSWYgbmVjZXNzYXJ5LCBwbGVhc2U8YnI+DQomZ3Q7IHVzZSAm cXVvdDtSZXBseSBBbGwmcXVvdDsgdG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJp ZmllZCBvcjxicj4NCiZndDsgcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFjaGVkLCB0 aGUgdmVyaWZ5aW5nIHBhcnR5Jm5ic3A7IDxicj4NCiZndDsgY2FuIGxvZyBpbiB0byBjaGFuZ2Ug dGhlIHN0YXR1cyBhbmQgZWRpdCB0aGUgcmVwb3J0LCBpZiBuZWNlc3NhcnkuIDxicj4NCiZndDsg PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZn dDsgUkZDODA0MCAoZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLTE4KTxicj4NCiZndDsgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IFRpdGxlJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogUkVTVENP TkYgUHJvdG9jb2w8YnI+DQomZ3Q7IFB1YmxpY2F0aW9uIERhdGUmbmJzcDsgJm5ic3A7IDogSmFu dWFyeSAyMDE3PGJyPg0KJmd0OyBBdXRob3IocykmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzogQS4gQmllcm1hbiwgTS4gQmpvcmtsdW5kLCBLLiBXYXRzZW48YnI+DQom Z3Q7IENhdGVnb3J5Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBQ Uk9QT1NFRCBTVEFOREFSRDxicj4NCiZndDsgU291cmNlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogTmV0d29yayBDb25maWd1cmF0aW9uPGJyPg0KJmd0 OyBBcmVhJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyA6IE9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQ8YnI+DQomZ3Q7IFN0cmVhbSZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IElFVEY8YnI+DQomZ3Q7 IFZlcmlmeWluZyBQYXJ0eSZuYnNwOyAmbmJzcDsgJm5ic3A7OiBJRVNHPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyBuZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm5l dGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRjb25mQGlldGYub3JnPC9hPjxicj4N CiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9ldXIwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZv JTJGbmV0Y29uZiZhbXA7ZGF0YT0wNCU3QzAxJTdDbXVseV9pJTQwcmFkLmNvbSU3QzU1NmRjMTBj Y2U2MzQ4ZDg1MGU4MDhkODhmYjAyNGUwJTdDZjkwNDcxMDhjYzJjNGU0ODk3YTM0M2ZhZDFiM2Jm OWQlN0MxJTdDMCU3QzYzNzQxNzMzMzk4OTk0MDY3NiU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhl eUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZD STZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT1SVHlIV09iVlJFdW1BVTNpM3BiMFEwYzh0SlZVRWNH MXYwRDBvbFVtMUxBJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_AM0PR0302MB3348B74B591E5D85C4A88FBCF9FC0AM0PR0302MB3348_-- From nobody Mon Nov 23 05:36:55 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 793433A0B0D for ; Mon, 23 Nov 2020 05:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.779 X-Spam-Level: * X-Spam-Status: No, score=1.779 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=ID5HFn3V; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LrFAqMvj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfw5l6kr4xr2 for ; Mon, 23 Nov 2020 05:36:52 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D723A0B08 for ; Mon, 23 Nov 2020 05:36:52 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 79FD25C0079; Mon, 23 Nov 2020 08:36:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 23 Nov 2020 08:36:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= 793djWB2z9FEBaNN5h7esbnZ2LQmoOb6TNFyheGdBzE=; b=ID5HFn3VYZVmkO/W R/CGNDhJiYdLiPiertZcZqva5Xrq/JA8NI5EDz0vvE4ZV6dCkEF+/mhP5HwQOY2e WTs5OcN3AwhBIqbSAL4iHOZ9YAeAiprWYOH6a5794qUkfbgEoY2lSWV+qHdxvOb8 diWDa8d53+0azgDQ0xKcUHlRHXbXtV6pGV39Yv9sqf60O01MdcswxwlBzrN03IOa KvKEISTin5hauhGnB2gcjHk+u0qYWEGKdyXrgirZFCUieDuu9vMdyrsCh9qCftbz QsR+POOvim3reeGYopez/s6vTsY/vjV05B8rH3FPn9GPBui2pWKdsjAe59Kb8kFw 8qG+7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=793djWB2z9FEBaNN5h7esbnZ2LQmoOb6TNFyheGdB zE=; b=LrFAqMvjEt/OUZYkWUeSvY9cmHDdvY9ku86pGJtcq/qn2AOVaqolL+S8G Fc44Py+FhOje1q1TVzHGMI4bGdZafjJt7NR+wlo74uZAYRM5KD2eBiSre6z5det7 peV/+JbkyA+5Hd9o+FIqaAH8vvhsyUtmK0vAEHDO0NHRwywaWvjHdPCmIM8+A1fV Q2CEql8imxvOVAYo8HF+awMKHZAQNQVprqr/6CGUPBFE+s+JVZ5jsTVnDACOOgWF f2DUQIucpaO5dZWK2mD0pihF40dKdmyAqk18emsmJQNF8O4YqlQYmnTz4u37PryN bSa1KLjKL7ExMfpBsuTvmGl/ynDvg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegiedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtqh ertdertddunecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepvdefudeggefhvdffuddtgf ekhfelvdevtdefvdejgffhhfekveejveejfeejfeegnecuffhomhgrihhnpeduhhhoshht vgigrghmphhlvgdrtghomhdpohhuthhlohhokhdrtghomhdprhhftgdqvgguihhtohhrrd horhhgpddvpdhivghtfhdrohhrghenucfkphepudehkedrudejgedrgedrvdduheenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivg htfhesgeeiieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id C86C33280060; Mon, 23 Nov 2020 08:36:48 -0500 (EST) Date: Mon, 23 Nov 2020 14:36:47 +0100 (CET) Message-Id: <20201123.143647.604827032575238071.id@4668.se> To: muly_i@rad.com Cc: rfc-editor@rfc-editor.org, kent+ietf@watsen.net, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: References: <20201123.131452.2154616412508504559.id@4668.se> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) 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, 23 Nov 2020 13:36:54 -0000 Muly Ilan wrote: > Hi Martin, > = > Plain PATCH is defined as a merge operation i.e. it can create a reso= urce. > It's not limited to editing of existing resources. > = > From section 4.6.1: > " The plain patch mechanism merges the contents of the message-body > with the target resource." > = > " Plain patch can be used to create or update, but not delete, a chil= d > resource within the target resource." I meant: However, PUT means completely replace or create the target resource, but plain PATCH modifies only the given fields in the target resource. /martin > It's better to have consistent examples. > I suggest either to modify the plain PATCH example or the PUT example= .= > = > = > Best, > = > Muly > = > = > -----Original Message----- > From: Martin Bj=F6rklund [mailto:mbj+ietf@4668.se] = > Sent: 23/11/2020 14:15 > To: Muly Ilan > Cc: rfc-editor@rfc-editor.org; kent+ietf@watsen.net; netconf@ietf.org= > Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) > = > Hi, > = > Muly Ilan wrote: > > Hi, > > = > > If list keys are not required in message body for plain PATCH then = > > they are also not required for the PUT method. > = > You are right that the keys are redundant also in PUT. However, PUT = means completely replace or create the resource, but plain PATCH modifi= es only the given fields. > = > = > /martin > = > = > > But the example for PUT in section 4.5 is: > > = > > PUT /restconf/data/example-jukebox:jukebox/\ > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > Host: example.com > > Content-Type: application/yang-data+json { "example-jukebox:album" = : [ = > > { "name" : "Wasting Light", "genre" : "example-jukebox:alternative"= , = > > "year" : 2011 } ] } > > = > > So, do we want consistency between PUT and plain PATCH? > > = > > I believe consistency is important and currently the RFC contains t= wo = > > inconsistent examples. > > = > > = > > Best, > > = > > Muly > > = > > = > > -----Original Message----- > > From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin= = > > Bj?rklund > > Sent: 23/11/2020 10:37 > > To: rfc-editor@rfc-editor.org > > Cc: kwatsen@juniper.net; netconf@ietf.org > > Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) > > = > > Hi, > > = > > The issue boils down to if list keys are required in a plain patch.= > > Unfortunately, the RFC doesn't specifucy this. From a technical po= w, = > > list keys are not necessary. In fact, if they are present in the = > > payload, they are redundant (since they are part of the URL) (this = is = > > actually mentioned in the RFC). > > = > > Since it isn't clearly specified, I think we must assume that the k= eys = > > are not required. Hence I think that this errata should be rejecte= d. > > = > > In a future version of this document, the behaviour should be = > > clarified. > > = > > = > > /martin > > = > > = > > RFC Errata System wrote: > > > The following errata report has been submitted for RFC8040, = > > > "RESTCONF Protocol". > > > = > > > -------------------------------------- > > > You may review the report below and at: > > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww. > > > rfc-editor.org%2Ferrata%2Feid6342&data=3D04%7C01%7Cmuly_i%40r= ad.co > > > m% = > > > 7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3= bf9 > > > d% = > > > 7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w= LjA > > > wM = > > > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat= a=3D2 > > > nm > > > LthW5HkwRvJZi%2F2Pj6%2B9qkLV9gV55wiBpIoiC%2FD4%3D&reserved=3D= 0 > > > = > > > -------------------------------------- > > > Type: Technical > > > Reported by: Muly Ilan > > > = > > > Section: 4.6.1 > > > = > > > Original Text > > > ------------- > > > To replace just the "year" field in the "album" resource (instead= of = > > > replacing the entire resource with the PUT method), the client mi= ght = > > > send a plain patch as follows: > > > PATCH /restconf/data/example-jukebox:jukebox/\ > > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > > Host: example.com > > > If-Match: "b8389233a4c" > > > Content-Type: application/yang-data+xml > > xmlns=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dht= tp%3A%2 > > > F%25 = > > > 2Fexample.com%2Fns%2Fexample-jukebox&data=3D04%7C01%7Cmuly_i%= 40rad > > > .c = > > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad= 1b3 > > > bf = > > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM= C4w > > > Lj = > > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s= dat > > > a=3D hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserve= d=3D0"> > > > 2011 > > > > > > = > > > Corrected Text > > > -------------- > > > To replace just the "year" field in the "album" resource (instead= of = > > > replacing the entire resource with the PUT method), the client mi= ght = > > > send a plain patch as follows: > > > PATCH /restconf/data/example-jukebox:jukebox/\ > > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > > Host: example.com > > > If-Match: "b8389233a4c" > > > Content-Type: application/yang-data+xml > > xmlns=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dht= tp%3A%2 > > > F%25 = > > > 2Fexample.com%2Fns%2Fexample-jukebox&data=3D04%7C01%7Cmuly_i%= 40rad > > > .c = > > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad= 1b3 > > > bf = > > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM= C4w > > > Lj = > > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s= dat > > > a=3D hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserve= d=3D0"> > > > Wasting Light > > > 2011 > > > > > > = > > > Notes > > > ----- > > > Missing key leaf value in the message-body (Wasting > > > Light) > > > = > > > Instructions: > > > ------------- > > > This erratum is currently posted as "Reported". If necessary, ple= ase = > > > use "Reply All" to discuss whether it should be verified or rejec= ted. > > > When a decision is reached, the verifying party can log in to cha= nge = > > > the status and edit the report, if necessary. > > > = > > > -------------------------------------- > > > RFC8040 (draft-ietf-netconf-restconf-18) > > > -------------------------------------- > > > Title : RESTCONF Protocol > > > Publication Date : January 2017 > > > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > > > Category : PROPOSED STANDARD > > > Source : Network Configuration > > > Area : Operations and Management > > > Stream : IETF > > > Verifying Party : IESG > > > = > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww. > > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D04%7C01%7Cmuly= _i%40 > > > ra = > > > d.com%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343= fad > > > 1b > > > 3bf9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIj= oiM > > > C4 = > > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am= p;s > > > da > > > ta=3DGOd8xUYLJ9C69r7aN6rujBhsYFJd05CxiHNXT9YXOZ0%3D&reserved=3D= 0 > > = > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww. > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D04%7C01%7Cmuly_i= %40ra > > d.com%7Cf5c6b052c9fe4dd9c64308d88fa96449%7Cf9047108cc2c4e4897a343fa= d1b > > 3bf9d%7C1%7C0%7C637417304990448682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi= MC4 > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= sda > > ta=3DSOPMijRWiUHA%2BpJnmxGJ4%2FLWqneTaFwfyIpdpuFl5yU%3D&reserve= d=3D0 From nobody Mon Nov 23 05:38:46 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 99DB23A0B0D for ; Mon, 23 Nov 2020 05:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.779 X-Spam-Level: * X-Spam-Status: No, score=1.779 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.999, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=WRfE7d3m; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G+ML5tJM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkhoM_PsKsgS for ; Mon, 23 Nov 2020 05:38:43 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C776E3A0B0B for ; Mon, 23 Nov 2020 05:38:43 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0E3B15C014B; Mon, 23 Nov 2020 08:38:43 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 23 Nov 2020 08:38:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm3; bh= q5aqbz0b1qJxJkKb7Es0JrmvGyq0/GKJ2C36iw1uuIM=; b=WRfE7d3maA9p2sL1 VyHpPJQ77Y7etenTPf4/fOkmsJ5cGqvajvupdUl0CppGOphuqg8VzS6JJtkJ/Etn 7zyl6zzqvCTkpVRl+mnZrIW+GhN9cQp14Zg5FbHDXcHgxSIw+qou+e/vLbT113An ADT81SzkI0w9ATNAEWw29oe7HRSLDcEmibinj2YClRG5+LcqHSWy8nplBZj+hMnN dtdsgq59QYJtFYN44VK4onJm+fc5voItZ5qg/MLkdnjv+/RKJpuHr4ydSQzmQMRk 6+TeUXLhih7WYLPm4tZ2PujxI3rO6BUXljA0Fe+/ahdxDGam1tvHOv4TmaNRC7Lj v4fa3Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=q5aqbz0b1qJxJkKb7Es0JrmvGyq0/GKJ2C36iw1uu IM=; b=G+ML5tJMxNzmQNUOTBxmEYn26KLCgCS+Ul+egm8c6sfgmgyqNA1Tuwkjm W+FAq2l5s6BmQLfFPheEfZ3cwcmps91/DHc8b9yJpzjr38hnEiz9NvRUqQeR5Kof GpDAxul8FEeTVpECI4aI0VKWxeI43XUE12q52rouVptyT5DY+iesjBd7eubbZwOc 4Iq9OQTlhV0hM4rd+d7j9XV1Tlvh+qL6J6R8X/YFSnrpH9IwgjK+j0Kqe2qbgZMm 5y/C9i581IaZ3p0jB51gR+9EiDwVsKvG73IZbRNv/yKZjJ5gonW3voYwzD2xl5yT u93pmbyXIduYKUCDChJOOg4MBNPhg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegiedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtqh ertdertddunecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepieehtedvteetjeekgfffgf dtteevudeileetheeghffhieeuvdeijeegheethfehnecuffhomhgrihhnpeduhhhoshht vgigrghmphhlvgdrtghomhenucfkphepudehkedrudejgedrgedrvdduheenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhes geeiieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id B87E33280059; Mon, 23 Nov 2020 08:38:41 -0500 (EST) Date: Mon, 23 Nov 2020 14:38:40 +0100 (CET) Message-Id: <20201123.143840.1300967807479051474.id@4668.se> To: muly_i@rad.com Cc: rfc-editor@rfc-editor.org, kent+ietf@watsen.net, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: References: <20201123.131452.2154616412508504559.id@4668.se> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) 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, 23 Nov 2020 13:38:46 -0000 Muly Ilan wrote: > Hi Martin, > = > Putting aside the similarity or not between plain PATCH and PUT, ther= e's another example of inconsistency with plain PATCH in the RFC. > = > Please check the plain PATCH example in appendix B.2.5. " Edit a Data= Resource". > This example has keys both in the message header and message body. > = > This means that either the example in 4.6.1 or the example in B.2.5 s= hould be modified. = No, different examples can show different things. > Section 4.6.1 includes the following text: > " > If the target resource represents a YANG list instance, then the key > leaf values, in message-body representation, MUST be the same as the > key leaf values in the request URI. > " > = > If keys are not needed in the message body so this "warning text" is = not needed either. It is needed, since keys are *allowed*. *If* the keys are present, they MUST match the existing keys. /martin > = > Moreover, since the above "warning text" is part of the RFC, it sugge= sts to me that the RFC assumes that there are keys in both header URI a= nd body. = > = > = > Best, > = > Muly > = > -----Original Message----- > From: Muly Ilan = > Sent: 23/11/2020 14:26 > To: Martin Bj=F6rklund > Cc: rfc-editor@rfc-editor.org; kent+ietf@watsen.net; netconf@ietf.org= > Subject: RE: [netconf] [Technical Errata Reported] RFC8040 (6342) > = > Hi Martin, > = > Plain PATCH is defined as a merge operation i.e. it can create a reso= urce. > It's not limited to editing of existing resources. > = > From section 4.6.1: > " The plain patch mechanism merges the contents of the message-body w= ith the target resource." > = > " Plain patch can be used to create or update, but not delete, a chil= d resource within the target resource." > = > It's better to have consistent examples. > I suggest either to modify the plain PATCH example or the PUT example= .= > = > = > Best, > = > Muly > = > = > -----Original Message----- > From: Martin Bj=F6rklund [mailto:mbj+ietf@4668.se] > Sent: 23/11/2020 14:15 > To: Muly Ilan > Cc: rfc-editor@rfc-editor.org; kent+ietf@watsen.net; netconf@ietf.org= > Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) > = > Hi, > = > Muly Ilan wrote: > > Hi, > > = > > If list keys are not required in message body for plain PATCH then = > > they are also not required for the PUT method. > = > You are right that the keys are redundant also in PUT. However, PUT = means completely replace or create the resource, but plain PATCH modifi= es only the given fields. > = > = > /martin > = > = > > But the example for PUT in section 4.5 is: > > = > > PUT /restconf/data/example-jukebox:jukebox/\ > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > Host: example.com > > Content-Type: application/yang-data+json { "example-jukebox:album" = : [ = > > { "name" : "Wasting Light", "genre" : "example-jukebox:alternative"= , = > > "year" : 2011 } ] } > > = > > So, do we want consistency between PUT and plain PATCH? > > = > > I believe consistency is important and currently the RFC contains t= wo = > > inconsistent examples. > > = > > = > > Best, > > = > > Muly > > = > > = > > -----Original Message----- > > From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin= = > > Bj?rklund > > Sent: 23/11/2020 10:37 > > To: rfc-editor@rfc-editor.org > > Cc: kwatsen@juniper.net; netconf@ietf.org > > Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) > > = > > Hi, > > = > > The issue boils down to if list keys are required in a plain patch.= > > Unfortunately, the RFC doesn't specifucy this. From a technical po= w, = > > list keys are not necessary. In fact, if they are present in the = > > payload, they are redundant (since they are part of the URL) (this = is = > > actually mentioned in the RFC). > > = > > Since it isn't clearly specified, I think we must assume that the k= eys = > > are not required. Hence I think that this errata should be rejecte= d. > > = > > In a future version of this document, the behaviour should be = > > clarified. > > = > > = > > /martin > > = > > = > > RFC Errata System wrote: > > > The following errata report has been submitted for RFC8040, = > > > "RESTCONF Protocol". > > > = > > > -------------------------------------- > > > You may review the report below and at: > > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww. > > > rfc-editor.org%2Ferrata%2Feid6342&data=3D04%7C01%7Cmuly_i%40r= ad.co > > > m% > > > 7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3= bf9 > > > d% > > > 7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w= LjA > > > wM > > > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat= a=3D2 > > > nm > > > LthW5HkwRvJZi%2F2Pj6%2B9qkLV9gV55wiBpIoiC%2FD4%3D&reserved=3D= 0 > > > = > > > -------------------------------------- > > > Type: Technical > > > Reported by: Muly Ilan > > > = > > > Section: 4.6.1 > > > = > > > Original Text > > > ------------- > > > To replace just the "year" field in the "album" resource (instead= of = > > > replacing the entire resource with the PUT method), the client mi= ght = > > > send a plain patch as follows: > > > PATCH /restconf/data/example-jukebox:jukebox/\ > > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > > Host: example.com > > > If-Match: "b8389233a4c" > > > Content-Type: application/yang-data+xml > > xmlns=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dht= tp%3A%2 > > > F%25 > > > 2Fexample.com%2Fns%2Fexample-jukebox&data=3D04%7C01%7Cmuly_i%= 40rad > > > .c > > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad= 1b3 > > > bf > > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM= C4w > > > Lj > > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s= dat > > > a=3D hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserve= d=3D0"> > > > 2011 > > > > > > = > > > Corrected Text > > > -------------- > > > To replace just the "year" field in the "album" resource (instead= of = > > > replacing the entire resource with the PUT method), the client mi= ght = > > > send a plain patch as follows: > > > PATCH /restconf/data/example-jukebox:jukebox/\ > > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > > Host: example.com > > > If-Match: "b8389233a4c" > > > Content-Type: application/yang-data+xml > > xmlns=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dht= tp%3A%2 > > > F%25 > > > 2Fexample.com%2Fns%2Fexample-jukebox&data=3D04%7C01%7Cmuly_i%= 40rad > > > .c > > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad= 1b3 > > > bf > > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM= C4w > > > Lj > > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s= dat > > > a=3D hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserve= d=3D0"> > > > Wasting Light > > > 2011 > > > > > > = > > > Notes > > > ----- > > > Missing key leaf value in the message-body (Wasting > > > Light) > > > = > > > Instructions: > > > ------------- > > > This erratum is currently posted as "Reported". If necessary, ple= ase = > > > use "Reply All" to discuss whether it should be verified or rejec= ted. > > > When a decision is reached, the verifying party can log in to cha= nge = > > > the status and edit the report, if necessary. > > > = > > > -------------------------------------- > > > RFC8040 (draft-ietf-netconf-restconf-18) > > > -------------------------------------- > > > Title : RESTCONF Protocol > > > Publication Date : January 2017 > > > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > > > Category : PROPOSED STANDARD > > > Source : Network Configuration > > > Area : Operations and Management > > > Stream : IETF > > > Verifying Party : IESG > > > = > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww. > > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D04%7C01%7Cmuly= _i%40 > > > ra > > > d.com%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343= fad > > > 1b > > > 3bf9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIj= oiM > > > C4 > > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am= p;s > > > da > > > ta=3DGOd8xUYLJ9C69r7aN6rujBhsYFJd05CxiHNXT9YXOZ0%3D&reserved=3D= 0 > > = > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww. > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D04%7C01%7Cmuly_i= %40ra > > d.com%7Cf5c6b052c9fe4dd9c64308d88fa96449%7Cf9047108cc2c4e4897a343fa= d1b > > 3bf9d%7C1%7C0%7C637417304990448682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi= MC4 > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= sda > > ta=3DSOPMijRWiUHA%2BpJnmxGJ4%2FLWqneTaFwfyIpdpuFl5yU%3D&reserve= d=3D0 From nobody Mon Nov 23 08:00:46 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 0A9033A02BC for ; Mon, 23 Nov 2020 08:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[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 AoiF6PCc7vlg for ; Mon, 23 Nov 2020 08:00:42 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3323A0140 for ; Mon, 23 Nov 2020 08:00:42 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id 142so18512270ljj.10 for ; Mon, 23 Nov 2020 08:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FHqWYzRUJKbtKAzPGl8HyofT+DIsJJEyNBSXdjqvLaw=; b=QSbeGW49VbKkAAEkua8sSSpKbW+hoQK6M533RBODdGilNnLmhEsl6jxXyLJaXXFFxJ YvyGF/kzlKd1IYjP1PKSJdHOx82K1m7+60cUhz7AbY2ZnMlJsbOq5vn2xlC+JtXwsgjr U2eVXLHZWBuOOEkAnqC0wBH4OQIUQsXNxBAkfsHZOqtv3bLoc+FU7UQlndVCRfEj/+Ax 6aZTMF37xfrTk7QwZvkfSd/ffS4EOC3i7+gfk70HAyps3xN0VDq9glZ6ufJUafqoYw7/ Zem8ge6qaec5y+Bd/PTTWE+vywgwiMV4JGgEjgJ0Q7LdBwdDkdornnQrQhlsKiGSlSdr vGYg== 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=FHqWYzRUJKbtKAzPGl8HyofT+DIsJJEyNBSXdjqvLaw=; b=ZIzay11JymPm+0aeS34TCV7NI0IxdddckQ6PYq3IniF6IeRz6lFBeuRsn0zNIu3FwC 6ECgxKnycwLwSXUwXM6ChteCBY/QVNYvmLZLk0Z0pv8ZxXyHiehABYV0Aylgg/6IKxb3 l7cuGabyVpXQu2cjoI9TwwQZOmytvd7yS1bYe9d8jMcmNCDMPeakCt9kLeVh0dMyo4My qXZhhblqb26S03XvioWy40jhngYDaWcFbJk/uSSagnlA3wZUTxSNwYbPCBMg1i/VjyS0 CLLMg4tN8Achf8XRQf6bztQ+morOZ2Kv/hZ3LVIgWkg1BaIH0lNnnAVdtLcrxxT8ORGl iuKg== X-Gm-Message-State: AOAM533x5wtxQcUMILg4Mj9iQKbeVw17G0PfaEFEoO/phkrY9B+ICGn8 dNL93GWbKlZ3fu278cjIjWATsKn578taH/b5rumzmQ== X-Google-Smtp-Source: ABdhPJw7CPlHi/wv+fNi15ZGvlAwuXdIN6eU/LXGmfoTSwOiq35RWfb1MgmTPMMP60A93f77Yp3y3rMsGyxnBnOxxyQ= X-Received: by 2002:a2e:9f16:: with SMTP id u22mr23188ljk.456.1606147238727; Mon, 23 Nov 2020 08:00:38 -0800 (PST) MIME-Version: 1.0 References: <20201123.131452.2154616412508504559.id@4668.se> <20201123.143840.1300967807479051474.id@4668.se> In-Reply-To: <20201123.143840.1300967807479051474.id@4668.se> From: Andy Bierman Date: Mon, 23 Nov 2020 08:00:27 -0800 Message-ID: To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= Cc: muly_i@rad.com, Netconf , RFC Editor Content-Type: multipart/alternative; boundary="0000000000009f2c3005b4c84b91" Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) 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, 23 Nov 2020 16:00:45 -0000 --0000000000009f2c3005b4c84b91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2020 at 5:38 AM Martin Bj=C3=B6rklund wr= ote: > Muly Ilan wrote: > > Hi Martin, > > > > Putting aside the similarity or not between plain PATCH and PUT, there'= s > another example of inconsistency with plain PATCH in the RFC. > > > > Please check the plain PATCH example in appendix B.2.5. " Edit a Data > Resource". > > This example has keys both in the message header and message body. > > > > This means that either the example in 4.6.1 or the example in B.2.5 > should be modified. > > No, different examples can show different things. > > > Section 4.6.1 includes the following text: > > " > > If the target resource represents a YANG list instance, then the key > > leaf values, in message-body representation, MUST be the same as the > > key leaf values in the request URI. > > " > > > > If keys are not needed in the message body so this "warning text" is no= t > needed either. > > It is needed, since keys are *allowed*. *If* the keys are present, > they MUST match the existing keys. > > > Agreed. Although we have several customers that would like to rename list entries, and sometimes think RESTCONF allows it. I do not think any YANG-based protocol allows list keys to be modified. You have to delete and re-create the list entry. I think this is something for YANG-next to consider, so it is done consistently across all protocols. > /martin > Andy > > > > > > Moreover, since the above "warning text" is part of the RFC, it suggest= s > to me that the RFC assumes that there are keys in both header URI and > body. > > > > > > Best, > > > > Muly > > > > -----Original Message----- > > From: Muly Ilan > > Sent: 23/11/2020 14:26 > > To: Martin Bj=C3=B6rklund > > Cc: rfc-editor@rfc-editor.org; kent+ietf@watsen.net; netconf@ietf.org > > Subject: RE: [netconf] [Technical Errata Reported] RFC8040 (6342) > > > > Hi Martin, > > > > Plain PATCH is defined as a merge operation i.e. it can create a > resource. > > It's not limited to editing of existing resources. > > > > From section 4.6.1: > > " The plain patch mechanism merges the contents of the message-body wit= h > the target resource." > > > > " Plain patch can be used to create or update, but not delete, a child > resource within the target resource." > > > > It's better to have consistent examples. > > I suggest either to modify the plain PATCH example or the PUT example. > > > > > > Best, > > > > Muly > > > > > > -----Original Message----- > > From: Martin Bj=C3=B6rklund [mailto:mbj+ietf@4668.se] > > Sent: 23/11/2020 14:15 > > To: Muly Ilan > > Cc: rfc-editor@rfc-editor.org; kent+ietf@watsen.net; netconf@ietf.org > > Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) > > > > Hi, > > > > Muly Ilan wrote: > > > Hi, > > > > > > If list keys are not required in message body for plain PATCH then > > > they are also not required for the PUT method. > > > > You are right that the keys are redundant also in PUT. However, PUT > means completely replace or create the resource, but plain PATCH modifies > only the given fields. > > > > > > /martin > > > > > > > But the example for PUT in section 4.5 is: > > > > > > PUT /restconf/data/example-jukebox:jukebox/\ > > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > > Host: example.com > > > Content-Type: application/yang-data+json { "example-jukebox:album" : = [ > > > { "name" : "Wasting Light", "genre" : "example-jukebox:alternative", > > > "year" : 2011 } ] } > > > > > > So, do we want consistency between PUT and plain PATCH? > > > > > > I believe consistency is important and currently the RFC contains two > > > inconsistent examples. > > > > > > > > > Best, > > > > > > Muly > > > > > > > > > -----Original Message----- > > > From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin > > > Bj?rklund > > > Sent: 23/11/2020 10:37 > > > To: rfc-editor@rfc-editor.org > > > Cc: kwatsen@juniper.net; netconf@ietf.org > > > Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) > > > > > > Hi, > > > > > > The issue boils down to if list keys are required in a plain patch. > > > Unfortunately, the RFC doesn't specifucy this. From a technical pow, > > > list keys are not necessary. In fact, if they are present in the > > > payload, they are redundant (since they are part of the URL) (this is > > > actually mentioned in the RFC). > > > > > > Since it isn't clearly specified, I think we must assume that the key= s > > > are not required. Hence I think that this errata should be rejected. > > > > > > In a future version of this document, the behaviour should be > > > clarified. > > > > > > > > > /martin > > > > > > > > > RFC Errata System wrote: > > > > The following errata report has been submitted for RFC8040, > > > > "RESTCONF Protocol". > > > > > > > > -------------------------------------- > > > > You may review the report below and at: > > > > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > > > > rfc-editor.org%2Ferrata%2Feid6342&data=3D04%7C01%7Cmuly_i%40rad= .co > > > > m% > > > > 7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b3bf= 9 > > > > d% > > > > 7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj= A > > > > wM > > > > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata= =3D2 > > > > nm > > > > LthW5HkwRvJZi%2F2Pj6%2B9qkLV9gV55wiBpIoiC%2FD4%3D&reserved=3D0 > > > > > > > > -------------------------------------- > > > > Type: Technical > > > > Reported by: Muly Ilan > > > > > > > > Section: 4.6.1 > > > > > > > > Original Text > > > > ------------- > > > > To replace just the "year" field in the "album" resource (instead o= f > > > > replacing the entire resource with the PUT method), the client migh= t > > > > send a plain patch as follows: > > > > PATCH /restconf/data/example-jukebox:jukebox/\ > > > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > > > Host: example.com > > > > If-Match: "b8389233a4c" > > > > Content-Type: application/yang-data+xml > > > xmlns=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dhttp= %3A%2 > > > > F%25 > > > > 2Fexample.com%2Fns%2Fexample-jukebox&data=3D04%7C01%7Cmuly_i%40= rad > > > > .c > > > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b= 3 > > > > bf > > > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4= w > > > > Lj > > > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda= t > > > > a=3D hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserved= =3D0"> > > > > 2011 > > > > > > > > > > > > Corrected Text > > > > -------------- > > > > To replace just the "year" field in the "album" resource (instead o= f > > > > replacing the entire resource with the PUT method), the client migh= t > > > > send a plain patch as follows: > > > > PATCH /restconf/data/example-jukebox:jukebox/\ > > > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1 > > > > Host: example.com > > > > If-Match: "b8389233a4c" > > > > Content-Type: application/yang-data+xml > > > xmlns=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dhttp= %3A%2 > > > > F%25 > > > > 2Fexample.com%2Fns%2Fexample-jukebox&data=3D04%7C01%7Cmuly_i%40= rad > > > > .c > > > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad1b= 3 > > > > bf > > > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4= w > > > > Lj > > > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda= t > > > > a=3D hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&reserved= =3D0"> > > > > Wasting Light > > > > 2011 > > > > > > > > > > > > Notes > > > > ----- > > > > Missing key leaf value in the message-body (Wasting > > > > Light) > > > > > > > > Instructions: > > > > ------------- > > > > This erratum is currently posted as "Reported". If necessary, pleas= e > > > > use "Reply All" to discuss whether it should be verified or rejecte= d. > > > > When a decision is reached, the verifying party can log in to chang= e > > > > the status and edit the report, if necessary. > > > > > > > > -------------------------------------- > > > > RFC8040 (draft-ietf-netconf-restconf-18) > > > > -------------------------------------- > > > > Title : RESTCONF Protocol > > > > Publication Date : January 2017 > > > > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > > > > Category : PROPOSED STANDARD > > > > Source : Network Configuration > > > > Area : Operations and Management > > > > Stream : IETF > > > > Verifying Party : IESG > > > > > > > > _______________________________________________ > > > > netconf mailing list > > > > netconf@ietf.org > > > > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > > > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D04%7C01%7Cmuly_i= %40 > > > > ra > > > > d.com%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fa= d > > > > 1b > > > > 3bf9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi= M > > > > C4 > > > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= s > > > > da > > > > ta=3DGOd8xUYLJ9C69r7aN6rujBhsYFJd05CxiHNXT9YXOZ0%3D&reserved=3D= 0 > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww. > > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=3D04%7C01%7Cmuly_i%4= 0ra > > > d.com%7Cf5c6b052c9fe4dd9c64308d88fa96449%7Cf9047108cc2c4e4897a343fad1= b > > > 3bf9d%7C1%7C0%7C637417304990448682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC= 4 > > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sd= a > > > ta=3DSOPMijRWiUHA%2BpJnmxGJ4%2FLWqneTaFwfyIpdpuFl5yU%3D&reserved= =3D0 > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --0000000000009f2c3005b4c84b91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 23, 2020 at 5:38 AM Marti= n Bj=C3=B6rklund <mbj+ietf@4668.se= > wrote:
= Muly Ilan <muly_i@ra= d.com> wrote:
> Hi Martin,
>
> Putting aside the similarity or not between plain PATCH and PUT, there= 's another example of inconsistency with plain PATCH in the RFC.
>
> Please check the plain PATCH example in appendix B.2.5. " Edit a = Data Resource".
> This example has keys both in the message header and message body.
>
> This means that either the example in 4.6.1 or the example in B.2.5 sh= ould be modified.

No, different examples can show different things.

> Section 4.6.1 includes the following text:
> "
> If the target resource represents a YANG list instance, then the key > leaf values, in message-body representation, MUST be the same as the > key leaf values in the request URI.
> "
>
> If keys are not needed in the message body so this "warning text&= quot; is not needed either.

It is needed, since keys are *allowed*.=C2=A0 *If* the keys are present, they MUST match the existing keys.



Agreed.

Altho= ugh we have several customers that would like to rename list entries,
=
and sometimes think RESTCONF allows it.=C2=A0 I do not think any YANG-= based protocol
allows list keys to be modified.=C2=A0 You have to= delete and re-create the list entry.
I think this is something f= or YANG-next to consider, so it is done consistently across
all p= rotocols.

=C2=A0
/martin

Andy
=C2=A0


>
> Moreover, since the above "warning text" is part of the RFC,= it suggests to me that the RFC assumes that there are keys in both header = URI and body.=C2=A0
>
>
> Best,
>
> Muly
>
> -----Original Message-----
> From: Muly Ilan
> Sent: 23/11/2020 14:26
> To: Martin Bj=C3=B6rklund <mbj+ietf@4668.se>
> Cc: rfc= -editor@rfc-editor.org; kent+ietf@watsen.net; netconf@ietf.org
> Subject: RE: [netconf] [Technical Errata Reported] RFC8040 (6342)
>
> Hi Martin,
>
> Plain PATCH is defined as a merge operation i.e. it can create a resou= rce.
> It's not limited to editing of existing resources.
>
> From section 4.6.1:
> " The plain patch mechanism merges the contents of the message-bo= dy with the target resource."
>
> " Plain patch can be used to create or update, but not delete, a = child resource within the target resource."
>
> It's better to have consistent examples.
> I suggest either to modify the plain PATCH example or the PUT example.=
>
>
> Best,
>
> Muly
>
>
> -----Original Message-----
> From: Martin Bj=C3=B6rklund [mailto:mbj+ietf@4668.se]
> Sent: 23/11/2020 14:15
> To: Muly Ilan <= muly_i@rad.com>
> Cc: rfc= -editor@rfc-editor.org; kent+ietf@watsen.net; netconf@ietf.org
> Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342)
>
> Hi,
>
> Muly Ilan <muly= _i@rad.com> wrote:
> > Hi,
> >
> > If list keys are not required in message body for plain PATCH the= n
> > they are also not required for the PUT method.
>
> You are right that the keys are redundant also in PUT.=C2=A0 However, = PUT means completely replace or create the resource, but plain PATCH modifi= es only the given fields.
>
>
> /martin
>
>
> > But the example for PUT in section 4.5 is:
> >
> > PUT /restconf/data/example-jukebox:jukebox/\
> > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP/1.1<= br> > > Host: example.com
> > Content-Type: application/yang-data+json { "example-jukebox:= album" : [
> > { "name" : "Wasting Light", "genre"= : "example-jukebox:alternative",
> > "year" : 2011 } ] }
> >
> > So, do we want consistency between PUT and plain PATCH?
> >
> > I believe consistency is important and currently the RFC contains= two
> > inconsistent examples.
> >
> >
> > Best,
> >
> > Muly
> >
> >
> > -----Original Message-----
> > From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin
> > Bj?rklund
> > Sent: 23/11/2020 10:37
> > To: rfc-editor@rfc-editor.org
> > Cc: kwat= sen@juniper.net; = netconf@ietf.org
> > Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342)=
> >
> > Hi,
> >
> > The issue boils down to if list keys are required in a plain patc= h.
> > Unfortunately, the RFC doesn't specifucy this.=C2=A0 From a t= echnical pow,
> > list keys are not necessary.=C2=A0 In fact, if they are present i= n the
> > payload, they are redundant (since they are part of the URL) (thi= s is
> > actually mentioned in the RFC).
> >
> > Since it isn't clearly specified, I think we must assume that= the keys
> > are not required.=C2=A0 Hence I think that this errata should be = rejected.
> >
> > In a future version of this document, the behaviour should be > > clarified.
> >
> >
> > /martin
> >
> >
> > RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> > > The following errata report has been submitted for RFC8040, =
> > > "RESTCONF Protocol".
> > >
> > > --------------------------------------
> > > You may review the report below and at:
> > > https://eur01.= safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> > > rfc-editor.org%2Ferrata%2Feid6342&amp;data=3D04%7C01%7C= muly_i%40r= ad.co
> > > m%
> > > 7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343f= ad1b3bf9
> > > d%
> > > 7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJWIjo= iMC4wLjA
> > > wM
> > > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= ;amp;sdata=3D2
> > > nm
> > > LthW5HkwRvJZi%2F2Pj6%2B9qkLV9gV55wiBpIoiC%2FD4%3D&amp;re= served=3D0
> > >
> > > --------------------------------------
> > > Type: Technical
> > > Reported by: Muly Ilan <muly_i@rad.com>
> > >
> > > Section: 4.6.1
> > >
> > > Original Text
> > > -------------
> > > To replace just the "year" field in the "albu= m" resource (instead of
> > > replacing the entire resource with the PUT method), the clie= nt might
> > > send a plain patch as follows:
> > > PATCH /restconf/data/example-jukebox:jukebox/\
> > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP= /1.1
> > > Host: example.com
> > > If-Match: "b8389233a4c"
> > > Content-Type: application/yang-data+xml <album
> > > xmlns=3D"https://= eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2
> > > F%25
> > > 2Fexample.com%2Fns%2Fexample-jukebox&amp;data=3D04%7C01%= 7Cmuly_i%40rad
> > > .c
> > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a3= 43fad1b3
> > > bf
> > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJW= IjoiMC4w
> > > Lj
> > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= amp;amp;sdat
> > > a=3D hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&am= p;reserved=3D0">
> > > <year>2011</year>
> > > </album>
> > >
> > > Corrected Text
> > > --------------
> > > To replace just the "year" field in the "albu= m" resource (instead of
> > > replacing the entire resource with the PUT method), the clie= nt might
> > > send a plain patch as follows:
> > > PATCH /restconf/data/example-jukebox:jukebox/\
> > > library/artist=3DFoo%20Fighters/album=3DWasting%20Light HTTP= /1.1
> > > Host: example.com
> > > If-Match: "b8389233a4c"
> > > Content-Type: application/yang-data+xml <album
> > > xmlns=3D"https://= eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2
> > > F%25
> > > 2Fexample.com%2Fns%2Fexample-jukebox&amp;data=3D04%7C01%= 7Cmuly_i%40rad
> > > .c
> > > om%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a3= 43fad1b3
> > > bf
> > > 9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8eyJW= IjoiMC4w
> > > Lj
> > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= amp;amp;sdat
> > > a=3D hxW6LA8t%2BNRka2GGRqRNsTnK2itYH1rRLnOxU7JbNlc%3D&am= p;reserved=3D0">
> > > <name>Wasting Light</name>
> > > <year>2011</year>
> > > </album>
> > >
> > > Notes
> > > -----
> > > Missing key leaf value in the message-body (<name>Wast= ing
> > > Light</name>)
> > >
> > > Instructions:
> > > -------------
> > > This erratum is currently posted as "Reported". If= necessary, please
> > > use "Reply All" to discuss whether it should be ve= rified or rejected.
> > > When a decision is reached, the verifying party can log in t= o change
> > > the status and edit the report, if necessary.
> > >
> > > --------------------------------------
> > > RFC8040 (draft-ietf-netconf-restconf-18)
> > > --------------------------------------
> > > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : RESTCONF Protocol
> > > Publication Date=C2=A0 =C2=A0 : January 2017
> > > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A. Bierm= an, M. Bjorklund, K. Watsen
> > > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED= STANDARD
> > > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Net= work Configuration
> > > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : Operations and Management
> > > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IET= F
> > > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
> > >
> > > _______________________________________________
> > > netconf mailing list
> > > netcon= f@ietf.org
> > > https://eur01.= safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> > > ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D04%7C01%7Cm= uly_i%40
> > > ra
> > > d.com%7Cf7ffd30dde054f875cc608d88f8b0eed%7Cf9047108cc2c4e4897a343fad<= br> > > > 1b
> > > 3bf9d%7C1%7C0%7C637417174712193376%7CUnknown%7CTWFpbGZsb3d8e= yJWIjoiM
> > > C4
> > > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10= 00&amp;s
> > > da
> > > ta=3DGOd8xUYLJ9C69r7aN6rujBhsYFJd05CxiHNXT9YXOZ0%3D&amp;= reserved=3D0
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@iet= f.org
> > https://eur01.safel= inks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
> > = ietf.org%2Fmailman%2Flistinfo%2Fnetconf&amp;data=3D04%7C01%7Cmuly_i= %40ra
> > d.c= om%7Cf5c6b052c9fe4dd9c64308d88fa96449%7Cf9047108cc2c4e4897a343fad1b
> > 3bf9d%7C1%7C0%7C637417304990448682%7CUnknown%7CTWFpbGZsb3d8eyJWIj= oiMC4
> > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am= p;amp;sda
> > ta=3DSOPMijRWiUHA%2BpJnmxGJ4%2FLWqneTaFwfyIpdpuFl5yU%3D&amp;r= eserved=3D0

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--0000000000009f2c3005b4c84b91-- From nobody Mon Nov 23 09:27:43 2020 Return-Path: <01000175f62594b1-4d3a5350-4f4d-43c3-9b8c-22fe14d0b36b-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 EEB043A08C5 for ; Mon, 23 Nov 2020 09:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.017 X-Spam-Level: X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 jrjzSOQOfORf for ; Mon, 23 Nov 2020 09:27:41 -0800 (PST) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69AB3A08C0 for ; Mon, 23 Nov 2020 09:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1606152459; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=fjS0YxsI9Fx+c3AoNHe77w0CuYwhAmX4VOctxNUfuPs=; b=g3og0ysm3r2KHyBWu4pEv9fQde9R02qEMgq8GZd1f1/iE81yGSLUS60l+JN5M3KH 6PYx4gv3qRAaKi7vAKe9Zpm+LIF1r6nZNrspXsSgx66yNxTBAg0Qrgot+dLgOyzvsSK 2czzISqyD/V0YEYWX6rTqWAWKaB3nAlK4Uuy3Vuc= From: Kent Watsen Message-ID: <01000175f62594b1-4d3a5350-4f4d-43c3-9b8c-22fe14d0b36b-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CEE4CA96-64C8-45E9-A743-F6DEA05E3612" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 23 Nov 2020 17:27:39 +0000 In-Reply-To: Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= , RFC Editor , "netconf@ietf.org" To: Andy Bierman References: <20201123.131452.2154616412508504559.id@4668.se> <20201123.143840.1300967807479051474.id@4668.se> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.11.23-54.240.48.110 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) 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, 23 Nov 2020 17:27:42 -0000 --Apple-Mail=_CEE4CA96-64C8-45E9-A743-F6DEA05E3612 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 on rejecting the errata. PUT replaces the resource, PATCH modifies = it. Any node not present in a PUT representation is assumed to be deleted, = but it is not allowed to delete keys, hence why keys MUST always to = present in a PUT. > Although we have several customers that would like to rename list = entries, > and sometimes think RESTCONF allows it. I do not think any YANG-based = protocol > allows list keys to be modified. You have to delete and re-create the = list entry. > I think this is something for YANG-next to consider, so it is done = consistently across > all protocols. YANG-next or RESTCONF-next? I think that it is unique to RESTCONF since only RC (not considering = COAP) targets specific resources. That said, the feature might be something that could be added via an = I-D, as opposed to an 8440-bis. K. --Apple-Mail=_CEE4CA96-64C8-45E9-A743-F6DEA05E3612 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1 = on rejecting the errata.  PUT replaces the resource, PATCH modifies = it.

Any node not = present in a PUT representation is assumed to be deleted, but it is not = allowed to delete keys, hence why keys MUST always to present in a = PUT.


Although we have several customers that would like to rename = list entries,
and sometimes think RESTCONF allows = it.  I do not think any YANG-based protocol
allows = list keys to be modified.  You have to delete and re-create the = list entry.
I think this is something for YANG-next to consider, = so it is done consistently across
all = protocols.

YANG-next or RESTCONF-next?

I think that it is unique to RESTCONF = since only RC (not considering COAP) targets specific = resources.

That = said, the feature might be something that could be added via an I-D, as = opposed to an 8440-bis.

K.

= --Apple-Mail=_CEE4CA96-64C8-45E9-A743-F6DEA05E3612-- From nobody Tue Nov 24 13:31:42 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 7D0FF3A0C38 for ; Tue, 24 Nov 2020 13:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66DJ3ps9wybb for ; Tue, 24 Nov 2020 13:31:31 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 2EDD23A0C63 for ; Tue, 24 Nov 2020 13:31:25 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id u19so137895lfr.7 for ; Tue, 24 Nov 2020 13:31:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cdLswaqd95pW8cZIOqsWKWo4HVOOx+n8eMBZI1bNtF0=; b=06JeanUGa2bCHUEvWYG4lPBJdNk8fE8sKUXrg4saKASWh6pHR9GHLv8PZ9i3NsUJe2 eAuVBKmwGw3kb4tNCq2MhCOabgNf4gAesP6Ap+ZWaQ7Gh8/XpvZPH6EcCMf7Eo1CeLyR X1BA6xeUyDpGUmVgC5f1resbRKM4kQO+n9bp6w4CUCFxts2ZpTksewvlBw9TZSwjV1EP qrb2LrjDgvFQ4MZlgHRpeki/Q73CLCcABvGpaPQknejAHe1u07PiY7NqEPJuV6MVHM9l +dcv0+YhRCmvomlbHHT8snNvMIWFWXvccZVJYbnnjiJoHqT56qqkOzIWKnhuwVOb8EMd sncQ== 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=cdLswaqd95pW8cZIOqsWKWo4HVOOx+n8eMBZI1bNtF0=; b=cfZHG2jkXduImqtKDDg1RXaf8R8wJo2gLopjmi9x/bIyhLS30u7dds9O9JElUGxQQu zwoMyjDaiGbCpIDvRymb9hHHsm5f+QyR/XKkBWROjdXAMFPjVv4zpeThxuhotfHeupK9 OE7+myzGIE2sqo5/3kbcXg7PCKaokDZB+T6m7W7oqihevfqZdpXI+KD5j4k4aQbw5KQQ Xf5gXQPwVBQrCcQEviB7RtznjGErkXAvcgcxFLv+t3TwnNqLw8/s22GlwNmNCx84ZRSL HVNw3r7CdikKy+KNgZXDCvDYdI6n7HZv3iL258Lfv1vyfYP4dycI6NiVJNg8V581PrlH wybw== X-Gm-Message-State: AOAM531Ww/WI8ost6IsvrhYGvytm9+hfjBIj80qgQO4owb7I/Ec+lbxA TS6g2STpzgqW0M/TAao02mQyYlbLypktlz3Tg8n+Xg== X-Google-Smtp-Source: ABdhPJwDXykkU4sxLfn8Sn/YBBnOfgboSLhJxBRQ3OiAZbTj2FFxhN8V6SOwlBjf5KRA6GpuFhndeWAzr3arUPAjEQ4= X-Received: by 2002:ac2:4182:: with SMTP id z2mr32469lfh.451.1606253483340; Tue, 24 Nov 2020 13:31:23 -0800 (PST) MIME-Version: 1.0 References: <20201123.131452.2154616412508504559.id@4668.se> <20201123.143840.1300967807479051474.id@4668.se> <01000175f62594b1-4d3a5350-4f4d-43c3-9b8c-22fe14d0b36b-000000@email.amazonses.com> In-Reply-To: <01000175f62594b1-4d3a5350-4f4d-43c3-9b8c-22fe14d0b36b-000000@email.amazonses.com> From: Andy Bierman Date: Tue, 24 Nov 2020 13:31:12 -0800 Message-ID: To: Kent Watsen Cc: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= , RFC Editor , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004b4ac105b4e108eb" Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6342) 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, 24 Nov 2020 21:31:41 -0000 --0000000000004b4ac105b4e108eb Content-Type: text/plain; charset="UTF-8" On Mon, Nov 23, 2020 at 9:27 AM Kent Watsen wrote: > +1 on rejecting the errata. PUT replaces the resource, PATCH modifies it. > > Any node not present in a PUT representation is assumed to be deleted, but > it is not allowed to delete keys, hence why keys MUST always to present in > a PUT. > > > Although we have several customers that would like to rename list entries, > and sometimes think RESTCONF allows it. I do not think any YANG-based > protocol > allows list keys to be modified. You have to delete and re-create the > list entry. > I think this is something for YANG-next to consider, so it is done > consistently across > all protocols. > > > YANG-next or RESTCONF-next? > > I think that it is unique to RESTCONF since only RC (not considering COAP) > targets specific resources. > > I think any YANG list with keys can have this problem. IMO it is better to define the common semantics in YANG and let the protocols decide how to encode them on the wire. The workaround (of course) is to pick an arbitrary integer or label as the key so there is no reason to change it. That said, the feature might be something that could be added via an I-D, > as opposed to an 8440-bis. > > Not to restart this thread, but I prefer yang-next vs. lots of add-on RFCs. Yes it is harder for standards writers to produce, but easier to use in the long run for the vendors and operators. > K. > > Andy --0000000000004b4ac105b4e108eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 23, 2020 at 9:27 AM Kent = Watsen <kent@watsen.net> wrote= :
+1 on rejecting the errata.=C2=A0 PUT replaces = the resource, PATCH modifies it.

Any node not present in= a PUT representation is assumed to be deleted, but it is not allowed to de= lete keys, hence why keys MUST always to present in a PUT.


Although we have sever= al customers that would like to rename list entries,
and sometimes think RESTCONF allows it.=C2=A0 I do not think any= YANG-based protocol
allows list keys to be modif= ied.=C2=A0 You have to delete and re-create the list entry.
I think this is something for YANG-next to consider, so it is do= ne consistently across
all protocols.
=

YANG-next or RESTCONF-next?
I think that it is unique to RESTCONF since only RC (not consid= ering COAP) targets specific resources.



I think any YANG list with keys can = have this problem.
IMO it is better to define the common semantic= s in YANG and let the protocols
decide how to encode them on the = wire.

The workaround (of course) is to pick an arb= itrary integer or label as the key
so there is no reason to chang= e it.=C2=A0


=
That said, the feature might be something that could be added via an I= -D, as opposed to an 8440-bis.

=
Not to restart this thread, but I prefer yang-next vs. lots = of add-on RFCs.
Yes it is harder for standards writers to produce= , but easier to use in the long run
for the vendors and operators= .

=C2=A0
K.<= /div>


Andy
= =C2=A0
--0000000000004b4ac105b4e108eb-- From nobody Mon Nov 30 15:03:00 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 390DA3A123F for ; Mon, 30 Nov 2020 15:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOaOsrmdotK3 for ; Mon, 30 Nov 2020 15:02:58 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 1BD2F3A123D for ; Mon, 30 Nov 2020 15:02:58 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id m9so23436pgb.4 for ; Mon, 30 Nov 2020 15:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=yOGtTBGZOduxaKFOdBXrRKzziVdRPqcs+GjXU40XEL0=; b=Pgp4CeJYXqqpxKajlvixQSVOw5rVqIaK2tqOkGowfQ1yijVJR9L5MZQBp2H+rGcxVZ T78Ufha5FAanbNBSjCLXeBRJgn/OAhv6XihV2ofjXDKH2JP8m+2uqItSSESjoBZVmjpD +OR4ad7xGsBUXFOFicE+aYpFnOvD2CEaBAmzvjMR6UiTuQjEGNnVOCxEF8jqCg8n+n2/ MzDuowhX3Sfs0IfBW2jmvLDCIiu7K/TRwcX3QKjxvtb15BEewmsiSo3DS8at9I14XIZB nwR6kTW5RLQSQ8t1Fzwziw56faOGvf3JGMdXLnuYGL189MIJp51F9EMoh3mejFQZ7kBE 8QSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=yOGtTBGZOduxaKFOdBXrRKzziVdRPqcs+GjXU40XEL0=; b=tvG5ncWM2lKNrUQkoPWkwVk2G9qp+TRctYR6knS71FtrPGmLqj4agFKyPAy7LsqueE uBtTXG52x0SgtIqYtwfRjycNbnTFQUMdI8ahYt+StRnLoOViNvDt4A6s2yEX6TJesp+N S9LNeUWtYi2y6Yf3JDGwmPX4n8oolUgEkiZZq4aSHQkmmUGgm1tN1nMKUzYyDvPQ0BB9 YHQWGXjWtOuKYK6ruil0mkyJgAion6ci0W9Yw7AOSl6/kxDm3R8vOuy2E3iDp359kByU WASnNONc4l3sL63Dm3jHJ7XJlTWBaSgQGwzR2Y1F058CtdhKnPdQbWuw0T7JgOJzgTKk Az0g== X-Gm-Message-State: AOAM532qQ+PXx6vH5wNCF+dpZNqa9oi5rnl4whJY/x1WqUhTVCM0mLei CI6wj4UZdoNkd6vcFWPglwt2/6HEFMY= X-Google-Smtp-Source: ABdhPJzw5S2Wmqq86VejC1gv0E2NGeMVEg2IWZ7hGHDWfjb4jZhnqCfQnePu/B54pl7xbUbbwVR4Qg== X-Received: by 2002:a63:2d87:: with SMTP id t129mr19775890pgt.82.1606777376776; Mon, 30 Nov 2020 15:02:56 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:2834:9e7e:7701:8c34? ([2601:647:5600:5020:2834:9e7e:7701:8c34]) by smtp.gmail.com with ESMTPSA id q12sm1818pfc.84.2020.11.30.15.02.55 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Nov 2020 15:02:56 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_243F4515-E4C2-4540-88B5-0AB532CA0449" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Mon, 30 Nov 2020 15:02:55 -0800 To: Netconf X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [netconf] Draft minutes 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, 30 Nov 2020 23:02:59 -0000 --Apple-Mail=_243F4515-E4C2-4540-88B5-0AB532CA0449 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft minutes for 109 meeting has been uploaded to the datatracker = at: https://datatracker.ietf.org/meeting/109/materials/minutes-109-netconf = Please review and provide updates Mahesh and Kent (as co-chairs) --Apple-Mail=_243F4515-E4C2-4540-88B5-0AB532CA0449 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii The draft minutes for 109 meeting has been uploaded to the datatracker at:


Please review and provide updates


Mahesh and Kent (as co-chairs)





--Apple-Mail=_243F4515-E4C2-4540-88B5-0AB532CA0449--