From nobody Wed Jun 2 02:59:46 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B801A3A3D2F; Wed, 2 Jun 2021 02:59:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <162262797725.18003.2285062248812997933@ietfa.amsl.com> Date: Wed, 02 Jun 2021 02:59:37 -0700 Archived-At: Subject: [core] Robert Wilton's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2021 09:59:38 -0000 Robert Wilton has entered the following ballot position for draft-ietf-core-senml-versions-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for the this document. Just a couple of minor comments. It looked like the equation in section 2 was mucked up in the text version of the doc. Presumably this will get fixed during the editing process: I.e., __ 52 fc version = \ present(fc) ⋅ 2 /__ fc = 0 Quantitatively, the expert could for instance steer the allocation to not allocate more than 10 % of the remaining set per year. Rather than setting this is a limit, I would suggest that it is better to set this as a target. E.g., if it turns out that there is a good justification for an extension, it would be a shame if it had to be delayed by a year merely to fit into a somewhat arbitrary rate limiting scheme. Besides, if you end up with 53 different optional extensions, then I suspect that the bigger problem will be that there are too many variants of what is supported by different implementations which will reduce interop, and you'll probably want to end up with batches of extensions that are expected to be supported together, i.e., some sort of hybrid between completely independent extensions and a strict linear version scheme. Rob From nobody Wed Jun 2 11:11:22 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFE93A155A; Wed, 2 Jun 2021 11:11:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <162265748074.13521.4368551591199171477@ietfa.amsl.com> Date: Wed, 02 Jun 2021 11:11:20 -0700 Archived-At: Subject: [core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2021 18:11:21 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-senml-versions-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks, this is nicely written and a reasonable approach. Section 3 I think I'm supposed to interpret this as being "the exact bit pattern 1010 in the last four bits indicates support for the base SenML version defined in RFC 8428; any other bitstring in that position cannot be taken as an indication of support for the base version". In other words, we're still getting a one-bit signal, just encoded in four bits. Is that right? Or maybe just "it's an error to see any other values for those four bits"? (If so, do we reject the entire pack?) Section 5 I'd consider adding a sentence "the assignment of new feature bits is done in a backwards-compatible manner, so existing implementations will not erroneously assume support for a version (feature) that is defined in the future" in the vein of an avoided security consideration. From nobody Wed Jun 2 22:29:13 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0C73A2A60; Wed, 2 Jun 2021 22:28:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <162269810882.11488.13987720333426834791@ietfa.amsl.com> Date: Wed, 02 Jun 2021 22:28:28 -0700 Archived-At: Subject: [core] Murray Kucherawy's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 05:28:30 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-core-senml-versions-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I only have a few nits to contribute here. In Section 2: The present specification defines "SenML Features", each identified by a "feature name" (a text string) and a "feature code", an unsigned integer less than 53. Why is the former descriptive clause parenthetical, while the latter is separated by a comma? In Section 2.1, I think all the instances of "less" should actually be "fewer". From nobody Thu Jun 3 00:42:04 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9E83A2E6A; Thu, 3 Jun 2021 00:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FufVDjPQ6Be; Thu, 3 Jun 2021 00:41:52 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9BD3A2E69; Thu, 3 Jun 2021 00:41:51 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FwdBg74t1z32hr; Thu, 3 Jun 2021 09:41:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162269810882.11488.13987720333426834791@ietfa.amsl.com> Date: Thu, 3 Jun 2021 09:41:47 +0200 Cc: The IESG , draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi X-Mao-Original-Outgoing-Id: 644398906.305542-abf16eb38c39676f04904ac09a17a22b Content-Transfer-Encoding: quoted-printable Message-Id: References: <162269810882.11488.13987720333426834791@ietfa.amsl.com> To: Murray Kucherawy X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Murray Kucherawy's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 07:41:57 -0000 On 2021-06-03, at 07:28, Murray Kucherawy via Datatracker = wrote: >=20 > Murray Kucherawy has entered the following ballot position for > draft-ietf-core-senml-versions-03: No Objection >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I only have a few nits to contribute here. >=20 > In Section 2: >=20 > The present specification defines "SenML Features", each identified > by a "feature name" (a text string) and a "feature code", an = unsigned > integer less than 53. >=20 > Why is the former descriptive clause parenthetical, while the latter = is separated by a comma? >=20 > In Section 2.1, I think all the instances of "less" should actually be = "fewer". Thanks, fixes now in = https://github.com/core-wg/senml-versions/commit/9229e0f (I only found one instance of less that should be =E2=80=9Cfewer=E2=80=9D,= though.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 3 01:48:30 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3773A3055; Thu, 3 Jun 2021 01:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, 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 SAXaWi3JIw1e; Thu, 3 Jun 2021 01:48:24 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943B43A3053; Thu, 3 Jun 2021 01:48:24 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FwfgP05H2z32jF; Thu, 3 Jun 2021 10:48:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162262797725.18003.2285062248812997933@ietfa.amsl.com> Date: Thu, 3 Jun 2021 10:48:16 +0200 Cc: The IESG , core-chairs@ietf.org, draft-ietf-core-senml-versions@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 644402895.274691-5b40dbf427e5651e3227e14b6f8558f3 Content-Transfer-Encoding: quoted-printable Message-Id: <7979093E-0771-4DE2-B3B1-5C99DFAA723B@tzi.org> References: <162262797725.18003.2285062248812997933@ietfa.amsl.com> To: Robert Wilton X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Robert Wilton's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 08:48:29 -0000 On 2021-06-02, at 11:59, Robert Wilton via Datatracker = wrote: >=20 > Robert Wilton has entered the following ballot position for > draft-ietf-core-senml-versions-03: No Objection > [=E2=80=A6] > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Hi, >=20 > Thanks for the this document. Just a couple of minor comments. >=20 > It looked like the equation in section 2 was mucked up in the text = version of > the doc. Presumably this will get fixed during the editing process: >=20 > I.e., > __ 52 fc > version =3D \ present(fc) =E2=8B=85 2 > /__ fc =3D 0 >=20 Indeed, this is an xml2rfc bug: https://trac.ietf.org/trac/xml2rfc/ticket/641 (I will manually fix this before submitting the next version, if I = remember to do that=E2=80=A6 The RFC editor will, at the latest.) > Quantitatively, the expert could for instance steer the allocation = to > not allocate more than 10 % of the remaining set per year. >=20 > Rather than setting this is a limit, I would suggest that it is better = to set > this as a target. E.g., if it turns out that there is a good = justification for > an extension, it would be a shame if it had to be delayed by a year = merely to > fit into a somewhat arbitrary rate limiting scheme. That actually was the intention of the weasel words =E2=80=9Ccould=E2=80=9D= , =E2=80=9Cfor instance=E2=80=9D, =E2=80=9Csteer =E2=80=A6 to=E2=80=9D. I further clarified: to not allocate =E2=9E=94 to a target of not allocating > Besides, if you end up with 53 different optional extensions, then I = suspect > that the bigger problem will be that there are too many variants of = what is > supported by different implementations which will reduce interop, and = you'll > probably want to end up with batches of extensions that are expected = to be > supported together, i.e., some sort of hybrid between completely = independent > extensions and a strict linear version scheme. I agree, and that=E2=80=99s certainly a reason why we thought =E2=80=9C49 = bits is enough for everyone=E2=80=9D. Added a paragraph based on your = text at the end of Section 2.1. Changes now in https://github.com/core-wg/senml-versions/commit/989d37c Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 3 03:29:05 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEDC3A334D; Thu, 3 Jun 2021 03:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krmwsaDZDXnP; Thu, 3 Jun 2021 03:28:42 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677103A334A; Thu, 3 Jun 2021 03:28:42 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FwhvC2clzz315m; Thu, 3 Jun 2021 12:28:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162265748074.13521.4368551591199171477@ietfa.amsl.com> Date: Thu, 3 Jun 2021 12:28:38 +0200 Cc: The IESG , draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, "core@ietf.org WG" , jaime@iki.fi X-Mao-Original-Outgoing-Id: 644408918.918173-2590708e1d7e789238803e0fb576208a Content-Transfer-Encoding: quoted-printable Message-Id: <3BC8BF6C-94C6-46B7-9A38-0DB25CCBD0D9@tzi.org> References: <162265748074.13521.4368551591199171477@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 10:28:48 -0000 Hi Ben, > On 2021-06-02, at 20:11, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-core-senml-versions-03: No Objection > [=E2=80=A6] >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks, this is nicely written and a reasonable approach. >=20 > Section 3 >=20 > I think I'm supposed to interpret this as being "the exact bit pattern > 1010 in the last four bits indicates support for the base SenML = version > defined in RFC 8428; any other bitstring in that position cannot be > taken as an indication of support for the base version". In other > words, we're still getting a one-bit signal, just encoded in four = bits. > Is that right? Or maybe just "it's an error to see any other values = for > those four bits"? (If so, do we reject the entire pack?) Well, really, RFC 8428 only defines version 10. So we have no idea what another setting of those four bits would mean. The cop-out is the text These four reserved feature codes are not to be used with any more specific semantics except in a specification that updates the present specification. which to me indeed means unless there is another specification updating = this one, one would reject lsb =E2=89=A0 1010, except for a legacy = application that, e.g. still supports SenML version 5. Does this need more text? Suggestions welcome. > Section 5 >=20 > I'd consider adding a sentence "the assignment of new feature bits is > done in a backwards-compatible manner, so existing implementations = will > not erroneously assume support for a version (feature) that is defined > in the future" in the vein of an avoided security consideration. You lost me here. How can one assign bits in a non-backwards-compatible = manner? Of course, feature code 37 could mean "support all of feature code 36 = except for feature foognorz, as well as feature barfgnup=E2=80=9D. When = 36 and 37 are set, this means 36 + barfgnup. We don=E2=80=99t even touch on how a receiving implementation could = signal its feature support to a generating implementation; the = underlying assumption is that most SenML is generated for eternity and = not for a specific recipient. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 3 04:21:30 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735103A34CC; Thu, 3 Jun 2021 04:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=JiBk5Lk5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Anu9Fley Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5LoD8pzXwdz; Thu, 3 Jun 2021 04:21:01 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C843A34CA; Thu, 3 Jun 2021 04:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3914; q=dns/txt; s=iport; t=1622719261; x=1623928861; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dKL6VyHPfKa5fpc9SQmyPNpOJPlhtEgOlUFQtb/GeGY=; b=JiBk5Lk5wXXeWZV89VfPv93GduqNy3g4WLpk1/LW+mSftyMlDgMQmoEp C4t7A4qP8WhJfYWOsXcmOuvq07K4ZHSbhSzpo54X3hUAEHbfO5Qlck3Em FLBGB1aToeCULFChfdXb+JzNJUffi8ybaCtK3t8kGr9o3//rZ8KEvlz2I Y=; X-IPAS-Result: =?us-ascii?q?A0AkAABEurhgl4cNJK1aHQEBAQEJARIBBQUBQIFDCAELA?= =?us-ascii?q?YFSUX5aNzELhD2DSAOEWWCIbgOBDZkCgS6BJQNUCwEBAQ0BATUKAgQBAYRQA?= =?us-ascii?q?heBZwIlNAkOAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBaIVoD?= =?us-ascii?q?YZEAQEBBBIREQwBASkOAQsEAgEGAg4DBAEBAQICJgICAjAVCAgCBA4FCBqCT?= =?us-ascii?q?wGCVQMvAQMLjmSPNAGBOgKKH3qBMoEBggcBAQYEBIE0AYN/GIIxAwaBECoBg?= =?us-ascii?q?nqEDoZhJxyBSUSBFUOCKTY+gmICgTgWFIMVNoIugWmBRQRDEH8ZLAiSKoM6l?= =?us-ascii?q?SaPbYIPCoMbig+ODoVpEqVaoWGYEAIEAgQFAg4BAQaBVDmBW3AVgyRQFwIOj?= =?us-ascii?q?h8ZHoM5hRSFSnM4AgYBCQEBAwl8h3OBNQGBEAEB?= IronPort-PHdr: A9a23:6g6HWhfcbSyuVh9ubkusRN+DlGM/q4qcDmcuAtIPl6BPNKO58MeqM E/e4KBri1nEFcXe5ulfguXb+6bnRSQb4JmHvXxDFf4EVxIMhcgM2QB1BsmDBB7nPv+saDY1T 4xOUVZ/9CS9Nk5YUM/1e1zVpCi06jgfUhXyPAZ4PKL7AInX2s+2zOu1vZbUZlYguQ== IronPort-HdrOrdr: A9a23:oJnWpq0s4Wd2X6GucFwxyQqjBWdyeYIsimQD101hICG9Lfb4qy n+ppomPEHP5wr5AEtQ5uxpOMG7MBThHO1OkPcs1NCZLUjbUQqTXc9fBO7ZowEIdBeOjdK1uZ 0QFpSWTeeAcWSS7vyKoDVQcexQuuVvmZrA7Yy1ohsdLnAJV0gj1XYFNu/xKDwReOAyP+tAKH Pq3Ls/m9PPQwVyUu2LQl0+G8TTrdzCk5zrJTQcAQQ81QWIhTS0rJbnDhmxxH4lInBy6IZn1V KAvx3y562lvf3+4ATbzXXv45Nfn8ak4sdfBfaLltMeJlzX+0SVjcVaKvi/VQIO0aaSAWUR4Z /xStAbTp1OAkbqDyWISN3WqlHdOXgVmiTfIBSj8AreSITCNUIH4ox69Nhkmt+z0Tt9gDm6u5 g7gl5x/qAnfi/ojWDz4cPFWAptkVfxqX0+kfQLh3gaSocGbqRNxLZvsX+9Pa1wVx4S0rpXWt WGzfusksq+emnqI0wxflMfiOBEe05DUStubnJyzvB94gIm1UyRlXFosfD3tk1wg67VZaM0ld j5Dg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.83,244,1616457600"; d="scan'208";a="748050367" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Jun 2021 11:21:00 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 153BL0a2017157 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Jun 2021 11:21:00 GMT Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 3 Jun 2021 06:21:00 -0500 Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 3 Jun 2021 06:20:59 -0500 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 3 Jun 2021 06:20:59 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kc/Duj0UOfiEnAaggIbe5OSYuKxnqu+Hr4aIkFckeC7vB2Xie2KtSEXiJ3R049wxl4hZSfegJKAefrFjIktVjm1eIaE8gT85qF87rDT9gzhc27tvC/V2ZbQZy3IFrUBv5x7vteopA46/Z920TzgvclaDj5ZyAywEBojAYyQ6qHal4mFmu0nOTtgkZBhIFjPRCArUbhmyZuq+5eOPlQvRoUK5pKXy9MotwsYef8j33Jz2MySE/0zgMaTH9tmK8zzCGMQ91UCgMGDhD3GvnkHV7ircWvSE3BU1wiwGuPjWn+Yj7UHkxwwH8J2TkA+tf2ZNAwJ5Wfkh63H+W2JjwkXd2A== 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=dKL6VyHPfKa5fpc9SQmyPNpOJPlhtEgOlUFQtb/GeGY=; b=VEcCfXmZPDfb1fo4PgSSeY6TK94EmtpSvRQVG7lJqStjmUBh36yx/ExAg38vxzijQv2yMzcCj0BBt9y/PMmtK1O42ai1geqOdWxWkrakR1olfAznczN2Sg7XTXYBTYJy4ITfDAS8qajx2xoOpKc1eSkOMdlrrdHCYaZAjFJSuuW6al8Ybe1Ml4f0P8zAt2k8OlbBoPzWlfaBhjtjFAGTV1MqdbzqrGem6fu+ZPEX5kqTiz5Dmi4FcYiX5jTiWRxopY3YijSdWKYF3U/gFCI7PbbsrRtyoIQB2KFGrvIdzG8jsXM9vpVIrEdjWMOIT4eVkRPs4KhhDOQerq+46Hd2BQ== 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=dKL6VyHPfKa5fpc9SQmyPNpOJPlhtEgOlUFQtb/GeGY=; b=Anu9FleyADdLaGHWWctbkdR9nCPUmnm+3W9KY4ApMr5kL5tuvjMBQn9cYXOzmxwhWEnCsgpMxapIgYVlZm1E47m+Z4wgqgxfUthl08z1euA2K7n6pFX6etWhUSJk7OsW5U0MOuCswkQYdWTPwf7KBiw6IrK+E150sulLMGWLkrg= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL1PR11MB5352.namprd11.prod.outlook.com (2603:10b6:208:311::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.24; Thu, 3 Jun 2021 11:20:57 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::217d:4810:6cea:ef72]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::217d:4810:6cea:ef72%6]) with mapi id 15.20.4195.022; Thu, 3 Jun 2021 11:20:57 +0000 From: "Rob Wilton (rwilton)" To: Carsten Bormann CC: "core-chairs@ietf.org" , The IESG , "core@ietf.org" , "draft-ietf-core-senml-versions@ietf.org" Thread-Topic: [core] Robert Wilton's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) Thread-Index: AQHXV5YOcTdfbG9zLEmHMenYe1rMa6sB+zcAgAAql6A= Date: Thu, 3 Jun 2021 11:20:56 +0000 Message-ID: References: <162262797725.18003.2285062248812997933@ietfa.amsl.com> <7979093E-0771-4DE2-B3B1-5C99DFAA723B@tzi.org> In-Reply-To: <7979093E-0771-4DE2-B3B1-5C99DFAA723B@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52c05130-de5e-4ac9-77ae-08d92681a8d2 x-ms-traffictypediagnostic: BL1PR11MB5352: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DY23gSf5Ke6IWgAVTuFDFI5/wiBVVuDxi70L19StMc0AeEmMrynJKWYnb/MrH77p3xkjC4mz8PXSPJxzsB2eLvWoXs3wQpnf+rDqjEaXYNOu2tr5cnPEceLwEAc6z8XvlalSWvZLnRwZTCeh/yZ+tH6nmr/B697H8NTioxAMowNWIdzXI+t9D6Nw5vpnVfKKXM8OVxpy/vTJ64RbKSS3C0qNFoMlgzX53SH1W0Zdt35BEJIRsFEBbZW17n5I9X6mTQ1DC6nEmhTn0nD/2k5CWqfTTvYsea9BZjXhkaCwehYzYQOy7BL65dxbZ9fQItY02XNbQ/RHFu6rqR5nK/FmlweJf9OMv5wkwgF4PgooHLvUnQwYpLLjLF4Ym5+iXhoTVIMRzr0FyX/usI8oxW9tC/cJYFsZMfY6ug0FzI/aIv3rcpGOfBDEI6mNs2i5oNJvwGelo2gJ/TGR817XuoyszwZBhmE3bylTgq/4S8cOn+CoSPMK+cdkTTac8mblVIDNfhy4RQXdamPqMgfxLVh+rPCjoNJyOJEXRwOzsbk7E2Opfhs8OIWIJHcfGmtcJsPVgxgrsA1rOleyg77cxD4hHvZB/pdnrsPrCMa2BWujG0dsmVYojwslaou8W8EMM45j/PfULvrre+THtcJsLavMn5UsQnc1nzH2e5gdNVqefRPvyrX+XGyXs1LHmb6D4KhbRZCJELJM7cCZzNfCCnXy0Gm6eBA5ZOVBHd3C642yq6m7qP8VS+CF6tETJ+BO+uNkdz+Bc+X34oFUU/zA72t1xQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(396003)(346002)(366004)(136003)(39860400002)(6916009)(26005)(186003)(5660300002)(83380400001)(2906002)(66946007)(86362001)(33656002)(76116006)(4326008)(71200400001)(478600001)(52536014)(38100700002)(64756008)(9686003)(66476007)(966005)(66556008)(55016002)(66446008)(316002)(7696005)(54906003)(8676002)(122000001)(6506007)(53546011)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?SmwvVzNlbStObW5qc28rY0JWckl6NFVpL2dPd3BCYnlCWHhhSXZ3M25sNTQy?= =?utf-8?B?YmFLeXRBWUNqQXJFSlR2MEJSSktRV28waVdsRFpjZDZnYmVMUnN3SnlJWUY4?= =?utf-8?B?N1Z5aFI5NTRqTlFYNlk0dUpDbnNrTkprSjhRTlFDb1gzZWNPR3JtZjRhUGR0?= =?utf-8?B?YlFRTm5XRG5vSjkva3JXUHlPd3NrVWhtdjROUzVTUUpLblRkRm1lU3dsUXVs?= =?utf-8?B?Q2p3T3hQaUtHbVRCYTJoc1pMZmZVVWM0RVp2QTJMQ3BxU0dVT2YzcG1QUjEx?= =?utf-8?B?RFpnUkhUTFhIS0dxU1NzSXdNNDVIUWVKVVFpQ2I1ZUtueVliZFgvcDVIT2hp?= =?utf-8?B?enZsaVhCRGVqM0hHTlhwajd3K0V5dXQySVpUUE1IbHBUTkpJOWcrT2NNZzJE?= =?utf-8?B?Y0IyYzB1VzJ2cmdjQnMxYnN4U2R4WWdYMStwUjF5Rm51eEJQWFFWL0t2YzVk?= =?utf-8?B?UzkzajFLaGZIVkRyVlZFN21XeFE4VVk4VVpDMi9JcHA5L21GcUc2allnSEln?= =?utf-8?B?ZzB3KzUrQmJLSlI4R2VHWmNOOG1jdTc3SXVBdDRLUkRpR2VVeVBielRsRDdl?= =?utf-8?B?dkk0ZVVBOUovemRtVjArbmJ1TXB1dWJtK1dHNksvekRsYkI2VTNhQ25wM21V?= =?utf-8?B?Z1c0K2JvWE4xRjB6RGZBUE5mK3oxWmIxd01BeUZJOENDUHJtNVErenFBazd5?= =?utf-8?B?Q2ZhazVWNXZtejRMeDZFWkc5NWVYMGdEckZha0dmNGRtcTk3ci9VemV4d01Z?= =?utf-8?B?MUw1bGQzNDJSUytXYnE5RXJtYXdXQWVjSmwwMm5NUkoySG1MM2xqTWQ5ZHV0?= =?utf-8?B?ODA4c3N0bnNTL2YrWHd1K28yQWU0VTNwT01USkh0Sm84U0dFd1FBS3RsSzhz?= =?utf-8?B?SXQ3TllBSHZaZ1lzZ3NlV0FqZjZNc21rT2xKUjNaYnQ0N2VoZGlBMDhIZ21m?= =?utf-8?B?SFlXUW92UHUvZnZXUXFlVEU5bU1ydmpHNFpsY0NBUnNKRGlPdE5IeWcxOW51?= =?utf-8?B?aTZYY290MHVKTXZ6eGFPTCszdHI5Nk9pSGxaSWI2SWZFY1c1ZlV2eEtUaDMr?= =?utf-8?B?Y3k2OXh1RFhjUEc3UlNkemtZK1hmSDlzeHVFT1FGQW53akJReTgrSFJZVGx2?= =?utf-8?B?cHYrKzlMcEFPajlBZ3lldmwvK2ZZRmJ0VXJrYXRDNDIwMVRMNjhMT0haNWJB?= =?utf-8?B?ak5YVVcyRXhxT0JxaUpEZXZXK3FkZ0FuWjh2QjE4VzNIbmtLVUVQWmRKd3Jv?= =?utf-8?B?T2NwTUpzRjY0bTdOaXNIWTVwSmg2aDM2UVNmbGhWNGI4czI0TERMYVozaDUw?= =?utf-8?B?YVhYemJQWVczays0VFFhOG1XL085RE1ocnk3OWNOaVArS3lna0ZtQStCa0J2?= =?utf-8?B?NGZUNzl5YWYzWllvdGQ0Mkd2ai9zRmxoRW1mdCtVOThSMXd1WkIyK3VJT0ZL?= =?utf-8?B?bTFKckdyRHNTL25DU2dUeU9qa2VvRkNYQ3ltQUEyRnQyY1plNnNWVFFVOTlt?= =?utf-8?B?d3dnNnVGcUZTRnBWRG16eStDZDBRWTRMbUw3bnF3aUtsK2JDRlRCa0lNMXJV?= =?utf-8?B?ajF1L3VjVzhUT1hwZVhmOXZ6M0dLNFVPVFlMcjNPbFI3QUk3R1duVThIU0RG?= =?utf-8?B?YnNjVVFrUXU0bURSRlUwaGZwaDBEc3BiNUxiZmlhVUhxT1F0cG9oSDc1L3BN?= =?utf-8?B?dGxHQUpRR0JaelUvUm9YNTZlTVhkMU9pd0kwbVhEeDVEV0F3NWRrQ3poOUF1?= =?utf-8?Q?Zsr6I8Cw+o7PohRjE7mp5eY8XNhvw+9Smd0xRZk?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52c05130-de5e-4ac9-77ae-08d92681a8d2 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2021 11:20:57.4058 (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: tV1qoEXNxz42JimPVMWMWCi14kH7m3suuepOuDj31HNXqSa0PNuPOcOFIcJvy3gWBo5yYJAs7bYaWo4DHSLVTA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5352 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [core] Robert Wilton's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 11:21:17 -0000 TEdUTS4NCg0KVGhhbmtzLA0KUm9iDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogaWVzZyA8aWVzZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBC b3JtYW5uDQo+IFNlbnQ6IDAzIEp1bmUgMjAyMSAwOTo0OA0KPiBUbzogUm9iIFdpbHRvbiAocndp bHRvbikgPHJ3aWx0b25AY2lzY28uY29tPg0KPiBDYzogY29yZS1jaGFpcnNAaWV0Zi5vcmc7IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgY29yZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi0NCj4gY29y ZS1zZW5tbC12ZXJzaW9uc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2NvcmVdIFJvYmVydCBX aWx0b24ncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1jb3JlLXNlbm1sLQ0KPiB2ZXJzaW9u cy0wMzogKHdpdGggQ09NTUVOVCkNCj4gDQo+IE9uIDIwMjEtMDYtMDIsIGF0IDExOjU5LCBSb2Jl cnQgV2lsdG9uIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4NCj4gd3JvdGU6DQo+ ID4NCj4gPiBSb2JlcnQgV2lsdG9uIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KPiA+IGRyYWZ0LWlldGYtY29yZS1zZW5tbC12ZXJzaW9ucy0wMzogTm8gT2Jq ZWN0aW9uDQo+ID4gW+KApl0NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gQ09NTUVOVDoNCj4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IFRoYW5rcyBmb3IgdGhlIHRoaXMg ZG9jdW1lbnQuICAgSnVzdCBhIGNvdXBsZSBvZiBtaW5vciBjb21tZW50cy4NCj4gPg0KPiA+IEl0 IGxvb2tlZCBsaWtlIHRoZSBlcXVhdGlvbiBpbiBzZWN0aW9uIDIgd2FzIG11Y2tlZCB1cCBpbiB0 aGUgdGV4dCB2ZXJzaW9uIG9mDQo+ID4gdGhlIGRvYy4gIFByZXN1bWFibHkgdGhpcyB3aWxsIGdl dCBmaXhlZCBkdXJpbmcgdGhlIGVkaXRpbmcgcHJvY2VzczoNCj4gPg0KPiA+IEkuZS4sDQo+ID4g ICAgICAgICAgICAgIF9fIDUyICAgICAgICAgICAgICAgICAgICAgICBmYw0KPiA+ICAgdmVyc2lv biA9IFwgICAgICAgICBwcmVzZW50KGZjKSZuYnNwO+KLhSZuYnNwOzINCj4gPiAgICAgICAgICAg ICAvX18gZmMgPSAwDQo+ID4NCj4gDQo+IEluZGVlZCwgdGhpcyBpcyBhbiB4bWwycmZjIGJ1ZzoN Cj4gDQo+IGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3htbDJyZmMvdGlja2V0LzY0MQ0KPiAN Cj4gKEkgd2lsbCBtYW51YWxseSBmaXggdGhpcyBiZWZvcmUgc3VibWl0dGluZyB0aGUgbmV4dCB2 ZXJzaW9uLCBpZiBJIHJlbWVtYmVyIHRvDQo+IGRvIHRoYXTigKYgIFRoZSBSRkMgZWRpdG9yIHdp bGwsIGF0IHRoZSBsYXRlc3QuKQ0KPiANCj4gPiAgIFF1YW50aXRhdGl2ZWx5LCB0aGUgZXhwZXJ0 IGNvdWxkIGZvciBpbnN0YW5jZSBzdGVlciB0aGUgYWxsb2NhdGlvbiB0bw0KPiA+ICAgbm90IGFs bG9jYXRlIG1vcmUgdGhhbiAxMCAlIG9mIHRoZSByZW1haW5pbmcgc2V0IHBlciB5ZWFyLg0KPiA+ DQo+ID4gUmF0aGVyIHRoYW4gc2V0dGluZyB0aGlzIGlzIGEgbGltaXQsIEkgd291bGQgc3VnZ2Vz dCB0aGF0IGl0IGlzIGJldHRlciB0byBzZXQNCj4gPiB0aGlzIGFzIGEgdGFyZ2V0LiAgRS5nLiwg aWYgaXQgdHVybnMgb3V0IHRoYXQgdGhlcmUgaXMgYSBnb29kIGp1c3RpZmljYXRpb24gZm9yDQo+ ID4gYW4gZXh0ZW5zaW9uLCBpdCB3b3VsZCBiZSBhIHNoYW1lIGlmIGl0IGhhZCB0byBiZSBkZWxh eWVkIGJ5IGEgeWVhciBtZXJlbHkNCj4gdG8NCj4gPiBmaXQgaW50byBhIHNvbWV3aGF0IGFyYml0 cmFyeSByYXRlIGxpbWl0aW5nIHNjaGVtZS4NCj4gDQo+IFRoYXQgYWN0dWFsbHkgd2FzIHRoZSBp bnRlbnRpb24gb2YgdGhlIHdlYXNlbCB3b3JkcyDigJxjb3VsZOKAnSwg4oCcZm9yIGluc3RhbmNl 4oCdLA0KPiDigJxzdGVlciDigKYgdG/igJ0uDQo+IA0KPiBJIGZ1cnRoZXIgY2xhcmlmaWVkOg0K PiB0byBub3QgYWxsb2NhdGUg4p6UIHRvIGEgdGFyZ2V0IG9mIG5vdCBhbGxvY2F0aW5nDQo+IA0K PiANCj4gPiBCZXNpZGVzLCBpZiB5b3UgZW5kIHVwIHdpdGggNTMgZGlmZmVyZW50IG9wdGlvbmFs IGV4dGVuc2lvbnMsIHRoZW4gSSBzdXNwZWN0DQo+ID4gdGhhdCB0aGUgYmlnZ2VyIHByb2JsZW0g d2lsbCBiZSB0aGF0IHRoZXJlIGFyZSB0b28gbWFueSB2YXJpYW50cyBvZiB3aGF0IGlzDQo+ID4g c3VwcG9ydGVkIGJ5IGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgd2hpY2ggd2lsbCByZWR1Y2Ug aW50ZXJvcCwgYW5kDQo+IHlvdSdsbA0KPiA+IHByb2JhYmx5IHdhbnQgdG8gZW5kIHVwIHdpdGgg YmF0Y2hlcyBvZiBleHRlbnNpb25zIHRoYXQgYXJlIGV4cGVjdGVkIHRvDQo+IGJlDQo+ID4gc3Vw cG9ydGVkIHRvZ2V0aGVyLCBpLmUuLCBzb21lIHNvcnQgb2YgaHlicmlkIGJldHdlZW4gY29tcGxl dGVseQ0KPiBpbmRlcGVuZGVudA0KPiA+IGV4dGVuc2lvbnMgYW5kIGEgc3RyaWN0IGxpbmVhciB2 ZXJzaW9uIHNjaGVtZS4NCj4gDQo+IEkgYWdyZWUsIGFuZCB0aGF04oCZcyBjZXJ0YWlubHkgYSBy ZWFzb24gd2h5IHdlIHRob3VnaHQg4oCcNDkgYml0cyBpcyBlbm91Z2ggZm9yDQo+IGV2ZXJ5b25l 4oCdLiAgQWRkZWQgYSBwYXJhZ3JhcGggYmFzZWQgb24geW91ciB0ZXh0IGF0IHRoZSBlbmQgb2Yg U2VjdGlvbiAyLjEuDQo+IA0KPiBDaGFuZ2VzIG5vdyBpbiBodHRwczovL2dpdGh1Yi5jb20vY29y ZS13Zy9zZW5tbC0NCj4gdmVyc2lvbnMvY29tbWl0Lzk4OWQzN2MNCj4gDQo+IEdyw7zDn2UsIENh cnN0ZW4NCg0K From nobody Thu Jun 3 08:55:24 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B663A0645; Thu, 3 Jun 2021 08:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, 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 TLbbxg8tRBzG; Thu, 3 Jun 2021 08:55:13 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB973A0603; Thu, 3 Jun 2021 08:55:13 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Fwr7x0q21z315N; Thu, 3 Jun 2021 17:55:09 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162244492744.31415.2969596725789001184@ietfa.amsl.com> Date: Thu, 3 Jun 2021 17:55:08 +0200 Cc: The IESG , draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, core@ietf.org, jaime@iki.fi X-Mao-Original-Outgoing-Id: 644428508.376442-b85dab0fc926d9929aac78e18897f450 Content-Transfer-Encoding: quoted-printable Message-Id: References: <162244492744.31415.2969596725789001184@ietfa.amsl.com> To: =?utf-8?Q?=C3=89ric_Vyncke?= X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-senml-versions-03=3A_=28with_COMMENT=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 15:55:19 -0000 Hi =C3=89ric, On 2021-05-31, at 09:08, =C3=89ric Vyncke via Datatracker = wrote: >=20 > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-core-senml-versions-03: No Objection[=E2=80=A6] > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for the work put into this document. >=20 > Please find below one non-blocking COMMENT points (but replies would = be > appreciated), and some nits. >=20 > Thanks to Jaime Jim=C3=A9nez for his shepherd's write-up (including = the WG > consensus) even if I regret that no motivation is given about the = intended RFC > status. Thank you Carsten for acknowledging Jaime's work. >=20 > I hope that this helps to improve the document, >=20 > Regards, >=20 > -=C3=A9ric >=20 > =3D=3D COMMENTS =3D=3D >=20 > -- Section 2.2 -- > While the motivation for the update is explained, is there any reason = why the > usual OLD TEXT / NEW TEXT is not used here? That is a convention that I have seen, but that I wouldn=E2=80=99t have = classified as =E2=80=9Cusual=E2=80=9D. NEW TEXT would essentially be a = reference to this section, so I don=E2=80=99t think that convention = would help a lot here. > =3D=3D NITS =3D=3D >=20 > -- Section 2 -- > Even with the warning in section 1.1, it took me a while to 'see' the = Sigma > sign (and the   were not helping). The   are the result of an xml2rfc bug (#641); I=E2=80=99ll do some = manual intervention for the next version. Added a caption, but I = can=E2=80=99t talk about the sigma character because a related xml2rfc = issue seems to prevent me from mentioning that in the caption. =20 Pioneers get shot full of arrows=E2=80=A6 Left an RFC editor note. > Suggest to 'show' it in section 1.1. > OTOH, congratulations for using the XMLv3 features for the SVG = equivalent, > quite neat. >=20 > The whole text of this section is quite convoluted as it is a plain = bit mask. Well, that=E2=80=99s what one gets if there are 10 independent sources = of suggested improvements=E2=80=A6 But with the improvements you = triggered, I think the section is quite clear now. Changes in https://github.com/core-wg/senml-versions/commit/cb7907b Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 3 11:46:07 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4403A13BD; Thu, 3 Jun 2021 11:46:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: core-chairs@ietf.org, core@ietf.org, francesca.palombini@ericsson.com, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162274596450.2555.17107982764380652652@ietfa.amsl.com> Date: Thu, 03 Jun 2021 11:46:05 -0700 Archived-At: Subject: [core] core - New Meeting Session Request for IETF 111 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 18:46:05 -0000 A new meeting session request has just been submitted by Marco Tiloca, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Marco Tiloca Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: ace cbor t2trg cose lake artarea asdf Technology Overlap: teep saag secdispatch sacm lwig 6tisch 6lo roll httpbis lpwan raw Key Participant Conflict: irtfopen rats suit dnssd netconf netmod emu dots anima People who must be present: Carsten Bormann Jaime Jimenez Francesca Palombini Marco Tiloca Resources Requested: Special Requests: Please keep the 2 hours on a single session. Please also avoid any potentially IoT related BOFs and PRGs that might come up. --------------------------------------------------------- From nobody Thu Jun 3 13:12:08 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3595D3A18A5; Thu, 3 Jun 2021 13:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 4mRkwdfYbyUP; Thu, 3 Jun 2021 13:11:58 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3FD23A18A2; Thu, 3 Jun 2021 13:11:57 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FwxrC2Pcpz315n; Thu, 3 Jun 2021 22:11:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162204318386.5937.225407037704905384@ietfa.amsl.com> Date: Thu, 3 Jun 2021 22:11:54 +0200 Cc: The IESG , draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, "core@ietf.org WG" , jaime@iki.fi X-Mao-Original-Outgoing-Id: 644443914.952159-76d25bc0491551b763c27b7875e4f3f2 Content-Transfer-Encoding: quoted-printable Message-Id: <816A83B9-1A98-443B-91EF-0DD1259A6ED6@tzi.org> References: <162204318386.5937.225407037704905384@ietfa.amsl.com> To: Martin Duke X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Martin Duke's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 20:12:03 -0000 On 2021-05-26, at 17:33, Martin Duke via Datatracker = wrote: >=20 > Martin Duke has entered the following ballot position for > draft-ietf-core-senml-versions-03: No Objection >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Given the very constrained space, I wonder if it's wise to reserve 0 = and 2 for > no real purpose. IIUC these would still result in version numbers > 10 = and > therefore not break anything, yes? Hi Martin, The cop-out (end of Section 3) is: These four reserved feature codes are not to be used with any more specific semantics except in a specification that updates the present specification. So we still can use these bits, we just haven=E2=80=99t said yet, how. But indeed, we could have used 0 and 2 as the first bits to be allocated = (much harder to do anything useful with 1 and 3). Not sure we want to change this now to reclaim those bits now, but we = still could. Any reaction, CoRE WG? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 3 13:16:28 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52203A18C2; Thu, 3 Jun 2021 13:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 AqkWhNl-3rNA; Thu, 3 Jun 2021 13:16:18 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 A11183A18C1; Thu, 3 Jun 2021 13:16:17 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id a8so7664175ioa.12; Thu, 03 Jun 2021 13:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yftb4GbrUHzrU64v5PtMKSRuzI0DKPpNVxYTs/h+7Lk=; b=txvPRK/vxPfS3ypOFPI5a0W3tb7i7o5OTwgkxkcG7C37vFvi1dR7A1yPmFTf86mix0 joEfCNUOLszuQp8sXVy1vKLeNNIMaRls//UJEtFWIbLnLY/Vd9hSWdZ+HDe+XHhCVjGz ZhaD3V/ryaYmGgJGEgAkT79gJmN43Rz0blHgZceItX8rV0tnUiYIz3ti3c8cu/7kXdOg tTaz7RV+T0nfWMd0DDSmPLSMLpWWdPa2q/j6pSyht1wREB6pHdCoQE86EdYK2uJV7da5 UrkY+gMx6oOi8aEtSOABcSH/pfWeK/kgBvcnmPUq+XYEL71I5mKcc3px8BkCxDpjhxux KAzw== 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=yftb4GbrUHzrU64v5PtMKSRuzI0DKPpNVxYTs/h+7Lk=; b=eFbmka90LDUg2pUmcPXm/19Ap04y5Ir2+DBJ7jOC1OatP/GfmCSFB8w9xdWz9cx+uc yLeiixTOvwMHCYAU4T3bmyefymEG4aAD+QzuIQJ1LudrwvqCZzkYiOWi56qcalk85VHN uLds1mj9xT06Vm+MEKw6+LtSIWz3nS+VCCHJDuD92Lbq05zDJM069Co5Cov4icgGuFYH JVXjar1M8wr24HElPKNGBDwtxuaXTa9kDYcVnfSi137Aoj0jVe95ebnJTGw/WSTePQVQ rpMC9gQnCjkcaQzKNq8VmA3HfTGF3hyyGzcXhN0iMXwDc6+odrGW874I5MbmkBwOmHxT Xa5g== X-Gm-Message-State: AOAM530v+TsekLdQwyn4Z9IucPFpjrc6NTcgIh5RpVhNWWU3cOjEDwgd VB5g+gqURHi/FmRutNpggRnPQBQG8aYQjQDv2H8k4vxw X-Google-Smtp-Source: ABdhPJzK1Xh90kYy+pMncdugq6jBcyCQTwKamWbby708z0eDlzyh/yZq6MkTaoFAxaIrukz5e2qRikpojimByTxhmws= X-Received: by 2002:a05:6602:1223:: with SMTP id z3mr845384iot.97.1622751375014; Thu, 03 Jun 2021 13:16:15 -0700 (PDT) MIME-Version: 1.0 References: <162204318386.5937.225407037704905384@ietfa.amsl.com> <816A83B9-1A98-443B-91EF-0DD1259A6ED6@tzi.org> In-Reply-To: <816A83B9-1A98-443B-91EF-0DD1259A6ED6@tzi.org> From: Martin Duke Date: Thu, 3 Jun 2021 13:16:03 -0700 Message-ID: To: Carsten Bormann Cc: The IESG , draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, "core@ietf.org WG" , jaime@iki.fi Content-Type: multipart/alternative; boundary="000000000000443fe005c3e23f76" Archived-At: Subject: Re: [core] Martin Duke's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 20:16:23 -0000 --000000000000443fe005c3e23f76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah, good point, you're not throwing them away forever. Thanks! On Thu, Jun 3, 2021 at 1:11 PM Carsten Bormann wrote: > On 2021-05-26, at 17:33, Martin Duke via Datatracker > wrote: > > > > Martin Duke has entered the following ballot position for > > draft-ietf-core-senml-versions-03: No Objection > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Given the very constrained space, I wonder if it's wise to reserve 0 an= d > 2 for > > no real purpose. IIUC these would still result in version numbers > 10 > and > > therefore not break anything, yes? > > Hi Martin, > > The cop-out (end of Section 3) is: > > These four reserved feature codes are not to be used with any > more specific semantics except in a specification that updates the > present specification. > > So we still can use these bits, we just haven=E2=80=99t said yet, how. > But indeed, we could have used 0 and 2 as the first bits to be allocated > (much harder to do anything useful with 1 and 3). > Not sure we want to change this now to reclaim those bits now, but we > still could. > Any reaction, CoRE WG? > > Gr=C3=BC=C3=9Fe, Carsten > > --000000000000443fe005c3e23f76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah, good point, you're not throwing them away for= ever.

Thanks!

On Thu, Jun 3, 2021 at 1:11= PM Carsten Bormann <cabo@tzi.org>= ; wrote:
On 2021= -05-26, at 17:33, Martin Duke via Datatracker <noreply@ietf.org> wrote:
>
> Martin Duke has entered the following ballot position for
> draft-ietf-core-senml-versions-03: No Objection
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Given the very constrained space, I wonder if it's wise to reserve= 0 and 2 for
> no real purpose. IIUC these would still result in version numbers >= 10 and
> therefore not break anything, yes?

Hi Martin,

The cop-out (end of Section 3) is:

=C2=A0 =C2=A0These four reserved feature codes are not to be used with any<= br> =C2=A0 =C2=A0more specific semantics except in a specification that updates= the
=C2=A0 =C2=A0present specification.

So we still can use these bits, we just haven=E2=80=99t said yet, how.
But indeed, we could have used 0 and 2 as the first bits to be allocated (m= uch harder to do anything useful with 1 and 3).
Not sure we want to change this now to reclaim those bits now, but we still= could.
Any reaction, CoRE WG?

Gr=C3=BC=C3=9Fe, Carsten

--000000000000443fe005c3e23f76-- From nobody Fri Jun 4 00:39:22 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC6F3A2D93 for ; Fri, 4 Jun 2021 00:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeHPKALbxjnv for ; Fri, 4 Jun 2021 00:39:15 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10134.outbound.protection.outlook.com [40.107.1.134]) (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 C2D743A2D91 for ; Fri, 4 Jun 2021 00:39:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FNHIliEGvJZdyAy0TH6/CKJeuT9c4pqXzv26tJESqNKhmpGFi4VavHNoef10Hgj1MHUz9Mg/MgIaAEST18j4iKBrRNKelLINpbwtcAkObwzzt3B8rhhyzhUNgA4gp6dKTt8Xm1wU4vW2jKNL6T+DjtLBMv3inU33TilkAHagNwotDDVCIKUiZwkQ0geUT29RCwRI38tUKKsD1iZInJbwnpr6FFRW46XaHCRXgBPU8aT2vhEWJ61pRheQ18f9tNrorj8Flv/XhZvcOytX8KJq7TYGPJNuRSDvY/OawVbp/GDYuN953Wyk79tvU4h6WO3A7iwLwuUh/v///feUnpnWPg== 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=ezgfYo6enUkOTFTmYKYtrWpa1pM8qT701mvlw+JnD4Y=; b=lXDs5X5NKKzHRXOAg1vYpe3SNaN7WZCFq887PHujbzSU4wmJG+nKj+Avcy0iLKzZNsg0CQz5J7dmvt0NqhATM7flvXifvOug3uQ96YctrpL9aytDBuyYMD7+AQ0X5ctEoBAbThfcUgkWe5kp8rwiRFwA19QXxePZDzKY1jQjKuJzzQ+Wad5q2NqgeuuCUUIJgiPrcsmlrnLxdtnrov08mZqU+cuGb464ei/lELSecpLLYuukPKr537dgWK3X8GM/teSJCbyJ1Tugv5BTlSZFltnUJKJ42E02bACWx0PXYYRBK23NWzxz/cjlvGqhNXTza0ndUQP6WUYOu5omlCdXaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ezgfYo6enUkOTFTmYKYtrWpa1pM8qT701mvlw+JnD4Y=; b=QQ7fl9EESgS1dgG//443P9YLMZGetUQWZZ8FGG3SSy1u2quMozdTkTsoLtllRKc/EkKa0vor+UV/8NcaYgt74pxCOUdo/8eyo+MiIffZJRdt1H3AmJaoOoNb9DcozJIbRDHf70Uy2jT07mijX/qSDatzePIfLYxxaeggHETR7Fc= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM0P190MB0708.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:198::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.22; Fri, 4 Jun 2021 07:39:10 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::cc31:ad15:16ab:a540]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::cc31:ad15:16ab:a540%7]) with mapi id 15.20.4195.024; Fri, 4 Jun 2021 07:39:10 +0000 From: Esko Dijk To: John Mattsson , "core@ietf.org" Thread-Topic: Review of draft-ietf-core-groupcomm-bis-03 Thread-Index: AQHXCwSqc4rdNewjlUGtn83ROTnvRasBRjGA Date: Fri, 4 Jun 2021 07:39:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=iotconsultancy.nl; x-originating-ip: [85.147.167.236] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 021c9289-5630-47ad-3e66-08d9272bd7c7 x-ms-traffictypediagnostic: AM0P190MB0708: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pccGelVO+u5HQSKVd4SMJP92LVg0/+vlIwTN4KRu+UiPpLmBTU41PP7H5iMWF+DUzz1dK5BMkdjxrL8yZb/Y+WuY2NVDFxr43sG61Ar5R9Kj9KKSHuLDa9HUINNyYsGnFpLnMnyLcSISV0YwHgNfiaZY4pTR3RGWLovpPUSdZ1FruIrCl3agg3cLL8vV8vZO3yjrR9L2wXNfnOEBK/w8YJq98yEro+IOdeuWPG2SnPkZyvsWRlfRHTsCahp4d5Ay5YLNZwLP/Hz4YlieY5jq/pg72owndpTIDAbi/wAVkMgd2yeu+ktERxclzQKbUshtZyT8pkpuSJXeNjXaMUd+QenTYbr33HTeRVTeID8kkkwKSRl3Aa7dvRz2HlRS4Sf2PafASnRb00KwW5hEmZ3ktjjA5Oks5WmaUAj+1gXLg0kZa3BCBSspKtm9DzqY1OOM21bx3aRl9mrdWaUEwq7taRWNkDgKlxAczLG/BNO+Djpm7cKFYcAA7BiYb5gjY6GqJ1jeuBuMRm7GgpgruVQXAy2T2d+MvdS9guk8qSzs7/WW/I1opVE6KNyOx8eemJhTPG9QdyS9YfaUjmGRD7F0R24wzi1FkAh5JUB2/mASAdGfCPu/UmIoHQHlgOd7JGv0zWfRukMH4F3r+S9aKkegXFznNTHEYT4/wjik/I3CTsNz/j4op41GSPdjeSCIlsPtMcZgv7yEKQtx44UDu1NPAw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(136003)(346002)(376002)(396003)(39830400003)(66446008)(33656002)(66556008)(316002)(64756008)(66476007)(66946007)(76116006)(86362001)(8936002)(66574015)(83380400001)(55016002)(9686003)(53546011)(6506007)(110136005)(5660300002)(8676002)(186003)(26005)(44832011)(38100700002)(2906002)(122000001)(71200400001)(7696005)(966005)(52536014)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?MllSeGcveGs5YzB4N2RKWWxCSG1kbWZnb290dTlCRkxJRnAvVjRubHJlM2Rl?= =?utf-8?B?emVNZUpVM2xBZFVCZEZrUTR6ZXRQQzVJU3dGRkRDa2h4Njg4ZVpuZlViL0J0?= =?utf-8?B?U2QrYXllSVpYN3EwNzlJakZNMDZlQlNCVkVqdE1QOUdrb2pCNzA3ZGpoQTNV?= =?utf-8?B?UmpnR21zbXl6Z3NBUWpkMkIrQlNpcWxxUTlzZ0kyZ2pXVU0vb1dIMTRxbkdj?= =?utf-8?B?dVRzTHlsYmxCUStOU2lUSzdOTjNXNmswYmZJeExnUjVMVTZsWk91MmRzK3gx?= =?utf-8?B?SWNZTHNCd2pSTU1TNHJvQTI5Z1R2T1RnVUl0THJ5NUN6enpjb0FJRHJhRXYr?= =?utf-8?B?VVphbmNRTE40anlXc0NHZUhOa21YLy84b2tUd1p3UEJxdENLaHk2bFZpSGQz?= =?utf-8?B?b0RaK0ZjMkh1d0dqSzZEdFN1WCtZSnlxWHNHTWEzdVpwSktzdXNaU2N3Y090?= =?utf-8?B?V201RVF6N2hOY3BmSG9mbEUzWnIwaGhlVnVmVmJFM1ZMaE03aVFGVE1UZnBr?= =?utf-8?B?K2t2dmEzQlZ1WExzK2VjUGdqbTRrK3BXb3BIWGJMVkd1MGM3aWQ1bUhCSy9G?= =?utf-8?B?c01YM1ZVOWM5RVVTeDJvWS8rQXdzbncySXc5blY1bHlFVzk2WEpOeVFNSFZO?= =?utf-8?B?eEQxYjdNMlBUNnZXMS90blJ3cW4vbnpuSmJ1WGpUbzFqUEkwUWVGTlJpaFFE?= =?utf-8?B?UmhNcmJyRm5HWFdBMVhycVpnNlY1aWhzcnR6NEliSWVDcSt4SlF2cG53RUJi?= =?utf-8?B?Rkh1MlBINEorbkJ2RDBSK0ZOU2RKT2haNkp5VHA4T1h5NWhYQUQvRnBIMllq?= =?utf-8?B?N0I3b25iSkNUYkNYakc3T285ME05a2QvUHVJak5Sc2dZbjNPZzAxT00yU2FR?= =?utf-8?B?MkxpYk1yZkJ3a3hLZnJIQlFPdFovTldkZUM5anZHVG5YTHFRUyt0YktzKzJv?= =?utf-8?B?Z1ZLTGRzbjJTUW15ZC9IZVN6ZENBc0R6QUtuUXdmZHpYWk1PcDVrcHFEM1pm?= =?utf-8?B?aGxCL0tnbHpaYkkrcTRFSkdiV3lyMWFEMWtaci9DempNTkQvQTlUaElCSno3?= =?utf-8?B?UEFDVzZ4eC9HZkNJdURkYTcwM3NpUDdCaVlvckNrSmRoNVhzWUgyNjhyVjRk?= =?utf-8?B?ZHpqZEFWUTg5Wk9TU0tZNkEvVGJJVVVLRlB1L0tNMXlYSFd6NVZKK0Z2SXFN?= =?utf-8?B?aG9yMGhpUzArWEhHVnhwRVc5c3h0S1ZJNjB1cG9lb0l6bFpEOUd6enB1b2xX?= =?utf-8?B?bmorZFZNb2JjMWhDMCtIT1NBVnFpZHZBaFd2bVMwNE9OWkdMTk8ydUhUN2l4?= =?utf-8?B?V0J5UWFmQzZGMG1TWUQvT1BHd3RBWEFuY1hJN1VUZ29SeHVZSGtrRG1teEVC?= =?utf-8?B?QzZWb1FLVWpwclBWOWJGNk5DMHFnc2FzQnJ1MXZmbWpGMHZyZkdIMEk0R2sx?= =?utf-8?B?QjEzZjdhWDVXSlg1eVU1WmcxMFBhNTk3UGpBb2lGcGFya05pakNlSlBIdTdF?= =?utf-8?B?M1ZMTW9rR2tQclQ5UG1abEtHTm9DWWRvWU1peG9qc2o0VHlQbXQyQnRFZXlS?= =?utf-8?B?RVNZQjNVaU5kOCt2UThmdU9uQ0xDT0N5Y1VQUWhubUhLeGNVaEV3eTUwRG1X?= =?utf-8?B?VVkrSTRUQ2VGQjcrMk9EWHdUZldSWXJWaUIwa0JFUHdWSE44U1ZacXNjRGtB?= =?utf-8?B?YXFONElkU203NFhhdmxUVjBjUU55MFZaRVZGdGFlY05HZTZFRkUwOER2a2xD?= =?utf-8?Q?3Rk1MKRYs87NxTSOW5gN4FJMIwwOYToxfT9BRIv?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 021c9289-5630-47ad-3e66-08d9272bd7c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2021 07:39:10.6005 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kKEtzZbaERzkRezuzxC6yp4VP8FLG/gQQVYAaGM813ChBBM2W+6cBxpUiECop3xbHcsnXV8Y1kROcKHRqAaCpwijqFenS48WrWrTAFlay1Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0708 Archived-At: Subject: Re: [core] Review of draft-ietf-core-groupcomm-bis-03 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 07:39:21 -0000 VGhhbmtzIEpvaG4gZm9yIHlvdXIgcmV2aWV3IQ0KDQpTb3JyeSBpdCB0b29rIGEgd2hpbGUgdG8g cmVzcG9uZDsgdGhpcyB3YXMgZHVlIHRvIG90aGVyIHdvcmsuDQoNCj4gLSBJdCBzZWVtcyB1bmNs ZWFyIHRvIG1lIGV4YWN0bHkgaG93IHRoaXMgdXBkYXRlcyBSRkMgNzI1Mi4gRG8gZXZlcnl0aGlu ZyBpbiBSRkMgNzI1MiBzdGlsbCBhcHBseSwgb3IgYXJlIHNvbWUgbXVsdGljYXN0IHBhcnRzIHJl cGxhY2VkPyBJbiBzdWNoIGNhc2Ugd2hpY2ggcGFydHM/DQoNClllcywgdGhhdCdzIG5vdCBhbHdh eXMgZnVsbHkgY2xlYXIgYW5kIHRoZSBpbnRyb2R1Y3Rpb24gb25seSBzdW1tYXJpemVzIHRoaXMu IEkndmUgY3JlYXRlZCBuZXcgaXNzdWUgKGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2dyb3Vw Y29tbS1iaXMvaXNzdWVzLzIwKSBmb3IgdGhpcyBhbmQgcHJvcG9zYWwgdG8gYWRkIGEgc2VjdGlv biAxLjMgdG8gZXhwbGFpbiB0aGlzIGluIGVub3VnaCBkZXRhaWwuDQoNCj4gLSBUaGUgZG9jdW1l bnQgc2VlbXMgYSBiaXQgdG9vIGxvY2tlZCB0byAiVURQL0lQIG11bHRpY2FzdCIgZm9yIG15IHRh c3RlLiBSRkMgNzI1MiBsZWZ0IHRoaW5ncyBtdWNoIG1vcmUgb3BlbiB3aXRoIHN0YXRlbWVudHMg bGlrZSAiYnkgZGVmYXVsdCwgYXJlIHRyYW5zcG9ydGVkIG92ZXIgVURQIi4gQ29BUCBpcyBub3cg cG9wdWxhciBpbiBtYW55IGVudmlyb25tZW50IHdpdGhvdXQgVURQL0lQIGFuZCB0aGUgc2FtZSB3 aWxsL2lzIHRydWUgZm9yIEdyb3VwIENvQVAuIEkgZG9uJ3Qgc2VlIGFueSByZWFzb24gd2h5IG1v c3Qgb2YgdGhlIHRoaW5ncyBpbiB0aGUgZG9jdW1lbnQgY291bGQgbm90IGVhc2lseSBiZSB1c2Vk IHdpdGggYnJvYWRjYXN0LCBnZW9jYXN0LCB1bmljYXN0LCBhbmQgbm9uLUlQIG11bHRpY2FzdC4g TWF5YmUgeW91IGNvdWxkIHNvZnRlbiBpdCBkb3duIGEgYml0IHNvIHBlb3BsZSB3YW50aW5nIHRv IHVzZSBHcm91cCBDb0FQIG92ZXIgRm9vIGNhbiBzdGlsbCBjbGFpbSB0aGV5IGFyZSBkb2luZyBn cm91cCBDb0FQIGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tYmlzLg0KDQpUaGF0IHNlZW1zIHVz ZWZ1bDsgYSBuZXcgaXNzdWUgaXMgY3JlYXRlZCAoaHR0cHM6Ly9naXRodWIuY29tL2NvcmUtd2cv Z3JvdXBjb21tLWJpcy9pc3N1ZXMvMjEpIHRvIGV4cGxvcmUgdGhpcyBmdXJ0aGVyIGFuZCBpZiBw b3NzaWJsZSwgZ2VuZXJhbGl6ZSB0aGUgYXNwZWN0cyB0aGF0IGFyZW4ndCBuZWNlc3NhcmlseSBk ZXBlbmRlbnQgb24gVURQL0lQIG11bHRpY2FzdC4NCg0KPiBUaGUgY3VycmVudCBkb2N1bWVudCBv bmx5IG1lbnRpb24gYW1wbGlmaWNhdGlvbiBpbiBzb21lIHNwZWNpZmljIGNhc2VzLiBJIHRoaW5r IHRoZSBkcmFmdCBuZWVkcyB0byBleHBhbmQgb24gdGhlIHRleHQgaW4gUkZDIDcyNTINCg0KRXhw YW5kaW5nIGEgYml0IG9uIHRoaXMgdGV4dCBzb3VuZHMgdXNlZnVsLCBhcyB3ZSBjYW4gbm93IHBv aW50IHRvIEdyb3VwIE9TQ09SRSBhcyB0aGUgc3BlY2lmaWMgbWVhbnMgdG8gImNyeXB0b2dyYXBo aWNhbGx5IGF1dGhlbnRpY2F0ZSIgYSBtdWx0aWNhc3QgbWVzc2FnZS4NCihpc3N1ZSBjcmVhdGVk IGh0dHBzOi8vZ2l0aHViLmNvbS9jb3JlLXdnL2dyb3VwY29tbS1iaXMvaXNzdWVzLzIyKSAgQWxz byB0aGUgY3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNhdGlvbiBjYW4gYmUgdXNlZCBpbiBjb21iaW5h dGlvbiB3aXRoIG90aGVyIG1lYXN1cmVzIGxpa2UgbGltaXRpbmcgdGhlIHNjb3BlIG9mIHRoZSBt dWx0aWNhc3QgZ3JvdXAuDQoNCj4gQSByZWFkZXIgb2YgZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29t bS1iaXMgbWlnaHQgdGhpbmsgdGhhdCBHcm91cCBPU0NPUkUgYW5kIEVjaG8gaXMgZW5vdWdoIHRv IHN0b3AgYW1wbGlmaWNhdGlvbiwgd2hpY2ggaXMgbm90IHRoZSBjYXNlLiBFY2hvIG9ubHkgaGVs cHMgYSBiaXQgYnkgbGltaXRpbmcgdGhlIHNpemUgb2YgdGhlIHJlc3BvbnNlcyBidXQgbm90IHRo ZSBudW1iZXIgb2YgcmVzcG9uc2VzLiBBbiBhdHRhY2tlciBjYW4gc3Bvb2YgdGhlIHNvdXJjZSBJ UCBvZiB0aGUgcmVxdWVzdCBhbmQgYSBzbWFydCBhdHRhY2tlciB3b3VsZCBzZW5kIGl0IHRvIGEg cmVzb3VyY2UgdGhhdCBzdXBwb3J0cyBtdWx0aWNhc3QgcmVxdWVzdHMuIE5vdCBzdXJlIEdyb3Vw IE9TQ09SRSBoZWxwcyBtdWNoIGF0IGFsbCBhcyBhbiBhdHRhY2tlciBjYW4gdGFrZSBhbiBleGlz dGluZyBncm91cCByZXF1ZXN0IGFuZCBjaGFuZ2UgdGhlIHNvdXJjZSBJUC4gDQoNCldlIGNhbiBj bGFyaWZ5IHRoYXQgZXZlbiB3aXRoIEVjaG8sIHJlc3BvbnNlcyBhcmUgc2VudC4gSWYgdGhlIGF0 dGFja2VyIHlvdSBtZW50aW9uIGNhcHR1cmVzIGEgdmFsaWQgZ3JvdXAgcmVxdWVzdCBhbmQgcmVw bGF5cyBpdCwgSSBhc3N1bWUgdGhhdCBtb3N0IHNlcnZlcnMgd2lsbCBzaWxlbnRseSBkaXNjYXJk IHRoZSByZXBsYXllZCBtZXNzYWdlIGJlY2F1c2UgdGhleSBoYXZlIGFscmVhZHkgcmVjZWl2ZWQg dGhlIG9yaWdpbmFsIHZhbGlkIGdyb3VwIHJlcXVlc3QuIE1heWJlIHNvbWUgc2VydmVycyB0aGF0 IG1pc3NlZCB0aGUgZmlyc3Qgb3JpZ2luYWwgZ3JvdXAgcmVxdWVzdCB3aWxsIHN0aWxsIHJlc3Bv bmQgKGUuZy4gd2l0aCBFY2hvIGJlY2F1c2UgdGhlIHNlcnZlciBkZXRlY3RlZCBhbiBJUCBhZGRy ZXNzIGNoYW5nZSBvZiB0aGUgY2xpZW50IGdyb3VwbWVtYmVyIGFuZCBpdCB3YW50cyB0byB2ZXJp ZnkgdGhhdCAnbmV3JyBJUCBhZGRyZXNzKS4gQnV0IEkgZXhwZWN0IHRoaXMgd2lsbCBvbmx5IGJl IGEgbWlub3JpdHkgb2Ygc2VydmVycywgcmVkdWNpbmcgdGhlIGFtcGxpZmljYXRpb24gZWZmZWN0 LiBTbyB0aGUgY29tYmluYXRpb24gb2YgRWNobyBhbmQgR3JvdXAgT1NDT1JFIHNob3VsZCBoZWxw IGEgZ3JlYXQgZGVhbC4NCk9yIGRpZCB5b3UgaGF2ZSBhbm90aGVyIHNjZW5hcmlvIGluIG1pbmQ/ ICAoZS5nLiBhIHZhbGlkIGdyb3VwIHJlcXVlc3QgaXMgY2FwdHVyZWQgYnkgYW4gb24tcGF0aCBh dHRhY2tlciwgYW5kIHJlcGxheWVkIHRvIGdyb3VwbWVtYmVyIHNlcnZlcnMgc28gdGhhdCBub25l IG9mIHRoZSBzZXJ2ZXJzIGFjdHVhbGx5IHNlZSB0aGUgb3JpZ2luYWwgbWVzc2FnZT8pDQoNCkJl c3QgcmVnYXJkcw0KRXNrbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29y ZSA8bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEpvaG4gTWF0dHNz b24NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNSwgMjAyMSAwMDoyOA0KVG86IG1haWx0bzpj b3JlQGlldGYub3JnDQpTdWJqZWN0OiBbY29yZV0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtY29yZS1n cm91cGNvbW0tYmlzLTAzDQoNClJldmlldyBvZiBkcmFmdC1pZXRmLWNvcmUtZ3JvdXBjb21tLWJp cy0wMw0KDQpJIHRoaW5rIHRoaXMgbG9va3MgdmVyeSB3ZWxsLXdyaXR0ZW4uIEkgcmVhZCB0aHJv dWdoIG1vc3Qgb2YgdGhlIGRvY3VtZW50IHF1aWNrbHkgYW5kIGZvdW5kIHZlcnkgbGl0dGxlIHRv IGNvbW1lbnQgYWJvdXQuDQoNCi0gSXQgc2VlbXMgdW5jbGVhciB0byBtZSBleGFjdGx5IGhvdyB0 aGlzIHVwZGF0ZXMgUkZDIDcyNTIuIERvIGV2ZXJ5dGhpbmcgaW4gUkZDIDcyNTIgc3RpbGwgYXBw bHksIG9yIGFyZSBzb21lIG11bHRpY2FzdCBwYXJ0cyByZXBsYWNlZD8gSW4gc3VjaCBjYXNlIHdo aWNoIHBhcnRzPw0KDQotIFRoZSBkb2N1bWVudCBzZWVtcyBhIGJpdCB0b28gbG9ja2VkIHRvICJV RFAvSVAgbXVsdGljYXN0IiBmb3IgbXkgdGFzdGUuIFJGQyA3MjUyIGxlZnQgdGhpbmdzIG11Y2gg bW9yZSBvcGVuIHdpdGggc3RhdGVtZW50cyBsaWtlICJieSBkZWZhdWx0LCBhcmUgdHJhbnNwb3J0 ZWQgb3ZlciBVRFAiLiBDb0FQIGlzIG5vdyBwb3B1bGFyIGluIG1hbnkgZW52aXJvbm1lbnQgd2l0 aG91dCBVRFAvSVAgYW5kIHRoZSBzYW1lIHdpbGwvaXMgdHJ1ZSBmb3IgR3JvdXAgQ29BUC4gSSBk b24ndCBzZWUgYW55IHJlYXNvbiB3aHkgbW9zdCBvZiB0aGUgdGhpbmdzIGluIHRoZSBkb2N1bWVu dCBjb3VsZCBub3QgZWFzaWx5IGJlIHVzZWQgd2l0aCBicm9hZGNhc3QsIGdlb2Nhc3QsIHVuaWNh c3QsIGFuZCBub24tSVAgbXVsdGljYXN0LiBNYXliZSB5b3UgY291bGQgc29mdGVuIGl0IGRvd24g YSBiaXQgc28gcGVvcGxlIHdhbnRpbmcgdG8gdXNlIEdyb3VwIENvQVAgb3ZlciBGb28gY2FuIHN0 aWxsIGNsYWltIHRoZXkgYXJlIGRvaW5nIGdyb3VwIENvQVAgZHJhZnQtaWV0Zi1jb3JlLWdyb3Vw Y29tbS1iaXMuDQoNCi0gSSB0aGluayBncm91cCBDb0FQIG5lZWRzIHF1aXRlIGEgYml0IG1vcmUg dGV4dCBvbiBhcGxpZmljYXRpb24gYXR0YWNrcyBhbmQgRG9TLiBUaGVyZSBoYXMgYmVlbiBzZXZl cmFsIG5lZ2F0aXZlIGFydGljbGVzIHJlZ2FyZGluZyBDb0FQIGFuZCBERG9TIGluIHRoZSBsYXN0 IHllYXJzLiBHcm91cCBDb0FQIHdpdGggaXQncyAxIHJlcXVlc3RzIGFuZCBOIHJlc3BvbnNlcyBp cyBhIGFtcGxpZmljYXRpb24gaW4gaXRzZWxmLiBNdWx0aWNhc3QgT2JzZXJ2ZSBpcyBldmVuIHdv cnNlLCAxIHJlcXVlc3RzIGFuZCBOXjIgcmVzcG9uc2VzLiBNdWx0aWNhc3QgY2FuIGhvd2V2ZXIg bm90IGJlIHVzZWQgb24gdGhlIHB1YmxpYyBJbnRlcm5ldCB3aGljaCBsaW1pdHMgYW55IGF0dGFj a3MuIFRoZSBjdXJyZW50IGRvY3VtZW50IG9ubHkgbWVudGlvbiBhbXBsaWZpY2F0aW9uIGluIHNv bWUgc3BlY2lmaWMgY2FzZXMuIEkgdGhpbmsgdGhlIGRyYWZ0IG5lZWRzIHRvIGV4cGFuZCBvbiB0 aGUgdGV4dCBpbiBSRkMgNzI1MjoNCg0KICJUaGlzIHNwZWNpZmljYXRpb24gYXR0ZW1wdHMgdG8g cmVkdWNlIHRoZQ0KICAgYW1wbGlmaWNhdGlvbiBlZmZlY3RzIG9mIG11bHRpY2FzdCByZXF1ZXN0 cyBieSBsaW1pdGluZyB3aGVuIGENCiAgIHJlc3BvbnNlIGlzIHJldHVybmVkLiAgVG8gbGltaXQg dGhlIHBvc3NpYmlsaXR5IG9mIG1hbGljaW91cyB1c2UsDQogICBDb0FQIHNlcnZlcnMgU0hPVUxE IE5PVCBhY2NlcHQgbXVsdGljYXN0IHJlcXVlc3RzIHRoYXQgY2FuIG5vdCBiZQ0KICAgYXV0aGVu dGljYXRlZCBpbiBzb21lIHdheSwgY3J5cHRvZ3JhcGhpY2FsbHkgb3IgYnkgc29tZSBtdWx0aWNh c3QNCiAgIGJvdW5kYXJ5IGxpbWl0aW5nIHRoZSBwb3RlbnRpYWwgc291cmNlcy4gIElmIHBvc3Np YmxlLCBhIENvQVAgc2VydmVyDQogICBTSE9VTEQgbGltaXQgdGhlIHN1cHBvcnQgZm9yIG11bHRp Y2FzdCByZXF1ZXN0cyB0byB0aGUgc3BlY2lmaWMNCiAgIHJlc291cmNlcyB3aGVyZSB0aGUgZmVh dHVyZSBpcyByZXF1aXJlZC4iDQoNCkEgcmVhZGVyIG9mIGRyYWZ0LWlldGYtY29yZS1ncm91cGNv bW0tYmlzIG1pZ2h0IHRoaW5rIHRoYXQgR3JvdXAgT1NDT1JFIGFuZCBFY2hvIGlzIGVub3VnaCB0 byBzdG9wIGFtcGxpZmljYXRpb24sIHdoaWNoIGlzIG5vdCB0aGUgY2FzZS4gRWNobyBvbmx5IGhl bHBzIGEgYml0IGJ5IGxpbWl0aW5nIHRoZSBzaXplIG9mIHRoZSByZXNwb25zZXMgYnV0IG5vdCB0 aGUgbnVtYmVyIG9mIHJlc3BvbnNlcy4gQW4gYXR0YWNrZXIgY2FuIHNwb29mIHRoZSBzb3VyY2Ug SVAgb2YgdGhlIHJlcXVlc3QgYW5kIGEgc21hcnQgYXR0YWNrZXIgd291bGQgc2VuZCBpdCB0byBh IHJlc291cmNlIHRoYXQgc3VwcG9ydHMgbXVsdGljYXN0IHJlcXVlc3RzLiBOb3Qgc3VyZSBHcm91 cCBPU0NPUkUgaGVscHMgbXVjaCBhdCBhbGwgYXMgYW4gYXR0YWNrZXIgY2FuIHRha2UgYW4gZXhp c3RpbmcgZ3JvdXAgcmVxdWVzdCBhbmQgY2hhbmdlIHRoZSBzb3VyY2UgSVAuIA0KDQpDaGVlcnMs DQpKb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjb3JlIDxtYWls dG86Y29yZS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIm1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmciIDxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KUmVwbHkg dG86ICJtYWlsdG86Y29yZUBpZXRmLm9yZyIgPG1haWx0bzpjb3JlQGlldGYub3JnPg0KRGF0ZTog TW9uZGF5LCAyMiBGZWJydWFyeSAyMDIxIGF0IDE3OjUxDQpUbzogIm1haWx0bzppLWQtYW5ub3Vu Y2VAaWV0Zi5vcmciIDxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KQ2M6ICJtYWlsdG86 Y29yZUBpZXRmLm9yZyIgPG1haWx0bzpjb3JlQGlldGYub3JnPg0KU3ViamVjdDogW2NvcmVdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tYmlzLTAzLnR4dA0KDQoNCkEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENvbnN0 cmFpbmVkIFJFU1RmdWwgRW52aXJvbm1lbnRzIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRp dGxlICAgICAgICAgICA6IEdyb3VwIENvbW11bmljYXRpb24gZm9yIHRoZSBDb25zdHJhaW5lZCBB cHBsaWNhdGlvbiBQcm90b2NvbCAoQ29BUCkNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogRXNr byBEaWprDQogICAgICAgICAgICAgICAgICAgICAgICAgIENob25nZ2FuZyBXYW5nDQogICAgICAg ICAgICAgICAgICAgICAgICAgIE1hcmNvIFRpbG9jYQ0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWlldGYtY29yZS1ncm91cGNvbW0tYmlzLTAzLnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDU4DQoJ RGF0ZSAgICAgICAgICAgIDogMjAyMS0wMi0yMg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1l bnQgc3BlY2lmaWVzIHRoZSB1c2Ugb2YgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uDQogICBQ cm90b2NvbCAoQ29BUCkgZm9yIGdyb3VwIGNvbW11bmljYXRpb24sIHVzaW5nIFVEUC9JUCBtdWx0 aWNhc3QgYXMNCiAgIHRoZSB1bmRlcmx5aW5nIGRhdGEgdHJhbnNwb3J0LiAgQm90aCB1bnNlY3Vy ZWQgYW5kIHNlY3VyZWQgQ29BUCBncm91cA0KICAgY29tbXVuaWNhdGlvbiBhcmUgc3BlY2lmaWVk LiAgU2VjdXJpdHkgaXMgYWNoaWV2ZWQgYnkgdXNlIG9mIHRoZQ0KICAgR3JvdXAgT2JqZWN0IFNl Y3VyaXR5IGZvciBDb25zdHJhaW5lZCBSRVNUZnVsIEVudmlyb25tZW50cyAoR3JvdXANCiAgIE9T Q09SRSkgcHJvdG9jb2wuICBUaGUgdGFyZ2V0IGFwcGxpY2F0aW9uIGFyZWEgb2YgdGhpcyBzcGVj aWZpY2F0aW9uDQogICBpcyBhbnkgZ3JvdXAgY29tbXVuaWNhdGlvbiB1c2UgY2FzZXMgdGhhdCBp bnZvbHZlIHJlc291cmNlLQ0KICAgY29uc3RyYWluZWQgZGV2aWNlcyBvciBuZXR3b3Jrcy4gIFRo aXMgZG9jdW1lbnQgcmVwbGFjZXMgUkZDNzM5MCwNCiAgIHdoaWxlIGl0IHVwZGF0ZXMgUkZDNzI1 MiBhbmQgUkZDNzY0MS4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3Ig dGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtY29yZS1ncm91cGNvbW0tYmlzLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u cyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j b3JlLWdyb3VwY29tbS1iaXMtMDMNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi1jb3JlLWdyb3VwY29tbS1iaXMtMDMNCg0KQSBkaWZmIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtY29yZS1ncm91cGNvbW0tYmlzLTAzDQoNCg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls YWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KY29yZSBtYWlsaW5nIGxpc3QNCm1haWx0bzpjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmNvcmUgbWFpbGluZyBsaXN0DQptYWlsdG86Y29yZUBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From nobody Fri Jun 4 11:21:20 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5192E3A1BFF; Fri, 4 Jun 2021 11:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=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 GyeSIdxjUNhW; Fri, 4 Jun 2021 11:21:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 DDB9F3A1BFE; Fri, 4 Jun 2021 11:21:06 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 154IKwGe023841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Jun 2021 14:21:03 -0400 Date: Fri, 4 Jun 2021 11:20:57 -0700 From: Benjamin Kaduk To: Carsten Bormann Cc: The IESG , draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, "core@ietf.org WG" , jaime@iki.fi Message-ID: <20210604182057.GS32395@kduck.mit.edu> References: <162265748074.13521.4368551591199171477@ietfa.amsl.com> <3BC8BF6C-94C6-46B7-9A38-0DB25CCBD0D9@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3BC8BF6C-94C6-46B7-9A38-0DB25CCBD0D9@tzi.org> Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 18:21:12 -0000 On Thu, Jun 03, 2021 at 12:28:38PM +0200, Carsten Bormann wrote: > Hi Ben, > > > On 2021-06-02, at 20:11, Benjamin Kaduk via Datatracker wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-core-senml-versions-03: No Objection > > […] > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks, this is nicely written and a reasonable approach. > > > > Section 3 > > > > I think I'm supposed to interpret this as being "the exact bit pattern > > 1010 in the last four bits indicates support for the base SenML version > > defined in RFC 8428; any other bitstring in that position cannot be > > taken as an indication of support for the base version". In other > > words, we're still getting a one-bit signal, just encoded in four bits. > > Is that right? Or maybe just "it's an error to see any other values for > > those four bits"? (If so, do we reject the entire pack?) > > Well, really, RFC 8428 only defines version 10. > So we have no idea what another setting of those four bits would mean. > The cop-out is the text > > These four reserved feature codes are not to be used with any > more specific semantics except in a specification that updates the > present specification. > > which to me indeed means unless there is another specification updating this one, one would reject lsb ≠ 1010, except for a legacy application that, e.g. still supports SenML version 5. > Does this need more text? Suggestions welcome. I was actually thinking less text, rather than more :) Specifically, we could skip talking about Reserved1/Reserved3 always set and Reserved0/Reserved2 always absent, and just say "the four least significant bits set to 0b1010 indicate version 10" before contining to the next sentence "These four reserved feature codes are not to be used..." > > Section 5 > > > > I'd consider adding a sentence "the assignment of new feature bits is > > done in a backwards-compatible manner, so existing implementations will > > not erroneously assume support for a version (feature) that is defined > > in the future" in the vein of an avoided security consideration. > > You lost me here. How can one assign bits in a non-backwards-compatible manner? Assigning Reserved0 would be backwards-incompatible, in that it would allow advertising support for a "version" that, when interpreted as a number, produces a value less than 10. So, a legacy 8428 implementation that applies an ordering on version numbers would find that version lower than the version 10 it supports, and presumably do something bad. -Ben > Of course, feature code 37 could mean "support all of feature code 36 except for feature foognorz, as well as feature barfgnup”. When 36 and 37 are set, this means 36 + barfgnup. > > We don’t even touch on how a receiving implementation could signal its feature support to a generating implementation; the underlying assumption is that most SenML is generated for eternity and not for a specific recipient. > > Grüße, Carsten > From nobody Fri Jun 4 13:23:03 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB1E3A1FC3; Fri, 4 Jun 2021 13:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, 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 PjJpQZoTs9bm; Fri, 4 Jun 2021 13:22:52 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3163A1FC1; Fri, 4 Jun 2021 13:22:51 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FxZ2H3tGTz2xH1; Fri, 4 Jun 2021 22:22:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <20210604182057.GS32395@kduck.mit.edu> Date: Fri, 4 Jun 2021 22:22:47 +0200 Cc: The IESG , draft-ietf-core-senml-versions@ietf.org, core-chairs@ietf.org, "core@ietf.org WG" , jaime@iki.fi X-Mao-Original-Outgoing-Id: 644530967.23076-5c5c090b105f7ee6eeb99e512b2522e2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <162265748074.13521.4368551591199171477@ietfa.amsl.com> <3BC8BF6C-94C6-46B7-9A38-0DB25CCBD0D9@tzi.org> <20210604182057.GS32395@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-versions-03: (with COMMENT) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 20:22:56 -0000 > On 2021-06-04, at 20:20, Benjamin Kaduk wrote: >=20 > On Thu, Jun 03, 2021 at 12:28:38PM +0200, Carsten Bormann wrote: >> Hi Ben, >>=20 >>> On 2021-06-02, at 20:11, Benjamin Kaduk via Datatracker = wrote: >>>=20 >>> Benjamin Kaduk has entered the following ballot position for >>> draft-ietf-core-senml-versions-03: No Objection >>> [=E2=80=A6] >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Thanks, this is nicely written and a reasonable approach. >>>=20 >>> Section 3 >>>=20 >>> I think I'm supposed to interpret this as being "the exact bit = pattern >>> 1010 in the last four bits indicates support for the base SenML = version >>> defined in RFC 8428; any other bitstring in that position cannot be >>> taken as an indication of support for the base version". In other >>> words, we're still getting a one-bit signal, just encoded in four = bits. >>> Is that right? Or maybe just "it's an error to see any other values = for >>> those four bits"? (If so, do we reject the entire pack?) >>=20 >> Well, really, RFC 8428 only defines version 10. >> So we have no idea what another setting of those four bits would = mean. >> The cop-out is the text >>=20 >> These four reserved feature codes are not to be used with any >> more specific semantics except in a specification that updates the >> present specification. >>=20 >> which to me indeed means unless there is another specification = updating this one, one would reject lsb =E2=89=A0 1010, except for a = legacy application that, e.g. still supports SenML version 5. >> Does this need more text? Suggestions welcome. >=20 > I was actually thinking less text, rather than more :) >=20 > Specifically, we could skip talking about Reserved1/Reserved3 always = set > and Reserved0/Reserved2 always absent, and just say "the four least > significant bits set to 0b1010 indicate version 10" before contining = to the > next sentence "These four reserved feature codes are not to be = used..." I=E2=80=99m sorry, that did lead me to add some more text: For SenML Version 10 as described in {{-senml}}, the feature codes 0 to = 3 are already in use. Reserved1 (1) and Reserved3 (3) are always present and the features Reserved0 (0) and Reserved2 (2) are always absent, -yielding a version number of 10 if no other feature is in use. +i.e., the four least significant bits set to 0b1010 indicate a version +number of 10 if no other feature is in use. >>> Section 5 >>>=20 >>> I'd consider adding a sentence "the assignment of new feature bits = is >>> done in a backwards-compatible manner, so existing implementations = will >>> not erroneously assume support for a version (feature) that is = defined >>> in the future" in the vein of an avoided security consideration. >>=20 >> You lost me here. How can one assign bits in a = non-backwards-compatible manner? >=20 > Assigning Reserved0 would be backwards-incompatible, in that it would = allow > advertising support for a "version" that, when interpreted as a = number, > produces a value less than 10. So, a legacy 8428 implementation that > applies an ordering on version numbers would find that version lower = than > the version 10 it supports, and presumably do something bad. Ah, but that just means Reserved1 and Reserved3 are useless (*), while = Reserved0 and Reserved2 could be used like any other flag. With Martin = Duke=E2=80=99s comment, that maybe bears saying. So I added +(Note that Reserved0 and Reserved2 could be used in such a +specification in a similar way to the way the feature codes 4 to 52 +are in the present specification.) This should now be abundantly clear, at the risk of talking the reader = into sound sleep. Thank you for these comments; changes are in = https://github.com/core-wg/senml-versions/commit/4aa6130 I=E2=80=99ll submit the -04 now. Gr=C3=BC=C3=9Fe, Carsten (*) No, they aren=E2=80=99t entirely, but I=E2=80=99m too tired to = explain the exact case in which they aren=E2=80=99t. So I won=E2=80=99t = write text about those. From nobody Fri Jun 4 13:27:00 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 309FC3A1FDC; Fri, 4 Jun 2021 13:26:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162283841811.6550.14663095309869309813@ietfa.amsl.com> Date: Fri, 04 Jun 2021 13:26:58 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-versions-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 20:26:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : SenML Features and Versions Author : Carsten Bormann Filename : draft-ietf-core-senml-versions-04.txt Pages : 8 Date : 2021-06-04 Abstract: This short document updates RFC 8428, Sensor Measurement Lists (SenML), by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-senml-versions-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-versions-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 4 13:32:46 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8000C3A2006; Fri, 4 Jun 2021 13:32:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162283874943.17699.7854572844887171684@ietfa.amsl.com> Date: Fri, 04 Jun 2021 13:32:29 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-versions-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 20:32:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : SenML Features and Versions Author : Carsten Bormann Filename : draft-ietf-core-senml-versions-05.txt Pages : 8 Date : 2021-06-04 Abstract: This short document updates RFC 8428, Sensor Measurement Lists (SenML), by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-senml-versions-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-versions-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 4 13:37:45 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8253A2031 for ; Fri, 4 Jun 2021 13:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 YSgyaxI4yR2f for ; Fri, 4 Jun 2021 13:37:38 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7133A202A for ; Fri, 4 Jun 2021 13:37:38 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FxZMN1pZ0z2xH1; Fri, 4 Jun 2021 22:37:36 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162283874943.17699.7854572844887171684@ietfa.amsl.com> Date: Fri, 4 Jun 2021 22:37:35 +0200 X-Mao-Original-Outgoing-Id: 644531855.772683-823b64f462aa86e4be3aa3e9b24e1da0 Content-Transfer-Encoding: quoted-printable Message-Id: <18907D5F-21EB-4AC8-852B-C9E09FC79056@tzi.org> References: <162283874943.17699.7854572844887171684@ietfa.amsl.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-senml-versions-05.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 20:37:43 -0000 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-versions-05 A true RFC 7386/7396 event (*). Gr=C3=BC=C3=9Fe, Carsten (*) https://www.ietf.org/rfcdiff?url1=3Drfc7386&url2=3Drfc7396 (The RFCs only differ in their number and in whitespace.) From nobody Mon Jun 7 08:48:34 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC133A1B2A for ; Mon, 7 Jun 2021 08:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-INWiflgH_c for ; Mon, 7 Jun 2021 08:48:28 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2041.outbound.protection.outlook.com [40.107.21.41]) (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 8F6383A1B28 for ; Mon, 7 Jun 2021 08:48:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=meDZgtFHcd3uZ9Z5dSJuLVnOHjqJA9af7eWPpyUhg5UdQ+9LQWlEYWF5yNR6vjx9+h9y4Sue6IGdRLgAQudvsl1cihDnGqBJM6CnBNh0CNKL05T5ObN+WT8tCx6BYtEFqc2GzDPytmLu6/yOcBPRA2jJPYaqaXjf8AxHPNWwxJhwWhDyHHWYP/i3qdytgLojniHGta1Jg307nt6NxsnjkJbir/ih2w/Y9kBSsgnd9yy/hv5Q5s72xOAMN1vvaEn0iAd43JrEU93wJDzjYqpLpmfxHyy1qUHxkYLsIGqb0d3af4VMQV4Ptj4OaSEmhjejLSlq2uEQLtJo9olD0LEeFA== 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=gUV9I05wPfmsByBLT/O5czylw4aOzyX9szvd9Srzypo=; b=RRm3KsP0PqbzKscsheupKaG7Q060wSCHVChkwP8TdTVTwFdzhgkDl9MZ4Ncw9gc4cDk01guksFeWJ/Z5/QT+NHQj6qNhxE59jxpZFreaZmbiC5/tSXQElCsD43znAQ0FoN9763LX3pbkD7vOmQdg2ulrP6l+2F30IcUcWs30l/ChCR9hWbuzVmtf0X+wtFq42h2jhJgNGFZSeLyHO6uKlHj666V7IOJODwFqSGhz5Q4kcViIGEW7ee5cR1bb4Ytn0ewkDmjh6BOSmmrucGH/2BUehDsuqcgCe9R9EJ/wdaiz+/FfByiOi2ze8w3PjZi1ltD1UPPBgPE9U0zkmTN+ZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gUV9I05wPfmsByBLT/O5czylw4aOzyX9szvd9Srzypo=; b=X4wB3xXVFHKPXMpBTcvNMTZX/ft90qe/HPf6O+0Nn9FXkDMgi10kUbL1fjEbPG5iOw+wqNqIcHs2cLDi/3s8NacZqfbzt8bKyLZGMWpwNLnfKYciQkZqFUZDQuXFeSLtwBvuHabZr6zKtRWlmsAmhB87A+5LzcZhqFer36iVu14= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB1095.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:169::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.23; Mon, 7 Jun 2021 15:48:26 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6%9]) with mapi id 15.20.4195.030; Mon, 7 Jun 2021 15:48:25 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: Date: Mon, 7 Jun 2021 17:48:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bKqflewpf7Vmzqb9kiH8iQKdVqsBEwHB2" X-Originating-IP: [86.106.103.13] X-ClientProxiedBy: HE1PR08CA0076.eurprd08.prod.outlook.com (2603:10a6:7:2a::47) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.1.5] (86.106.103.13) by HE1PR08CA0076.eurprd08.prod.outlook.com (2603:10a6:7:2a::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.15 via Frontend Transport; Mon, 7 Jun 2021 15:48:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c8f16da2-e1fe-43ea-ac8f-08d929cbafea X-MS-TrafficTypeDiagnostic: DB8P189MB1095: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:1360; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Or81sfk8JwUldZgZ0+v45XD8UpP+gsBdO2dSvshR4TQS+mCPQkd9ri85i6wTbztiR1OVBfnTZOTaKsmrtkOXt7NxV2xrL6nxwbt+7Wfy2pPXzf/SQFCv5ELVhZ6W/VRak7eq1OTfqUL6qtbAVOVRmjFSHRngmkipuYjTC1wvpSrr7CM5syGNkO3AdmpQlBk/kHUhol6bcTz8VayFNZL517JZ7t5NiiYZ5/IJSv11/ejjTAZgVjSxE404+tor497H50S5wb4069lTLpcKTY7LY4M823dIw+mYukq7rXS650SiPLw2BebAQ9qeSPfJ0x7WFR1IhznM8rK2Z6eX14Mh++XN2PA1dV1brbYJgDuJydwsTeAi9evk6ODK2GUZiTZSnT5V+ICjFiDpBT7hs0o7s29h+odIQUQQ1oGhA65Twn0Ilsw2Ywyxce4ERG1vt5X59ojt6Qy98o8jBNiHpyvNoizMOKOmoJMgo/uy8nc/ghtJZuha7PFpUN6AhzfyU7/WAQ0OlR5Bj0WtGTin/IyBGGDWy3dOxeZss+1rk/ww7X/hpvuk/wZaEl9UrJFJ+9r5GxSPkbQFHm7/y9kl5WJKn1HXbbHMqDLcKlc/QiYX8HugPCniIlxdFhUduEUFsHmflkoVrunYEWiXNhxTT3EzgzVVGtkdCqLJYzWhvZFjK60UHF1UbnE9TNDT4q0TP4lbgkK8An2SXRdi81x9JXIWA7bVLd9jKktMoQ0i/V/587810/IRirT+UDmMJiEy/W1zc4ElxQ6UwcYJnMHn3i1sY4X+8oCWBaoLVRd6mXGBz9s= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(39850400004)(396003)(366004)(136003)(376002)(8936002)(8676002)(235185007)(6916009)(83380400001)(478600001)(66556008)(16526019)(966005)(44832011)(6486002)(66574015)(5660300002)(26005)(186003)(31696002)(31686004)(36756003)(16576012)(86362001)(316002)(66476007)(33964004)(66946007)(956004)(2616005)(2906002)(21480400003)(38100700002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?bUdCVmhJTmZ0NytZdkVjSHd6ZGJ1b3h1SEVGbzJNYVBZcHVvZjBTSitrMU9h?= =?utf-8?B?ZngwaTRUSkFWL0E4SlZYazNuYlRZZjZsRVdwWXR1MmNyRnM0dHRXT3Q0T3VH?= =?utf-8?B?Mm0vUW1CRjJKMVdROWVPcFpkb1k1V2NXemlIUllmYzR5WERKNEp0ZlIvUVFP?= =?utf-8?B?eHU0MUxwQi93YUpLTDVpditEY2RTVTZNWVYrRlRGR2IvMVFDUnduT0tZeE5W?= =?utf-8?B?bmFwZzVIQmd4NTNMU3dSTW9FNmEzNXhML1NQTENCR1JVeGZ3U0Q4aE96SitT?= =?utf-8?B?TU15MGJzWEkvdWp6NmFjOG5WdXR3clFBSlI5eWQybTh6TGNvV0xvWEtCRmhY?= =?utf-8?B?OURKZUxwUDd5cUZkczNWZytDWi9uWDl5YlpTNFE4UENDMDV6NC82UUlCWjJp?= =?utf-8?B?SjF5MmNOcGwra2JpdHpuS1BpbHMvcTVwRWRRZTB4MGpHSC91UVVTUHNiSnZP?= =?utf-8?B?ZC9tSC9vakkxNTBvZ3ZmUW9UUWlvQkpCNkdDYUloR0hTSGFOa1oyS3RYYzBk?= =?utf-8?B?ZXVUS2c0ME53Ym9nRlFqbXcrNGpPOXNtVXk1L0Z2VkEzWlpHNXQweGpNQ0Fo?= =?utf-8?B?SUVqZCtDQ3NLTmZYVkNtc2FWT3UvbDNqMVpYcXY1cVRpeFVOeVZ0SlM1Y09v?= =?utf-8?B?ZkpieXhFelhXYmdSdHpGWXZtRGRta3d3T1BQN3FpQ2hQOS9pZUNrYlhiUDNR?= =?utf-8?B?UkdTcEpRcE5nb21wMmJxR0FEMEoyNFpDUmgxSEl6MnNaRDFwZ0cxZG55VE11?= =?utf-8?B?QW1nVzV1cVUvbHJCNTcwR2hmcm1KM3IzbVB4Ymd5bzI4ZmQwakJJZHo3SzlN?= =?utf-8?B?elpXMkNtbGRTL1JLNHVyaDhnS3ZxSW9LZlArbTUvMkE5d0pRV0grWXJ1K3RW?= =?utf-8?B?YkIyTm0zb2ZYdjQvVlBJTFhCeXJJNk9QK0IydER2TjNQTmplbXVqcUlDdmor?= =?utf-8?B?RnR4a0lPTDZtR3RPYlNmRlJvUFpubVp2SXZ3YUpZd0FyWktrek5GZk5POVcr?= =?utf-8?B?bFdQZlJwdUpoTEh5NDA1Smw5dDBMRDE1SlJkZzJhTERIOXJ0MEZKWWpEbmhR?= =?utf-8?B?NUVsbE9FWi9ibkRIYTZXb3R0MjU5Q0g1dnhqYVR3endYcWJudlMxZm85L0Z2?= =?utf-8?B?Zno2Wi9INndwYm8yVTVDMFQrN3hBUzY0UTFQRE9laWNsTjU5VGdpWTRNeVo2?= =?utf-8?B?eExMTWFoTVpHYVplSVNpOFFCZFBZUkNIUGJlZlpDQ2dQS3daTHk0U3htdkkv?= =?utf-8?B?UlRHcEJCMnpTTnd6OUd4SFkrTzJTSUgxbGFnRGdsRjVtMktGZm02WUVEdC9E?= =?utf-8?B?aUh1Uk5RMjRBN243VlQvSG5NTzFrTDdjL2lwK3dzN1dEcFE5TFh3aGxzWkpV?= =?utf-8?B?U0J2QTV6cnhsdWxIZitWVFFlc2xobk5pb0JwT3FlbWI4WFp2N29yYUwxZmhF?= =?utf-8?B?WUdVOGlBV0JjRTRuYUUwREVDYTJFUXRmdmlBa3JYOHFFKzgwNUFxNjN0WU9o?= =?utf-8?B?dmxMRFZGdWdTWUJXNkxZQWdWZi9zMHR4S1d2UmZuaEZSZTJNQk1ab0c2WUQ0?= =?utf-8?B?cHA2Zlp5YzFwSE9ON1BXNUVBMEk1WEZmbks1S1kzSFlUcW8vQXJOcjBvT2la?= =?utf-8?B?TVRYbWFaQ0ZCT1c2Y29hazdJeTYyNXcrSWNlaEIrVlc5bnAvalFLYTN4ekZq?= =?utf-8?B?RlFHNGxvdzlneVJjQ3ViY2xONW9yRWllVWpWMmh0a0xQM1ByS0FXTWlhRTd2?= =?utf-8?Q?xUhORgT5kkWgWCF+KEdCkvK7+PaWv2/DmodP5Nn?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: c8f16da2-e1fe-43ea-ac8f-08d929cbafea X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jun 2021 15:48:25.8542 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: I4YU3b+w6JZwSF7LAgVH1WVS6BTFK6EKWsspBZ4YnLaq2pHerNLYRQSR4nO22LTVo3SGxfG0KUL+SRX8jlfWtw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1095 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-06-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 15:48:33 -0000 --bKqflewpf7Vmzqb9kiH8iQKdVqsBEwHB2 Content-Type: multipart/mixed; boundary="6vsgsLQ3jq8DzDCFiiwrjZX8pnqlZUWD8"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: [core] CoRE WG Virtual Interim 2021-06-09 --6vsgsLQ3jq8DzDCFiiwrjZX8pnqlZUWD8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we'll have a virtual interim meeting on Wednesday,=20 June 9th at 14:00 UTC. The agenda and other pointers are available at [1]. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-07/session/cor= e --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --6vsgsLQ3jq8DzDCFiiwrjZX8pnqlZUWD8-- --bKqflewpf7Vmzqb9kiH8iQKdVqsBEwHB2 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmC+P8cFAwAAAAAACgkQ7iZktA5Y2kNy iQf/QNK1QIC03S9D3le0EiJ5oHqX1I3RXYFQsK4jMeIFPowZm/0TtsAph6o3IER+9gq2Zn2aNWkM hSWKdZgDdT0CRxMytzdxUlOiE5d3HgGs3g+JIy7LzLwKa8COqH2o0rk6lcSwqFWNRVXkrlN/OTw3 BFr0s/Bad7vgoYlrQHQxFy0xDeZkeVBDJXEaGEuX0fQ296xXKXEmAjXUprpGr21WwTREV1brF7s/ mTV/uMR75KWZIe7xwuTHDB0oMZ4aSubHbjMhnoaRhtCfkPEPPkoMyXOR3XRM0AHxOuGRqg9/B1Do fIjPWgQe4freUl2cWzreyzsueRbdcRpLAuC5S0y7YQ== =Vy2P -----END PGP SIGNATURE----- --bKqflewpf7Vmzqb9kiH8iQKdVqsBEwHB2-- From nobody Mon Jun 7 12:37:58 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E613A0407 for ; Mon, 7 Jun 2021 12:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.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 RahB3bRTFaBg for ; Mon, 7 Jun 2021 12:37:50 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 80CF83A03EF for ; Mon, 7 Jun 2021 12:37:50 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id d184so406584wmd.0 for ; Mon, 07 Jun 2021 12:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SbkYbnhfGtPhb/ve7XsOjOXuSao36DpoStf5shCiYi4=; b=fzUmocB3FPNofgdZJkdpGiwqco/YMT9n++1xHNAvIu0mO1Nmd0HkSgRdQloohqk5ds VqhJvhfrwmeFq0RHwI/3QiM14ofVoK2jUBrg+xmHN+d5KJ2HVtTfAqqs0J5FtJpW/V2G uD1eoLeD/ddNuBTsDTgTIg+WbR/f+SHlaBuC8b13v4QkxBDFOWZ+GFDylHtaA7NRml9M glcQN1HhVb07TjW8bjBMiy+C9lSzCvbHVLDTo+za66ckOmrpeM2mSJJAZTN3SJVx9n40 qy6W94uZ4xJSsroaqS34mhXppLVAaRfVHOqRSGNa0flq0qnZmejL0cMDddhSZ0b3EOW+ M5SA== 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=SbkYbnhfGtPhb/ve7XsOjOXuSao36DpoStf5shCiYi4=; b=bmXMUrksOgfqebFsqNhVKASujMJlgDIzbQICDFygcO3DdBlzMLJ8t5oJ9Q26aB5Ej7 EKiWOALvU/arNfC6Pkb11JxTa5MNgYaGg1l3ahkw/1FTQ/4G9UGOq/GufZuAMIO4hae8 j9qJMCVuinOAUvwvCLA3gUEX3ldSwRu38/ADifGy0q8blD5dB/nhlaGepkNA/353+Lhn +VLYq3WJDEMVRtm3IhQ9a4DZBdLL8yA0YdOrTp7C2KhCLZlTY8ujjRJ0TbaYdw8vjncT S74MtQrr5qg2MYYKsyTR637AASmKsABPupZkkj4ZLeeHFbngR84C3dpvpSsJ2HwfGRgw r0YQ== X-Gm-Message-State: AOAM532r8/DVDXvJaHhmUAR4EcnF2kE1k/ZaFQjPFDec6XvY3nKb9gqj E7qgVhuUwUAKdJ5Au0p1IVxEBe5/LkSFg1Ahe/dLYA== X-Google-Smtp-Source: ABdhPJxbNRBBaqA3YZI6h0vIImwNL2iwCZ7AHYuQDf7gC69vF3fW1estGtaJvXnGb2tmPNnOFSqAy11p/XuU5pzGidM= X-Received: by 2002:a1c:c256:: with SMTP id s83mr18059244wmf.86.1623094667677; Mon, 07 Jun 2021 12:37:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ivaylo Petrov Date: Mon, 7 Jun 2021 21:37:21 +0200 Message-ID: To: Francesca Palombini Cc: "barryleiba@computer.org" , "core-chairs@ietf.org" , "core@ietf.org" , "draft-ietf-core-sid@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001aa3af05c4322d89" Archived-At: Subject: Re: [core] Review of draft-ietf-core-sid-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 19:37:56 -0000 --0000000000001aa3af05c4322d89 Content-Type: text/plain; charset="UTF-8" Hello Francesca, Thank you for the review and apologies for the delay! Please find our answers to your questions below. The diff with -15 is available here . updated version is available as txt and as html . Thanks, Ivaylo On Wed 24 Feb 2021 at 13:40, Francesca Palombini < francesca.palombini@ericsson.com> wrote: > Thanks for the work on this document. I have reviewed it and have some > comments. Please handle these comments together with the Last Call comments. > > Chairs: I believe it would make sense to request a review from YANG > Doctors for this document. Let me know if you need help setting that up. > > Thanks, > Francesca > > == > > Section 1: > > SIDs are assigned permanently, items introduced by a new revision of > a YANG module are added to the list of SIDs already assigned. If the > meaning of an item changes, for example as a result from a non- > backward compatible update of the YANG module, a new SID should be > assigned to it. > > should or SHOULD? In general it is not clear to me when it makes sense for > SID need to be re-registered and when they don't, maybe some examples would > be useful. > IP: I rephrased this to make it more clear: SIDs are assigned permanently, items introduced by a new revision of a YANG module are added to the list of SIDs already assigned. If the meaning of an item changes, for example as a result from a non-backward compatible update of the YANG module, a new SID SHOULD be assigned to it. A new SID MUST always be assigned if the new meaning of the item is going to be referenced using a SID. > == > > Section 3: > > Each time a YANG module or one of its imported module(s) or included > sub-module(s) is updated, a new ".sid" file MAY need to be created. > > Maybe s/MAY need to/MAY. I assume this is application specific if the new > .sid file is created or not, so you are leaving it somewhat optional, is > that correct? Might be good to clarify. IP: Clarified as Each time a YANG module or one of its imported module(s) or included sub-module(s) is updated, a new ".sid" file MAY be created if the new or updated items will need SIDs. > > == > > Section 7: IANA is going to ask where to create the registries. Could this > be under yang-parameters or does it need a new registry? IP: That could be discussed, but my understanding was that it's going to be a new registry. > > == > > Section 7.4: Because the policy is expert review, I wonder if a change > controller field should be added (see RFC 8126) > > When creating a new registry with Expert Review as the registration > policy, in addition to the contact person field or reference, the > registry should contain a field for change controller. Having a > change controller for each entry for these types of registrations > makes authorization of future modifications more clear. IP: There is the following text The information associated to the Organization name should not be publicly visible in the registry, but should be available. This information includes contact email and phone number and change controller email and phone number. that for me specifies this. The difference from what you suggest is that this information is not publicly visible in the current text. I believe this is the expected behaviour, but please let me know if you do not agree. Note that this has not been raised by the IANA review. > > == > > Section 7.5.3 Includes initial entries for the registry that are not > consistent with the guideline: > > + "Expert Review" [RFC8126] in case the ".sid" file comes from > a YANG module from an existing RFC, or > > since some of these points are registered from drafts. Should the WG do > early allocation of those? IP: Yes, I believe that should be the expected process. > > == > > Nits > > - expand acronyms on first use ( e.g. NETCONF, RPC, see > https://www.rfc-editor.org/materials/abbrev.expansion.txt ) IP: Done. > > --0000000000001aa3af05c4322d89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Francesca,

Thank you for the review and apologies for= the delay! Please find our answers to your questions <= font color=3D"#000000">below. The diff with -15 is available here. updated version is a= vailable as txt and as html.

<= /span>Thanks,
Ivaylo=

On Wed 2= 4 Feb 2021 at 13:40, Francesca Palombini <francesca.palombini@ericsson.com> wrote:
Thanks for the work on this document= . I have reviewed it and have some comments. Please handle these comments t= ogether with the Last Call comments.

Chairs: I believe it would make sense to request a review from YANG Doctors= for this document. Let me know if you need help setting that up.

Thanks,
Francesca

=3D=3D

Section 1:

=C2=A0 =C2=A0SIDs are assigned permanently, items introduced by a new revis= ion of
=C2=A0 =C2=A0a YANG module are added to the list of SIDs already assigned.= =C2=A0 If the
=C2=A0 =C2=A0meaning of an item changes, for example as a result from a non= -
=C2=A0 =C2=A0backward compatible update of the YANG module, a new SID shoul= d be
=C2=A0 =C2=A0assigned to it.

should or SHOULD? In general it is not clear to me when it makes sense for = SID need to be re-registered and when they don't, maybe some examples w= ould be useful.



=3D=3D

Section 3:

=C2=A0 =C2=A0Each time a YANG module or one of its imported module(s) or in= cluded
=C2=A0 =C2=A0sub-module(s) is updated, a new ".sid" file MAY need= to be created.

Maybe s/MAY need to/MAY. I assume this is application specific if the new .= sid file is created or not, so you are leaving it somewhat optional, is tha= t correct? Might be good to clarify.

IP:=C2=A0Clarified as=C2=A0

Each time = a YANG module or one of its imported module(s) or included

sub-module(s) is updated, a new ".sid" file MAY be cr= eated if the new or

updated items will need SID= s.=C2=A0




=3D=3D

Section 7: IANA is going to ask where to create the registries. Could this = be under yang-parameters or does it need a new registry?

IP:=C2=A0That could be discussed, but my understanding was that = it's going to be a new registry.



=3D=3D

Section 7.4: Because the policy is expert review, I wonder if a change cont= roller field should be added (see RFC 8126)

=C2=A0 =C2=A0When creating a new registry with Expert Review as the registr= ation
=C2=A0 =C2=A0policy, in addition to the contact person field or reference, = the
=C2=A0 =C2=A0registry should contain a field for change controller.=C2=A0 H= aving a
=C2=A0 =C2=A0change controller for each entry for these types of registrati= ons
=C2=A0 =C2=A0makes authorization of future modifications more clear.

IP:=C2=A0There is the following text
=


that for me specifies this. The differe= nce from what you suggest is that this information is not publicly visible = in the current text. I believe this is the expected beh= aviour, but please let me know if you do not agree. Note that= this has not been raised by the IANA review.

<= br>



=3D=3D

Section 7.5.3 Includes initial entries for the registry that are not consis= tent with the guideline:

+=C2=A0 "Expert Review" [RFC8126] in case the ".sid" fi= le comes from
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a YANG module from an existing RF= C, or

since some of these points are registered from drafts. Should the WG do ear= ly allocation of those?




=3D=3D

Nits

- expand acronyms on first use ( e.g. NETCONF, RPC, see https://www.rfc-editor.org/materials/abbrev.expansion.txt = )

IP: Done.
=



--0000000000001aa3af05c4322d89-- From nobody Tue Jun 8 03:22:48 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 365833A2B86; Tue, 8 Jun 2021 03:22:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: core-chairs@ietf.org, core@ietf.org, francesca.palombini@ericsson.com, marco.tiloca@ri.se X-Test-IDTracker: no X-IETF-IDTracker: 7.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162314776574.22393.6905391353008266661@ietfa.amsl.com> Date: Tue, 08 Jun 2021 03:22:46 -0700 Archived-At: Subject: [core] core - Update to a Meeting Session Request for IETF 111 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 10:22:46 -0000 An update to a meeting session request has just been submitted by Marco Tiloca, a Chair of the core working group. --------------------------------------------------------- Working Group Name: Constrained RESTful Environments Area Name: Applications and Real-Time Area Session Requester: Marco Tiloca Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: ace cbor t2trg cose lake artarea asdf Technology Overlap: teep saag secdispatch sacm lwig 6tisch 6lo roll httpbis lpwan raw iotops Key Participant Conflict: irtfopen rats suit dnssd netconf netmod emu dots anima People who must be present: Carsten Bormann Jaime Jimenez Francesca Palombini Marco Tiloca Resources Requested: Special Requests: Please keep the 2 hours on a single session. Please also avoid any potentially IoT related BOFs and PRGs that might come up. --------------------------------------------------------- From nobody Tue Jun 8 07:52:21 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3796A3A3303; Tue, 8 Jun 2021 07:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nT3d-dKb44Km; Tue, 8 Jun 2021 07:52:13 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68ACE3A1811; Tue, 8 Jun 2021 07:52:09 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 4E04B40895; Tue, 8 Jun 2021 16:52:05 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C2A78D7; Tue, 8 Jun 2021 16:52:03 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [141.244.84.125]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 739C67D; Tue, 8 Jun 2021 16:52:03 +0200 (CEST) Received: (nullmailer pid 2851787 invoked by uid 1000); Tue, 08 Jun 2021 14:52:02 -0000 Date: Tue, 8 Jun 2021 16:52:02 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Cc: lwip@ietf.org, draft-ietf-ace-wg-coap-eap@ietf.org, draft-ietf-lake-edhoc@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dsGaW19CM8c9MMe6" Content-Disposition: inline Archived-At: Subject: [core] Examples of lock-step protocols X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 14:52:16 -0000 --dsGaW19CM8c9MMe6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE, hello implementers of lock-step authentication protocols on top of it, based on discussion around how to implement EAP on CoAP, and in parallel on EDHOC discussions (and triggered by Carsten's clarifying comment in today's ACE meeting), I've expanded the CoAP FAQ[1] by an item on how lock-step protocols are best done. (Full text below the mail). EAP is given as a best-practice example; to EDHOC it doesn't apply in full, and EDHOC does to an extent need to go its own way, especially as the connection identifiers are part of the running protocol (given they're used later on, eg. for OSCORE Sender-IDs), and need more expressitivity than just the UTF-8 strings usable inside paths. I don't think that there is any current LWIG document where it'd make sense to add it, but if so, please let me know and I'd try to fit it in. If you disagree or would like to add to it, please edit the wiki or just continue this thread. BR Christian [1]: https://github.com/core-wg/wiki/wiki/CoAP-FAQ -- prominent caveat: Answers are provided by various editors, can be conflicting, and do not necessarily reflect any working group consensus. Full text of the new item: Q: I'd like to run my lock-step protocol over CoAP (where one device sends a message, then the other sends a message, until some sequence is completed),= and need a reliable way to not lose messages or get duplicate ones. How do I do that? A: In a typical and idiomatic solution, there is an entry point URI to which the client POSTs the first message. The server then sends the response in a 2.01 Created response as a payload,= and indicates in Location-Path options where the next POST request should go. T= he client then POSTs the next message there, receives a new Location-Path. A typical (easy-to-debug) pattern of URIs for a given "service" would be /service/ as an entry point, with a random identifier (eg. 0f4ef9bc) used f= or the individual exchange, and a message counter. Thus, the first POST would = go to /service/ containing the first message, the response would contain the second message and a Uri-Location of /service/0f4ef9bc/3. The third message would be sent to /service/0f4ef9bc/3, and the response would contain the fo= urth message and /service/0f4ef9bc/5 et cetera. This is never a rule, though -- = in any such protocol, any server can pick completely arbitrary paths, and while the protocol may place constraints on the maximum length of the path, the client may not place assumptions on the path or read anything into it. The server can correlate and sort the messages by structuring the addresses used for them, and the client can correlate and sort the messages by the request-response matching (through the token) as it knows to which of its o= wn messages it is the successor. The document draft-ietf-ace-wg-coap-eap provides an example of such an exchange. As many constrained servers do not implement message deduplication, such a scheme (relying on POST which is not on by default idempotent) can be difficult. These implementations can be accommodated for by specifying that= the client may only send a request once to each received URI, and that duplicate messages are responded to with the latest sent message. Thus, the server can forego message deduplication on the CoAP layer for these resources, and the implementation would just need to check whether the message number encoded = in the request URI is the expected next (in which case it's processed normally= ), or whether it's the one befoer (in which case the request payload is discar= ded, and the exchange's last state is used to send the last response again). (Ev= en earlier messages can be discarded, and answered e.g. with a 4.04 Not Found). --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --dsGaW19CM8c9MMe6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmC/hA8ACgkQOY0REtOk veF3mxAAoDw9wJzAvRYS3jxditbJLjQNMRN6+5ZbwhmI17HSWZkk5iGbd4Z5X/vS 4+BD2G7QWvS98KIiyefbWupcTzUqG50rXLQSvw71lNEhf+axtClAQyrU14yJW84a 160mos6se/hjlXljgnh8dW8QMYsdvvfSFfpqVQIL1SZDCx81JszX0lZHl8XRd9cb jdTEk7A0pV79iKQ/Z0qgYEV4iOW82yE9cgbAZmd3jmPOFh9/AntELn4iIY0j1dxq peAittYdXhpHTtGe0uE16HfifYx5PfcZwVEk5dhLqhmlw8Hj10XQ7bAVaG8HArmQ 9Vzb0hmowL54oNTls0qLi2PtT+dIFiZJgJCzrqZblzF08XdV2R4+yGkZ+ZzBQJO6 4oM9T6PVgiz81JS/vtYVBYxdi+7s1NxqyyURSktLH70AvgqfDooZS1nBLB4xaO3Z a3v9gJlToLKFkmV0bQ3FHVkrYG05mDeAUzEXDdF4d7iR8oP/tFuDit+Svkt7sJV/ FnLJ2z46+14Ko6w4FLN1a6IHDg15Dv+cbVJu7Fmij90PwP/quEI2PSQAgQhrJx6V y6WaJr+8qHZQnz1uPJmYroKGZGv37IpYbhvChH0/8eiXjCFrRfxGqGr1NY1o4irP vw0m8bV0ImkVEBRaJ8OC8G1hF+pVrMtiqioczoboIqZJY9sp1Kg= =5Oy+ -----END PGP SIGNATURE----- --dsGaW19CM8c9MMe6-- From nobody Wed Jun 9 05:02:19 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3994D3A126D for ; Wed, 9 Jun 2021 05:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lv834ZwkbCE for ; Wed, 9 Jun 2021 05:02:12 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2089.outbound.protection.outlook.com [40.107.21.89]) (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 E7FC43A1265 for ; Wed, 9 Jun 2021 05:02:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bkN10U7aoN2V7S8/YXIfbQezDG/FrcVZRm30GVOZ8ngqwTniynCqrkwcKmypjbPLF07ULZbsGzd0MJLAoyFP119QNdr9GCKHfHqo8ZtGx19VqiGmFPfEC7kV3vtJ3aM9S8OD7X2AC+h0m0fqxBOGrYYKNNPYisId5bcdq2lptP0ZTMTi6EfZoQLcv9n/vHoYzvu224fZtehoSLoLOUX9IdDCf+d+k31BU2SdxCJP17Gk7p/eVK7Ij8+WW8nxojREqOjPiFwagMqhtKfVC4FizeOWT/kVE9lfQ0yRRET26yPWjkctvJfHWemcZ5h9d1k0xiw5Mu7dP7TuB85TyE1wCw== 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=AZqNGhZX1n8DuzY2sImJBGGRiI5SRU8c2gUqNPMNfLc=; b=GKeaAjtlfr3E2zFjjoV45NZkq4MEO1baWa9N5PPcSV/0xXO30AasLpxcVCNKM2I8y/BZC+Pn8mEw11FD8r2DMVct3RWjfo93moNy7uyuMgX5xSqE12ZAbxXk6p2LcMB5cDYaWmK5xn5NkH1OjZ8Q/wOtnXOOgxuH7Ei4zhEoYcSa5q4mdLRobWgvirmG9pHp7GxAgFWLEX8TH+qgrDFQdW+mYSigFJMWREKbAJvC7hSGdgAIVAtrdq4KKkGKn1to0Uoi290WmHz/nwAFRduPbDhJyfoTDAOb3HZmG/ToLyXpJhtVeIhB2fx/s1y+ZOAjpFEx6AvW3vjkx+IJLtgI2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AZqNGhZX1n8DuzY2sImJBGGRiI5SRU8c2gUqNPMNfLc=; b=TsSBpr97HxVFvcHy/KAOxDMvXQ4Z/LSSS+Lh7MltiIRJgd2+NjORybqb4K8k0PG2XKXGafvDrh6GsLhaaEPJthz3e4e1MDcNMQG1wOmR3yFtzpl1w4wBZtK5htinbkEXnsyb8qKZWMkV8NL1YiVqZspVkmmLnmAfDD+U/wn7S14= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB9P189MB1596.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:2a7::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.24; Wed, 9 Jun 2021 12:02:09 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6%9]) with mapi id 15.20.4219.021; Wed, 9 Jun 2021 12:02:08 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: Message-ID: <59ecd8d2-1ce5-dd66-2bd5-98c55867f1ca@ri.se> Date: Wed, 9 Jun 2021 14:02:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XfG6ZMOL4Tdc44988TKb6nLKcbOXlaer8" X-Originating-IP: [86.106.103.116] X-ClientProxiedBy: HE1P190CA0046.EURP190.PROD.OUTLOOK.COM (2603:10a6:7:52::35) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.3] (86.106.103.116) by HE1P190CA0046.EURP190.PROD.OUTLOOK.COM (2603:10a6:7:52::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.20 via Frontend Transport; Wed, 9 Jun 2021 12:02:08 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e981bd0d-62fb-4312-b445-08d92b3e6819 X-MS-TrafficTypeDiagnostic: DB9P189MB1596: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2958; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Wckw3tSFmQb+jyBxUy0tZdLIlkUQdhGqHJ6Gs4bgF+iPnFJvIJfW1llbfgGiSVn1fVamSzQQ5lpFVK7yENUHyGAF6OkP9Pf1FozrUgesqlx11VWomoFXmVIYmSLKql69b+f6n/uNUfwnwi6N1C622969DbOax0jAWVOpVzNItN/5OYsICyqOFtY77DM1rSdJ7C1VslOFbp6+CL5iER5/PUzAJwayO47d93gTWMsYdylPzZ4RmYc6cvyF+QWz3MD66YzvK/n+DbxRMagrSRjjanZORKGMRONh+9TaKaYMc3wQnScnUouRe4/PL31+Sl9M6+xybYkog4Yr4yBILt9xC7zg3KvjRiNrPIlLGqh1LhuhRdcWfN77eANpRb3SIbVyBdNumrDBon5DIMt5/Z19MPk/u71WjvwHG9b02M8nD7uUlD+w+I3QSTcjQ01Ekw4h3WHVQlnttpCJDosWblAHingsiAvTzRw/pKtGV/JYPUumy9onW5a2oZ78QHsOI8dwt2vN0h2u05urUZM+gWLjQ/x6NIoSWEP2LCyXBBAKdlWUrVdBJsF+9hLW4wOTU/4orRaCCf1KYJ6B49Cbln+q7h+UL9VC4Ul4s7PvfwOf1KTuoTwknepm/f3ljNcmXy6ICIMiGdzs3Ux5d7baIQb1Ky3JsQkJg6W0STv19fqPwQHp7KiEnHl6+dzh0h8iS0jisEMx1fGKn5XN/pKUKB90zVGwaxuysKW60FZM4rTJ4cVe8sl6+wMFReCAC0P806X6+hsNNdgrmOcoNPOg5rl/qlB1gyg1CFIw0IJp88nGSyY= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(346002)(396003)(39850400004)(136003)(6486002)(478600001)(36756003)(38100700002)(235185007)(86362001)(2906002)(66946007)(66476007)(83380400001)(316002)(66556008)(2616005)(66574015)(44832011)(21480400003)(16526019)(186003)(26005)(5660300002)(8676002)(31686004)(16799955002)(16576012)(8936002)(33964004)(53546011)(966005)(956004)(31696002)(6916009)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?bjM2b3dBTlJRMFVZdmtFTE9LbmtlUGNzRlJ4dkgvbm5TeklHSDdTZ0I4UUtv?= =?utf-8?B?eTRrN0FOZWJRR3BEMDF5NzhQdEhIZlJpMDQ1eTROeCtwWUIyS09TUFc2K0p5?= =?utf-8?B?ZUhLR3luK0NIN3lodXRwS1k1WDNzZzVqWkJNYkV3R1ZuVit6NTB4LzVWZWYr?= =?utf-8?B?U0xwUW1JOWpCUWtoSTZJUG5VMUJtQjlaNFN0aWlLck1nRm14bWllb1J3ak11?= =?utf-8?B?RHUyQXM0WEd4RGRtTDQyS2dGcmErRWZ1NlJ0TGRaZmVPdTZrazhFK2dyekxh?= =?utf-8?B?cGpUd3JXOFZtVmpuT0xhRElwRllQQ3lLWlpDbEFlZnlKRkNPM0xaMXQydnB2?= =?utf-8?B?OHFiSkM3UXdoRXM1aCtxOTB5bXpidFR0UUhpM3B0cG1HU2pHdEdZV01JK1Jk?= =?utf-8?B?MGFjczY4aCs2QjliNGNJVHFTUWpHMUMxM0J0NktjZW1saTlhd2FWejQwaHAv?= =?utf-8?B?ZUlnWkQvNURzQVFaZFJHU0xBTm1XMThFS2NucjlJb1d5ZVRMSlJiUUYxeVBS?= =?utf-8?B?N3l3R2UybVFXcGc1UHlsenZpMStEaG10WTdtcDc2eVhTUnZ1QStXMjBleU96?= =?utf-8?B?ZjdsODlJdXMzOGs1TGZsZ05aSkpGQUFxb0hXanBJRGxKUnpoTlhqd00yWFcy?= =?utf-8?B?TjVudEZyaSsxaDRCL3V0eTVvOUJ5S1JoRGZRa3pVMnJJZ2VwYnBSb0dTZ05q?= =?utf-8?B?R1FIT1IxQlN0Wnp3VUpZMjFMMWFkOTlqYXZpYVZHSnVTUnhMUzcxS3NMaThB?= =?utf-8?B?ZWZrTk45UEQ3dlRuWXM0Rjg4RFVSdU1KQkpzSkVUSXdrODhmTUliTHlSZXJr?= =?utf-8?B?bU0xQkpIT2xPaHFxNXNTRnpxZDI4RnRFa1FGSXhVSFN5eUJ5UTJadFVkM3Jk?= =?utf-8?B?L2JrcVZETE9na1haaW4zVWV5QWtralFIT2hBTTVKOS8raHVFWi9xZ21CRkc0?= =?utf-8?B?cy9nODY4aWU0UXY1L2RHZEp6NDdabks0ZDlYcG1GNHB3RlYxc3BqTlhsQUlx?= =?utf-8?B?SmFCay9JZ0NkRTBzU1Jxd29GZ2hpU2x1RHkvaGlqWWh4cnRYbmRpQ0wzMkNh?= =?utf-8?B?RTVqRUpINFBQTTZOM040ZVI5bUpjc28wRS9td1NIVlM4dUF6VzNxQ0U4WkhU?= =?utf-8?B?NW9zakdSenBjRkJIZllOYXdxY2pQbkcrbHVoRFpUUVNwVUtmRWZUV2RpeUt1?= =?utf-8?B?SDZnanVDS1pQM1UrT3ViZG40ODM4REo2bzJQVkk3RWhpamNGdTdxc090NGl6?= =?utf-8?B?djFPT0ZyWERkYjJkQWU2OXpxNUtobmlQaisyeWY0Qk05QTg0NmQ5K2VMN0Va?= =?utf-8?B?Vlp3KzAwMFhIOGxkWW9uSnZiaEkyc29xOWU4ZUdvNXhqRTZEVjlkbDM5T0ds?= =?utf-8?B?eXBqb3VuQ0Z5SVFGUUJiRFRUaDcwR1dKV1FlZVIwYTRmK014RTFXRmRXKy8w?= =?utf-8?B?VFovc2hiaWI3WTNvb3ZYSGJYdGt1S0FibzRtRUdBbEIwQjZpSEVkMENJNk9p?= =?utf-8?B?cmNhby9Ic1hKZmpWRExjdUZsRVZ2Skh5RnFjOVR0VCtBak9sU3ZYVGNUMS9J?= =?utf-8?B?WEl0dGtMalRza2FiSktlR1JUbng5bVhHbXA0NlFIRGlEcHZqa1RMRkhxT2tj?= =?utf-8?B?UXlJN1ViTjUwRUR1OW1XZm16ckRnYi9hUkJCT28xUUt0VFNTUHVlZ3FBTmg3?= =?utf-8?B?cFdSS0YzazRSb05KMkJnemE5SUpNSjVVeTExaXJTRE04SGZud05RS0gwdkRH?= =?utf-8?Q?6lxz/q9O+69wB5qQKPz1Sn8Bz7njvHv/CtW/gS9?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: e981bd0d-62fb-4312-b445-08d92b3e6819 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2021 12:02:08.8025 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: PlemoOfP7IMN6h+WGu1refKr/fk7ctua9LISFdRlQ0YArVnuHJG1lTILzxhWnrcPC2SqehC5oO6NbU8GYBSxwQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P189MB1596 Archived-At: Subject: Re: [core] CoRE WG Virtual Interim 2021-06-09 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 12:02:17 -0000 --XfG6ZMOL4Tdc44988TKb6nLKcbOXlaer8 Content-Type: multipart/mixed; boundary="0v75GuAfngW9PpdMPf3q1vMPapsebLrae"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: <59ecd8d2-1ce5-dd66-2bd5-98c55867f1ca@ri.se> Subject: Re: [core] CoRE WG Virtual Interim 2021-06-09 References: In-Reply-To: --0v75GuAfngW9PpdMPf3q1vMPapsebLrae Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we are having our virtual interim meeting in about=20 2 hours [1]. Please find below the information to join. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-07/session/cor= e =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2021-core-07-core?bo= th Meeting link:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dm39160e23c122b545abcd4e12f73da25= 7 Meeting number: 185 202 4858 Password: constrained More ways to join Join by video system Dial 1852024858@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in number (US/Canada) Access code: 185 202 4858 On 2021-06-07 17:48, Marco Tiloca wrote: > Dear all, > > Just a reminder that we'll have a virtual interim meeting on=20 > Wednesday, June 9th at 14:00 UTC. > > The agenda and other pointers are available at [1]. > > Best, > Marco and Jaime > > [1]=20 > https://datatracker.ietf.org/meeting/interim-2021-core-07/session/core > --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --0v75GuAfngW9PpdMPf3q1vMPapsebLrae-- --XfG6ZMOL4Tdc44988TKb6nLKcbOXlaer8 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB4BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmDArb4FAwAAAAAACgkQ7iZktA5Y2kM2 NQf3c1KyFsLPkdXMd1G0/DnEA1xOrH5sVS2BoSpulsCIYbkA27AVb/16WwbC6QugMk/ZdUgvDsDK 5W2tgYRz8sjZOApxI1DHYnZfVG/3Sx20/BEVRy4eX7TZAraQsZJlt/rUr/Yaf+1PBM/sCXV/NMYF dBySDdd4UnSf1qakA4AFo/fYs/a5Xv+3P8Jbudz+d6WmYA25fjtcE6gZ9Zsn9YN1TPQloSrNYMTd rcm0430lskVSqzupIqnTilzr6XJ0qLV56QldtBmS6Uyr/PCmY3tcjf+01L0s/P1FeVjgdbWLW8ov CACDrufaGBwywEe+74Q7b+/sWiXRyo7Sh5dy+Lzd =CoML -----END PGP SIGNATURE----- --XfG6ZMOL4Tdc44988TKb6nLKcbOXlaer8-- From nobody Fri Jun 11 10:26:43 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC753A0781; Fri, 11 Jun 2021 10:26:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , core-chairs@ietf.org, core@ietf.org, draft-ietf-core-senml-versions@ietf.org, francesca.palombini@ericsson.com, jaime@iki.fi, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <162343239516.2582.602097581385620387@ietfa.amsl.com> Date: Fri, 11 Jun 2021 10:26:35 -0700 Archived-At: Subject: [core] Protocol Action: 'SenML Features and Versions' to Proposed Standard (draft-ietf-core-senml-versions-05.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 17:26:36 -0000 The IESG has approved the following document: - 'SenML Features and Versions' (draft-ietf-core-senml-versions-05.txt) as Proposed Standard This document is the product of the Constrained RESTful Environments Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml-versions/ Technical Summary This short document updates RFC8428 by specifying how to express versions for SenML. A version is a bitmap calculated based on which SenML "features" are active. Feature codes are used to express which features are available. The document registers feature codes 0,1,2,3 for the first 4 reserved features the 5th feature code is reserved for when RFC8798 is used. A new subregistry is created within the SenML IANA registry, named "SenML features". The document sets a hard limit for the number of SenML features that can be registered (with only 48 codes left). Expert reviewers should then be very conservative with the allocation of the remaining feature codes. Working Group Summary The document was reviewed (https://mailarchive.ietf.org/arch/msg/core/5cWnixOE8nX4HTIy5w3rE4Whpo8/ ) and discussed in several IETF meetings. Most of the comments were regarding the hard limit to feature codes and therefore of version numbers. Document Quality There is one implementation from Ericsson. Personnel Document Shepherd: Jaime Jiménez Area Director: Francesca Palombini From nobody Sun Jun 13 14:52:55 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41B73A10C1 for ; Sun, 13 Jun 2021 14:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=ackl-io.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 YGoO8CCICELS for ; Sun, 13 Jun 2021 14:52:48 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 0FE773A10BC for ; Sun, 13 Jun 2021 14:52:47 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id q5so12280203wrm.1 for ; Sun, 13 Jun 2021 14:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZXbiqfxpuz4doUUPxz9dZVqf9rBCbI8QeuPZeQLusBs=; b=ueH5WHiSIrSX4uWr0GW6BeUKw9gpocFEnyhjb7548kxEwlAxh/C0wcgRjslS3bEZ5p 6orQ//9scmr/aRApXbTQmVZN9pJjC025Be+nIwMKrIyZXNBHC8Sq5FGDZOsqkliNvscK SXFSD+ZyVFhSYUkdW4VP1MB7GarpWI6lnHuc0mF35ATJMGwfvE8NenOGZDT2uY+wzVdP Ka9RBC8c9tVUozFds7/wJo4ROskVi1fE0PBteg+mveTIE0wxzTb1nA9a3YYJT8ko6j8r siYGKFD+bj7V2f8xnMA1fUCJqTJEmfR5Xe+F5apdSpQDOU7rc6YBjEKM6z2BucW0YjGG UsAA== 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:content-transfer-encoding; bh=ZXbiqfxpuz4doUUPxz9dZVqf9rBCbI8QeuPZeQLusBs=; b=C9f9OlCOK8QsUCT7LDvPjYjzjOvDrO2enV1rHLTVBgYrflMyTuGsiUwW5U32qmvGS/ QG23h+C44UBLzlPqzshL2iCjPBGF1269d4Bm0r3mAw9jOO1M4X3q2ryUv1+LBC95oUsp KMXRKDuZbta+Huf/1bvAh3vDA837b+yqguiBbIamJfUinOu0t3mOJD8UrETQQ07+Fhaa iwcfsZF7Na587ejh6NIiGVgxbE9XEswMPpxTng5jAZtobWUoEcap6sG/syZ4EJIUC343 1V/NBRGGwtwYMjYirOoM1MUUUQ3KuLrjloDjOYqksQVPeNTnqayYFOhN+w+fSgGQPWCn BAeA== X-Gm-Message-State: AOAM5300gord9R7/y32WmkstKcVolgmPeBALQ7dzC+cLGthDxSvx9lo4 Y4w7sfToxRVRpHmfe8iLPBjcudHz8/kACHPm5F1V9A== X-Google-Smtp-Source: ABdhPJxiRHUx0vkvEpxrcpylnkCF4/ShiqaKxlKkAbVLY/w0lLh7GNnA3fGzzRKH+BIOUqzxpgRELMVPati1Zcqefec= X-Received: by 2002:adf:82a3:: with SMTP id 32mr14886635wrc.136.1623621165321; Sun, 13 Jun 2021 14:52:45 -0700 (PDT) MIME-Version: 1.0 References: <161671562340.18744.12200188901217754567@ietfa.amsl.com> In-Reply-To: <161671562340.18744.12200188901217754567@ietfa.amsl.com> From: Ivaylo Petrov Date: Sun, 13 Jun 2021 23:52:19 +0200 Message-ID: To: Xufeng Liu Cc: yang-doctors@ietf.org, core , draft-ietf-core-sid.all@ietf.org, Last Call Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] Yangdoctors last call review of draft-ietf-core-sid-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2021 21:52:53 -0000 Hello Xufeng, Thank you for your review and apologies for the delay! Please find our answers to your questions below. The diff with -15 is available here [1]. The updated version is available as txt [2] and as html [3]. Thanks, Ivaylo [1]: https://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-= ietf-core-sid-15.txt&url2=3Dhttps://core-wg.github.io/yang-cbor/draft-ietf-= core-sid-latest.txt [2]: https://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt [3]: https://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.html On Fri, Mar 26, 2021 at 12:40 AM Xufeng Liu via Datatracker wrote: > > Reviewer: Xufeng Liu > Review result: Ready with Nits > > This is a review of the YANG module in draft-ietf-core-sid-15. > > Minor Issues, Nits, and Questions: > > 1) This module uses the yang-data extension in RFC8040, which was the bes= t > choice a few years ago when this draft started. However, RFC8791 has been > published so that the YANG structure extension is available now. Has the = YANG > structure extension been considered to replace the yang-data extension? > [IP]: Thank you for providing this pointer! We would really prefer not to change this given the mature state of this document, unless there are some really important advantages of using YANG structure extension. Quickly looking at the document I did not find compelling reasons to do the change, but please do let us know if you believe there are such reasons. > 2) The container sid-file is missing in the tree diagram in Section 4. RF= C8340 > specifies the tree format to represent such a yang-data definition. If th= e YANG > structure extension in RFC8791 is used, RFC8791 describes how the tree di= agram > looks like for such a YANG structure. Also, the top container would not b= e > needed, because a YANG structure is encoded as a 'container'. > [IP]: I fixed the tree diagram. About adding the sid-file container, it was suggested in the following email: https://mailarchive.ietf.org/arch/msg/core/-1YKD5X75p9CeTIm1yt0BM3KtOg/. We can discuss with Andy, but from the email I am under the impression that he believed the container is needed. > 3) In the container sid-file, the leaf module-name is optional. What is t= he > assumption when it is not specified? It would be beneficial to clarify in= the > description statement. [IP]: I could not remember why that was made optional. I will have to check with my co-authors and come back to you. > 4) In the container sid-file, the leaf sid-file-version is optional. The > description says that this number starts at zero. Let=E2=80=99s say that = there are two > .sid files, one of which does not have the version number and the other o= ne has > version number 0. Are they the same? If so, would it be better to have a > default statement with a default value of 0? [IP]: Fixed. > 5) For =E2=80=9Clist dependency-revision=E2=80=9D, the key is module-name= . The =E2=80=9Cmandatory > true=E2=80=9D statement is not necessary for this leaf because it is a ke= y. [IP]: Fixed. > 6) Under the =E2=80=9Clist dependency-revision=E2=80=9D, the leaf revisio= n-identifier is > specified as =E2=80=9Cmandatory=E2=80=9D. What would this leaf be specifi= ed when a dependent > module does not have a revision? [IP]: Is it possible to make two different versions of a YANG module without revisions in practice? If the answer is no, then I believe we can make that optional. My understanding is that the answer would be maybe and then I do not think we can support this as it will add non determinism in the SID allocation, which we can not allow. > 7) =E2=80=9Clist assigment-ranges=E2=80=9D should be =E2=80=9Clist assign= ment-ranges=E2=80=9D. A letter =E2=80=98n=E2=80=99 is > missing in the current YANG module because of a typo. > > 8) For =E2=80=9Clist assignment-ranges=E2=80=9D, the key is entry-point. = The =E2=80=9Cmandatory true=E2=80=9D > statement is not necessary for this leaf because it is a key. [IP]: Fixed. > 9) As a convention, the node names of =E2=80=9Clist assignment-ranges=E2= =80=9D and =E2=80=9Clist items=E2=80=9D > should be in the singular form, the same way as =E2=80=9Clist dependency-= revision=E2=80=9D, so > that they would be =E2=80=9Clist assignment-range=E2=80=9D and =E2=80=9Cl= ist item=E2=80=9D. [IP]: Fixed. > 10) Since a YANG SID value is globally unique, would it be beneficial to = have a > statement in the YANG file to describe the requirement formally? This can= be > easily done by adding the following statement under =E2=80=9Clist items= =E2=80=9D: > unique "sid"; [IP]: Added. > 11) The format of the YANG file needs to be adjusted. Some of the lines i= n the > .yang file are longer than 69 characters. For example, at line 108 is: > o Any subsequent schema node name is in the namespace-qualified f= orm > To examine, the command =E2=80=9Cpyang --ietf --max-line-length 69 FILE= =E2=80=9D can be used. > Before publishing, an RFC editor would normalize the format by using the > command =E2=80=9Cpyang -f yang --keep-comments --yang-line-length 69 FILE= =E2=80=9D. It would be > helpful to run this command now since it may change the lines to be longe= r than > the limit of 69 characters. [IP]: Fixed. > 12) In the example in Appendix A, the four "module-revision" statements c= ontain > =E2=80=9C.yang=E2=80=9D after the date, not following the pattern rule of= the > revision-identifier. It seems that the sid generation tool did not take o= ut the > extension =E2=80=9C.yang=E2=80=9D. [IP]: Removed those and made a note to check the tool. > 13) In Appendix A, the 5th item is: > o iana-crypt-hash@2014-04-04.yang (defined in [RFC7317]) > but in RFC7317, the revision of iana-crypt-hash is 2014-08-06 [IP]: I believe I manually downloaded or created that file when I last generated this and probably I have mistakenly put an incorrect revision. Now it's fixed. > 14) The following is a thought that may have been discussed before and de= cided > by the WG, but I=E2=80=99d mention it here anyway just in case: Since the= scope of a > .sid file is for a single YANG file (module), many of the data nodes star= t with > the namespace of this particular module. The =E2=80=9Cschema-node-path=E2= =80=9D currently > requires an identifier string to always start with a namespace. Because o= f this > requirement, there are many repeated namespace strings in the identifiers= of > the items. If we assume that the default starting namespace is the module > associated with the .sid file, we may shorten the .sid file? [IP]: On the constraint devices or over the network the SID file will not be present at all, therefore having some possibly redundant data is not a big issue and my concern is can we introduce possible ambiguity because of an attempt to save a few bytes where they were not creating an issue. If you feel strongly about this, we will bring it to the WG to discuss. > - Xufeng > > > From nobody Sun Jun 13 18:33:35 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3345C3A197F; Sun, 13 Jun 2021 18:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_yAQm4k4L1e; Sun, 13 Jun 2021 18:33:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9F83A197D; Sun, 13 Jun 2021 18:33:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 27AFA38B3C; Sun, 13 Jun 2021 21:34:27 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HVYvRGfkUJo2; Sun, 13 Jun 2021 21:34:26 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A2A2B38B2B; Sun, 13 Jun 2021 21:34:26 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 41BD92B3; Sun, 13 Jun 2021 21:33:22 -0400 (EDT) From: Michael Richardson To: netmod@ietf.org, anima@ietf.org, core@ietf.org In-Reply-To: <6795.1623632992@localhost> References: <6795.1623632992@localhost> 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: Re: [core] [Anima] looking for practical advice on managing YANG source in XML format RFCs X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 01:33:29 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > 3) how do I get my YANG includes downloaded, and do I put them into m= y repo? The other part of the question is how to manage the various extensions that are occuring. What I know about so far: (ascii art warning. fixed font nee= ded) https://www.yangcatalog.org/yang-search/impact_analysis/ietf-voucher@2018-0= 5-09 RFC8355(voucher) ----> RFC8995(voucher-request) \ \ |\ |\ | \ | \ | ietf-anima-constrained-voucher | ietf-anima-constrained-voucher | [ietf-constrained-voucher] | [ietf-constrained-voucher-requ= est] | | \ \ |\ \ | \ \ | ietf-anima-brski-cloud ietf-anima-brski-async-enroll | [ietf-redirected-voucher] [ietf-async-voucher-request] \ \ \ richardson-anima-voucher-delegation [ietf-delegated-voucher] * ietf-{redirected,delegated}-voucher are probably bad names, and it should be ietf-voucher-{redirected,delegated}. Just noticed that. So far, we haven't needed to mix anything from voucher extensions into voucher-requests extensions. But, having a constrained-voucher which is also a delegated-voucher does ma= ke sense. Since the constrained-voucher users the yang-sid to serialize to CBOR, I don't know exactly how that is going to work. I would sure like be sure that we know to mix and match these groupings. I suspect that one has to write a new YANG file importing all the different groupings? I also suspect that it might be time for RFC8366bis that just wraps these things all up into a single document. =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+93Q3WUFAmDGseIACgkQgItw+93Q 3WUPKwf+LNv8YQPCr8DxBYRvmCIb10Sa8STETR7lFhHJALBwT3t+VcruU4rE2/xd LUZlMrFoW15NnmfgarWeIKUFmDoGRR+wN+wH3Tt1wfc/NMZhgYcJJkxBC6wVgqCG FQw98d5lTJObhzYpxvd4wYf2KHBpVRQoYb7YKzHqJ+2LygIhrL6XiQ5LaAyu8MCc K3SSM29cvRxx1qE0h35dpcbTN4mu+pbtHIa5PhaKA4ObavXXLLwo8dis3aJBUbWl ANnNiHCNA17FER01fFT+9xgZrEGxQ3XV+CXR5cVX/66pjGV/gkdzWwx5jrAry2RP 5eGEDW67yK7Ar5q+6tnHPOLOOB+DPA== =w26b -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 13 23:05:14 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70BE3A147F for ; Sun, 13 Jun 2021 23:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.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 VcACzTjXfoDH for ; Sun, 13 Jun 2021 23:05:06 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 568DD3A147C for ; Sun, 13 Jun 2021 23:05:05 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id y13-20020a1c4b0d0000b02901c20173e165so4133414wma.0 for ; Sun, 13 Jun 2021 23:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tP0NfDXCt0DITZ9c0dz7JZ3vGp+N+OjNomPKgXwHpB0=; b=NzLvDqDhHCz9WD2pzW97QUk6HILbyPrnx+qIug7Xz4PL710LiP3m9R77Kf/lOWAAY3 94pPDYfP2CR5w+uv4iQ9Mq0zkgLp/RPjKQ0kcsL9K+pe2XMKBEaebW2s+uATowkkP9kK EviAOB9fauDUQlpv3sgeWp3r2az7dJhXVSIp8SOPUE1DEKlHjY7rBx6HGiKdlpk1uHVq v4OhNPJx4c5bgMTInHlVuQTzlqViYstFkmMPeiJ0F1c60Tfgdw5w/TwlLz41wR90j+4S q2Hsj1V5krXq4scNkqFTAVqtFqdq2PEY28BzoG65axY1b005Tv/fAv9SSKr2E4J63uoB j+UA== 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:content-transfer-encoding; bh=tP0NfDXCt0DITZ9c0dz7JZ3vGp+N+OjNomPKgXwHpB0=; b=G5M7S6cSEHh+2XBVwhSLVZyE6T1j1OfbFXPWdvheTYrPtm8uRhypdDqLzf1yH5JH2g ayO60odV6+5szuJlzMi3XAVSImsNTfsSUTtyDM+uL1hCM2cE+q9cR38wDGutvzuK1vKs JpvZ2Tv7eWdWRtdZ88YZOJI/Qc1dr4CvaBK1U42agb0SS9P5XWQnSThfWoAnE5ls36/l rT8JJw29bH69CLl0xjZHDniTknIR8H8i+nLQQv7HJD5oiqFzLo5iFKXi1edEgugeFeCP GDjE+yoKDX3EQproo3g2jWzJXcL7j3UZH3wul84wFZJrGlYX/TsASc6R5+vOkK+cxs5X HRrQ== X-Gm-Message-State: AOAM532QQaPRrVocOEtsQST23J9iLtid/vnUCLYrHT992AeC/egGCem1 H4FalY+fNe5iZoR+g2dw3w84gQWnLBYZLxuukx8Gzg== X-Google-Smtp-Source: ABdhPJzNr5uGmFyywYwcw673Dt9VN7+/BfPpwmZ6yTkAfp39Uch/KSksRotMT4NtTP38baFdc+Rh9YptVNt3mRhnfDM= X-Received: by 2002:a1c:c256:: with SMTP id s83mr14386120wmf.86.1623650703659; Sun, 13 Jun 2021 23:05:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ivaylo Petrov Date: Mon, 14 Jun 2021 08:04:37 +0200 Message-ID: To: Francesca Palombini Cc: "draft-ietf-core-yang-cbor@ietf.org" , "barryleiba@computer.org" , "core-chairs@ietf.org" , "core@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] Review of draft-ietf-core-yang-cbor-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 06:05:12 -0000 Hello Francesca, Thank you for your review and apologies for the delay! Please find our answers to your questions below. The diff with -15 is available here [1]. The updated version is available as txt [2] and as html [3]. Thanks, Ivaylo [1]: https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-yang-cbor&url2= =3Dhttp://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt [2]: https://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.t= xt [3]: https://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.= html On Wed, Feb 24, 2021 at 1:41 PM Francesca Palombini wrote: > > Thanks for the work on this document. I have reviewed it and have some c= omments. Please handle these comments together with the Last Call comments. > > Chairs: I believe it would make sense to request a review from YANG Docto= rs for this document. Let me know if you need help setting that up. > > Thanks, > Francesca > > =3D=3D > > 4.4. The 'list' and 'list' instance(s) - should this second 'list' be "s= ubset of 'list'" [IP]: There were places where instances were used as instantiations of schema nodes and places where instances were used instead of entries. I tried to clear this out. > =3D=3D > > Section 4.6: > > anyxml value MAY > contain CBOR data items tagged with one of the tags listed in > Section 9.3, these tags shall be supported. > > Why not BCP 14 SHALL? [IP]: For certain types of data we can know from the CBOR type what is inside the anyxml (true/false/null, etc). For others, that is not the case and that's where we need the tags. > =3D=3D > > * General question: about the SID values used throughout the document: as= far as I can tell these are not allocated right now (and they will take so= me time to get registered as defined in core-sid document) It might be good= to add a sentence about where the SID values from the examples come from. [IP]: I believe most/all of those values can be considered fictional and provided only as examples, hence the need to provide the element being encoded each time. I believe this makes reading the text also easier as you are not expected to remember information for too long. I will ask my co-authors if there is specific reasoning behind the values and add that sentence. > =3D=3D > > Section 6.6 (and other sections that use tags defined by this document): > > There is a new CBOR tag appearing in this section's example, tag 44. This= is quite surprising without any text. Although the registration follows th= e template from RFC8949, I would have expected to see some descriptive text= about the tag (and not only appearing in the sentence "The encoding MUST b= e enclosed by the enumeration CBOR tag as specified in Section 9.3." - note= that section 9.3 does not specify how to use the tags). > This is valid for the following sections specifying new CBOR tags as well= . [IP]: I am not certain what kind of additional text would be useful for the reader. Is the fact that inside tag 44 there needs to be an encoding of an enum not clear or is it rather why is that tag necessary. Or maybe something else? > =3D=3D > > Section 6.7: > > I find it hard to understand the example, without any indication on which= bits are set. [IP]: Modified The following example shows the encoding of an 'alarm-state' leaf instance with the 'critical', 'warning' and 'indeterminate' flags set. to The following example shows the encoding of an 'alarm-state' leaf instance with the 'critical' (position 3), 'warning' (position 8) and 'indeterminate' (position 128) flags set. > =3D=3D > > Nits > > - expand acronyms on first use ( e.g. NETCONF, RPC, see https://www.rfc-e= ditor.org/materials/abbrev.expansion.txt ) [IP]: Done for acronyms that I noticed. > - move YANG SID terminology description before delta description. [IP]: Done. > Section 4.5 > > module event-log { > ... > anydata last-event; # SID 60123 > > Please close the parenthesis of this example [IP]: Done. > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Jun 14 04:47:39 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960AD3A2165 for ; Mon, 14 Jun 2021 04:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.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 NOWFnbCZYFSP for ; Mon, 14 Jun 2021 04:47:29 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74783A2166 for ; Mon, 14 Jun 2021 04:47:28 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id q5so14243676wrm.1 for ; Mon, 14 Jun 2021 04:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kw7oEP5GbeyyUIsXVVo5EfByblXCK76OM3jax7EnYsU=; b=S9E1/0NwXpi3EhYt04xzdPVcnOslmuFfvVHqQ5Ims3UXrQYTSnEcdbURGYy6ANiT7m PbU2h4HuNdIzBZdKJaR5q69alH+zlTNnYgerHbE/2ZVpTk8nbS+4hLsMKE7iKbdQnDwd 4PGnrQRnz3Z0qLLqv8u1+GK/34rt7eyRyc2GAKWwra47irnf7p+nhoxFAwGOrW9TSpzm sX6sUFY83S7uzYi7NDgJQzJlXsakRE1CrjagQpJAva2Jw0BcMOe4BL7SPa5hh7Ea7KyB h7vRxhaAuocuz1MH1vqcktrFF34S/2YeGYsj4vyc+HiqmlpbSx8bTxw7IRq6wTUkp2vO BqOQ== 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=kw7oEP5GbeyyUIsXVVo5EfByblXCK76OM3jax7EnYsU=; b=HMe0pA08CXGxhAYv6WLi+9GXWxIO475wQH7c+82T0jeMlOoZxV33atQEyh/IKCrvDy WxaSbOdZFe5nBTrt0f+5OWxlSTGPBY92U0/l4+R1qky+aSvx0i4M7eugBQzrRCTEmG35 0jxgZI2hzGTA0R2nr983K5FrrDJi0KHTbd4jL6VeDT3291LVgmOXzU4hbuMD7siEAHFv /JC7yUjX1RxNbICry4mgnsusYA2FNVfh8tV4Q/3GTAlI9Y/fhjqT1ubQgQVI+jU581EM sBgzKusgcn3EIIXYNOnO44sBPOuoyOs/EJXYV7IcPZphcVkikv698RBt58a3CJLAJSNK zDHg== X-Gm-Message-State: AOAM533pz6t2ypKO8c1I0zHaCHNLfQNWuQUOyVEo3ohdWQcBjCdxaxcz j91Yd01SiEUytM9qScW/xjaf70eP6F3ZiRe1exFKPg== X-Google-Smtp-Source: ABdhPJw3NkIWEpwrzWf4hCpFNR6OMnKQb8ARNIay7OlDR9ZZ4DNkO4PosKKpbv12+EvMLv+yTXmhSR1CEg15MJjYFoI= X-Received: by 2002:adf:82a3:: with SMTP id 32mr17660913wrc.136.1623671245619; Mon, 14 Jun 2021 04:47:25 -0700 (PDT) MIME-Version: 1.0 References: <161592338136.13562.2421108714318351834@ietfa.amsl.com> In-Reply-To: <161592338136.13562.2421108714318351834@ietfa.amsl.com> From: Ivaylo Petrov Date: Mon, 14 Jun 2021 13:46:59 +0200 Message-ID: To: Joe Clarke Cc: yang-doctors@ietf.org, draft-ietf-core-yang-cbor.all@ietf.org, Last Call , core , ivaylopetrov@google.com Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] Yangdoctors last call review of draft-ietf-core-yang-cbor-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 11:47:35 -0000 Hello Joe, Thank you for your review and apologies for the delay! Please find our answers to your questions below. The diff with -15 is available here [1]. The updated version is available as txt [2] and as html [3]. Thanks, Ivaylo [1]: https://tools.ietf.org/rfcdiff?url1=draft-ietf-core-yang-cbor&url2=http://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt [2]: https://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt [3]: https://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.html On Tue, Mar 16, 2021 at 8:37 PM Joe Clarke via Datatracker wrote: > > Reviewer: Joe Clarke > Review result: Almost Ready > > I have been asked to review this document on behalf of yang-doctors. Overall, > I found the document with its many examples to be quite readable and clear. > However, I did find a few readable and typo issues and I have a few questions. > See below. > > === > > Abstract: > > s/notifications and yang-data/notifications and the yang-data/ [IP]: Fixed. > === > > Section 2: > > Move the definition of YANG Schema iDentifier higher up in the list of > terminology so it's defined before you use it when discussing deltas. This > should likely be first in the list. [IP]: Fixed. > === > > Section 3 > > s/When schema node are serialized/When schema nodes are serialized/ [IP]: Fixed. > === > > Section 3.3 > > s/identifiers as string, similar/identifiers as strings, similar/ [IP]: Fixed. > === > > Section 4.1 > > In other examples you include the associated type definition inline. You don't > do that with inet:domain-name. In fact, you _do_ include the domain-name > typedef in Section 4.3, but I think it should move up here as well to aid in > readability. [IP]: Added the typedef here as well to make the example self-contained and simpler for reading. > === > > Section 4.2.1 > > s/In the case of an 'notification content'/In the case of a 'notification > content'/ [IP]: Fixed. > === > > Section 4.2.2 > > You duplicate the YANG snippet here that you included in the overarching > Section 4.2. I don't think both are needed. Probably best to drop this here > since you didn't include it in 4.2.1. [IP]: Agreed! Fixed. > === > > Section 4.4 > > You use the term "list instance" to mean what I think is better stated as "list > entry". The latter is clearer with respect to an element within a list vs. the > instance of a list itself. You use "list instance" in Section 3 as well (and > in other places in the document) where I think "list entry" would be clearer. [IP]: There were places where instances were used as instantiations of schema nodes and places where instances were used instead of entries. I tried to clear this out. > === > > Section 4.4.1 > > I think documenting the true/false value of the primitives here (noted in the > CBOR encoding) would aid in clarity. For example, "primitive(20) [false]". [IP]: I am not against that, I am only concerned if that would be readable for others that are used to the diagnostic notation, otherwise I am fine to apply this change. > === > > Section 4.5.1 > > I'm being pedantic here, but ahead of the { 60123 : { ... example, you usually > state "CBOR diagnostic output". You don't here, though. I think you should > add it. [IP]: I might be misunderstanding the point, but it appears to me that there is such a note already, only it unfortunately appeared at the top of the previous page in the txt version and was quite easy to miss. > === > > Section 4.6 > > Concerning text "anyxml value MAY contain CBOR data items tagged with one of > the tags listed in Section 9.3, these tags shall be supported.": > > This sentence fragment makes no sense. Did you mean something along the lines > of: "the tags listed in Section 9.3 SHALL be supported"? [IP]: I believe I fixed that now. > === > > Section 5 > > s/Just like YANG containers, yang-data/Just like YANG containers, the yang-data/ [IP]: Fixed. > === > > Section 6.7 > > s/same example yang definition, but this/same example YANG definition, but this/ [IP]: Fixed. > s/byte string MUST instead by encoded/byte string MUST instead be encoded/ [IP]: Fixed. > === > > Section 6.13.1 > > It isn't clear to me how a YANG list with multiple keys or a YANG list with no > keys would be encoded in CBOR. I think examples and some clarifying text would > help. [IP]: I have modified one of the examples so that it uses two keys. As for the other point, Is it possible to have a list with no keys being referenced through an instance-identifier? My understanding is that this is not possible, but I might be wrong. If it is not possible, we will only need to clarify this in the text. If it is possible, can we use the position in the list to identify the element? > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Jun 14 05:08:32 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180343A2213 for ; Mon, 14 Jun 2021 05:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.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 ZkuVWKraD1h3 for ; Mon, 14 Jun 2021 05:08:19 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 91D0B3A220A for ; Mon, 14 Jun 2021 05:08:19 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id l9so12002894wms.1 for ; Mon, 14 Jun 2021 05:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NB2Rda7ICkGpJUBgNJ0fAcyRSaeYm2gTtBNkee3Xhfw=; b=iGwsom2gDAEgek5tVVHxrZbIQ6QMVh4p7FBOp8j2GLgrDTHkzH7pjeyN4rn70RXdX+ d127sxB4NELjWnrOfnd9yBXssOzz1k5L3b2qgYCd72I6AiOwvXrXnuFzJOgCTl6WoO2G UnhUJ4PdNlB0DbmAd5YB4tYiQiNW0ofyBqVBK6GdYJx5JiS66c6JLXiBeRxUfth6/lYA UGjHaFWF5qlOn866UgpmYof+0bMdsiK3sij0Jhd5sf95fGsPXUZF22fr0lzPw7NHqaa1 FhL7MnkxiHR1++DBj1NB3Nc2nHPuiHAPNVKePAW6yg7gnDTCshAG+w8ScZ8/kRio/tIM /Hsg== 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:content-transfer-encoding; bh=NB2Rda7ICkGpJUBgNJ0fAcyRSaeYm2gTtBNkee3Xhfw=; b=l10QB7kiqOO/L42JbYxIvEKQ8fXnwZm42kKCddqSe5pYzyrSSR2XsGi5Y+S/pf93NI B6J3RiEVLQly336lBEuV0ukT2xMwrqJZdBsN1a4NaWtihNWw6VAsLothcnlGx+REoGTx OuxIRfxk0bB6IR9bA6Y1f/0DDK1UY15dBLhmAF/3u4x1vl3Ya7wPE7DWAPMeu/ooggpg vXeb85Qk7DlK0NO83VGOgorCLRI6rxegDbV3EeR3wCSTJqkXuylN5ZUmn8RJCPfRuIjn lgxl06DaXYQPp/vAEM5e9IkVqchX3SrAEvXR8mhp9SZh+s2+BEa1vFanODM5SukeQZTG +DGQ== X-Gm-Message-State: AOAM531UNo8wuuOHntKK03dAgQuTROEPI8e0EoPeVfXhXIGc1Y0AqRJu Qtof6GGTT5ZVBkNPcsXdV5hYIQk1vEKbtBwENYolGA== X-Google-Smtp-Source: ABdhPJz2UqUzdP4itqbXsr7uX51DLDoSqAcI29sVJwtwhsN8d1DDOjSkQg7WaeJc28rnzLxS8yOUjb+SWeLnJ2GVl4k= X-Received: by 2002:a1c:c256:: with SMTP id s83mr15963215wmf.86.1623672492644; Mon, 14 Jun 2021 05:08:12 -0700 (PDT) MIME-Version: 1.0 References: <161628931741.12906.14218382588913943918@ietfa.amsl.com> In-Reply-To: <161628931741.12906.14218382588913943918@ietfa.amsl.com> From: Ivaylo Petrov Date: Mon, 14 Jun 2021 14:07:46 +0200 Message-ID: To: Peter Yee Cc: Review Team , draft-ietf-core-yang-cbor.all@ietf.org, Last Call , core , ivaylopetrov@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-yang-cbor-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 12:08:31 -0000 Hello Peter, Thank you for your review and apologies for the delay! Please find our answers to your questions below (TL;DR: all suggestions sound good). The diff with -15 is available here [1]. The updated version is available as txt [2] and as html [3]. Thanks, Ivaylo [1]: https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-yang-cbor&url2= =3Dhttp://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt [2]: https://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.t= xt [3]: https://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.= html On Sun, Mar 21, 2021 at 2:15 AM Peter Yee via Datatracker wrote: > > Reviewer: Peter Yee > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-core-yang-cbor-15 > Reviewer: Peter Yee > Review Date: 2021-03-20 > IETF LC End Date: 2021-03-17 > IESG Telechat date: Not scheduled for a telechat > > Summary: This seems like a straightforward encoding specification draft. = While > I did not check to see that the example encodings were correct, they appe= ared > logical to the eye. Really, the only thing I have to offer is a small set= of > nits that mildly improve the readability of the document. [Ready with nit= s] > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > > General: > > Ensure that =E2=80=9Ci.e.=E2=80=9D is followed by a comma. [IP]: Done. > Specific: > > Page 4, =E2=80=9Cchild=E2=80=9D term: insert =E2=80=9Cor=E2=80=9D before = =E2=80=9Can action output=E2=80=9D. [IP]: Done. > Page 4, =E2=80=9Citem=E2=80=9D term: append a comma after submodule. [IP]: Done. > Page 5, section 3, 2nd paragraph, 1st sentence: append a comma after =E2= =80=9Cinput=E2=80=9D. > Change the first =E2=80=9Cand=E2=80=9D to =E2=80=9Cor=E2=80=9D (before = =E2=80=9Caction output=E2=80=9D). [IP]: Done. > Page 5, section 3, 3rd paragraph, 2nd sentence: consider inserting =E2=80= =9Ca=E2=80=9D before > =E2=80=9CSID=E2=80=9D. Append a comma after =E2=80=9Cnodes=E2=80=9D. Chan= ge the =E2=80=9Cand=E2=80=9D to =E2=80=9Cor=E2=80=9D. [IP]: Done. > Page 5, section 3, 5th paragraph, 1st sentence: change =E2=80=9Cand=E2=80= =9D to =E2=80=9Cor=E2=80=9D. [IP]: Done. > Page 5, section 3, 6th paragraph, 1st sentence: change the first =E2=80= =9Cnode=E2=80=9D to > =E2=80=9Cnodes=E2=80=9D. Append a comma after =E2=80=9Cname=E2=80=9D. [IP]: Done. > Page 8, section 3.2, 6th bullet item: append a comma after =E2=80=9Csubmo= dules=E2=80=9D. [IP]: Done. > Page 8, section 3.3, 1st paragraph, 1st sentence: change =E2=80=9Cstring= =E2=80=9D to =E2=80=9Cstrings=E2=80=9D. > Change =E2=80=9Cas=E2=80=9D after =E2=80=9Csimilar=E2=80=9D to =E2=80=9Ct= o=E2=80=9D. [IP]: Done. > Page 8, section 3.3, 1st paragraph, 2nd sentence: change =E2=80=9Cto SIDs= =E2=80=9D to =E2=80=9Cwith > SID=E2=80=9D. [IP]: Done. > Page 11, section 4.2, 1st paragraph, 1st sentence: consider aligning the > capitalization and pluralization of terms in this sentence with the usage= in > the Abstract. Append a comma after =E2=80=9Cinputs=E2=80=9D (or =E2=80=9C= input=E2=80=9D if you change this > sentence to match the Abstract). [IP]: Done. > Page 22, 1st paragraph following the bullet items, 2nd sentence: change c= omma > after to either a period or a semicolon. [IP]: Done. > Page 26, section 5.1, 1st paragraph, 2nd sentence: change the comma to a > semicolon. Insert =E2=80=9Cto=E2=80=9D before =E2=80=9Cthe CBOR=E2=80=9D. [IP]: Done. > Page 27, section 5.2, 1st paragraph, 2nd sentence: change the comma to a > semicolon. Insert =E2=80=9Cto=E2=80=9D before =E2=80=9Cthe CBOR=E2=80=9D. [IP]: Done. > Page 29, 1st paragraph: change =E2=80=9Ca=E2=80=9D before =E2=80=9C=E2=80= =99mtu=E2=80=99=E2=80=9D to =E2=80=9Can=E2=80=9D. [IP]: Done. > Page 35, section 6.10: delete the comma after =E2=80=9Cidentityref=E2=80= =9D. Insert =E2=80=9Cas=E2=80=9D before > both =E2=80=9Ca YANG Schema=E2=80=9D and =E2=80=9Ca name=E2=80=9D. [IP]: Done. > Page 35, section 6.10.1, 2nd sentence: consider changing =E2=80=9Cas=E2= =80=9D to =E2=80=9Cused for=E2=80=9D. [IP]: Done. > Page 36, section 6.11, 2nd paragraph: change =E2=80=9Ca=E2=80=9D to =E2= =80=9Can=E2=80=9D before =E2=80=9C=E2=80=99is-router=E2=80=99=E2=80=9D. [IP]: Done. > Page 37, section 6.12, 2nd paragraph following the bullet items: insert = =E2=80=9Ca=E2=80=9D > before =E2=80=9CCBOR=E2=80=9D. [IP]: Done. > Page 39, 3rd paragraph: would it make more sense to change =E2=80=9CSchem= a nodes > member=E2=80=9D to =E2=80=9CSchema node members=E2=80=9D? [IP]: Yes, done. > Page 39, 2nd bullet item, 2nd sentence: insert =E2=80=9Cthe=E2=80=9D befo= re =E2=80=9Ctop=E2=80=9D. Change > =E2=80=9Cfollow=E2=80=9D to =E2=80=9Cfollowed=E2=80=9D. [IP]: Done. > Page 41, section 6.13.2, 1st paragraph, 1st sentence: I believe =E2=80=9C= analogous=E2=80=9D > makes more sense than =E2=80=9Canalogical=E2=80=9D in this sentence: [IP]: Done. > Page 43, section 8, 2nd paragraph, 2nd sentence: change =E2=80=9Cof=E2=80= =9D to =E2=80=9Cto=E2=80=9D. [IP]: Done. > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Jun 14 05:51:08 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344333A2332; Mon, 14 Jun 2021 05:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, 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 gIP61jPzCkFX; Mon, 14 Jun 2021 05:50:58 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC9B3A2333; Mon, 14 Jun 2021 05:50:58 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4G3WXG43vJz2xHN; Mon, 14 Jun 2021 14:50:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Mon, 14 Jun 2021 14:50:54 +0200 Cc: Joe Clarke , draft-ietf-core-yang-cbor.all@ietf.org, yang-doctors@ietf.org, "ivaylopetrov@google.com" , core , Last Call X-Mao-Original-Outgoing-Id: 645367854.17946-dcd403590f5c97a2a970fb4b32e46e06 Content-Transfer-Encoding: quoted-printable Message-Id: References: <161592338136.13562.2421108714318351834@ietfa.amsl.com> To: Ivaylo Petrov X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] Yangdoctors last call review of draft-ietf-core-yang-cbor-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 12:51:04 -0000 > On 2021-06-14, at 13:46, Ivaylo Petrov wrote: >=20 >> I think documenting the true/false value of the primitives here = (noted in the >> CBOR encoding) would aid in clarity. For example, "primitive(20) = [false]". >=20 > [IP]: I am not against that, I am only concerned if that would be > readable for others that are used to the diagnostic notation, > otherwise I am fine to apply this change. Let me pick this one because it is all my fault. The =E2=80=9CCBOR encoding=E2=80=9D snippets are generated by the CBOR = diagnostic tool (which is also available at cbor.me on the Web.) The comments it generates in its =E2=80=9Cpretty hex=E2=80=9D output are = rather generic comments about the encoding; they are not trying to = reflect the exact meaning of the content. This usually comes up with = negative numbers (where the argument numbers shown are not bit-wise = inverted to generate the negative number), but more detail could also be = added for false/null/true/undefined. Instead of manually tweaking dozens of generated examples, I think it = would be a good idea to agree about the best way to update the tool. = Until that is done and implemented, I would feel uncomfortable with all = this tweaking, because it will be error-prone and inconsistent. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 14 09:28:31 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407D23A29D4; Mon, 14 Jun 2021 09:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=lJllYHDF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xdZEZ2RK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GnMe5JRP9E9; Mon, 14 Jun 2021 09:28:24 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409983A2A12; Mon, 14 Jun 2021 09:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2834; q=dns/txt; s=iport; t=1623688104; x=1624897704; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=kVHb01ZYcUYGMi51sMznxaQrzAYWGTBpo3fWQz8Ts7Y=; b=lJllYHDFGVIwKgoaLG/PKZoVMc9mjkJvy0ALhFzR/Yn9uo1pqA4FXbml LtKM5rN7oy4zqUBr8Zu5RSXD6YTUdz5Vy1T9G7o33GF70+bLqH8EoOkyr P7rRB4NrrHkPk0QhK5usmIBPfAB8E01PrqHNNeclLH/BlHR/4Koulu4o+ w=; IronPort-PHdr: =?us-ascii?q?A9a23=3A/ykYNxPinivuPiyRVaIl6ncdWUAX0o4cdiYc4?= =?us-ascii?q?ZkjzbNJIeyv/JXnaUrY4/glzFrERp7S5P8Mje3K+7vhVmoN7dfk0jgCfZVAW?= =?us-ascii?q?gVDhZAQmAotU8eOCkm9Lfm5JyA/Fd5JAVli+XzzOENJGcH4MlvVpHD67TMbF?= =?us-ascii?q?hjlcwRvIeGgEY/JhMPx3Oe3qPXu?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AnPzPCqp/fA+Q65fnp47F3FwaV5utL9V00z?= =?us-ascii?q?EX/kB9WHVpm5Oj9vxGzc506farslkssSkb6Ky90KnpewK6yXcH2/hvAV7EZn?= =?us-ascii?q?imhILIFvAt0WKG+V3d8kLFh5VgPMtbAs1D4b7LfBhHZKTBkXOF+r8bqbHtms?= =?us-ascii?q?3F9ISurUuFDzsaFp2IhD0JbDpzZ3cGPDWucqBJbaZ0iPA3wwaISDAyVICWF3?= =?us-ascii?q?MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWna4j4uFxd0hZsy+2nMlAL0oo?= =?us-ascii?q?+5teug9xPa32jPq7xLhdrazMdZDsDksLlWFtyssHfsWG1SYczEgNkHmpDo1L?= =?us-ascii?q?/sqqiUn/4UBbU215oWRBDsnfKi4Xi67N9k0Q6d9bbRuwqTnSW+fkNhNyKE7r?= =?us-ascii?q?gpLicwLCEbzYxBOetwrhKknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTO?= =?us-ascii?q?IlGfVsRKEkjQto+a07bWnHAUEcYZ5TJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFh?= =?us-ascii?q?PDRkQZoMSa3zVfgXg8liIjtYAit2ZF8Ih4R4hP5uzCPKgtnLZSTtUOZaY4AO?= =?us-ascii?q?saW8O4BmHEXBqJOmOPJlbsEr0BJhv22tPKCXUOlaiXkbkzvdQPcbj6ISZlXF?= =?us-ascii?q?8JCjTT4Je1re92Gzj2MRGAtBrWu7Jj26Q=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAACwgsdg/5xdJa1QCh0BAQEBCQE?= =?us-ascii?q?SAQUFAUCBRAcBCwGBUlEHd1o3MQuIBQOFOYh8A5oYgS4UgREDVAsBAQENAQE?= =?us-ascii?q?wDwIEAQGBGIM4AoJpAiU1CA4CBAEBARIBAQUBAQECAQYEcROFaA2GRQEBAQM?= =?us-ascii?q?BEigGAQE3AQ8CAQgYHhAyJQIEDg0aglCCVQMOIQEOnVgBgToCih94gTSBAYI?= =?us-ascii?q?HAQEGBASFKxiCMQmBOgGCeoJxU4crJxyBSUSBFUOCYD6CYgIBAQEXgRkTGgK?= =?us-ascii?q?DS4IMIoMYBmgvIgEBe2M0lGCmWgmBDAqDHIoPlAASg16LIJZml2qJf5MfhHo?= =?us-ascii?q?CAgICBAUCDgEBBoFWAjeBWXAVO4JpCUcXAg6OHwwWg06CZIIwhUpzAgEBNAI?= =?us-ascii?q?GCgEBAwl8h10BgRABAQ?= X-IronPort-AV: E=Sophos;i="5.83,273,1616457600"; d="scan'208";a="902119425" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jun 2021 16:28:22 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 15EGSMSI024203 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Jun 2021 16:28:22 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Mon, 14 Jun 2021 11:28:22 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 14 Jun 2021 12:28:21 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Mon, 14 Jun 2021 12:28:21 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BfPmc3l0gMWKUmfJe+/sNMy9P6to+s9T7mBhea39viKoyAJ3vxEeQ1dGkx1aJuo6bTgaEYEemNGSgPb0tlcutaTLOnn9TwTWWXljXvtTAYNQ1254QfvZ+bddK9j+i/rr4a34tFZUNhaFA/TlmQQ+4xcA6XP3raKvQbppgt2E8HBzT+KFrywJrqCa/FAD6/kjzCGrVX4jtnJjIYC17ds+Kt8NEfASXnShBCzAQkS4OOFktHifkmBDKtjkb3/7KlMMQZGAs3zzu7WgUTnRm+pQ7vhvFaDqPH1z2rzRzmmLUCwY5BSKgP0mzezfosRNF7wuxxz/KWuXAqDOosL2iijDBQ== 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=V7LYk1YcIPXGEQyMBnNMCPl9+YJmLst8vxqP+drE1fw=; b=IWuevnleW0Km1ANJlvXqLlBXqE9gMUZng/GgQZEIR8nM73B93UQ4tjH9wP4iWopTuy+E9ZL6TSJr8hRWYhh9ioVqf6luJQQSvwBsHc0J1SkEpXFxow+K8B3MDLDsXbk/ece3UL75vIlqD3O6bodhtJuC8XcHpFfVbrKQGGcEf94AiRm3H67ZekQVwSGA5GliVvx5+D+RRUNb9xI4fkmuYBNGRyDt+v9MyKTqgV1g4+H+F/0m8LJVVxMzsdAuwjF4N9QunRuDqfuiPqIl+gwaNfV8O+mw5wqab9Q2vQd5zBxtjrRmQssVaz4jz83CX4W45leNngwqfUXbJWj/fJctyQ== 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=V7LYk1YcIPXGEQyMBnNMCPl9+YJmLst8vxqP+drE1fw=; b=xdZEZ2RKNCsMF8wyy1T7CCxWnhEWLQbSTBvhmzS2/pN10xbcCb1tMhJfORvUa2hJa9g5gSfUuUig5FnB1l9wswzPdw1HBi0PYErHU/F1HX8e3cFWdSQKW+N6oBVhzGL27O2uePZeXlekNyrWWt9cHM9v5XzpRyCqwUDngOvj/fQ= Received: from BL3PR11MB5681.namprd11.prod.outlook.com (2603:10b6:208:33c::10) by MN2PR11MB4461.namprd11.prod.outlook.com (2603:10b6:208:192::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.24; Mon, 14 Jun 2021 16:28:20 +0000 Received: from BL3PR11MB5681.namprd11.prod.outlook.com ([fe80::2099:b812:527e:8cee]) by BL3PR11MB5681.namprd11.prod.outlook.com ([fe80::2099:b812:527e:8cee%4]) with mapi id 15.20.4219.025; Mon, 14 Jun 2021 16:28:20 +0000 From: "Joe Clarke (jclarke)" To: Ivaylo Petrov CC: "yang-doctors@ietf.org" , "draft-ietf-core-yang-cbor.all@ietf.org" , Last Call , core , "ivaylopetrov@google.com" Thread-Topic: [core] Yangdoctors last call review of draft-ietf-core-yang-cbor-15 Thread-Index: AQHXYRMbcEoV7cO2t0maBKvPSxqzRg== Date: Mon, 14 Jun 2021 16:28:20 +0000 Message-ID: References: <161592338136.13562.2421108714318351834@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ackl.io; dkim=none (message not signed) header.d=none;ackl.io; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d1f65b86-b3bd-45cc-e700-08d92f516c31 x-ms-traffictypediagnostic: MN2PR11MB4461: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jz8tYmMOebvE2CE/lZExmnYsa76hwYU3L/oMuOZzaz0ZurgRxQysBO0LeinIeeCXRRPbZYK/hYPHjHEaNkOhya5+HzCUf2uQ6KTHcf7uns518uqdx75dVb29rWSB8nC/fJ26uz7qQRAeKz8KzrJEChxlg+LlWEshOhzNxunQZ3IEHxiGnbyQtujwKlovGSBLenqi3r40v6ZsNZXesAHaXvUqAG5F+8nodgliLjzNOtVV9cmGg3vCgD8sD++5gVT9DkSwBRU6P6otcJCrqDSpEXNH+toybNXCe4OZizV9AUYIYwizmcMDvZgkE5TDYriszJNoihT7oLvFRos0t9c2tJHsqOz51uxrSSYxcuRUqd2wtCmzaN28ekgwkcc+JFXE2IFyzmga7SGvchlBZuOCdn0+8eObfINBQzNKxID1Bwf7vePrDKFV8wmEsjwDWO5On5cJshlGgoU1US0dSPJV+m9cU76E5qjKJwOlgWlmE4w+OVAavRAYCHXXmPu5YAIm17x167GrNqf7FozN7qLM0SvqW1Si/XgZfFQsuRIpufnfcSc8MM01gNXRrzgsuFLdmkPKH4uWO9DzlUIsaDLs+svqzP7BoVy45LxZr/8wrLxheY3OSiCTFRqc0jZiieXgdsPArPQV5nWFOPt/kZtXhUfEHPpUzMN3HQrkW/JlJV/orwjPyp+rhCme4xFpMB0Sp2EEX2ZF9dYK6tdR3pWFPw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL3PR11MB5681.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(39860400002)(346002)(376002)(136003)(966005)(8936002)(7696005)(8676002)(53546011)(6916009)(478600001)(6506007)(9686003)(4326008)(54906003)(5660300002)(55016002)(83380400001)(186003)(71200400001)(316002)(122000001)(86362001)(66446008)(64756008)(66556008)(66476007)(2906002)(38100700002)(52536014)(33656002)(66946007)(26005)(76116006)(91956017); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?PXNp7uQNkve4ANG1W1QNTWBpGMSdSygOzBQL5/YhAiXcdOWV5pzXAuoMmS6y?= =?us-ascii?Q?bNxMPjTXkNXZsfitH+bNhs3eKfZMzUcTdad8hz+Qc5WHynORT3VCZhurU6eJ?= =?us-ascii?Q?VrWoKpxMrecKUYAbf/wpBdOXiQwU1P4QOkslN8aIlOfnB4wNSwnaCp8Ezb9Z?= =?us-ascii?Q?igxWTvHifN0M+F2+k2eLvFT/1Qu3T6KMzXyiSeZZS9HIG+x4KT9AXvJiKcbK?= =?us-ascii?Q?URNhfyI4O47U+BT1oN5C4hs8msepGHTK2X4Wapm9LL64u9wGfb6PxHp1RJbU?= =?us-ascii?Q?UoA72jsTCqqlQuoCmqiZCPaJlLoBNy4sWZuqgXKms04gO029hE5HfcxN5+dj?= =?us-ascii?Q?tN2zqe42d08Jie8CyLXVieKPMIWZHSvzQxDjkS1yoCltaeONOligM3s56HCY?= =?us-ascii?Q?KhalLQ3JLNk9hUwEC7PBXoykt1hD/qYujJPu/bAc4sATM4tChxnb/eIj5PQL?= =?us-ascii?Q?IemZmQJ6jCNy1tBgXJ4KFi46qezqN9F14SKscDX5xp5v2xkQ3Xu7f1zNMB7g?= =?us-ascii?Q?/oHv4kAqNlX+PgRzg+KzaCYZhNjkvLHhimatOVWeRwZ2wIA/gcXYkzk5UWBo?= =?us-ascii?Q?/xIVPYPvdj1BOdckIpAOZ7rwIdINYu0TuU3yV34W4rhw43P6Xh/8GPsIL/kC?= =?us-ascii?Q?Mh+Mom0jJnun44i7uC2Y6HXQ5NzCpvjPRH6bt5OKUBwXBcAUDmJOkGhx0MrA?= =?us-ascii?Q?1hlgNF2YZvtdbnPqp9ZeB0wOW3/pdnSmp+LfBLfhFgNLkv5Ja4ZtYNmKLz2b?= =?us-ascii?Q?ihj4+wLRlV+GmJ1tXCDhyzc5zUjzJ8LDqL3p6gWfl9Q29r9evzpDvMY/ph7l?= =?us-ascii?Q?gkJEL1NtGvRT6elfDFiLMbSfCcYd0WKB+jsIvezVGnao9JY7Jt5or+Px0syC?= =?us-ascii?Q?f8hwknqfgALPNUXI9rwi15vpZ8Zs10B033sg96JauAj0r0Ko1j4x1D5C1ANC?= =?us-ascii?Q?GnxY6mcRENhZkCebyJ71n785S/U1xiHU4YwUfCUpa8Jksru0J+12eOTYZNYg?= =?us-ascii?Q?xUzJPhbtnzyrBojOp3eZ5auNd+cjjGzWnZu+ebt9wkPo4BMfkZmn/47X1S04?= =?us-ascii?Q?tRJ6UQWhhkDb63nvWmDx5eP/QM0s4iA3GG+XrNNidPRAH8LOc+wNigZAg4Jh?= =?us-ascii?Q?xAmmX825DPMnYFz5ZXB3tcgDn0O8qxXFQFDwV4IKKrEr4lDi6b0HRfq0CMQ4?= =?us-ascii?Q?mtLRRubYuJxsMahiY0GcXoFyLYtq2XHdH/BqhKg6OayKW2ezYZK9pIthGZjO?= =?us-ascii?Q?OFhrpyJKEgzY4ESgl2SLgkRwtVpMh21dNSI6WwRbVTOA6evT0zwQMntl+w+E?= =?us-ascii?Q?GH/EmU+dik0aBYhdaUp7QiZW?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL3PR11MB5681.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d1f65b86-b3bd-45cc-e700-08d92f516c31 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2021 16:28:20.2308 (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: bSBqcIelW5XAhAdzQb8an3L+s/QLfin/TNxOgBNBk/w2wqNykHgXay+Uy2BkS4Bf22a5qalQkDUwTljX2qAqIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4461 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [core] Yangdoctors last call review of draft-ietf-core-yang-cbor-15 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 16:28:29 -0000 On 6/14/21 07:47, Ivaylo Petrov wrote:=0A= > Hello Joe,=0A= >=0A= > Thank you for your review and apologies for the delay! Please find our=0A= > answers to your questions below. The diff with -15 is available here=0A= > [1]. The updated version is available as txt [2] and as html [3].=0A= >=0A= > Thanks,=0A= > Ivaylo=0A= >=0A= > [1]: https://tools.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-yang-cbor&url2= =3Dhttp://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest.txt= =0A= > [2]: https://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-latest= .txt=0A= > [3]: https://core-wg.github.io/yang-cbor/draft-ietf-core-yang-cbor-lates= t.html=0A= =0A= Thanks, Ivaylo. I'll look through the diffs, but it sounds like you=0A= addressed all of my comments.=0A= =0A= >> Section 4.4.1=0A= >>=0A= >> I think documenting the true/false value of the primitives here (noted i= n the=0A= >> CBOR encoding) would aid in clarity. For example, "primitive(20) [false= ]".=0A= > [IP]: I am not against that, I am only concerned if that would be=0A= > readable for others that are used to the diagnostic notation,=0A= > otherwise I am fine to apply this change.=0A= =0A= Sounds like Carsten addressed this in a follow-up. I think his response=0A= is reasonable whereby manual effort is removed in favor of an update=0A= toolchain.=0A= =0A= >=0A= >> =3D=3D=3D=0A= >>=0A= >> Section 4.5.1=0A= >>=0A= >> I'm being pedantic here, but ahead of the { 60123 : { ... example, you u= sually=0A= >> state "CBOR diagnostic output". You don't here, though. I think you sh= ould=0A= >> add it.=0A= > [IP]: I might be misunderstanding the point, but it appears to me that=0A= > there is such a note already, only it unfortunately appeared at the=0A= > top of the previous page in the txt version and was quite easy to=0A= > miss.=0A= =0A= Yep. Sorry. Those darn page breaks...=0A= =0A= >> =3D=3D=3D=0A= >>=0A= >> Section 6.13.1=0A= >>=0A= >> It isn't clear to me how a YANG list with multiple keys or a YANG list w= ith no=0A= >> keys would be encoded in CBOR. I think examples and some clarifying tex= t would=0A= >> help.=0A= > [IP]: I have modified one of the examples so that it uses two keys. As=0A= > for the other point, Is it possible to have a list with no keys being=0A= > referenced through an instance-identifier? My understanding is that=0A= > this is not possible, but I might be wrong. If it is not possible, we=0A= > will only need to clarify this in the text. If it is possible, can we=0A= > use the position in the list to identify the element?=0A= =0A= I'm referring to something like the last example in Section 9.13.4 of=0A= RFC 7950 for an i-i for a list entry without keys. In this case, a=0A= numeric identifier is used.=0A= =0A= Joe=0A= =0A= From nobody Mon Jun 21 06:49:52 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892CB3A101E for ; Mon, 21 Jun 2021 06:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKMA0OG3wF0s for ; Mon, 21 Jun 2021 06:49:46 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2052.outbound.protection.outlook.com [40.107.20.52]) (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 DF3BB3A101C for ; Mon, 21 Jun 2021 06:49:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jeUMaKmqUno1+t+tBLK9zXluC8IJ0mj9IYHEJY7A2dh1j8156x2DKl23278jRdnaIjESmCwiAccC/Y9jy12KeI9WO4439N6uQsWNZw72RlszlGbB4ojE3cVvkVj6ll+SgpvPSNyLZV9amZilbTMn2h51GFcPlZuvQrkuYhXIjk2shE/tBuaBL+a65aP+5j6DRDga+QDPGR07DroZ20rCQ6wSPErPT/HUIKDYrHhgorQj1hZ3joRGDqu61GeIooZPsLcssGFfE0UN1Wl9et1/Iv/rLGLZTI8/KE7qv/qt3HplTckY9UXNr1jUNRTtqpMhEH0JI1Bjg91xqTlmw1Tg+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AhaKbXRDBFH5W2XyhwHQoqDYkDT33799v2q5aHakf6A=; b=ezIrs9mMxn0+gKB8apeQ/95/1cXf22RmyUov86TWkOpRAxaePIQ8B9VZ0bJ+HFBpMTT2X52W/9THVrVCKd0I4MbK94B8+N8tWdAqXXBkfhK2bpDBJ6qSI0DSFtRMejeVWo28zSy2R3rVPFyAUtREx/3h5uIU3ZlRewvm8ZBifTnpfGMMFzw3xAFmfiuJev5FlEBXcJuXh4YVT8msucquBrjKh35AIhW+vMLCpjB3M1mJ0Mt/bDpsKWeuGa07f4q8kG/GZhFA6CwwsStl0eXLs/dWY9P10dwP103GhdAduEPe0Xts+P9OinIyXw4x3jpJBKSba41BzYFGuiBDfGgGfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AhaKbXRDBFH5W2XyhwHQoqDYkDT33799v2q5aHakf6A=; b=KEgaK+8sz1qXWuFXoEpgPkLBybJFjfHbcRdgKHm8EaXNZhRbiAVf6cB4w1KXwwKCI/ad6rIbnljOWo/sYZUK5gJwYtEvSXe5mg+BRiOZZgT/BxLdndeN4FbZ1n+EQjYLffw1jrX0Xju/32wpUcSPPmjVRW7Bubb0PmIKkMxjL5w= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB1029.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:164::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.18; Mon, 21 Jun 2021 13:49:42 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6%9]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 13:49:42 +0000 To: "core@ietf.org WG (core@ietf.org)" From: Marco Tiloca Message-ID: Date: Mon, 21 Jun 2021 15:49:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9i29vaf4xJk6NJuF1dIM8la5b9K62cMnG" X-Originating-IP: [195.181.166.75] X-ClientProxiedBy: HE1PR09CA0057.eurprd09.prod.outlook.com (2603:10a6:7:3c::25) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.3] (195.181.166.75) by HE1PR09CA0057.eurprd09.prod.outlook.com (2603:10a6:7:3c::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19 via Frontend Transport; Mon, 21 Jun 2021 13:49:42 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 11d09443-201d-460a-14d7-08d934bb6bf1 X-MS-TrafficTypeDiagnostic: DB8P189MB1029: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:1360; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zoNp9PdBQAfzcGPSlx1SWXq2TUAqmnylwY/wCT5ehzY/GE4APep8FwrYoZVm79rSruguYygwk1mjfvwX8IpL8GILC+fb0kew9sb2nx2F2wUjjQs2Wxn6vFWYEqHhj4ERC1iphyAuTXbjTMp6uWplkSwVzBYp2KlIgOWh3J/wDVKOJ7e9U4dmNkHpnYGtqjyKLjP6oyxgb/3KjkHn5z3uvhWOXg0LJqifdI6iEvzVy7mf+wB1mgdoDGvr/89glf0+Eh88Oac+XOUPhx4cyRUnOEkTFMtCcp1OZvRnyebV4HK67cRTQpC9DrvqAd4ivSdyeK7fAOFn+3n7ktKVesDW27CXFYQnrkcId8J11B4U9ypfqoimjX5i4UiIEDboy/Z4XZHO4+fU7WGtA9OZeDJmz5ORRQ+H3CxhnU9yh2G2BuB1Jzi1KJq4y6UF7xhxocmlPa9K3VEUpOfg3B+byrqomaHsEFEkqd3bNN/z+0WgQTkKOY0raZaA7jj4jVjDlaBufGnQj0ke7L4EPXW2bzctx45ZjOnoTvQPDfT0nCvno7ymZvpGLGtVlL+ZNLTEAlOpJQnocBOQRm8Rn6XJ+tze9MKfSOpazeP87+ZMp7mWTVhvnhkdF7DNll7IKVOfoohyGu1PWE+YT6CFyRvhMVj4Rko8EOoEyNYx5P9avZM4Rcy4x6X7Knaz7HV2QjNsOLk1RQ+T8e1U696RaBwl8a7NRPnYx6CwNGXaSvl96fnx1FBoxk1RqXRET3py7xeL+qJNUAFGtGytZm3JNuMuNt4Upb9fi8fxX2VLBLsOiA20AdM= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(376002)(39850400004)(346002)(8936002)(16576012)(966005)(956004)(86362001)(2616005)(21480400003)(33964004)(31696002)(235185007)(316002)(186003)(16526019)(5660300002)(26005)(83380400001)(8676002)(478600001)(66574015)(66946007)(44832011)(66556008)(6916009)(6486002)(38100700002)(31686004)(2906002)(36756003)(66476007)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SHdRMG9WdkxyQWRTYnlMUHdYTnhqVytaVTI4T3EySmtKQ0ZuVEtERlNiT3lW?= =?utf-8?B?S1M2SUpBNllqR2NoQk9NNnJzVlVMUDMyYnh4TjdkQjhJbm00TGlscS9TTlla?= =?utf-8?B?RVVyRUxnQVJSaDRnQnBmL2R0bEtFWDZlc0VQZWNEak1aazd2c0ZtbTByWUxs?= =?utf-8?B?aGQwRDIzM1EyL0locUJnTTdBTTBiNitpMEQ5cHFZSUIrcWpQczVjYXQySzhH?= =?utf-8?B?enJDREMrcHYxRmlta05paExIanErYWdyR2U5L2VPOFNYWmUxWVg4NWRBWVpL?= =?utf-8?B?VnRRQ3ZUdWIwOU5TL2l0TEVEbHhQVzdvdGFMSHBNNWU0US8yUmZxV2NxNlpF?= =?utf-8?B?WitqWUhhYytDbEwzajJyT0dtY3dieXZyL2ZVV3NNYU54VCtEdlhPWVZrWEZ6?= =?utf-8?B?bG5MNXZXYnpoLzJrUlhHUXRvWjFhQWQxTnJLemtkcGs4UkkxNlhKcEVQWVV5?= =?utf-8?B?UzFCd3JDMGhXN0NHbytIRktUZnA3M1dQTHNxV3F1clBvTTQrS1BrbXgrcGZI?= =?utf-8?B?b3kzYlFzNFJtbGJoVTNPUWczd1ZaZFBNaEZJaDNlVXZXS2t4WDhRUzFGZG1C?= =?utf-8?B?LzZhOUVUazVudGtrSXFYMEt5Z2xCY2pMNHBSdW94ZnB1cHAvSFZCZmEvRkQv?= =?utf-8?B?OGdraWl0YnZpdFZlRHNqSFRWNWl0L0FPSGdtVXZrdTA5Y25rYlNUSUNUam9M?= =?utf-8?B?dHgvOVYwUlRuSUFaajM3ZmRuN1BIMFZqMkdvWU1XTUlDMmZnQzFzSDFuM2ZS?= =?utf-8?B?cVI2Nit0Z3hFN3I0TUNYdmgwRnBEVkdBMjF2RmQvRlJ1R2pYMjJWNjYrazhY?= =?utf-8?B?N3Fyek1rcExiN0dIeWJXQ3VqcE5XT3BVRUtXRFNlT25lbWtBUkplQzBZS1RB?= =?utf-8?B?T2FockgrS3FKV2lZdXZkdk92Z2dCRGZWMm84MWN2OFg1SWJLYWYrMDJJUGlk?= =?utf-8?B?aHZvQzhKdk5oWWZ2eXdtWlJPcW5ES0hudWhxV29jY1lKKy80WDNwT29hdlVn?= =?utf-8?B?V0swYkpjZ0s1ak1nNlZTbm9ldXdCTTRacEh1RSsvNEZ6MFBFZTk0N1JjdG9B?= =?utf-8?B?OUhqU3VjeUxFMS9OZVBmZWExK0ptbXBpRjAyYmhhemFDOXpWSjJjMS9NR01L?= =?utf-8?B?NzB0QndTR0hZUHRSVzNNTGJLLzFOc1N1aWpDYkxZVXlTWWRZUWtJU0Z0dGVU?= =?utf-8?B?NWU5RHU3RjFZRXRsUDA2c25Mc3BYWjlGNXRuOHNHcXliR3lFRi9mcXphUHZx?= =?utf-8?B?aC9NK0lyWS9xT1hieGZDaFV6OUM2RGliM0Y3ZldEUXdpRUJLYVI3QXFJWm5k?= =?utf-8?B?VnZETkVoOXUrU1ovMDh4SS9xbVRuYWhTaThHcDgxa3RESXdNdHVRbEJPZnN3?= =?utf-8?B?L3g4UTNkVVM1TlJsNGhvb2lUNy96OXJ1RjU0U2xvSXRtSjhEVDBOdHd2VWky?= =?utf-8?B?Sm1VTWlUQWd2RDMrYWtnVUxYRHg5djA1dE4xUGExb3d0TElTTEt3emxMVnpm?= =?utf-8?B?cjkrNGZyY3pIVjhRVlJLOHJ4QzJaRnFWS0trYkdtV3VoUG8yS1hFbjVqSXlJ?= =?utf-8?B?MnRJaFdocnE0endkekg5NEF4Mk1YWTJOSXEvRXFXdDd5ZVkxY0JSUlcyQ1I1?= =?utf-8?B?OWJqS3FxMzhycXFXcTdtcmZjTkp0NWRwWmNna1JydjJ0TjlTNTFCQktvSUhH?= =?utf-8?B?aU5LR1MxUE5meUdENTF4Y204aFp3M2VmS2g1WUJ2YVRCam8veDEzck45aits?= =?utf-8?Q?9qHJc7R2ZnsDrih1VfRuBudZx848Boc19G7Bz52?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 11d09443-201d-460a-14d7-08d934bb6bf1 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2021 13:49:42.7123 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: AZJCc2fLm6qSUiqwXXciR1HkHK2kZ2NHs4Crq3coIX2yxH5jzcXIYvoXNSxsuSL1RTXgSgHtlYm1tyVOtsDRYg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1029 Archived-At: Subject: [core] CoRE WG Virtual Interim 2021-06-23 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 13:49:51 -0000 --9i29vaf4xJk6NJuF1dIM8la5b9K62cMnG Content-Type: multipart/mixed; boundary="qXnAmNShi7Cmgpmz4u44iNJvgTwHtP4Ml"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: [core] CoRE WG Virtual Interim 2021-06-23 --qXnAmNShi7Cmgpmz4u44iNJvgTwHtP4Ml Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we'll have a virtual interim meeting on Wednesday,=20 June 23rd at 14:00 UTC. The agenda and other pointers are available at [1]. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-08/session/cor= e --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --qXnAmNShi7Cmgpmz4u44iNJvgTwHtP4Ml-- --9i29vaf4xJk6NJuF1dIM8la5b9K62cMnG Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmDQmPQFAwAAAAAACgkQ7iZktA5Y2kOz 0wf+NrvdGeYgq/01qoECEaU+Vp55S6dnEi2lzL0ZcUOD4K4uOgXgb8lcm3cVw52+EAt/EpBER/P1 pMKSqGOefC6LnFZJ/gkBHi5S7LDh6UfoeU3FV6naN9CHSDP2+DKgVeqjDsZv0WMPeTOin8Ncq1oD WuE8CLTvjuKXZ6Ym/N6f5UNcqUClJZdpJqSItECNsYkxE391dWIdMiuUVKuiXQm0q9/08cHfrVad 7zCT+OpX8+FifX89GyUxR5SFObkwdz3qSl7+hvIJYGZM5sd7UVHGJoP5n60VD80FLeGn1koFefGy WjwLAFon7h6BRRk9r8N2D1za7IqCkaZALHBxs2bMIQ== =rN+n -----END PGP SIGNATURE----- --9i29vaf4xJk6NJuF1dIM8la5b9K62cMnG-- From nobody Wed Jun 23 04:42:55 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0153A34E6 for ; Wed, 23 Jun 2021 04:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_FAIL=0.001, SPF_HELO_NONE=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 abNTwIr9XZ4M for ; Wed, 23 Jun 2021 04:42:51 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9164B3A34E3 for ; Wed, 23 Jun 2021 04:42:51 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4G91bS0RMzz334M; Wed, 23 Jun 2021 13:42:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <162041037568.22240.16248531622206492564@ietfa.amsl.com> Date: Wed, 23 Jun 2021 13:42:43 +0200 X-Mao-Original-Outgoing-Id: 646141363.652259-3bdd32442167a4184e9620cf834d18f9 Content-Transfer-Encoding: quoted-printable Message-Id: <61FD490D-81D8-44B0-824D-C3CD02A6DFB1@tzi.org> References: <162041037568.22240.16248531622206492564@ietfa.amsl.com> To: core X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] CoRAL href (CRI): simplicity vs. compactness? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 11:42:54 -0000 (Please read this in a monospaced font.) href-04 has the optimized href syntax that we worked out with Jim Schaad = and further optimized recently, which can be summarized as: CRI-Reference =3D [ ((?scheme, ?authority)=20 // discard), *path-segment, ? ((null, fragment) ; no query section, but fragment //([+query-segment], ?fragment)) ; present query section has >0 = items ] This is so efficient because relative URI-references such as /a are = extremely short, with the CRI reference. [=E2=80=9Ca=E2=80=9D] On the other hand, quite some juggling is needed to translate a URI/URI = reference into this format. The weirdness that kept us thinking was that the path doesn=E2=80=99t = have its own delimiters, so the presence or absence of a path needs to = be inferred from other information, here the discard value. If the = discard is absent, there is always a path; only if discard is present, = there can be an absent path! This, together with the RFC 3986 rule to suppress a leading empty path = segment, leads to the following translations of URI references info CRI = references (*): / [] /a ["a"] /a/b ["a", "b"] /a/b?foo ["a", "b", ["foo"]] a [1, "a"] . [1]n.. [2] ../a [2, "a"] ../a?foo [2, "a", ["foo"]] ../.. [3] a?foo [1, "a", ["foo"]] ?foo [0, ["foo"]] #bar [0, null, "bar"] [0] (Yes, that is the empty URI reference at the end.) Most of the weirdness is inherited from RFC 3986. Internally, my code uses [scheme, [host, port], discard, path, query, fragment] where most items can be null. So I have code that translates between the internal and the external = form, and that is full of if statements. We could, instead, decide that we want to use something like the = internal form for transfer as well. We would replace absent items by nulls (or leave them off the end). So this would lead to something like: / [] 0 [] /a ["a"] 4 [null, null, null, ["a"]] /a/b ["a", "b"] 4 [null, null, null, ["a", "b"]] /a/b?foo ["a", "b", ["foo"]] 4 [null, null, null, ["a", "b"], = ["foo"]] a [1, "a"] 3 [null, null, 1, ["a"]] . [1] 2 [null, null, 1] .. [2] 2 [null, null, 2] ../a [2, "a"] 3 [null, null, 2, ["a"]] ../a?foo [2, "a", ["foo"]] 3 [null, null, 2, ["a"], ["foo"]] ../.. [3] 2 [null, null, 2] a?foo [1, "a", ["foo"]] 3 [null, null, 1, ["a"], ["foo"]] ?foo [0, ["foo"]] 3 [null, null, 0, null, ["foo"]] #bar [0, null, "bar"] 3 [null, null, 0, null, null, "bar"] [0] 2 [null, null, 0] The third column is the number of wasted bytes, which (apart from the = outlier =E2=80=9C/=E2=80=9C) ranges from 2 to 4 bytes. Simplicity vs. saving these 2 to 4 bytes for relative CRI references? Maybe one simple tweak (**) can reduce this to 0 to 2 bytes. But how important are relative references? Let=E2=80=99s discuss in 160 minutes. Gr=C3=BC=C3=9Fe, Carsten (*) I typed these by hand and apologize for the many errors likely to be = in there=E2=80=A6 (**) Something about leaving out the first two nulls; probably needs a = separate discard value (true?) for discard all. Exercise left to the = reader=E2=80=A6 From nobody Wed Jun 23 04:58:47 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B13D3A3539 for ; Wed, 23 Jun 2021 04:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjtznnVEpjIx for ; Wed, 23 Jun 2021 04:58:40 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50057.outbound.protection.outlook.com [40.107.5.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 D38883A3538 for ; Wed, 23 Jun 2021 04:58:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NcGgjDeKoL+HjFTXkFFnI56k4I4eKw23Ktdh2jzUBAxqaIHIGa4r/BXZXh/W128bmL4J4c9XidTMwz7HzeEVChC3ZKiU8ZQJyQJGu7GbHgZwMTecG4PPYxIO5S08ohngRPDxJolxJ4JyzIMtdjE+/y82rAmXeh7OASs/8oSEnwmJWZUVSJh+vhh06+pg9WhZ15y+FQxzoLEfMo5grsbq29gvuHYzwbCYIO4NsD1yNf+gwPHJ8tzVeOgKohvq+4me8G6xVMmi02FM5WB9dD2QaAY+9UDwvEgWnFmzfzCp+9cXdONbYN+oKdnoiO+BwNAnU7MHqnxnoTWnyYUic6SdbQ== 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=wq9ZF0MmrFDDOUmARZeOu1HqTFvbgetOgRZmYwKkhPk=; b=MlgPivelgQq0srn0Hdw1hTC4JXEpfLWzCqPVtKKD4DpstmUwqw3eR/nMJWjxPeaREaib3ND1MKOULCn7cXHosaZUty4RXuWGe2QnxEKHVUg0I2jyNyoVcJZ9T1aM/gfhuOcPobB7YhTkqL7FHSsncCVvKZrXhiCRE0ih5h7NS9Aj5qLgtxcHqcqMo1Lf2iMZejP/k3F8FIUYAMS5waARCcgdiWYRYPMNGAe7IQaSgqQ5hHD+HGX1Agba8U8KThNUkol8N/NLMzdyScWLuE0KaJ7HEr2bSm0HT7OsO7S2jsMYwdaCQeCEseMfGKWJ73K12tIrCix/UENAqTkIWFKwow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wq9ZF0MmrFDDOUmARZeOu1HqTFvbgetOgRZmYwKkhPk=; b=aS+rFDLj9gVGdL7cgH2h7WGykyRIW1GAdU+Fbq8xKYYE1oTDX4LE/3nZO04iDyP1NfCiY8xkiDM2phuqohPe41eLmjFCZTy2YLNdJ/Pj8rb9QpYnt+TNH2qOug1ANVd1GfBPL3BlgK9QLRs6eadtBVC2vJd+8Pxv9sKqDKKG4iA= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0887.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:169::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Wed, 23 Jun 2021 11:58:37 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::1913:bcf7:e20a:a4e6%9]) with mapi id 15.20.4264.019; Wed, 23 Jun 2021 11:58:37 +0000 From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" References: Message-ID: Date: Wed, 23 Jun 2021 13:58:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EKb70hRhFuXYCt6X94o9MLSp6PgZiYCXe" X-Originating-IP: [185.219.140.60] X-ClientProxiedBy: HE1PR05CA0325.eurprd05.prod.outlook.com (2603:10a6:7:92::20) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.3] (185.219.140.60) by HE1PR05CA0325.eurprd05.prod.outlook.com (2603:10a6:7:92::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18 via Frontend Transport; Wed, 23 Jun 2021 11:58:36 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 281cd557-8ada-46f9-8186-08d9363e3ba1 X-MS-TrafficTypeDiagnostic: DB8P189MB0887: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2958; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lyx37L4npiUPwypXqdVlKNw35lFNRvHS4Z4z6qcSkcV2fvyS+TyBIlG9/+KId05i7AeWwth4poCsSskzHNwXht4k2NKj1IHBve95ktwTquGtToem2gIlCT5zFawe1Ou+q0ey7+RDEqk7F6Z2fYydeYcMeAtmJCta3GXbTVkNYmPeuoKBIaDKa228848JLQJORkBMM6tT7ydCksFdp2IcPdmWYO9eSpI7RLfsGAWpSsH5lHkviCzZ9ncAgr8kHNwH2VT+F8B9wyDpebGCTn2Aq/rPcNaUBSsufO0X3i9Fkl7OHCcCDroPLhdFabbDeB27pyzl4KPAXlc//XYxx5HggE02Dn4yTn1GqxKmlKG5tjKkmJDE7IBskxQz2BgO7jVxyUWpM/RN3dTArDgOORbukVa477IrzLFLMcQ/bDrBdiDrjwQAz02++0vI3NkPRUq2dNM5raf2Z+HHXITwIYGnVZGVIpiBl45k5zPKdtq1ZZOfDWezS+lQSkV2r9/ZoUhjaK75hHVFf5ClZcSsbKsJg4hBH8gd6PPDGdl03IGwsBeN36C04811a6aBWZx3VEU/ALWJ600FTFKsaVI8bOh0cx5VgvfTWuNmJJO1RK+c74FM3oz+lKNEsvwYeVzk69BHWkle0IK95rOqeVr33JHgeJxABlmT6EqpbH7uL2O2i+2IDpLvJBexNIpimMiF9WSqRAG3C05U9OkJDEBZVVL17mEJqkJ9a1NX3wxNvYRHjva739a7NKlGHeoVmomB4r+/Bpo5UYdxUuTGBvmJcPYZkM9a/bfdJRhWVNfyxVvpcvU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(136003)(39850400004)(346002)(396003)(21480400003)(36756003)(66946007)(956004)(2616005)(66476007)(66556008)(44832011)(8676002)(8936002)(5660300002)(235185007)(86362001)(316002)(16576012)(2906002)(31696002)(31686004)(66574015)(16799955002)(83380400001)(26005)(53546011)(6486002)(33964004)(186003)(38100700002)(16526019)(966005)(478600001)(6916009)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WlJNVm9DUEJ6b1hJdW0rTzZyM3dPV29JV2pnTW9qdnBES0RYOGpRZnNKeEFp?= =?utf-8?B?VnpIR1g3VGhGSUplcEhyMEJQK055Q1orc0lDSk9MQmQydjVRakxybXBJZlhm?= =?utf-8?B?SjdqVEdoZUFKV2Z0OTByb2pFUUQ3UjVYSVlwRGo3RjhJM2NTeDc1enJXdXA3?= =?utf-8?B?ai8xelorY1lHZmFsOXROTHgyWS9LK3Q1cEo0WDVvdnVvZE9PYW0wZmllcW9W?= =?utf-8?B?bTh4dml6b3pQN3N6MmF5d2JYNWFBSE4rcWtmck1nd0t6ZjhSS3dsNnIzV3Rx?= =?utf-8?B?Q0JidXA0VzN2V2Vpa1RiREw3UXhNcGlJaC96M1B2akpyRVBteUJxSE9zbzhl?= =?utf-8?B?eXloNVlQb25kVnpFRnpIOG0yRlpuTU9rQ2k2T3FzSnJXcUlqWkg0OTZKRUpP?= =?utf-8?B?cUwzclYwTFRGSUxvZjg4RzY0UkVpRWVxc2g5c0VEbGU1WUV2THRZS3dHTDVH?= =?utf-8?B?UGFsWGx5OWlYS1MzZE9UZlRGSE12bEZxd2pVMUtraEZNbEhzTlc4cmV2N2NS?= =?utf-8?B?SHI0eEtzdkVnNmQrTkd0enJaMnZnS01BTXpUTHVGUG8xOHoyTnUzOTBiZm1U?= =?utf-8?B?dEFPNHZDN1kzZFllanpEZitGaUNya0piaGl6ZTgxZWRsMDhUbzAyR0RDRmZj?= =?utf-8?B?RFdwS1pPZGFRc3BiZFlVd3liVjlweGcyRjhrTWd3Q1lLYXlJeGU1NXV1ajJu?= =?utf-8?B?a2J5YVd5N2k0a2lQS3I4aWRMaTFEZmQyL1lwZkJ6S2tKbllKZzd0T2V2ZjFa?= =?utf-8?B?SDBuNU81RUFVTHozM2tCZkVISWsybEhGLzZLMjkvMGltZHRLREZtd0dsZDRJ?= =?utf-8?B?Z3BkQ2FaRmpKR0pTeEVmc1NadVdTYnhxN3NnbGh0MGFiOG54N2ErZytrM3Q0?= =?utf-8?B?OVhFUXlOemVVUGg4dkRLcVhRWnNHMUtKQW5IcC9hQWNkK2xhSi91NmtHVjRa?= =?utf-8?B?c3Roby8vZk14dEJrQStFSWhFOFBSdGNhOGlvVS95TlRGajZ3TE9WUU5LR09u?= =?utf-8?B?bkZYWEZNNXJhTDBxUDFPWWZsQ3ZjTE1WSGFRbzA4aHU3YVphR3E0cTl2Z3dH?= =?utf-8?B?SE5UZnJWSmFVYmozb1F2cjJ4WXRVaTMxTVNKTUNnKzNZZnJiTWFrTWl6KzUw?= =?utf-8?B?M0p3T1hYZkU3UjFLcG5VR1ErMW44eGFCdGZNTGNaeHhMK0tvZGdWWjBtbGgy?= =?utf-8?B?dlBtS01pdDlPeEVSTVBtS2Q2bDA4eExkUE0zRk9UQk9BVUZFTzUzUUJHcmZs?= =?utf-8?B?M2pSWHJKbzB4UGlkMFBWM0F4Q01SQmNnYmNkKzVpMzhUanh6R2RvVkxCME02?= =?utf-8?B?VkUwTGR4SHF2NVgrSjZBOFZWVHpyS202M0pYUkV0R3ZjejRxSWhsbWhzOEs2?= =?utf-8?B?S0dpYmhnTlVvaFpyNkFqSUJBb0xVVFZseENpR0lXalNpOU9qM21sZjhMcWVi?= =?utf-8?B?c2NiTmplQktHbEpucjVmRnBZOVBWbXhYb2VaOW9taEpiMUFjdEhzRVB6Q1Q1?= =?utf-8?B?UUxOVS9sREpzV0p6MnV2WENSa0FkUHdQT1JqSkZHVnNFcVhiUzZkVzJHME1T?= =?utf-8?B?Q3VmYXRaaGJkWC8wRm1aK2RWYlV4TFB2eVI2akdHaC9tY0MrYkducURrVXNw?= =?utf-8?B?MEVlR1NQWFp5SkNOOFpBR2p3d09oSTgyaHJCU0ZJQ0IxVnBLSllTMHhyRXo3?= =?utf-8?B?NXJ5NHc2eFJwd0gvamhPSW1BSHNqYWJJY3ltNnRVR1FYT3ArL041ZEkzWFlE?= =?utf-8?Q?8VTu7tD803bC5xhG6ep1q626RCz/i1q+Hh+korO?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 281cd557-8ada-46f9-8186-08d9363e3ba1 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2021 11:58:36.9114 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 9xXNW6pHg3+rV+t6JluaMT35vw9zA0uuYRFwE/ozyLPakgkgGpsoauTOb1oQZUr6n0JDwEWzE6bRRYgSP7Rsig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0887 Archived-At: Subject: Re: [core] CoRE WG Virtual Interim 2021-06-23 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 11:58:46 -0000 --EKb70hRhFuXYCt6X94o9MLSp6PgZiYCXe Content-Type: multipart/mixed; boundary="N8fhcsgSTJZgGe6hpDlz82a40zZ4Zs6Kn"; protected-headers="v1" From: Marco Tiloca To: "core@ietf.org WG (core@ietf.org)" Message-ID: Subject: Re: [core] CoRE WG Virtual Interim 2021-06-23 References: In-Reply-To: --N8fhcsgSTJZgGe6hpDlz82a40zZ4Zs6Kn Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear all, Just a reminder that we are having our virtual interim meeting in about=20 2 hours [1]. Please find below the information to join. Best, Marco and Jaime [1] https://datatracker.ietf.org/meeting/interim-2021-core-08/session/cor= e =3D=3D=3D Meeting Information =3D=3D=3D Jabber: core@jabber.ietf.org Etherpad: https://codimd.ietf.org/notes-ietf-interim-2021-core-08-core Meeting link:=20 https://ietf.webex.com/ietf/j.php?MTID=3Dm9a2d53595d20a6faffb464cfee95297= e Meeting number: 185 898 6252 Password: constrained More ways to join Join by video system Dial 1858986252@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in number (US/Canada) Access code: 185 898 6252 On 2021-06-21 15:49, Marco Tiloca wrote: > Dear all, > > Just a reminder that we'll have a virtual interim meeting on=20 > Wednesday, June 23rd at 14:00 UTC. > > The agenda and other pointers are available at [1]. > > Best, > Marco and Jaime > > [1]=20 > https://datatracker.ietf.org/meeting/interim-2021-core-08/session/core > --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --N8fhcsgSTJZgGe6hpDlz82a40zZ4Zs6Kn-- --EKb70hRhFuXYCt6X94o9MLSp6PgZiYCXe Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmDTIeoFAwAAAAAACgkQ7iZktA5Y2kN5 RAgAno+gZClhxtFH5izgG7NWY2rqka1Gla+jBXrHr6EQ2n7sCDg9FN+Od/DmqOqxrYq3RRFPX45f Wzz9ntV38CSkSk8nZcTd0265dfO9b57QgIvKkKqCSYfT5QXgdDvWHItFgTbvlX9Bcos6C/WqTYGN 8JPzyNqANHzoirC5QWx8dmwIebJYiTgLNtctNcZlLQBwcrNWWMLs9IXyxtbA8d7l7XH7jHIlG3AJ D2sn8KZDP7Gxk/dLF5lz1059c0FNVOxr+hR6xcSCsSCSHgSucqBj3vhZoCYqGki/ZhvT0xQwVGYB 52ajsf+qBrl+0t+kaK3gjzPBC+KJvURo2Y3fnGsrlA== =07KT -----END PGP SIGNATURE----- --EKb70hRhFuXYCt6X94o9MLSp6PgZiYCXe-- From nobody Thu Jun 24 12:15:04 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E77D3A27F5; Thu, 24 Jun 2021 12:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zyrkn1vGMaqi; Thu, 24 Jun 2021 12:14:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F5A3A28D7; Thu, 24 Jun 2021 12:14:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EA37038BAD; Thu, 24 Jun 2021 15:16:21 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id umpEeHiBq0DK; Thu, 24 Jun 2021 15:16:20 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E157138B34; Thu, 24 Jun 2021 15:16:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6336763B; Thu, 24 Jun 2021 15:14:35 -0400 (EDT) From: Michael Richardson To: Qin Wu , netconf@ietf.org CC: core@ietf.org In-Reply-To: <5ba27e43a63e427091f3093b35be09a0@huawei.com> References: <5ba27e43a63e427091f3093b35be09a0@huawei.com> 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: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 19:15:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I read: Title : Adaptive Subscription to YANG Notification Filename : draft-wang-netconf-adaptive-subscription-05.txt today. I understand the need for some kind of way to switch between some kind of periodic capture of value vs a edge-triggered/on-change proces= s. I'm a bit surprised that the example-wifi-mac module had to be created in t= he appendix to provide an example. Surely we should already have likely modules that are really being used and need this kind of thing. So one recommendation is that the document focus on already published YANG models that could benefit from this kind of subscription. (Perhaps the wifi-mac module is something that also needs to exist, and does not. I will note that CHIP/MATTER has some kind of WIFI statistics module, but it's not presently written up in YANG) I had to back to RFC8641, which I don't know well at all, to be sure I understood the xpath criteria. I guess I don't understand how RFC8641 and this document can be used for non-XML serialized YANG interactions. If bandwidth is at a premium, wouldn't you want to use draft-ietf-core-comi= -11 (YANG in CBOR) rather than XML? At which point, the obvious interaction with RFC7641 would need to be explained? It seems that the netconf (RESTCONF) and CORECONF groups should spend some more time together. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =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+93Q3WUFAmDU2ZsACgkQgItw+93Q 3WU8LAgAjHxRTmDPiPyC9s4HNzQxyn2Fy11UwrUoSDQmv7QtvgUXh/LRh/vX5idE 5xmGtpPXglZ+cQ3bVbkGw0JzFdiN7FXcKNBlkC0OOaU4Mt8ZCqO0EgDvl7AK6wBK GxB0ph+da/0l6d6in0Mhp4jVczbCJvbVnsx9vJBUSrumQmRlNwZBlguo7TUHbNLj x+AS6yT1N0f17MlI52UdTxtE4zahK4kKjSP2aKkpBLAoiAcIN6xWfUI6I7RllrVG Rm8dx4vlsg4XOX9ogLb/mTYIPHa5uo9qjrLESFmYH0U8pXVKjRXzm6daIyUFhpX/ 4ui45y/nvC71enXfoCkqTDsriQkAqA== =YBzo -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 24 15:23:00 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7053A2D72; Thu, 24 Jun 2021 15:22:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162457337875.24837.11422050083374725531@ietfa.amsl.com> Date: Thu, 24 Jun 2021 15:22:58 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-yang-cbor-16.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 22:22:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : CBOR Encoding of Data Modeled with YANG Authors : Michel Veillette Ivaylo Petrov Alexander Pelov Carsten Bormann Filename : draft-ietf-core-yang-cbor-16.txt Pages : 47 Date : 2021-06-24 Abstract: This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, action input, action output, notifications and the yang-data extension defined within YANG modules using the Concise Binary Object Representation (CBOR, RFC 8949). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-yang-cbor-16.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-yang-cbor-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 24 15:24:01 2021 Return-Path: X-Original-To: core@ietf.org Delivered-To: core@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAF13A2DA4; Thu, 24 Jun 2021 15:23:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <162457343378.15314.3407973366626537205@ietfa.amsl.com> Date: Thu, 24 Jun 2021 15:23:53 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-sid-16.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 22:23:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments WG of the IETF. Title : YANG Schema Item iDentifier (YANG SID) Authors : Michel Veillette Alexander Pelov Ivaylo Petrov Carsten Bormann Filename : draft-ietf-core-sid-16.txt Pages : 38 Date : 2021-06-24 Abstract: YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items. This document defines the semantics, the registration, and assignment processes of YANG SIDs. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-sid/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-core-sid-16.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 24 17:56:15 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A11C3A31F7 for ; Thu, 24 Jun 2021 17:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXoPn7Pf9Qrg for ; Thu, 24 Jun 2021 17:56:05 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E463A31F8 for ; Thu, 24 Jun 2021 17:56:04 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id d2so10246204ljj.11 for ; Thu, 24 Jun 2021 17:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SQy6StQU3uZn8R/PmCSK5VavK6G+vxD67aEl0yPTPn0=; b=0NAkdvnEcSDjFbUBe9KvbH12nBjWaSBH75x3VSdHB8QXL0UxURI/Kk9TRfvmZBb5nO lGyv7zdusOeJF6iF3Eu24eAxkz2df+IzQqTSEBetIt5t6mw+FXjp2MOGBg1Eq7T/tG57 dCOXKqgbm9iJ3kvrtRe9iPu7R2HcfPcim3aO8xxs5V30Dw1L6zPJUPZniBDreZmGEZhm RSV2MMFvzTPNWyXyHGYNfd7SkTgUpDls5eQu+3Mc5sZVggAjmS5MHwfMPb81qBPna5EG lEgVpkoSwHvwTmrWgA46QKLKp9798tJgigXovMq8J+Z8qZFMWK4Yzk0i7wGhIB2a01Fa kxwQ== 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=SQy6StQU3uZn8R/PmCSK5VavK6G+vxD67aEl0yPTPn0=; b=GJ8jDU4/dWg4A0S85+OZ3p2z8g5vxSM6K5c337hRhgYusAt9hJyeEwrnrsqJbnkHSq 2X79B9geiXBNG5T7RJfQRXF1n8GSgzdwpy/ZuZArjx9v0fciStwHfpOuaehorLb8WGqO D68eSbUZb/uob9hKRhszuHTIc2M+Y5mFaHRv0NuSSfzz5vUZz0D8Jf4+Q/y19xH7FoeO 8l3/QDNvoND8gD/gR6ZnOKuED9Dgg8wL87D0izuavYxAcc2DxAV9OIE0xjsE8k1Tuhy8 g+F2zq1XAPp4s7gyHcYjq5Asm1/lKH8HyVc5JJqusTIoTjSALE3jvn6kqLsScBTw1v4d kVtg== X-Gm-Message-State: AOAM533ArXl93nCufU1glM9ItjcbBBh8iWAj0/BDvhsOGI3s3To4taMx mOLRPQEaXGksrbUm9GY1ku02MDJpMWxDACsdZiybaA== X-Google-Smtp-Source: ABdhPJzS7ZKzmSQ53eVoP56k72vvUm/TjMod//0xu7DCXgroJJHgKUowlwILBIL4EAk5P8uefjBNDaiEuWFpzwqIcRY= X-Received: by 2002:a2e:9297:: with SMTP id d23mr5902837ljh.160.1624582562195; Thu, 24 Jun 2021 17:56:02 -0700 (PDT) MIME-Version: 1.0 References: <5ba27e43a63e427091f3093b35be09a0@huawei.com> <14286.1624562075@localhost> In-Reply-To: <14286.1624562075@localhost> From: Andy Bierman Date: Thu, 24 Jun 2021 17:55:51 -0700 Message-ID: To: Michael Richardson Cc: Qin Wu , Netconf , Core Content-Type: multipart/alternative; boundary="000000000000873f7805c58c9ad8" Archived-At: Subject: Re: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 00:56:11 -0000 --000000000000873f7805c58c9ad8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 24, 2021 at 12:15 PM Michael Richardson wrote: > > I read: > Title : Adaptive Subscription to YANG Notification > Filename : draft-wang-netconf-adaptive-subscription-05.txt > > today. I understand the need for some kind of way to switch between > some kind of periodic capture of value vs a edge-triggered/on-change > process. > > I'm a bit surprised that the example-wifi-mac module had to be created in > the > appendix to provide an example. Surely we should already have likely > modules that are really being used and need this kind of thing. > So one recommendation is that the document focus on already published YAN= G > models that could benefit from this kind of subscription. > (Perhaps the wifi-mac module is something that also needs to exist, and > does > not. I will note that CHIP/MATTER has some kind of WIFI statistics modul= e, > but it's not presently written up in YANG) > > I had to back to RFC8641, which I don't know well at all, to be sure I > understood the xpath criteria. I guess I don't understand how RFC8641 an= d > this document can be used for non-XML serialized YANG interactions. > > If bandwidth is at a premium, wouldn't you want to use > draft-ietf-core-comi-11 > (YANG in CBOR) rather than XML? > At which point, the obvious interaction with RFC7641 would need to be > explained? > > Commenting only on the use of CORECONF, not this draft... IMO CORECONF is for constrained devices, possibly on constrained networks. But if only the network is constrained, then perhaps only CBOR is really needed. E.g., Use RESTCONF and support "application/yang-data+cbor" in the Accept and Content-Type headers. Expect developers to use this media type in creative ways ;-) It seems that the netconf (RESTCONF) and CORECONF groups should spend some > more time together. > I first raised these issues in NETCONF WG in 2013 https://datatracker.ietf.org/doc/html/draft-bierman-netconf-efficiency-exte= nsions-00 There was not then (or is now) much interest in minimizing resources used by NETCONF. The WG rejected other efforts as well https://datatracker.ietf.org/doc/html/draft-mahesh-netconf-binary-encoding-= 00 IMO the WG missed the point of this draft, which was to preserve the massive and expensive investment in the NETCONF application layer already deployed. Just optimize the network traffic and not rewrite any feature code. Andy > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > > > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000873f7805c58c9ad8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 24, 2021 at 12:15 PM Mich= ael Richardson <mcr+ietf@sand= elman.ca> wrote:

I read:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Adaptive Subscription to YANG Notification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-wan= g-netconf-adaptive-subscription-05.txt

today.=C2=A0 I understand the need for some kind of way to switch between some kind of periodic capture of value vs a edge-triggered/on-change proces= s.

I'm a bit surprised that the example-wifi-mac module had to be created = in the
appendix to provide an example.=C2=A0 Surely we should already have likely<= br> modules that are really being used and need this kind of thing.
So one recommendation is that the document focus on already published YANG<= br> models that could benefit from this kind of subscription.
(Perhaps the wifi-mac module is something that also needs to exist, and doe= s
not.=C2=A0 I will note that CHIP/MATTER has some kind of WIFI statistics mo= dule,
but it's not presently written up in YANG)

I had to back to RFC8641, which I don't know well at all, to be sure I<= br> understood the xpath criteria.=C2=A0 I guess I don't understand how RFC= 8641 and
this document can be used for non-XML serialized YANG interactions.

If bandwidth is at a premium, wouldn't you want to use draft-ietf-core-= comi-11
(YANG in CBOR) rather than XML?
At which point, the obvious interaction with RFC7641 would need to be
explained?



Commenting only on the = use of CORECONF, not this draft...
IMO CORECONF is for constraine= d devices, possibly on constrained networks.
But if only the netw= ork is constrained, then perhaps only CBOR is really needed.

=
E.g., Use RESTCONF and support "application/yang-data+cbor&= quot; in the Accept and Content-Type headers.
Expect developers t= o use this media type in creative ways ;-)



It seems that the netconf (RESTCONF) and CORECONF groups should spend some<= br> more time together.

I first raised thes= e issues in NETCONF WG in 2013


IMO the WG missed the point of this draft, which was to preserve the massi= ve and expensive
investment in the NETCONF application layer alre= ady deployed. Just optimize the network traffic
and not rewrite a= ny feature code.


Andy

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [






--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000873f7805c58c9ad8-- From nobody Thu Jun 24 18:05:30 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049653A3278; Thu, 24 Jun 2021 18:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A4XsDMp2Qcl; Thu, 24 Jun 2021 18:05:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B223A3273; Thu, 24 Jun 2021 18:05:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F118338BAD; Thu, 24 Jun 2021 21:07:05 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2YPC9PUeqzBG; Thu, 24 Jun 2021 21:07:03 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BFF013898C; Thu, 24 Jun 2021 21:07:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 571701C6; Thu, 24 Jun 2021 21:05:18 -0400 (EDT) From: Michael Richardson to: Qin Wu , netconf@ietf.org, core@ietf.org In-Reply-To: <14286.1624562075@localhost> References: <5ba27e43a63e427091f3093b35be09a0@huawei.com> <14286.1624562075@localhost> 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: Re: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 01:05:28 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > I had to back to RFC8641, which I don't know well at all, to be sure I > understood the xpath criteria. I guess I don't understand how RFC8641 > and this document can be used for non-XML serialized YANG interaction= s. > If bandwidth is at a premium, wouldn't you want to use > draft-ietf-core-comi-11 (YANG in CBOR) rather than XML? At which > point, the obvious interaction with RFC7641 would need to be explaine= d? > It seems that the netconf (RESTCONF) and CORECONF groups should spend > some more time together. I didn't finish my thought here. Specifically, it seems that the CORE WG is doing a lot of stuff with CoAP Observes and SENML and all sorts of interesting triggers. It seems that there ought to be more common work here. Routers are really the original Things Of Internet. =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+93Q3WUFAmDVK84ACgkQgItw+93Q 3WWbOAf/aRp0QD6u5WY3667mQNqq7si7ue9gkL4OLn3PBQYgrfSM9cdTPrBDbXu0 3zBZMZENvg4KxE/XsBtXCS4wPIT0oDK5dh4oBs3W374nmzm9OufvMOUZTPnn0RQx vjpzaFn9XmNSEGycb+OxFgIGycIGWZ2/ZCspQvewb45XQoWfLQn3JjTHmfZ/D3FX N9CzcTtWAKHTg8HdeGAT+MX89aVaDPAq1z9HvjMNdK0IVTKcr8zr+ixT1M1tAT05 f75aklNp+jEdihZJmzrROkuvEJdfO+Wv+F056na0EEu7+gylyZdiN2COaW+GNkrj j46QREd66bvwSVEFrmPG+Ha/+P4IHw== =QvY9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 25 07:16:31 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F903A19F6; Fri, 25 Jun 2021 07:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_OgDO5fwtIc; Fri, 25 Jun 2021 07:16:24 -0700 (PDT) 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 57E943A19F7; Fri, 25 Jun 2021 07:16:24 -0700 (PDT) Received: from fraeml743-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GBJc74ktdz6L52F; Fri, 25 Jun 2021 22:02:47 +0800 (CST) Received: from dggeml752-chm.china.huawei.com (10.1.199.151) by fraeml743-chm.china.huawei.com (10.206.15.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Fri, 25 Jun 2021 16:16:20 +0200 Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml752-chm.china.huawei.com (10.1.199.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Fri, 25 Jun 2021 22:16:18 +0800 Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2176.012; Fri, 25 Jun 2021 22:16:18 +0800 From: Qin Wu To: Michael Richardson , "netconf@ietf.org" CC: "core@ietf.org" Thread-Topic: some comments on netconf-adaptive-subscription Thread-Index: AddpxCmbKxamTYjtQFuNdpDeReFPpQ== Date: Fri, 25 Jun 2021 14:16:17 +0000 Message-ID: <0ded93e29090419dabc5551e49dac97d@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.202.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 14:16:30 -0000 VGhhbmtzIE1pY2hhZWwgZm9yIHZhbHVhYmxlIGNvbW1lbnRzLCBzZWUgcmVwbHkgaW5saW5lIGJl bG93Lg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBNaWNoYWVsIFJpY2hhcmRz b24gW21haWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2FdIA0K5Y+R6YCB5pe26Ze0OiAyMDIx5bm0 NuaciDI15pelIDM6MTUNCuaUtuS7tuS6ujogUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+OyBu ZXRjb25mQGlldGYub3JnDQrmioTpgIE6IGNvcmVAaWV0Zi5vcmcNCuS4u+mimDogc29tZSBjb21t ZW50cyBvbiBuZXRjb25mLWFkYXB0aXZlLXN1YnNjcmlwdGlvbg0KDQoNCj5JIHJlYWQ6DQo+ICAg ICAgICBUaXRsZSAgICAgICAgICAgOiBBZGFwdGl2ZSBTdWJzY3JpcHRpb24gdG8gWUFORyBOb3Rp ZmljYXRpb24NCj4JRmlsZW5hbWUgICAgICAgIDogZHJhZnQtd2FuZy1uZXRjb25mLWFkYXB0aXZl LXN1YnNjcmlwdGlvbi0wNS50eHQNCg0KPnRvZGF5LiAgSSB1bmRlcnN0YW5kIHRoZSBuZWVkIGZv ciBzb21lIGtpbmQgb2Ygd2F5IHRvIHN3aXRjaCBiZXR3ZWVuIHNvbWUga2luZCBvZiBwZXJpb2Rp YyBjYXB0dXJlIG9mIHZhbHVlIHZzIGEgZWRnZS10cmlnZ2VyZWQvb24tY2hhbmdlIHByb2Nlc3Mu DQoNCj5JJ20gYSBiaXQgc3VycHJpc2VkIHRoYXQgdGhlIGV4YW1wbGUtd2lmaS1tYWMgbW9kdWxl IGhhZCB0byBiZSBjcmVhdGVkIGluIHRoZSBhcHBlbmRpeCB0byBwcm92aWRlIGFuIGV4YW1wbGUu ICBTdXJlbHkgd2Ugc2hvdWxkIGFscmVhZHkgaGF2ZSBsaWtlbHkgbW9kdWxlcyB0aGF0IGFyZSBy ZWFsbHkgYmVpbmcgdXNlZCBhbmQgbmVlZCB0aGlzIA0KDQo+a2luZCBvZiB0aGluZy4NCj5TbyBv bmUgcmVjb21tZW5kYXRpb24gaXMgdGhhdCB0aGUgZG9jdW1lbnQgZm9jdXMgb24gYWxyZWFkeSBw dWJsaXNoZWQgWUFORyBtb2RlbHMgdGhhdCBjb3VsZCBiZW5lZml0IGZyb20gdGhpcyBraW5kIG9m IHN1YnNjcmlwdGlvbi4NCg0KW1Fpbl06IFRoYXQncyBhIGdvb2Qgc3VnZ2VzdGlvbiwgV2lGaSBw cm92aWRlcyBhIGdvb2QgdXNlIGNhc2UgZm9yIHRoaXMgYWRhcHRpdmUgc3Vic2NyaXB0aW9uIG1l Y2hhbmlzbS4gd2UgZGlkIHRyeSBzb21lIGV4aXN0aW5nIHB1Ymxpc2hlZCBZQU5HIG1vZGVscywg YnV0IGl0IHNlZW1zIFlBTkcgbW9kZWxzIHNpemUgaXMgdG9vIGJpZy4NClRoYXQncyB3aHkgd2Ug Y3JlYXRlIHNpbXBsaWZpZWQgV2lmaSBtYWMgZXhhbXBsZSBNb2R1bGUuIElmIHlvdSBjYW4gcHJv dmlkZSBhIGxpbmsgdG8gQ0hJUC9NQVRURVIgV0lGSSBzdGF0aXN0aWNzIG1vZHVsZSwgd2UgYXJl IGhhcHB5IHRvIHF1b3RlIHRoYXQgZXhpc3RpbmcgbW9kdWxlLg0KDQo+KFBlcmhhcHMgdGhlIHdp ZmktbWFjIG1vZHVsZSBpcyBzb21ldGhpbmcgdGhhdCBhbHNvIG5lZWRzIHRvIGV4aXN0LCBhbmQg ZG9lcyBub3QuICBJIHdpbGwgbm90ZSB0aGF0IENISVAvTUFUVEVSIGhhcyBzb21lIGtpbmQgb2Yg V0lGSSBzdGF0aXN0aWNzIG1vZHVsZSwgYnV0IGl0J3Mgbm90IHByZXNlbnRseSB3cml0dGVuIHVw IGluIFlBTkcpDQoNCj5JIGhhZCB0byBiYWNrIHRvIFJGQzg2NDEsIHdoaWNoIEkgZG9uJ3Qga25v dyB3ZWxsIGF0IGFsbCwgdG8gYmUgc3VyZSBJIHVuZGVyc3Rvb2QgdGhlIHhwYXRoIGNyaXRlcmlh LiAgSSBndWVzcyBJIGRvbid0IHVuZGVyc3RhbmQgaG93IFJGQzg2NDEgYW5kIHRoaXMgZG9jdW1l bnQgY2FuIGJlIHVzZWQgZm9yIG5vbi1YTUwgc2VyaWFsaXplZCANCg0KPllBTkcgaW50ZXJhY3Rp b25zLg0KW1Fpbl06IFJGQzg2NDEgaXMgYnVpbHQgb24gdG9wIG9mIFJGQzg2MzksIFJGQzg2Mzkg U3Vic2NyaWJlIE5vdGlmaWNhdGlvbiBtb2R1bGUgYWxsb3cgeW91IHNwZWNpZnkgZW5jb2Rpbmcs IHRha2UgUkVTVENPTkYgYXMgYW4gZXhhbXBsZSwgeW91IGNhbiBzcGVjaWZ5IGFueSBlbmNvZGlu ZyB5b3UgbGlrZS4NCg0KPklmIGJhbmR3aWR0aCBpcyBhdCBhIHByZW1pdW0sIHdvdWxkbid0IHlv dSB3YW50IHRvIHVzZSBkcmFmdC1pZXRmLWNvcmUtY29taS0xMSAoWUFORyBpbiBDQk9SKSByYXRo ZXIgdGhhbiBYTUw/DQpbUWluXTogVGhlIGludGVudGlvbiBpcyB0byBvcHRpbWl6ZSB0aGUgZXhp c3RpbmcgWUFORyBwdXNoIG1lY2hhbmlzbSBmb3IgTkVUQ09ORi9SRVNUQ09ORiBhbmQgb3RoZXIg bWFuYWdlbWVudCBwcm90b2NvbHMuIEFuZCB0aGUgbmV0d29yayBkZXZpY2UgY2FuIHN1cHBvcnQg bXVsdGlwbGUgY2FwdHVyZSBwZXJpb2RpYyBpbnRlcnZhbHMsIHRoZSBtZWNoYW5pc20gd2UgaW50 cm9kdWNlIGlzIHRvIGFsbG93IHRoZSBuZXR3b3JrIGRldmljZSBzd2l0Y2ggdG8gZGlmZmVyZW50 IGNhcHR1cmUgcGVyaW9kaWMgaW50ZXJ2YWwgYXV0b21hdGljYWxseSB3aXRob3V0IGFza2luZyB0 aGUgTk1TIGZvciBwZXJtaXNzaW9uIGVhY2ggdGltZS4gSSBob3BlIHRoaXMgY2xhcmlmaWVzLg0K PkF0IHdoaWNoIHBvaW50LCB0aGUgb2J2aW91cyBpbnRlcmFjdGlvbiB3aXRoIFJGQzc2NDEgd291 bGQgbmVlZCB0byBiZSBleHBsYWluZWQ/DQoNCj5JdCBzZWVtcyB0aGF0IHRoZSBuZXRjb25mIChS RVNUQ09ORikgYW5kIENPUkVDT05GIGdyb3VwcyBzaG91bGQgc3BlbmQgc29tZSBtb3JlIHRpbWUg dG9nZXRoZXIuDQoNCltRaW5dOiBJIGFtIGFsc28gaG9waW5nIFJFU1RDT05GIGFuZCBDT1JFQ09O RiBjYW4gd29yayB0b2dldGhlciwgYnV0IHRoZXkgc2VlbXMgdG8gbG9vayBpbnRvIGRpZmZlcmVu dCB1c2UgY2FzZXMgKGNvbnN0cmFpbmVkIGRldmljZSBtYW5hZ2VtZW50IHZzIHVuY29uc3RyYWlu ZWQgZGV2aWNlIG1hbmFnZW1lbnQpIC4NCkkgYW0gbm90IHN1cmUgd2Ugc2hvdWxkIGdlbmVyYWxp emVkIFJFU1RDT05GIGFuZCBDT1JFQ09ORiBpbnRvIGEgc2luZ2xlIHByb3RvY29sLg0KTXkgdW5k ZXJzdGFuZGluZyB0aGV5IGhhdmUgYSBkaWZmZXJlbnQgYmFzaXMsIGZvciBDT1JFQ09ORiwgdGhl IGJhc2lzIGlzIENPTUksIHNob3VsZCBpdCBiZSBleHRlbmRlZCB0byBzdXBwb3J0IHB1YiBzdWI/ LCB0aGVyZSBpcyBvbmUgcmVsZXZhbnQgZHJhZnQsIGkuZS4sDQpEcmFmdC1iaXJraG9sZHoteWFu Zy1jb3JlLXRlbGVtZXRyeSwgDQpSRkM3NjQxIGhhdmUgZGlmZmVyZW50IGJhc2lzLCB3aGljaCBp cyBjb2FwLCBpdCBzZWVtcyBpbnRyb2R1Y2Ugc2ltaWxhciBwdWIgc3ViIG1lY2hhbmlzbSwgYnV0 IEkgY29uZnVzZWQgdGhpcyB3b3JrIHdpdGggZHJhZnQtaWV0Zi1jb3JlLWNvYXAtcHVic3ViLiBT byB3aGF0IGFib3V0IG90aGVyIElvVCBwcm90b2NvbCBzdWNoIGFzIE1RVFQ/IEl0IGFsc28gc3Vw cG9ydCBwdWIgc3ViIG1lY2hhbmlzbS4NCkkgdGhpbmsgd2Ugc2hvdWxkIG5vdCBtaXggY29hcCB3 aXRoIGNvbWksIG90aGVyd2lzZSwgd2Ugd2lsbCBzZWUgYSBsb3Qgb2YgbWVzcyBhbmQgY29uZnVz aW9uLiBBbSBJIHJpZ2h0Pw0KDQotLQ0KXSAgICAgICAgICAgICAgIE5ldmVyIHRlbGwgbWUgdGhl IG9kZHMhICAgICAgICAgICAgICAgICB8IGlwdjYgbWVzaCBuZXR3b3JrcyBbDQpdICAgTWljaGFl bCBSaWNoYXJkc29uLCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgICAgICAgIHwgICAgSW9UIGFy Y2hpdGVjdCAgIFsNCl0gICAgIG1jckBzYW5kZWxtYW4uY2EgIGh0dHA6Ly93d3cuc2FuZGVsbWFu LmNhLyAgICAgICAgfCAgIHJ1Ynkgb24gcmFpbHMgICAgWw0KDQoNCg0KDQoNCg0KLS0NCk1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJw7hU IGNvbnN1bHRpbmcgKQ0KICAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBP dHRhd2EgYW5kIFdvcmxkd2lkZQ0KDQoNCg0KDQo= From nobody Fri Jun 25 07:31:30 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21DD3A1A66; Fri, 25 Jun 2021 07:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBDqsABis7-l; Fri, 25 Jun 2021 07:31:24 -0700 (PDT) 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 CAF8C3A1A60; Fri, 25 Jun 2021 07:31:23 -0700 (PDT) Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GBK4P0TGwz6DBYt; Fri, 25 Jun 2021 22:23:49 +0800 (CST) Received: from dggeml704-chm.china.huawei.com (10.3.17.142) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Fri, 25 Jun 2021 16:31:19 +0200 Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml704-chm.china.huawei.com (10.3.17.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Fri, 25 Jun 2021 22:31:17 +0800 Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2176.012; Fri, 25 Jun 2021 22:31:16 +0800 From: Qin Wu To: Michael Richardson , "netconf@ietf.org" , "core@ietf.org" Thread-Topic: [core] some comments on netconf-adaptive-subscription Thread-Index: AddpzM/nht0jvow6SDipme2i6FvtBQ== Date: Fri, 25 Jun 2021 14:31:16 +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.52.202.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 14:31:29 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBNaWNoYWVsIFJpY2hhcmRzb24gW21h aWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2FdIA0K5Y+R6YCB5pe26Ze0OiAyMDIx5bm0NuaciDI1 5pelIDk6MDUNCuaUtuS7tuS6ujogUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+OyBuZXRjb25m QGlldGYub3JnOyBjb3JlQGlldGYub3JnDQrkuLvpopg6IFJlOiBbY29yZV0gc29tZSBjb21tZW50 cyBvbiBuZXRjb25mLWFkYXB0aXZlLXN1YnNjcmlwdGlvbg0KDQoNCk1pY2hhZWwgUmljaGFyZHNv biA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCiAgICA+IEkgaGFkIHRvIGJhY2sgdG8g UkZDODY0MSwgd2hpY2ggSSBkb24ndCBrbm93IHdlbGwgYXQgYWxsLCB0byBiZSBzdXJlIEkNCiAg ICA+IHVuZGVyc3Rvb2QgdGhlIHhwYXRoIGNyaXRlcmlhLiAgSSBndWVzcyBJIGRvbid0IHVuZGVy c3RhbmQgaG93IFJGQzg2NDENCiAgICA+IGFuZCB0aGlzIGRvY3VtZW50IGNhbiBiZSB1c2VkIGZv ciBub24tWE1MIHNlcmlhbGl6ZWQgWUFORyBpbnRlcmFjdGlvbnMuDQoNCiAgICA+IElmIGJhbmR3 aWR0aCBpcyBhdCBhIHByZW1pdW0sIHdvdWxkbid0IHlvdSB3YW50IHRvIHVzZQ0KICAgID4gZHJh ZnQtaWV0Zi1jb3JlLWNvbWktMTEgKFlBTkcgaW4gQ0JPUikgcmF0aGVyIHRoYW4gWE1MPyAgQXQg d2hpY2gNCiAgICA+IHBvaW50LCB0aGUgb2J2aW91cyBpbnRlcmFjdGlvbiB3aXRoIFJGQzc2NDEg d291bGQgbmVlZCB0byBiZSBleHBsYWluZWQ/DQoNCiAgICA+IEl0IHNlZW1zIHRoYXQgdGhlIG5l dGNvbmYgKFJFU1RDT05GKSBhbmQgQ09SRUNPTkYgZ3JvdXBzIHNob3VsZCBzcGVuZA0KICAgID4g c29tZSBtb3JlIHRpbWUgdG9nZXRoZXIuDQoNCkkgZGlkbid0IGZpbmlzaCBteSB0aG91Z2h0IGhl cmUuDQpTcGVjaWZpY2FsbHksIGl0IHNlZW1zIHRoYXQgdGhlIENPUkUgV0cgaXMgZG9pbmcgYSBs b3Qgb2Ygc3R1ZmYgd2l0aCBDb0FQIE9ic2VydmVzIGFuZCBTRU5NTCBhbmQgYWxsIHNvcnRzIG9m IGludGVyZXN0aW5nIHRyaWdnZXJzLg0KDQpJdCBzZWVtcyB0aGF0IHRoZXJlIG91Z2h0IHRvIGJl IG1vcmUgY29tbW9uIHdvcmsgaGVyZS4NClJvdXRlcnMgYXJlIHJlYWxseSB0aGUgb3JpZ2luYWwg VGhpbmdzIE9mIEludGVybmV0Lg0KW1Fpbl06IGRhdGEgbW9kZWxpbmcgbGFuZ3VhZ2Ugc3VjaCBh cyBZQU5HIGNhbiBiZSBjb21tb24gd29yayBmb3IgYm90aCBDT1JFIFdHIGFuZCBORVRDT05GIFdH LA0KQnV0IHRoZXkgbWF5IGNob29zZSBkaWZmZXJlbnQgdHJhbnNwb3J0IHByb3RvY29sLCBzdWNo IGFzIE5FVENPTkYsIFJFU1RDT05GLCBIVFRQIDIuMCwgQ09BUCwgTVFUVCwgQ09NSQ0KU2Vjb25k bHksIEkgdGhpbmsgaXQgd2lsbCBiZSBuaWNlIHRvIHNlcGFyYXRlIGNvbnN0cmFpbmVkIGRldmlj ZSBtYW5hZ2VtZW50IGZyb20gcmVzb3VyY2UgdW5jb25zdHJhaW5lZCBuZXR3b3JrIGRldmljZSBt YW5hZ2VtZW50LA0KQ29uc3RyYWludCBkZXZpY2UgYXMgSW9UIGRldmljZSBjYW4gYmUgdGVtcGVy YXR1cmUgc2Vuc29yLCBjdXJyZW50LCB2b2x0YWdlIHNlbnNvciB3aGljaCBjYW4gYmUgc2VlbiBh cyBhZmZpbGlhdGVkIGRldmljZXMgcGVydGFpbmluZyB0byByZXNvdXJjZSB1bnN0cmFpbmVkIG5l dHdvcmsgZGV2aWNlLg0KSW4gZGF0YSBjZW50ZXIgc2NlbmFyaW9zLCB3ZSBkbyBhIGxvdCBvZiBz dWNoIGFmZmlsaWF0ZWQgZGV2aWNlcyBvciBzZW5zb3JzIHN1Y2ggYXMgYWlyIGNvbmRpdGlvbmVy LCB3YXRlciBsZWFrYWdlIGFsYXJtIHNlbnNvciBkZXBsb3llZCB0b2dldGhlciB3aXRoIGRhdGEg Y2VudGVyIHN3aXRjaCBkZXZpY2VzLg0KVGhlc2UgSW9UIGRldmljZXMgb25seSB1c2UgTVFUVC9D T0FQL0hUVFAgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGVpciBJb1QgcGxhdGZvcm0sIGZvciBkYXRh IGNlbnRlciBzd2l0Y2ggZGV2aWNlcywgeW91IG1heSBzdGlsbCByZWx5IG9uIG5ldHdvcmsgbWFu YWdlbWVudCBwcm90b2NvbHMgc3VjaCBhcyBORVRDT05GLA0KU05NUCwgZ1JQQywgZXRjLg0KRG8g eW91IHNlZSB0aGlzIGRpZmZlcmVudGx5PyBNaWNoYWVsPw0KLS0NCk1pY2hhZWwgUmljaGFyZHNv biA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJw7hUIGNvbnN1bHRpbmcg KQ0KICAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBPdHRhd2EgYW5kIFdv cmxkd2lkZQ0KDQoNCg0KDQo= From nobody Fri Jun 25 07:41:41 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6333A1AAB for ; Fri, 25 Jun 2021 07:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlChSCvERfNz for ; Fri, 25 Jun 2021 07:41:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDED63A1AAA for ; Fri, 25 Jun 2021 07:41:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B1C638B95 for ; Fri, 25 Jun 2021 10:43:20 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 47Bxt_b0DDTb for ; Fri, 25 Jun 2021 10:43:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EB0B438B32 for ; Fri, 25 Jun 2021 10:43:18 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 68A9A553 for ; Fri, 25 Jun 2021 10:41:31 -0400 (EDT) From: Michael Richardson To: core@ietf.org In-Reply-To: <162457337875.24837.11422050083374725531@ietfa.amsl.com> References: <162457337875.24837.11422050083374725531@ietfa.amsl.com> 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: Re: [core] I-D Action: draft-ietf-core-yang-cbor-16.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 14:41:40 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-yang-cbor-16 I went through the diff on this, and for draft-ietf-core-sid-16.txt, and I see mostly editorial nits. This is good. I guess we are now just about to submit to IESG? Do we need a new shepherd? =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+93Q3WUFAmDV6xsACgkQgItw+93Q 3WW4Ggf+MiQwGlRvgTtDbgAPETtO/I3NXLVtCtcUFH0FkyM7bg01WyKLoLCTIRA5 o7/lkLdio2axspP0ys6Kr5KiiH4HjVBJ7TITlpAsS7UdmV3ZzgUltiWKYrpMr3Yw uMAFmNVo4UR72HGFSOrWowjsdfNBxi7+SBX2EeE19M0X/5RIrqJAxTHhCK9wfpjO G+ilfR2MIrq4cNyvvnf92Dnif0v3Lf4P+WF0r9kWQM6P/SSgnk/9+P/QyTCuJfWz TEMTyJ6z0aNXRVGK4htCtbnMA4rPA4YFfV7JaH066iMjH6bTlUZgQGxd9QI2t9qq aBcwvEmNrz5V9UNLU3818mUKUgftgg== =Fg4D -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 25 07:49:24 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396ED3A1AE9; Fri, 25 Jun 2021 07:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 gxNb9oCVxY30; Fri, 25 Jun 2021 07:49:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D133A1AE8; Fri, 25 Jun 2021 07:49:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E681538B97; Fri, 25 Jun 2021 10:51:03 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5jriCkkNL3WR; Fri, 25 Jun 2021 10:51:01 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B1C1538B95; Fri, 25 Jun 2021 10:51:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 28FF0553; Fri, 25 Jun 2021 10:49:14 -0400 (EDT) From: Michael Richardson To: Andy Bierman , Qin Wu , Netconf , Core In-Reply-To: References: <5ba27e43a63e427091f3093b35be09a0@huawei.com> <14286.1624562075@localhost> 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: Re: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 14:49:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Andy Bierman wrote: >> If bandwidth is at a premium, wouldn't you want to use >> draft-ietf-core-comi-11 (YANG in CBOR) rather than XML? At which >> point, the obvious interaction with RFC7641 would need to be >> explained? > Commenting only on the use of CORECONF, not this draft... IMO CORECO= NF > is for constrained devices, possibly on constrained networks. But if > only the network is constrained, then perhaps only CBOR is really > needed. CoAP/CBOR/etc. work well in less-constrained devices. ESP32 now have several megabytes of flash, almost, but not quite 640K of RA= M (520K). Meanwhile router control plane CPUs are often way beyond this today. > I first raised these issues in NETCONF WG in 2013 > https://datatracker.ietf.org/doc/html/draft-bierman-netconf-efficienc= y-extensions-00 ... > IMO the WG missed the point of this draft, which was to preserve the > massive and expensive investment in the NETCONF application layer > already deployed. Just optimize the network traffic and not rewrite a= ny > feature code. I don't think it's too late, but I don't really understand the NETCONF investment right now. While I'm sure that each major router vendor has a management platform like JUNOS, I've not seen it cross-vendor for real. I also know ISPs who try stuff like JUNOS, and get frustrated and go back t= o CLI. (Often without the discipline to do it well) =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+93Q3WUFAmDV7OkACgkQgItw+93Q 3WUAnwf/Tq8r45WUlyj0S5OnPz4YNQa1qWHuF8sT62gR/zgqneuUL/Dzkz9j8nEE DXdqKGiskOYCIihqHWzxKeQCzTXktxTe/B5Ifzxzs4lQv26AbLUl5xYyQHYzqrtA i/v7TT5y3cESmyDwyrXRzC3f/+EerPp4tfVZQ79V8cZOQccPTbI/gYexAR7/b0IS cCqSCc5otZ1gPMJfejiovgLg/ISd3AiJJW6VcnCOl9gLTunFdUjRZcIP66lyqIVu FM2RroaaDv5iNfaHgRPFXVbZfKKqeO+ZvJCHi8D7r/L/fiKSC44BPuVjeywzr9cD eafiKCSPSYEZQs/ZsrZK6n2sClwVxw== =Xw3k -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 25 07:57:37 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFC63A1B32 for ; Fri, 25 Jun 2021 07:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYdjMhg23-fg for ; Fri, 25 Jun 2021 07:57:31 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114963A1B2A for ; Fri, 25 Jun 2021 07:57:30 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GBKqD3SwQz2xGy; Fri, 25 Jun 2021 16:57:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <7990.1624632091@localhost> Date: Fri, 25 Jun 2021 16:57:28 +0200 Cc: core X-Mao-Original-Outgoing-Id: 646325847.9495831-07a97ed2b06774882591221a4d317c56 Content-Transfer-Encoding: quoted-printable Message-Id: <4D4D93FB-8DFB-4F1F-9E2C-DBDA7FA30AA2@tzi.org> References: <162457337875.24837.11422050083374725531@ietfa.amsl.com> <7990.1624632091@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [core] I-D Action: draft-ietf-core-yang-cbor-16.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 14:57:36 -0000 > On 2021-06-25, at 16:41, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > internet-drafts@ietf.org wrote: >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-yang-cbor-16 >=20 > I went through the diff on this, and for draft-ietf-core-sid-16.txt, = and I > see mostly editorial nits. This is good. I guess we are now just = about to > submit to IESG? Sorry, I should have written an announcement mail. Publication request was 2021-02-05 IETF Last-call was 2021-02-24 to 2021-03-17 (?) Leading to an IANA - Not OK on the same date (?) We got an =E2=80=9Cissues identified=E2=80=9D from IANA at 2021-06-08 ...and took some time to clear this up. -16 is now essentially cleaned up wrt to the issue identified, which a = clearer division of work between YANG-CBOR and core=E2=80=94SID. So, overall, -16 was the completion of addressing IANA and AD comments. The state is now AD followup; if and when Francesca is satisfied she = could press the =E2=80=9CIESG tele chat=E2=80=9D button, which probably = would give us a few more reviews and a telechat date in ?two weeks?. > Do we need a new shepherd? Yes, Marco (yang-cbor) and Jaime (core-sid) have stepped in, = respectively. Many thanks to them. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jun 25 09:04:29 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFB43A076E for ; Fri, 25 Jun 2021 09:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 uhfuOS_Z4GJR for ; Fri, 25 Jun 2021 09:04:23 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599193A0744 for ; Fri, 25 Jun 2021 09:04:23 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id d13so13124891ljg.12 for ; Fri, 25 Jun 2021 09:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FgvExJPOzpl/xYNhRAmw1cPsZtX07H+SRvU1FPH2bVo=; b=nlXh1iz3rQ9ABxEXNUewZEzGUxStPPW3QgdB+MGvWi/j7xJ9MGtnBHSWdAOvcudAym wCF0LkvNBsGYKHpHxcyGLFbt7obpXBh6q8l2ZlxSMMj0BiEwju4jGyjHRKpsO6NATn12 RPw+ycER1eNOGSobDxyWUf8/uX6VgW6Q6igeL2ShgcXSsXNVal5co6Z10Ufr78Zzm9jH Cn+ImawOJTNAQgU8mN9T1Mc5fImgdv/Di7/YpWeCFsnuV13ZluukAYHL21G2XuFHpIJk sTNPJ+Iu5/fRIDv+WP4hr5u5VNXgkSYLtJ1WXEyNvTkVrC20vV8K2Y5j1ppFXd2awMUZ Wt+w== 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=FgvExJPOzpl/xYNhRAmw1cPsZtX07H+SRvU1FPH2bVo=; b=IKsECR6FNu708pssX6pppTEH8ADNfv76vAwpMjo4GcoJj3WgQEQ8F3n/fwXGobv1A9 De0QaEUxuhaHkumEc/Tx8ay8D6W/zkWSMMCeb0YSBtf05WGfw9CoNsKZYGbM/SDvCjaC fsUXDnEzoGWS/Ky6FSrrlUoQBDXe2kR87sTQhe60rvhivJy30pG+z8VB8qlI5IogTnTP TOXJyEkchfUChNszg1nWPPDWh7/bbX9pGWoYcQxPuSKuS+1/Bszx4In07zTZ+XmFcPbn dpTVIRYCnXcfg6lDLWkInBvsnvlkavP4/5Vndb6bWct8EowAscgTz5akNuJWZccLyvjS r0eQ== X-Gm-Message-State: AOAM532dl6BRAhBVJBc+qRqwvjeDvKUt1d9SwHfu8KRbR6orQWF8XtVD 7hlCqmH1Htc8Jw63HhMRcyLk8a93EyOJmtGjDmjAYg== X-Google-Smtp-Source: ABdhPJw9ji8Hc9OeBPL1RiHJPWUi2oxVur3FIH7SksswKeNtWLUwfc7ZY5H2WoE0nW3LqyozZ7PZX2lV9/lyXoTYDwU= X-Received: by 2002:a2e:b80a:: with SMTP id u10mr7458256ljo.325.1624637056242; Fri, 25 Jun 2021 09:04:16 -0700 (PDT) MIME-Version: 1.0 References: <5ba27e43a63e427091f3093b35be09a0@huawei.com> <14286.1624562075@localhost> <11607.1624583118@localhost> In-Reply-To: <11607.1624583118@localhost> From: Andy Bierman Date: Fri, 25 Jun 2021 09:04:05 -0700 Message-ID: To: Michael Richardson Cc: Qin Wu , Netconf , Core Content-Type: multipart/alternative; boundary="000000000000a06fe405c5994ab6" Archived-At: Subject: Re: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 16:04:28 -0000 --000000000000a06fe405c5994ab6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 24, 2021 at 6:05 PM Michael Richardson wrote: > > Michael Richardson wrote: > > I had to back to RFC8641, which I don't know well at all, to be sur= e > I > > understood the xpath criteria. I guess I don't understand how > RFC8641 > > and this document can be used for non-XML serialized YANG > interactions. > > > If bandwidth is at a premium, wouldn't you want to use > > draft-ietf-core-comi-11 (YANG in CBOR) rather than XML? At which > > point, the obvious interaction with RFC7641 would need to be > explained? > > > It seems that the netconf (RESTCONF) and CORECONF groups should spe= nd > > some more time together. > > I didn't finish my thought here. > Specifically, it seems that the CORE WG is doing a lot of stuff with CoAP > Observes and SENML and all sorts of interesting triggers. > There have long been 2 camps in CORE WG on this -- 1 that thinks YANG data modeling should be used in IoT and another that thinks YANG data modeling is overkil= l and not needed for IoT. If YANG is used then SENML info is redundant. YANG automation is about the entire tool chain, not just the bytes on the wire, but even if you focus just on that, I think CBOR+SID can achieve much highe= r information density than SENML. > It seems that there ought to be more common work here. > Routers are really the original Things Of Internet. > I do not think it helps to classify a router as an IoT device. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > Andy > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --000000000000a06fe405c5994ab6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 24, 2021 at 6:05 PM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
=C2=A0 =C2=A0 > I had to back to RFC8641, which I don't know well at= all, to be sure I
=C2=A0 =C2=A0 > understood the xpath criteria.=C2=A0 I guess I don't= understand how RFC8641
=C2=A0 =C2=A0 > and this document can be used for non-XML serialized YAN= G interactions.

=C2=A0 =C2=A0 > If bandwidth is at a premium, wouldn't you want to u= se
=C2=A0 =C2=A0 > draft-ietf-core-comi-11 (YANG in CBOR) rather than XML?= =C2=A0 At which
=C2=A0 =C2=A0 > point, the obvious interaction with RFC7641 would need t= o be explained?

=C2=A0 =C2=A0 > It seems that the netconf (RESTCONF) and CORECONF groups= should spend
=C2=A0 =C2=A0 > some more time together.

I didn't finish my thought here.
Specifically, it seems that the CORE WG is doing a lot of stuff with CoAP Observes and SENML and all sorts of interesting triggers.
<= div>
There have long been 2 camps in CORE WG on this -- 1 tha= t thinks YANG data modeling
should be used in IoT and another tha= t thinks YANG data modeling is overkill
and not needed for IoT.= =C2=A0 If YANG is used then SENML info is redundant.

YANG automation is about the entire tool chain, not just the bytes on th= e wire,
but even if you focus just on that, I think CBOR+SID can = achieve much higher
information density than SENML.

It seems that there ought to be more common work here.
Routers are really the original Things Of Internet.
I do not think it helps to classify a router as an IoT device.=

=C2=A0

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




Andy
=C2=A0

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--000000000000a06fe405c5994ab6-- From nobody Fri Jun 25 09:09:46 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCDF3A07B1; Fri, 25 Jun 2021 09:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 gNDgIjFbtCrt; Fri, 25 Jun 2021 09:09:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28FEA3A07B3; Fri, 25 Jun 2021 09:09:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EE3ED38B97; Fri, 25 Jun 2021 12:11:21 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HHlk8pn4U8yF; Fri, 25 Jun 2021 12:11:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BB00638B96; Fri, 25 Jun 2021 12:11:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F2A08553; Fri, 25 Jun 2021 12:09:31 -0400 (EDT) From: Michael Richardson To: Qin Wu , netconf@ietf.org, "core\@ietf.org" In-Reply-To: <0ded93e29090419dabc5551e49dac97d@huawei.com> References: <0ded93e29090419dabc5551e49dac97d@huawei.com> 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: Re: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 16:09:40 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Qin Wu wrote: > [Qin]: That's a good suggestion, WiFi provides a good use case for th= is > adaptive subscription mechanism. we did try some existing published > YANG models, but it seems YANG models size is too big. That's why we > create simplified Wifi mac example Module. If you can provide a link = to > CHIP/MATTER WIFI statistics module, we are happy to quote that existi= ng > module. The CHIP/MATTER document not public yet, but Huawei is a member and can get= the document. But, it's not a YANG module. The fact that they have a set of wifi statistics in their base definition argues that there ought to be an equivalent YANG model though. > [Qin]: The intention is to optimize the existing YANG push mechanism > for NETCONF/RESTCONF and other management protocols. And the network > device can support multiple capture periodic intervals, the mechanism > we introduce is to allow the network device switch to different captu= re > periodic interval automatically without asking the NMS for permission > each time. I hope this clarifies. yes, I understood that from the document. > [Qin]: I am also hoping RESTCONF and CORECONF can work together, but > they seems to look into different use cases (constrained device > management vs unconstrained device management) . I am not sure we > should generalized RESTCONF and CORECONF into a single protocol. That's not what I'm suggesting. I'm asking, if bandwidth is an issue, why not use a smaller encoding. And, why not integrate with CoAP Observe? =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+93Q3WUFAmDV/7sACgkQgItw+93Q 3WUw4gf7BTYuXW0/ogms5J7YRgA+pfCUmz5fCt1kYho56ne4ZitN0M50N2oIUc6b OMLtuLRDfpQjHAYMaXi1RdmLbh+yx1PtUCbp1fteYPEIKhq7RP/gSdpakyzEvkoa Js/3ViwP3mlttbR98i3Wc/eV7fdZlTb8bYM5xmvWg0m9sIaLPJc+2+X6rrmdhNTc fR8mkaAhJTaNCIp+1Ss/qfgftw3Nv/GNoZjaaucnxKNAG2PO9kz/g4wE5deffPyJ YUuopRQp/0KtI11e0zW0NrzR0jnIyPWrI3lzeV/XRLzezrmtpIdgRPOMmDo0xxGu ZLN+Ak+mz8hMp7CIl0BqMuN+8YpLsg== =v2mb -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 25 09:37:18 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864253A09C1; Fri, 25 Jun 2021 09:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QehzDcMD-uC1; Fri, 25 Jun 2021 09:37:10 -0700 (PDT) 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 61A093A09BB; Fri, 25 Jun 2021 09:37:10 -0700 (PDT) Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GBMkY05Ngz6L52v; Sat, 26 Jun 2021 00:23:33 +0800 (CST) Received: from dggeml751-chm.china.huawei.com (10.1.199.150) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Fri, 25 Jun 2021 18:37:06 +0200 Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml751-chm.china.huawei.com (10.1.199.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Sat, 26 Jun 2021 00:37:04 +0800 Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2176.012; Sat, 26 Jun 2021 00:37:03 +0800 From: Qin Wu To: Michael Richardson , "netconf@ietf.org" , "core@ietf.org" Thread-Topic: some comments on netconf-adaptive-subscription Thread-Index: Addp3Xbz9EsUzJGVQoilQopppt0Pig== Date: Fri, 25 Jun 2021 16:37:03 +0000 Message-ID: <5a168444f56a4ef8bb8d98f186a190e1@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.202.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 16:37:16 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBNaWNoYWVsIFJpY2hhcmRzb24gW21h aWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2FdIA0K5Y+R6YCB5pe26Ze0OiAyMDIx5bm0NuaciDI2 5pelIDA6MTANCuaUtuS7tuS6ujogUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+OyBuZXRjb25m QGlldGYub3JnOyBjb3JlQGlldGYub3JnDQrkuLvpopg6IFJlOiBzb21lIGNvbW1lbnRzIG9uIG5l dGNvbmYtYWRhcHRpdmUtc3Vic2NyaXB0aW9uDQoNClFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29t PiB3cm90ZToNCiAgICA+IFtRaW5dOiBUaGF0J3MgYSBnb29kIHN1Z2dlc3Rpb24sIFdpRmkgcHJv dmlkZXMgYSBnb29kIHVzZSBjYXNlIGZvciB0aGlzDQogICAgPiBhZGFwdGl2ZSBzdWJzY3JpcHRp b24gbWVjaGFuaXNtLiB3ZSBkaWQgdHJ5IHNvbWUgZXhpc3RpbmcgcHVibGlzaGVkDQogICAgPiBZ QU5HIG1vZGVscywgYnV0IGl0IHNlZW1zIFlBTkcgbW9kZWxzIHNpemUgaXMgdG9vIGJpZy4gIFRo YXQncyB3aHkgd2UNCiAgICA+IGNyZWF0ZSBzaW1wbGlmaWVkIFdpZmkgbWFjIGV4YW1wbGUgTW9k dWxlLiBJZiB5b3UgY2FuIHByb3ZpZGUgYSBsaW5rIHRvDQogICAgPiBDSElQL01BVFRFUiBXSUZJ IHN0YXRpc3RpY3MgbW9kdWxlLCB3ZSBhcmUgaGFwcHkgdG8gcXVvdGUgdGhhdCBleGlzdGluZw0K ICAgID4gbW9kdWxlLg0KDQpUaGUgQ0hJUC9NQVRURVIgZG9jdW1lbnQgbm90IHB1YmxpYyB5ZXQs IGJ1dCBIdWF3ZWkgaXMgYSBtZW1iZXIgYW5kIGNhbiBnZXQgdGhlIGRvY3VtZW50Lg0KQnV0LCBp dCdzIG5vdCBhIFlBTkcgbW9kdWxlLiAgVGhlIGZhY3QgdGhhdCB0aGV5IGhhdmUgYSBzZXQgb2Yg d2lmaSBzdGF0aXN0aWNzIGluIHRoZWlyIGJhc2UgZGVmaW5pdGlvbiBhcmd1ZXMgdGhhdCB0aGVy ZSBvdWdodCB0byBiZSBhbiBlcXVpdmFsZW50IFlBTkcgbW9kZWwgdGhvdWdoLg0KDQpbUWluXTpU aGFua3MsIEkgd2lsbCB0YWtlIGEgbG9vayBhdCBpdCBhbmQgc2VlIGlmIHNvbWV0aGluZyBjYW4g YmUgcmV1c2VkLg0KDQogICAgPiBbUWluXTogVGhlIGludGVudGlvbiBpcyB0byBvcHRpbWl6ZSB0 aGUgZXhpc3RpbmcgWUFORyBwdXNoIG1lY2hhbmlzbQ0KICAgID4gZm9yIE5FVENPTkYvUkVTVENP TkYgYW5kIG90aGVyIG1hbmFnZW1lbnQgcHJvdG9jb2xzLiBBbmQgdGhlIG5ldHdvcmsNCiAgICA+ IGRldmljZSBjYW4gc3VwcG9ydCBtdWx0aXBsZSBjYXB0dXJlIHBlcmlvZGljIGludGVydmFscywg dGhlIG1lY2hhbmlzbQ0KICAgID4gd2UgaW50cm9kdWNlIGlzIHRvIGFsbG93IHRoZSBuZXR3b3Jr IGRldmljZSBzd2l0Y2ggdG8gZGlmZmVyZW50IGNhcHR1cmUNCiAgICA+IHBlcmlvZGljIGludGVy dmFsIGF1dG9tYXRpY2FsbHkgd2l0aG91dCBhc2tpbmcgdGhlIE5NUyBmb3IgcGVybWlzc2lvbg0K ICAgID4gZWFjaCB0aW1lLiBJIGhvcGUgdGhpcyBjbGFyaWZpZXMuDQoNCnllcywgSSB1bmRlcnN0 b29kIHRoYXQgZnJvbSB0aGUgZG9jdW1lbnQuDQoNCiAgICA+IFtRaW5dOiBJIGFtIGFsc28gaG9w aW5nIFJFU1RDT05GIGFuZCBDT1JFQ09ORiBjYW4gd29yayB0b2dldGhlciwgYnV0DQogICAgPiB0 aGV5IHNlZW1zIHRvIGxvb2sgaW50byBkaWZmZXJlbnQgdXNlIGNhc2VzIChjb25zdHJhaW5lZCBk ZXZpY2UNCiAgICA+IG1hbmFnZW1lbnQgdnMgdW5jb25zdHJhaW5lZCBkZXZpY2UgbWFuYWdlbWVu dCkgLiAgSSBhbSBub3Qgc3VyZSB3ZQ0KICAgID4gc2hvdWxkIGdlbmVyYWxpemVkIFJFU1RDT05G IGFuZCBDT1JFQ09ORiBpbnRvIGEgc2luZ2xlIHByb3RvY29sLg0KDQpUaGF0J3Mgbm90IHdoYXQg SSdtIHN1Z2dlc3RpbmcuDQpJJ20gYXNraW5nLCBpZiBiYW5kd2lkdGggaXMgYW4gaXNzdWUsIHdo eSBub3QgdXNlIGEgc21hbGxlciBlbmNvZGluZy4NCltRaW5dOiBGb3IgWUFORyBwdXNoLCB1c3Vh bGx5IHRoZSBzZXJ2ZXIgbGVhcm5zIHRoZSBlbmNvZGluZyBzdXBwb3J0ZWQgYnkgdGhlIGNsaWVu dCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBtYW5hZ2VtZW50IHNlc3Npb24uIFR3byByZWxldmFu dCBkcmFmdHMgYXJlOg0KZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmDQpkcmFmdC10YW8t bmV0Y29uZi1kYXRhLWV4cG9ydC1jYXBhYmlsaXRpZXMNCkkgYW0gbm90IHN1cmUgd2UgY2FuIHN3 aXRjaCBlbmNvZGluZyBpbiB0aGUgbWlkZGxlIG9mIHNlc3Npb24sIHdoaWNoIHByb2JhYmx5IG5l ZWRzIHRvIHRlYXIgZG93biB0aGUgc2Vzc2lvbiBhbmQgbG9zcyB0aGUgc2VydmljZSBjb250aW51 aXR5Lg0KRm9yIHRoZSBuZXR3b3JrIGRldmljZSBzdXBwb3J0IG11bHRpcGxlIGNhcHR1cmUgcGVy aW9kaWMgaW50ZXJ2YWxzLCBzd2l0Y2ggdGhlIGludGVydmFsIGlzIGNoZWFwIGFuZCBkb2Vzbid0 IGNhdXNlIHRoZSBzZXNzaW9uIHRvIGJlIGludGVycnVwdGVkLg0KVGhhdCBpcyB3aHkgd2Ugbm90 IGNvbnNpZGVyIGEgc21hbGxlciBlbmNvZGluZyBpbiB0aGUgc29sdXRpb24uDQpBbmQsIHdoeSBu b3QgaW50ZWdyYXRlIHdpdGggQ29BUCBPYnNlcnZlPw0KW1Fpbl06IEkgaGF2ZSBhIHF1aWNrIGxv b2sgYXQgQ09BUCBPYnNlcnZlLiBJIHNlZSB0aGUgY29tbW9uYWxpdHkgYmV0d2VlbiBDb0FQIE9i c2VydmVyIGFuZCB0aGlzIGRyYWZ0IGlzIA0KVGhlIHNlcnZlciBvciBuZXR3b3JrIGRldmljZSBp biBib3RoIGNhc2VzLCBuZWVkIHRvIHNlbmQgbm90aWZpY2F0aW9uIHRvIHRoZSBjbGllbnQgdG8g aW5mb3JtIHRoZSBjdXJyZW50IHRlbXBlcmF0dXJlIG9yIHN1YnNjcmliZWQgZGF0YS4NClRoZSBj bGllbnQgaW4gYm90aCBjYXNlIG5lZWRzIHRvIG9ic2VydmVyIHJlc291cmNlIGNoYW5nZSBvciBk YXRhIGNoYW5nZSBpbiB0aGUgc2VydmVyLg0KQnV0IHRoZSBkaWZmZXJlbmNlIGlzIHRoZSBzZXJ2 ZXIgaW4gYWRhcHRpdmUtc3Vic2NyaXB0aW9uIGRyYWZ0IGhhcyBzb21lIGNvbnRyb2wgYW5kIGNh biBzd2l0Y2ggY2FwdHVyZSBwZXJpb2RpYyBpbnRlcnZhbC4gSW4gYWRkaXRpb24sIHRoZSBzZXJ2 ZXIgaW4gdGhlIGFkYXB0aXZlLXN1YnNjcmlwdGlvbiBkcmFmdA0KQ2FuIHNlbmQgaW50ZXJ2YWwg c3dpdGNoaW5nIG5vdGlmaWNhdGlvbiB0byB0aGUgY2xpZW50Lg0KU28gYmFzZWQgb24gdGhpcyBh bmFseXNpcywgSSBiZWxpZXZlIENvQVAgT2JzZXJ2ZSBoYXMgYmVlbiBpbnRlZ3JhdGVkIGludG8g dGhpcyBkcmFmdCB3aGljaCBpcyBzaW1pbGFyIHRvIHdoYXQgUkZDODY0MSBzcGVjaWZpZXMgKGku ZS4sIFB1YiBTdWIgbWVjaGFuaXNtKS4NCg0KLS0NCk1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lF VEZAc2FuZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJw7hUIGNvbnN1bHRpbmcgKQ0KICAgICAg ICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBPdHRhd2EgYW5kIFdvcmxkd2lkZQ0K From nobody Fri Jun 25 09:51:11 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EBA3A0AA6; Fri, 25 Jun 2021 09:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUWYauFZIl3i; Fri, 25 Jun 2021 09:51:05 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76F83A0AA0; Fri, 25 Jun 2021 09:51:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C46138B87; Fri, 25 Jun 2021 12:52:50 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FwlVbgA9eITn; Fri, 25 Jun 2021 12:52:48 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2AA4338A36; Fri, 25 Jun 2021 12:52:48 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 49151553; Fri, 25 Jun 2021 12:51:00 -0400 (EDT) From: Michael Richardson to: Qin Wu , netconf@ietf.org, "core\@ietf.org" In-Reply-To: <30012.1624637371@localhost> References: <0ded93e29090419dabc5551e49dac97d@huawei.com> <30012.1624637371@localhost> 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: Re: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 16:51:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: >> [Qin]: I am also hoping RESTCONF and CORECONF can work together, but >> they seems to look into different use cases (constrained device >> management vs unconstrained device management) . I am not sure we >> should generalized RESTCONF and CORECONF into a single protocol. > That's not what I'm suggesting. I'm asking, if bandwidth is an issue, > why not use a smaller encoding. And, why not integrate with CoAP > Observe? draft-birkholz-yang-core-telemetry-01 [now expired] for instance tries to do a lot of the matching. I think that the adaptive rate subscription that you've created would work very well within that model. I guess yang-core-telemetry-01 needs to update itself as ietf-netconf-subscribed-notifications is published as RFC 8639 right. I still don't know how XPath would work with COMI, but really I'm just sitting around the edges of the YANG over the wire space. =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+93Q3WUFAmDWCXQACgkQgItw+93Q 3WUgKgf+LZg0HKpMQoC4o6waz58vwjRvvlo6DVD5w7ueK+4K3xZG1JGbWbLFWBF7 tP0MQZu1sxY/d85XKcY+EiYvbExNT/f59Mo7VXy1iD+qvih1+GFqRwid+Bro9tQ8 Gp3zeEVg9Parwmokz8ua37ylMYaGqc1Qc14kkjHddfU6iTC83C50F/OPnP3DbFSk 2aqwgmc6mJ/5xLM5gqY+VHg69WJVZZ4kmGi9OcZULeimXN5J/3ISwQMDH60SB/qv PDhLQsO3n7gyAxjVG4I2xOsPR+fjcpJFRMyaTbzMhjuR5QX/fq6sB0Tq1CBIWkvo /HFB94x2W+U6EY34rtNybA4/kNnsfQ== =YBZE -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 25 09:58:35 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7BC3A0B06; Fri, 25 Jun 2021 09:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0ZbJ8-6u8tf; Fri, 25 Jun 2021 09:58:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60273A0B02; Fri, 25 Jun 2021 09:58:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C215B38B97; Fri, 25 Jun 2021 13:00:08 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5sbQjQDcS7Nu; Fri, 25 Jun 2021 13:00:06 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C2B6538B92; Fri, 25 Jun 2021 13:00:06 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DCA71553; Fri, 25 Jun 2021 12:58:18 -0400 (EDT) From: Michael Richardson To: Qin Wu , "netconf\@ietf.org" , "core\@ietf.org" In-Reply-To: References: 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: Re: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 16:58:29 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Qin Wu wrote: mcr> I didn't finish my thought here. Specifically, it seems that the = CORE mcr> WG is doing a lot of stuff with CoAP Observes and SENML and all so= rts mcr> of interesting triggers. Qin> data modeling language such as YANG can be common work for both CO= RE Qin> WG and NETCONF WG, But they may choose different transport protoco= l, Qin> such as NETCONF, RESTCONF, HTTP 2.0, COAP, MQTT, COMI Secondly, I Qin> think it will be nice to separate constrained device management fr= om Qin> resource unconstrained network device management, Constraint device Qin> as IoT device can be temperature sensor, current, voltage sensor Qin> which can be seen as affiliated devices pertaining to resource Qin> unstrained network device. temperature, current are critical values for routing equipment, aren't they? Qin> In data center scenarios, we do a lot of such affiliated devices or Qin> sensors such as air conditioner, water leakage alarm sensor deploy= ed Qin> together with data center switch devices. These IoT devices only Qin> use MQTT/COAP/HTTP to communicate with their IoT platform, for data Qin> center switch devices, you may still rely on network management Qin> protocols such as NETCONF, SNMP, gRPC, etc. Do you see this Qin> differently? Michael? It seems that we ought to seek convergence here. That's what I'm saying. That any split here is for historical reasons, and does not make sense going forward. =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+93Q3WUFAmDWCyoACgkQgItw+93Q 3WVFfAf/ZCWMMJ3YMXLvg6mJL08nw1Yd5G7w4QNu1bg+ak4BkpJm/OhhKh/Ims4J WOQvrv29lnrVyeGbgF0DfQfmBNwKBs/K5aQGXhsyhCQ+hF7XJRmR9F7qTc15Bgkh +6yNa1Mw84fIB42AbHinqWWQxFZCAJtdnCqLNmAWwkxVB17K2pFa2Q+5rtRJ1TGc rk3DNHJC0fHGE2ILrAKBINXnGWbTmnRE7mh4txaaFOHpCrkCqhSV5LYR3rZoOK5P a+fc3J3eseOstZzKLkIAyxY+RQz3/kt6/eLdVck/oFShs13MmQ0jv/xgM4hVjv5+ dTgRflqoeJjrenYEzxEWrsbeSOBDiQ== =5B0U -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 25 10:05:13 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010E43A0B8B; Fri, 25 Jun 2021 10:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPI_JUF4alve; Fri, 25 Jun 2021 10:05:05 -0700 (PDT) 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 ABD963A0B8D; Fri, 25 Jun 2021 10:05:05 -0700 (PDT) Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GBNTk5GJwz6G8G1; Sat, 26 Jun 2021 00:57:30 +0800 (CST) Received: from dggeml704-chm.china.huawei.com (10.3.17.142) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Fri, 25 Jun 2021 19:05:01 +0200 Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml704-chm.china.huawei.com (10.3.17.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Sat, 26 Jun 2021 01:04:59 +0800 Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2176.012; Sat, 26 Jun 2021 01:04:59 +0800 From: Qin Wu To: Michael Richardson , "netconf@ietf.org" , "core@ietf.org" Thread-Topic: some comments on netconf-adaptive-subscription Thread-Index: Addp45gbKxamTYjtQFuNdpDeReFPpQ== Date: Fri, 25 Jun 2021 17:04:59 +0000 Message-ID: <34e1882b99774c4e94216050aefafe78@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.202.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 17:05:11 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBNaWNoYWVsIFJpY2hhcmRzb24gW21h aWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2FdIA0K5Y+R6YCB5pe26Ze0OiAyMDIx5bm0NuaciDI2 5pelIDA6NTENCuaUtuS7tuS6ujogUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+OyBuZXRjb25m QGlldGYub3JnOyBjb3JlQGlldGYub3JnDQrkuLvpopg6IFJlOiBzb21lIGNvbW1lbnRzIG9uIG5l dGNvbmYtYWRhcHRpdmUtc3Vic2NyaXB0aW9uDQoNCg0KTWljaGFlbCBSaWNoYXJkc29uIDxtY3Ir aWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KICAgID4+IFtRaW5dOiBJIGFtIGFsc28gaG9waW5n IFJFU1RDT05GIGFuZCBDT1JFQ09ORiBjYW4gd29yayB0b2dldGhlciwgYnV0DQogICAgPj4gdGhl eSBzZWVtcyB0byBsb29rIGludG8gZGlmZmVyZW50IHVzZSBjYXNlcyAoY29uc3RyYWluZWQgZGV2 aWNlDQogICAgPj4gbWFuYWdlbWVudCB2cyB1bmNvbnN0cmFpbmVkIGRldmljZSBtYW5hZ2VtZW50 KSAuICBJIGFtIG5vdCBzdXJlIHdlDQogICAgPj4gc2hvdWxkIGdlbmVyYWxpemVkIFJFU1RDT05G IGFuZCBDT1JFQ09ORiBpbnRvIGEgc2luZ2xlIHByb3RvY29sLg0KDQogICAgPiBUaGF0J3Mgbm90 IHdoYXQgSSdtIHN1Z2dlc3RpbmcuICBJJ20gYXNraW5nLCBpZiBiYW5kd2lkdGggaXMgYW4gaXNz dWUsDQogICAgPiB3aHkgbm90IHVzZSBhIHNtYWxsZXIgZW5jb2RpbmcuICBBbmQsIHdoeSBub3Qg aW50ZWdyYXRlIHdpdGggQ29BUA0KICAgID4gT2JzZXJ2ZT8NCg0KZHJhZnQtYmlya2hvbHoteWFu Zy1jb3JlLXRlbGVtZXRyeS0wMSBbbm93IGV4cGlyZWRdIGZvciBpbnN0YW5jZSB0cmllcyB0byBk byBhIGxvdCBvZiB0aGUgbWF0Y2hpbmcuICBJIHRoaW5rIHRoYXQgdGhlIGFkYXB0aXZlIHJhdGUg c3Vic2NyaXB0aW9uIHRoYXQgeW91J3ZlIGNyZWF0ZWQgd291bGQgd29yayB2ZXJ5IHdlbGwgd2l0 aGluIHRoYXQgbW9kZWwuDQpbUWluXTogV2VsbCwgSSB3aWxsIGludmVzdGlnYXRlIHRoaXMgYW5k IHNlZSB3aGF0IGlzIG1pc3NpbmcgdGhlcmUuDQpJIGd1ZXNzIHlhbmctY29yZS10ZWxlbWV0cnkt MDEgbmVlZHMgdG8gdXBkYXRlIGl0c2VsZiBhcyBpZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3Rp ZmljYXRpb25zIGlzIHB1Ymxpc2hlZCBhcyBSRkMgODYzOSByaWdodC4NCltRaW5dOiBBZ3JlZS4g DQpJIHN0aWxsIGRvbid0IGtub3cgaG93IFhQYXRoIHdvdWxkIHdvcmsgd2l0aCBDT01JLCBidXQg cmVhbGx5IEknbSBqdXN0IHNpdHRpbmcgYXJvdW5kIHRoZSBlZGdlcyBvZiB0aGUgWUFORyBvdmVy IHRoZSB3aXJlIHNwYWNlLg0KW1Fpbl06IEdvb2QgcXVlc3Rpb24sIG5vdGUgdGhhdCBYUEFUSCB1 c2VkIGZvciBORVRDT05GIGZvbGxvd3MgWFBhdGggMS4wIFtXM0MuUkVDLXhwYXRoLTE5OTkxMTE2 XSBhbmQgWFBhdGggMi4wDQpTZWUgUkZDNjI0MSBzZWN0aW9uIDguOSBhbmQgUkZDNzk1MCBzZWN0 aW9uIDYuNC4NCi0tDQpNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4g ICAuIG8gTyAoIElQdjYgScO4VCBjb25zdWx0aW5nICkNCiAgICAgICAgICAgU2FuZGVsbWFuIFNv ZnR3YXJlIFdvcmtzIEluYywgT3R0YXdhIGFuZCBXb3JsZHdpZGUNCg0KDQoNCg0K From nobody Fri Jun 25 10:12:17 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34D23A0BF1; Fri, 25 Jun 2021 10:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53H_1TjRMAYX; Fri, 25 Jun 2021 10:12:06 -0700 (PDT) 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 017E43A0BF0; Fri, 25 Jun 2021 10:12:06 -0700 (PDT) Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GBNdr5098z6G8LR; Sat, 26 Jun 2021 01:04:32 +0800 (CST) Received: from dggeml751-chm.china.huawei.com (10.1.199.150) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Fri, 25 Jun 2021 19:12:03 +0200 Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml751-chm.china.huawei.com (10.1.199.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Sat, 26 Jun 2021 01:12:01 +0800 Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2176.012; Sat, 26 Jun 2021 01:12:00 +0800 From: Qin Wu To: Michael Richardson , "netconf@ietf.org" , "core@ietf.org" Thread-Topic: [core] some comments on netconf-adaptive-subscription Thread-Index: Addp5FkYCLrfoHWHSouJ7G0uLCP+5w== Date: Fri, 25 Jun 2021 17:12:00 +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.52.202.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [core] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 17:12:11 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBNaWNoYWVsIFJpY2hhcmRzb24gW21h aWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2FdIA0K5Y+R6YCB5pe26Ze0OiAyMDIx5bm0NuaciDI2 5pelIDA6NTgNCuaUtuS7tuS6ujogUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+OyBuZXRjb25m QGlldGYub3JnOyBjb3JlQGlldGYub3JnDQrkuLvpopg6IFJlOiBbY29yZV0gc29tZSBjb21tZW50 cyBvbiBuZXRjb25mLWFkYXB0aXZlLXN1YnNjcmlwdGlvbg0KDQpRaW4gV3UgPGJpbGwud3VAaHVh d2VpLmNvbT4gd3JvdGU6DQogICAgbWNyPiBJIGRpZG4ndCBmaW5pc2ggbXkgdGhvdWdodCBoZXJl LiAgU3BlY2lmaWNhbGx5LCBpdCBzZWVtcyB0aGF0IHRoZSBDT1JFDQogICAgbWNyPiBXRyBpcyBk b2luZyBhIGxvdCBvZiBzdHVmZiB3aXRoIENvQVAgT2JzZXJ2ZXMgYW5kIFNFTk1MIGFuZCBhbGwg c29ydHMNCiAgICBtY3I+IG9mIGludGVyZXN0aW5nIHRyaWdnZXJzLg0KDQogICAgUWluPiBkYXRh IG1vZGVsaW5nIGxhbmd1YWdlIHN1Y2ggYXMgWUFORyBjYW4gYmUgY29tbW9uIHdvcmsgZm9yIGJv dGggQ09SRQ0KICAgIFFpbj4gV0cgYW5kIE5FVENPTkYgV0csIEJ1dCB0aGV5IG1heSBjaG9vc2Ug ZGlmZmVyZW50IHRyYW5zcG9ydCBwcm90b2NvbCwNCiAgICBRaW4+IHN1Y2ggYXMgTkVUQ09ORiwg UkVTVENPTkYsIEhUVFAgMi4wLCBDT0FQLCBNUVRULCBDT01JIFNlY29uZGx5LCBJDQogICAgUWlu PiB0aGluayBpdCB3aWxsIGJlIG5pY2UgdG8gc2VwYXJhdGUgY29uc3RyYWluZWQgZGV2aWNlIG1h bmFnZW1lbnQgZnJvbQ0KICAgIFFpbj4gcmVzb3VyY2UgdW5jb25zdHJhaW5lZCBuZXR3b3JrIGRl dmljZSBtYW5hZ2VtZW50LCBDb25zdHJhaW50IGRldmljZQ0KICAgIFFpbj4gYXMgSW9UIGRldmlj ZSBjYW4gYmUgdGVtcGVyYXR1cmUgc2Vuc29yLCBjdXJyZW50LCB2b2x0YWdlIHNlbnNvcg0KICAg IFFpbj4gd2hpY2ggY2FuIGJlIHNlZW4gYXMgYWZmaWxpYXRlZCBkZXZpY2VzIHBlcnRhaW5pbmcg dG8gcmVzb3VyY2UNCiAgICBRaW4+IHVuc3RyYWluZWQgbmV0d29yayBkZXZpY2UuDQoNCnRlbXBl cmF0dXJlLCBjdXJyZW50IGFyZSBjcml0aWNhbCB2YWx1ZXMgZm9yIHJvdXRpbmcgZXF1aXBtZW50 LCBhcmVuJ3QgdGhleT8NCg0KW1Fpbl06IE15IHVuZGVyc3RhbmRpbmcgaXMgeWVzLCB0aGVyZSBp cyBoYXJkd2FyZSBZQU5HIG1vZGVsIHdoaWNoIGNhbiBiZSB1c2VkIHRvIGNvbGxlY3QgdGhlc2Ug aW52ZW50b3J5IGRhdGEgYXNzb2NpYXRlZCB3aXRoIHRoZSByb3V0aW5nIGVxdWlwbWVudA0KU2Vl IFJGQzgzNDguDQoNCiAgICBRaW4+IEluIGRhdGEgY2VudGVyIHNjZW5hcmlvcywgd2UgZG8gc2Vl IGEgbG90IG9mIHN1Y2ggYWZmaWxpYXRlZCBkZXZpY2VzIG9yDQogICAgUWluPiBzZW5zb3JzIHN1 Y2ggYXMgYWlyIGNvbmRpdGlvbmVyLCB3YXRlciBsZWFrYWdlIGFsYXJtIHNlbnNvciBkZXBsb3ll ZA0KICAgIFFpbj4gdG9nZXRoZXIgd2l0aCBkYXRhIGNlbnRlciBzd2l0Y2ggZGV2aWNlcy4gIFRo ZXNlIElvVCBkZXZpY2VzIG9ubHkNCiAgICBRaW4+IHVzZSBNUVRUL0NPQVAvSFRUUCB0byBjb21t dW5pY2F0ZSB3aXRoIHRoZWlyIElvVCBwbGF0Zm9ybSwgZm9yIGRhdGENCiAgICBRaW4+IGNlbnRl ciBzd2l0Y2ggZGV2aWNlcywgeW91IG1heSBzdGlsbCByZWx5IG9uIG5ldHdvcmsgbWFuYWdlbWVu dA0KICAgIFFpbj4gcHJvdG9jb2xzIHN1Y2ggYXMgTkVUQ09ORiwgU05NUCwgZ1JQQywgZXRjLiAg RG8geW91IHNlZSB0aGlzDQogICAgUWluPiBkaWZmZXJlbnRseT8gTWljaGFlbD8NCg0KSXQgc2Vl bXMgdGhhdCB3ZSBvdWdodCB0byBzZWVrIGNvbnZlcmdlbmNlIGhlcmUuDQpUaGF0J3Mgd2hhdCBJ J20gc2F5aW5nLiAgVGhhdCBhbnkgc3BsaXQgaGVyZSBpcyBmb3IgaGlzdG9yaWNhbCByZWFzb25z LCBhbmQgZG9lcyBub3QgbWFrZSBzZW5zZSBnb2luZyBmb3J3YXJkLg0KDQpbUWluXTogVGVuZCB0 byBhZ3JlZSwgdW5pZmllZCBkYXRhIG1vZGVsaW5nIG9yIHNlbWFudGljcyBpbnRlcm9wZXJhYmls aXR5IG1heSBiZSB0aGUgc29sdXRpb24uIE9uZSBvZiBleGFtcGxlIGlzIHRvDQpCdWlsZCBkaWdp dGFsIHR3aW4gZGF0YSBtb2RlbCBhbmQgbW9kZWxzIHNlbnNvciBkYXRhIGFuZCBuZXR3b3JrIGRl dmljZSBoZWFsdGggZGF0YSB0b2dldGhlci4NCg0KLS0NCk1pY2hhZWwgUmljaGFyZHNvbiA8bWNy K0lFVEZAc2FuZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJw7hUIGNvbnN1bHRpbmcgKQ0KICAg ICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBPdHRhd2EgYW5kIFdvcmxkd2lk ZQ0KDQoNCg0KDQo= From nobody Fri Jun 25 14:08:44 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9100F3A082D; Fri, 25 Jun 2021 14:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, 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 WrEfQUz8BKi8; Fri, 25 Jun 2021 14:08:27 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA083A0827; Fri, 25 Jun 2021 14:08:27 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GBV3C5VpXz2xGb; Fri, 25 Jun 2021 23:08:23 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 646348103.259271-3cd40f942b38302a328a5b2d0665a0e0 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Fri, 25 Jun 2021 23:08:23 +0200 Message-Id: <352EE1F2-0BF6-4B97-B1FE-78FDB1714CE5@tzi.org> To: ace@ietf.org, core , cose , cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [core] Constrained Node/Network Cluster @ IETF111: DRAFT AGENDA X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 21:08:34 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF111. Remember that there is still quite some potential for changes. The IoT-relevant conflicts that most meet the eye this time are LAKE/RATS, IOTOPS/RATS (and there is likely to be an IoT-relevant discussion at tsvwg, which overlaps the third RATS). All times *on my agenda* are in UTC (the default page is UTC-0700). Please forgive the 2500, I'm way too lazy to write code to turn this into 0100. (And it is advisable to ignore the fictional end time of the Wednesday plenary anyway.) https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten 1900-2100 Hackathon Kickoff Rm 1 GEN hackathon Hackathon FRIDAY, July 23, 2021 1900-2100 Hackathon Closing Rm 1 GEN hackathon Hackathon MONDAY, July 26, 2021 1900-2100 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 2 IRTF anrw ACM/IRTF Applied Networking Research = Workshop - New Internet Protocols & Practical Congestion Control Rm 3 IRTF pearg Privacy Enhancements and Assessments = Research Group Rm 7 SEC gnap Grant Negotiation and Authorization = Protocol WG 2130-2230 Session II Rm 1 ART wpack Web Packaging WG Rm 2 IRTF irtfopen IRTF Open Meeting Rm 3 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 4 RTG babel Babel routing protocol WG Rm 7 SEC *** rats Remote ATtestation ProcedureS WG Rm 8 TSV (!) tsvwg Transport Area Working Group WG 2300-2500 Session III Rm 2 ART jsonpath JSON Path WG Rm 3 IRTF coinrg Computing in the Network Research Group Rm 7 SEC secdispatch Security Dispatch WG Rm 8 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG TUESDAY, July 27, 2021 1900-2100 Session I Rm 1 ART sedate Serialising Extended Data About Times = and Events WG Rm 2 INT 6man IPv6 Maintenance WG Rm 3 IRTF anrw ACM/IRTF Applied Networking Research = Workshop - Interconnection and Routing & Monitoring Internet Traffic Rm 5 RTG bier Bit Indexed Explicit Replication WG Rm 6 RTG raw Reliable and Available Wireless WG Rm 7 SEC *** danish DANE AutheNtication for Iot Service = Hardening BOF Rm 8 TSV quic QUIC WG 2130-2230 Session II Rm 3 INT dnssd Extensions for Scalable DNS Service = Discovery WG Rm 6 SEC saag Security Area Open Meeting Rm 7 TSV taps Transport Services WG 2300-2500 Session III Rm 7 SEC ohttp Oblivious HTTP BOF WEDNESDAY, July 28, 2021 1900-2100 Session I Rm 1 ART *** core Constrained RESTful Environments WG Rm 3 INT madinas MAC Address Device Identification for = Network and Application Services BOF Rm 4 IRTF anrw ACM/IRTF Applied Networking Research = Workshop - Privacy & Applications Rm 7 SEC tls Transport Layer Security WG 2130-2230 Session II Rm 2 ART uta Using TLS in Applications WG Rm 4 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 5 INT *** drip Drone Remote ID Protocol WG Rm 8 RTG rift Routing In Fat Trees WG Rm 9 SEC *** cose CBOR Object Signing and Encryption WG 2300-2440 IETF Plenary - Plenary THURSDAY, July 29, 2021 1900-2000 Session I Rm 3 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 4 OPS v6ops IPv6 Operations WG Rm 7 SEC *** lake Lightweight Authenticated Key Exchange = WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG Rm 9 TSV tsvarea Transport Area Open Meeting 2030-2130 Session II Rm 5 IRTF qirg Quantum Internet Research Group Rm 6 OPS *** iotops IOT Operations WG Rm 7 RTG rtgarea Routing Area Open Meeting Rm 9 SEC mls Messaging Layer Security WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG 2200-2300 Session III Rm 5 SEC *** ace Authentication and Authorization for = Constrained Environments WG 2330-2430 Session IV Rm 4 IRTF panrg Path Aware Networking RG Rm 8 SEC emu EAP Method Update WG Rm 9 SEC *** teep Trusted Execution Environment = Provisioning WG FRIDAY, July 30, 2021 1900-2100 Session I Rm 1 ART webtrans WebTransport WG Rm 2 INT add Adaptive DNS Discovery WG Rm 5 RTG apn Application-aware Networking BOF Rm 7 SEC *** suit Software Updates for Internet of Things = WG 2130-2230 Session II Rm 1 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 2 IRTF maprg Measurement and Analysis for Protocols Rm 5 RTG detnet Deterministic Networking WG Rm 6 SEC acme Automated Certificate Management = Environment WG Rm 7 SEC privacypass Privacy Pass WG 2300-2500 Session III Rm 1 ART httpapi Building Blocks for HTTP APIs WG Rm 2 INT intarea Internet Area Working Group WG Rm 3 IRTF cfrg Crypto Forum Rm 4 IRTF*** dinrg Decentralized Internet Infrastructure Rm 8 SEC *** teep Trusted Execution Environment = Provisioning WG Rm 9 TSV tsvwg Transport Area Working Group WG From nobody Fri Jun 25 14:50:09 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C5C3A0B44; Fri, 25 Jun 2021 14:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.338, 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 (1024-bit key) header.d=fraunhofer.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 5nADADz3Pj7W; Fri, 25 Jun 2021 14:50:03 -0700 (PDT) Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (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 916053A0B40; Fri, 25 Jun 2021 14:50:01 -0700 (PDT) IronPort-SDR: b7n4w2pZ4u0a7xLT95VhwKbVWBHikE8a8QDgRZfKBYeS/2lHXWcXNHFf5V0k72n8yGdbJTTOv2 QlogIL/4FY8A== IronPort-PHdr: =?us-ascii?q?A9a23=3A1o5l1hMScEvAC3TtmEYl6nfnWUAX0o4cdiYU5?= =?us-ascii?q?4YpzbVUfffr85fjORnZ4vNgxB/MUJ7A4v1Jw+zRr+j7WGMG7JrA1RJKcJFFW?= =?us-ascii?q?xIfz8lDmQsmDZ2EBFH1avnwYH9yEMFLTlQw+Xa9PABcE9r/YFuHpHq04HYSF?= =?us-ascii?q?xzzOBAzKP7yH9vJjtjx2fq75pvTZAtFnnyxbOAaEQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GtDQB6TtZg/xmnZsBagQmDKlF+gUI?= =?us-ascii?q?LhD2DAkcBAYU5iDktA4ENmRCCUwNJCwsBAQEBAQEBAQEIASoLCgIEAQEDA4F?= =?us-ascii?q?YgjBEAjWCPQElOBMCBAEBARIBAQYBAQEBAQYEAgKBAIVoDYNWgQgBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAkFHDDIBAQEDAQEQEQ8?= =?us-ascii?q?BBQgBASwMDwkCDgoCAgkaAwICJwsUEQYBDAYCAQEegk8BglUDLgEBAwuMcY8?= =?us-ascii?q?0AYE6AoofeoEygQGCBwEBBgQEgUhBRoJqGFiBWgMGCQGBBiqCe4Z1g3onEIF?= =?us-ascii?q?VRIEVJw+CNzY+gmIBAQOEdIJkgj1haEMQIDsnW4EXkQcWjzCbHCwHgX2BJoE?= =?us-ascii?q?nBguIX5NlBhMmg1+RLAaQa5VkghiKCpNHhG0CBAIEBQIOAQEGgWuBfk0kT4I?= =?us-ascii?q?1ATNQFwIOi0eCZBaDToUUhUxxOAIGAQkBAQMJWyGKVQEyXgEB?= X-IPAS-Result: =?us-ascii?q?A2GtDQB6TtZg/xmnZsBagQmDKlF+gUILhD2DAkcBAYU5i?= =?us-ascii?q?DktA4ENmRCCUwNJCwsBAQEBAQEBAQEIASoLCgIEAQEDA4FYgjBEAjWCPQElO?= =?us-ascii?q?BMCBAEBARIBAQYBAQEBAQYEAgKBAIVoDYNWgQgBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEFAkFHDDIBAQEDAQEQEQ8BBQgBASwMDwkCD?= =?us-ascii?q?goCAgkaAwICJwsUEQYBDAYCAQEegk8BglUDLgEBAwuMcY80AYE6AoofeoEyg?= =?us-ascii?q?QGCBwEBBgQEgUhBRoJqGFiBWgMGCQGBBiqCe4Z1g3onEIFVRIEVJw+CNzY+g?= =?us-ascii?q?mIBAQOEdIJkgj1haEMQIDsnW4EXkQcWjzCbHCwHgX2BJoEnBguIX5NlBhMmg?= =?us-ascii?q?1+RLAaQa5VkghiKCpNHhG0CBAIEBQIOAQEGgWuBfk0kT4I1ATNQFwIOi0eCZ?= =?us-ascii?q?BaDToUUhUxxOAIGAQkBAQMJWyGKVQEyXgEB?= X-IronPort-AV: E=Sophos;i="5.83,300,1616454000"; d="scan'208";a="30001488" Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2021 23:49:57 +0200 IronPort-SDR: xoXhfu7HU1qYTJwGqkaRHTFLzS/bxzMnQdY9Ti5qfdqeW40qMymgA85VICH1g6lXGb91yn1UV2 Brnv12HYsY/Xfey80D38cwaJix7U2eB0k= IronPort-PHdr: =?us-ascii?q?A9a23=3A/rM8/BZcpuLN04Ty3uER/Uj/LTDNhN3EVzX9o?= =?us-ascii?q?rImhq5ANKO58MeqME/e4KBri1nEFcXe5ulfguXb+6bnRSQb4JmHvXxDFf4EV?= =?us-ascii?q?xIMhcgM2QB1BsmDBB76IeLkKSsgE5cKWFps5XruN09TFY73bEHTpXvn6zkUF?= =?us-ascii?q?13/OAN5K/6zFJTVipGs1vz09YfafgNIgzSwe/V+IUbekA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AJaEVCaHvCpIwqvG7pLqEjceALOsnbusQ8z?= =?us-ascii?q?AXPidKOH9om62j9/xG885w6faZslsssRIb+OxoWpPufZq0z/ccirX5Vo3NYO?= =?us-ascii?q?CJggeVEL0=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7TwD8TtZg/z6wYZlagQkJgVCBPAI?= =?us-ascii?q?BElEHTCtaJUMLhD2DAkcBAYU5hkaBcy0DOAFUmRCCUwNUCwEDAQEBAQEIAQQ?= =?us-ascii?q?mCwkBAgQBAYFegjBEAjWCOgImOBMCBAEBARIBAQUBAQECAQYEcROFaA1DAQw?= =?us-ascii?q?BhXUBAQQBARARDwEFCAEBFBgMDwkCDgoCAgkaAwICJwsHDREGAQwGAgEBHoJ?= =?us-ascii?q?PAYJVAy4CAwuMb480AYE6AoofeoEygQGCBwEBBgQEgUhBRoJqGFiBWgMGCQG?= =?us-ascii?q?BBigCAQEBgniGdYN6N4FVRIEVJw+CNzY+gmIBAQOEdIJkgj1haEMQIDsnW4E?= =?us-ascii?q?XkQcWjzCbHCwHgX2BJoEnBguIX5NlBhMmg1+RLAaQa5VkghiKCpNHhG0CBAI?= =?us-ascii?q?EBQIOAQEGgWskgVlNJE+CNQEzUBcCDotHgmQWg06FFIVMcTgCBgEJAQEDCVk?= =?us-ascii?q?BASGCZodvATJeAQE?= X-IronPort-AV: E=Sophos;i="5.83,300,1616454000"; d="scan'208";a="114399021" Received: from 153-97-176-62.vm.c.fraunhofer.de (HELO mobile.exch.fraunhofer.de) ([153.97.176.62]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2021 23:49:52 +0200 Received: from XCH-HYBRID-02.ads.fraunhofer.de (10.225.8.59) by XCH-HYBRID-01.ads.fraunhofer.de (10.225.8.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.12; Fri, 25 Jun 2021 23:49:52 +0200 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (10.225.8.37) by XCH-HYBRID-02.ads.fraunhofer.de (10.225.8.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.858.12 via Frontend Transport; Fri, 25 Jun 2021 23:49:52 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LM+4cJIWT5GG7RHlF6j35xdfF5t6XBsV6pUN/o7Amx6tW7MWppGFCAC2WlJL2dZHugiIxO1V6nJsscDf/Y0WWZ82wzlcJTPrf+OV1sFJmLu4j25HMgfJkAE6x3l1FwdHcejxBY7zthxlUWHA2ASFuWHVo52DX7rRTdTduSorAyep+4kgObOOXhxvJQV1OFqiiwfmF/qKIvUddQ4yStEVbdninChzIFSo6oik9otQ+h5cnD0QeerBo7lIzRIPVzZ3RSTNsZULOOuGS2Cn/k9qS6Wfa48uLejNKDCPZ3zB2ke2GEyF6KHgeU98jqrjrB7l+CpBP6mwU96Gbcnky30rzw== 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=YE31nq5ZRiISgbelL5tAyP0AU0AJY0knEaQkEoNVmyw=; b=UpjOkSOHzpqTcC1UEzX0P2LE8WAFTYSG/JjaYN1iK6kGQ1Q11T34ZdmWvL9g95eAHNwLT9Sar52UvjfV7glGIdMLuSlvOoAQ0D7jTUs5i0j1nOWQMGMTNdyH1ULOXawV9X9uaUBXISl7qhvy3Nu0wk2ZWgsIcpZD/EGTXrZmSTjAv0BsKm06i0+XeddyHKFUwNEHzJSdCSN4kMQdCDBoiM6sRumTKCce4+qewsEPqBDiY8Vv+P+ykNs3yQYLiiteIEdU7k7onVhGl2+GSBwSlaj+P5hdlALUI1wm+vDn1r+cKC7QcwLmJmSphac2WUay4dlNG+4fKA3lFCsGZn4gWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sit.fraunhofer.de; dmarc=pass action=none header.from=sit.fraunhofer.de; dkim=pass header.d=sit.fraunhofer.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fraunhofer.onmicrosoft.com; s=selector2-fraunhofer-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YE31nq5ZRiISgbelL5tAyP0AU0AJY0knEaQkEoNVmyw=; b=BpU17vWJoxRrBQYILs5n67XLoV4pwahWjgjTgmPaeOa1Ud+3mik6R3KMDHvO44r1f63s4Dlh5MifpgO0Q8m8ad6YhzTZGdU1xc0Wa9RGAyFmyFcycNe0+tn+GDwl9etMmIbXgRKJv/AsYwXJ0IxNxUpL9ufRKj4qTZIyxAmXryM= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=sit.fraunhofer.de; Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) by DB6P194MB0134.EURP194.PROD.OUTLOOK.COM (2603:10a6:4:c6::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Fri, 25 Jun 2021 21:49:50 +0000 Received: from DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::ac4d:c6fc:9d66:ba8f]) by DU2P194MB1709.EURP194.PROD.OUTLOOK.COM ([fe80::ac4d:c6fc:9d66:ba8f%5]) with mapi id 15.20.4264.023; Fri, 25 Jun 2021 21:49:50 +0000 To: Qin Wu , Michael Richardson , "netconf@ietf.org" , "core@ietf.org" References: <34e1882b99774c4e94216050aefafe78@huawei.com> From: Henk Birkholz Message-ID: Date: Fri, 25 Jun 2021 23:49:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <34e1882b99774c4e94216050aefafe78@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.151.153] X-ClientProxiedBy: AM4PR0701CA0022.eurprd07.prod.outlook.com (2603:10a6:200:42::32) To DU2P194MB1709.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:276::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.16.50] (79.206.151.153) by AM4PR0701CA0022.eurprd07.prod.outlook.com (2603:10a6:200:42::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.12 via Frontend Transport; Fri, 25 Jun 2021 21:49:49 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8487fb34-0cef-477c-7366-08d938232844 X-MS-TrafficTypeDiagnostic: DB6P194MB0134: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3+JwVTD1lye1Yzc1wSuVVrAsK+8BM5hFjxbIDgfsGUJl9eAtcm21qbBv+94xYZaZnm/5AqvSdXkNJyK01rNGs58WPLISoj49KuCopgpGR40pZ+pmk24Znzeld+Q/wbGv3xNf20IHHAmoJVoPsBbYoaC/eVtOSwdz+Qna1kJFXuXBtKb4VgqicncAnMUBOHQzMDWBxAk1yrXFSYWVn8Dho3I8xyCwYHgxCW9AuDIraLnOhxETPRx+OlpQRz+7/1eaXNDu605g9ifjbBkWQwh8CnExX2a8VLOMSBOf1QwQbVyvFyTNQdL0Mq+iwig4iWCTjvJmD7iJGHEHJBoKf9xOP0ndSKza25rwm3AYNTSl7133hzABMnP4lLNPCpSSns7lCbpSXU8MqME5X8ONQ/kfNhPtutHLdXgc5avE5EMxHILtLSE/bD/WxOlu/5kK7jaqJEHux8Vu7qFKM2LHMFepw25CkVum6tTS6771aM/EcM6hs8laSZ1KsvZWtb+C8YAUsPVHtzui0gK9IEdUoEF8/QEy+PjxG2GcVVYBiVsrjvC2YVLe2+a0fgq0JkhjZCNHqKpS5OblAg2TbdYWTGHIpes3/wo6qDcdsCMRcX7V1aE/5/jzCcU2U8uNhxCaX2YETTEJJY/0UWGSc0XDbYMtXkIfizBGt20mAdrAth8nlw5rMLQ7d9RG9NwnbS5el11xhez3UMAwMy2Zd+GnyWtHsMWtKI79eiJNVcUuAlxODqGvuEY/xeiP6L2L1ujd0BEEE7GXNuWNPjdy39yHwxKinua7lNdEIUi9tjCDgzfxvmbRrIaV6JKuM4R5+RUYHGGV5SVXT6CgAezmltMxiI1Fm4IqmPMLtVEQFchsseKqHDvF5/IGvJrD1ziE2WItLwzO X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU2P194MB1709.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(376002)(136003)(396003)(39830400003)(2906002)(66946007)(53546011)(478600001)(66574015)(31686004)(956004)(86362001)(26005)(83380400001)(31696002)(44832011)(2616005)(66556008)(66476007)(8676002)(186003)(38100700002)(38350700002)(16576012)(110136005)(316002)(16526019)(8936002)(5660300002)(966005)(6486002)(52116002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eHNKZTlaUnZNcU1ZcCswOGJoTWtkOG9uSHl2Y05NLzZXU3dVK3E1ZU1BWmZ1?= =?utf-8?B?djYzRnBneDRzNUdNUmpSYU5tTU1FZVVYcW90UTk1VmFpaCtGV0tRSmh5YlY4?= =?utf-8?B?dWtzTjBGczNQdTNpWGpuUkxiRlJVY1VSUHdhWFFVY2xTd0hmcFlOWjdHWnVQ?= =?utf-8?B?bEdEdFJndlFWcmF3VnhZMDA4MUo4M1NaUG1WVW1IWkVBRXNPTEhLb3B5S3F6?= =?utf-8?B?azR2TXExUmtBbU5XcnRhY08zaW9TZEtLN254UlNtbjM5NXlsazJBZWt0MUNM?= =?utf-8?B?Y1hSYkdRL0VHTUpDRzhQOU5aSjREd0d6ZUNEUUcydzVxclI2ZTExWno4YVB0?= =?utf-8?B?SkgvbTRxenErQVFPK29ieWw2SGwwb3Rua1RsaTRNRTY5MHRZdE96V2tRbWYy?= =?utf-8?B?YjZ0MnNDZENNSnQ1OURnaDc2Mm43bWN5SjZoYk1hSHgzdVFEaWl3Vzh1L2lS?= =?utf-8?B?MWNnN2pPVXpuRks0ZTdOTzFGR2FZM2FsTi9XRDRqK2xWaXRLcDQ4aS9CMlZa?= =?utf-8?B?dmZucWg4SlRPelRTWkhUbnU1blg4RVQrazUyelh0aE5mVy9lZEJKdHBHenZj?= =?utf-8?B?SHpMYVIzcWh5M1NZc3BLVTFkMlgyRHZvbGRMZTM1bldYVENtMVUyamx1SEFV?= =?utf-8?B?TU9RdkEvaVE1NG9mTVhMNVMrUjJkR3R3OFlETFFNNzRDQ09qT2h0eHlndFZx?= =?utf-8?B?d0ZjUjZMOUU2a1ZBN3VFaXRSYWpZcmE4SHhRVWdid2tQbWg2WnVocER3YVg5?= =?utf-8?B?ZHJlTHFVZEVjVklzcVhEc0RkWG9CZVd4VThFNUtzNTR0ckV6V3F0R0pNMTlK?= =?utf-8?B?Si95ZjRDUFQ4VVVhWXNFZWVTK0pMdm5GbFFMeG1wa3ZHYWVWeHUxQTk0enk2?= =?utf-8?B?OWJJeDd0N3NrRkQyMzBTMUdiaWcyVU8rQ29xZEJod0NZamMwa1NmTWJtN09I?= =?utf-8?B?eGdHMUJ4VWlvY0hnTHhSNHJZc1AyaU1wM2pvV0lLbThPN3NUWGZjU01UZHhS?= =?utf-8?B?aTRiait5TVVyejB2RzFZUXlRUHFjNU5uSGFvSTI3TVYxVGthcG1iYjhyWms1?= =?utf-8?B?OG50QUt4M3pEaVBEeDNyTUMzdGppUlowMzJpUU5CbTNzOG0ySFRTM0hnM1Vj?= =?utf-8?B?cGFwY3lETmo4aURJcGxhZVBLTWtxZ2VNUjdPdEwvSnJHdHNjRVd2UTI4OG45?= =?utf-8?B?cXlDQ0hSamtuZFZoTkVzMjI3SUdjSVpiVmVPZXdZenRueVVhRW1GekRqdjNz?= =?utf-8?B?cFVZZnVmL0NwTE1hVXcydE5wbE82czhUb3p3aWhSbmFKMStVeW1iY0FhSldk?= =?utf-8?B?bHpTaEtzY0JLZEhTcnBDYUJiKzMxOEhlb3dFbDdoS3d5MkUya3d6RXNzM3ha?= =?utf-8?B?WnFhZFYxZG12NG1YQW5xdFBKTTRsalZpYkpzZ255TGZoeDgzbDd2SGpRb0xr?= =?utf-8?B?TUYzbCt2ZXNkSUNqR3lHWFN5b3VQZzRLRFRYb1c0bmszMWg0U3dUc0wxalJE?= =?utf-8?B?S2hwSFVnYWRpTkM0ellFUE9wMm5wWU0wUGlNK3pvYWhudnhaaERKQk16N3R4?= =?utf-8?B?ZUZadkg0ejFxSWQrWko4Mnp5TDZGbmlmdHZ4dW5BMDU0SlNEZ2x5cDVla1dl?= =?utf-8?B?VE9oZjdRV2ZiMEtiLzNqL1hJa1ZRSXhES2U4V3BWd0FKb09kOWlENWxxeVA2?= =?utf-8?B?RlVQUFBRUE52NE90SlRvb0wwdFdQeHB6UDlkV1ZURW9OYTB0UER1ZTRGb3JY?= =?utf-8?Q?/rSCO4GLPy1ecPg/eF72cRO0X2jqA0ce6isb4ci?= X-MS-Exchange-CrossTenant-Network-Message-Id: 8487fb34-0cef-477c-7366-08d938232844 X-MS-Exchange-CrossTenant-AuthSource: DU2P194MB1709.EURP194.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2021 21:49:50.1465 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f930300c-c97d-4019-be03-add650a171c4 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: VUqYHR2AdoDgjqMlnKGi4fU+iVRvWcFDrvkXdPVD8CEjo8RP7yIMz5DO8jjf1pu4g3ih0r/82Um5CQmd2xVjgoyzp/Hj8qxG5TDD9Z3y0E4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P194MB0134 X-OriginatorOrg: sit.fraunhofer.de Archived-At: Subject: Re: [core] [netconf] some comments on netconf-adaptive-subscription X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 21:50:08 -0000 Hi Michael, hi Qin, hi all, I am painfully aware that I did not find the cycles to progress Concise YANG Telemetry in the recent past. This seems to be a good opportunity to change that :-) Wrt the topic of XPATH, there is https://datatracker.ietf.org/wg/jsonpath/about/ now and specifically https://datatracker.ietf.org/doc/draft-ietf-jsonpath-base/ It probably makes sense to create an I-D here that tracks the gaps that need to be bridged to do a CBORPATH for CORECONF. I'll take that item in concert with rekindling the other one. Viele Grüße, Henk On 25.06.21 19:04, Qin Wu wrote: > -----邮件原件----- > 发件人: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > 发送时间: 2021年6月26日 0:51 > 收件人: Qin Wu ; netconf@ietf.org; core@ietf.org > 主题: Re: some comments on netconf-adaptive-subscription > > > Michael Richardson wrote: > >> [Qin]: I am also hoping RESTCONF and CORECONF can work together, but > >> they seems to look into different use cases (constrained device > >> management vs unconstrained device management) . I am not sure we > >> should generalized RESTCONF and CORECONF into a single protocol. > > > That's not what I'm suggesting. I'm asking, if bandwidth is an issue, > > why not use a smaller encoding. And, why not integrate with CoAP > > Observe? > > draft-birkholz-yang-core-telemetry-01 [now expired] for instance tries to do a lot of the matching. I think that the adaptive rate subscription that you've created would work very well within that model. > [Qin]: Well, I will investigate this and see what is missing there. > I guess yang-core-telemetry-01 needs to update itself as ietf-netconf-subscribed-notifications is published as RFC 8639 right. > [Qin]: Agree. > I still don't know how XPath would work with COMI, but really I'm just sitting around the edges of the YANG over the wire space. > [Qin]: Good question, note that XPATH used for NETCONF follows XPath 1.0 [W3C.REC-xpath-19991116] and XPath 2.0 > See RFC6241 section 8.9 and RFC7950 section 6.4. > -- > Michael Richardson . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Jun 29 02:18:49 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A0A3A2C7A for ; Tue, 29 Jun 2021 02:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hl7gY-Awhkrc for ; Tue, 29 Jun 2021 02:18:43 -0700 (PDT) Received: from smtpout1.mo529.mail-out.ovh.net (smtpout1.mo529.mail-out.ovh.net [178.32.125.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9459F3A2C5B for ; Tue, 29 Jun 2021 02:18:41 -0700 (PDT) Received: from mxplan6.mail.ovh.net (unknown [10.108.16.62]) by mo529.mail-out.ovh.net (Postfix) with ESMTPS id A02F9B13ABC6 for ; Tue, 29 Jun 2021 11:18:38 +0200 (CEST) Received: from simonbernard.eu (37.59.142.98) by DAG3EX2.mxp6.local (172.16.2.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 29 Jun 2021 11:18:37 +0200 Authentication-Results: garm.ovh; auth=pass (GARM-98R002f62213cf-d535-4a24-99e4-2aaeb02c2446, 41D70A9821A63A1868E3E232E7381517373EE788) smtp.auth=contact@simonbernard.eu X-OVh-ClientIp: 91.174.163.99 From: Simon Bernard To: "core@ietf.org WG" Message-ID: Date: Tue, 29 Jun 2021 11:18:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [37.59.142.98] X-ClientProxiedBy: DAG3EX1.mxp6.local (172.16.2.21) To DAG3EX2.mxp6.local (172.16.2.22) X-Ovh-Tracer-GUID: 2d663b5d-606b-4067-8a53-e5ae22fb5cbe X-Ovh-Tracer-Id: 16532151285921363991 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrfeehiedguddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefhuffvkffffgggtgfgiheshhekredttdefjeenucfhrhhomhepufhimhhonhcuuegvrhhnrghrugcuoegtohhnthgrtghtsehsihhmohhnsggvrhhnrghrugdrvghuqeenucggtffrrghtthgvrhhnpeejfefghfffgeetjefhveegveejhfdthffhleetuefhhedvhfevudeigfegvdejveenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedtrddtrddtrddtpdefjedrheelrddugedvrdelkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehmgihplhgrnheirdhmrghilhdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomheptghonhhtrggtthesshhimhhonhgsvghrnhgrrhgurdgvuhdprhgtphhtthhopegtohhrvgesihgvthhfrdhorhhg Archived-At: Subject: [core] More precision about CoAP Observe with FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 09:18:46 -0000

Hi all,

  The PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) (RFC8132) says that FETCH can be used with RFC7641 (Observing Resources in CoAP)
  

2.4.  Working with Observe

   The Observe option [RFC7641] can be used with a FETCH request as it
   can be used with a GET request
  But "CoAP Observe" seems to be designed with a "GET without payload" in mind.
  E.g. it says : 

3.1.  Request

   A client registers its interest in a resource by issuing a GET
   request with an Observe Option set to 0 (register).  If the server
   returns a 2.xx response that includes an Observe Option as well, the
   server has successfully added an entry with the client endpoint and
   request token to the list of observers of the target resource, and
   the client will be notified of changes to the resource state.

   Like a fresh response can be used to satisfy a request without
   contacting the server, the stream of updates resulting from one
   observation request can be used to satisfy another (observation or
   normal GET) request if the target resource is the same.  A client
   MUST aggregate such requests and MUST NOT register more than once for
   the same target resource.  The target resource is identified by all
   options in the request that are part of the Cache-Key. This includes,
   for example, the full request URI and the Accept Option. 

The target resource is not identified by the payload.  So 2 FETCH requests on same resource with 2 different payload seem to not be allowed ?

Is it intended or just an oversight ? if this is intended, is there any particular reason about this ?

Simon

From nobody Tue Jun 29 02:45:55 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199943A2D54 for ; Tue, 29 Jun 2021 02:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 f6O26oOvpaHD for ; Tue, 29 Jun 2021 02:45:51 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 A94C23A2D52 for ; Tue, 29 Jun 2021 02:45:50 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lyAJL-00049d-Dr; Tue, 29 Jun 2021 10:45:43 +0100 From: "Jon Shallow" To: "'Simon Bernard'" , References: In-Reply-To: Date: Tue, 29 Jun 2021 10:45:54 +0100 Message-ID: <013501d76ccb$8e2be040$aa83a0c0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0136_01D76CD3.EFF04840" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICowpRfhMxcn6CYMw9eR2mIOGlfarUT20g Content-Language: en-gb Archived-At: Subject: Re: [core] More precision about CoAP Observe with FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 09:45:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0136_01D76CD3.EFF04840 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Simon, =20 As per https://datatracker.ietf.org/doc/html/rfc8132#section-2 the = FEETCH request body is a part of the cache key. =20 Depending on the response code as defined by [RFC7252 = ], the response to a FETCH request is cacheable; the request body is part of the cache key. Specifically, 2.05 (Content) response codes (the responses for which are cacheable) are a typical way to respond to a FETCH request. (Note that this aspect differs markedly from [HTTP-SEARCH = ] and = also that caches that cannot use the request payload as part of the cache key will not be able to cache responses to FETCH requests at all.) The Max-Age option in the response has equivalent semantics to its use in a GET. =20 So, different payloads would create different cache keys and hence = individually be unique. Regards =20 Jon =20 From: Simon Bernard [mailto: contact@simonbernard.eu]=20 Sent: 29 June 2021 10:19 To: core@ietf.org WG Subject: [core] More precision about CoAP Observe with FETCH =20 Hi all, The PATCH and FETCH Methods for the Constrained Application Protocol = (CoAP) (RFC8132 ) says = that FETCH can be used with RFC7641 = (Observing Resources in = CoAP) =20 2.4 . = Working with Observe =20 The Observe option [RFC7641 = ] can be used with a = FETCH request as it can be used with a GET request But "CoAP Observe" seems to be designed with a "GET without payload" = in mind. E.g. it says :=20 3.1 . = Request =20 A client registers its interest in a resource by issuing a GET request with an Observe Option set to 0 (register). If the server returns a 2.xx response that includes an Observe Option as well, the server has successfully added an entry with the client endpoint and request token to the list of observers of the target resource, and the client will be notified of changes to the resource state. =20 Like a fresh response can be used to satisfy a request without contacting the server, the stream of updates resulting from one observation request can be used to satisfy another (observation or normal GET) request if the target resource is the same. A client MUST aggregate such requests and MUST NOT register more than once for the same target resource. The target resource is identified by all options in the request that are part of the Cache-Key. This includes, for example, the full request URI and the Accept Option. =20 The target resource is not identified by the payload. So 2 FETCH = requests on same resource with 2 different payload seem to not be = allowed ?=20 Is it intended or just an oversight ? if this is intended, is there any = particular reason about this ?=20 Simon ------=_NextPart_000_0136_01D76CD3.EFF04840 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Simon,

 

As per https://= datatracker.ietf.org/doc/html/rfc8132#section-2 the FEETCH request = body is a part of the cache key.

 

=C2=A0=C2=A0 Depending on the response code as defined = by [RFC7252], the response

=C2=A0=C2=A0 to a FETCH request is cacheable; the = request body is part of the

=C2=A0=C2=A0 cache key.=C2=A0 Specifically, 2.05 = (Content) response codes (the

=C2=A0=C2=A0 responses for which are cacheable) are a = typical way to respond to a

=C2=A0=C2=A0 FETCH request.=C2=A0 (Note that this = aspect differs markedly from

=C2=A0=C2=A0 [HT= TP-SEARCH] and also that caches that cannot use the = request

=C2=A0=C2=A0 payload as part of the cache key will not = be able to cache responses

=C2=A0=C2=A0 to FETCH requests at all.)=C2=A0 The = Max-Age option in the response has

=C2=A0=C2=A0 equivalent semantics to its use in a = GET.

 

So, different payloads would create different cache keys and hence = individually be unique.

Regards

 

Jon

 

From:= Simon = Bernard [mailto: contact@simonbernard.eu]
Sent: 29 June 2021 = 10:19
To: core@ietf.org WG
Subject: [core] More = precision about CoAP Observe with = FETCH

 

Hi all,

  The = PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) = (RFC8132) = says that FETCH can be used with RFC7641 = (Observing Resources in CoAP)
  

2.4.=C2=A0 Working with =
Observe
 
=C2=A0=C2=
=A0 The Observe option [RFC7641] can be used with a FETCH request as =
it
=C2=A0=C2=A0 can be used with a GET =
request

  But = "CoAP Observe" seems to be designed with a "GET without = payload" in mind.
  E.g. it says : = 

3.1. =
=C2=A0Request
 
=C2=
=A0=C2=A0 A client registers its interest in a resource by issuing a =
GET
=C2=A0=C2=A0 request with an Observe Option set =
to 0 (register).=C2=A0 If the server
=C2=A0=C2=A0 =
returns a 2.xx response that includes an Observe Option as well, =
the
=C2=A0=C2=A0 server has successfully added an =
entry with the client endpoint and
=C2=A0=C2=A0 =
request token to the list of observers of the target resource, =
and
=C2=A0=C2=A0 the client will be notified of =
changes to the resource =
state.
 
=C2=A0=C2=A0 =
Like a fresh response can be used to satisfy a request =
without
=C2=A0=C2=A0 contacting the server, the =
stream of updates resulting from one
=C2=A0=C2=A0 =
observation request can be used to satisfy another (observation =
or
=C2=A0=C2=A0 normal GET) request if the target =
resource is the same.=C2=A0 A =
client
=C2=A0=C2=A0 MUST aggregate such =
requests and MUST NOT register more than once =
for
=C2=A0=C2=A0 the same target =
resource.=C2=A0 The target resource is identified by =
all
=C2=A0=C2=A0 options in the request that =
are part of the Cache-Key. This =
includes,
=C2=A0=C2=A0 for example, the full =
request URI and the Accept Option.  =

The target resource is not identified = by the payload.  So 2 FETCH requests on same resource with 2 = different payload seem to not be allowed ?

Is it intended or = just an oversight ? if this is intended, is there any particular reason = about this ?

Simon

------=_NextPart_000_0136_01D76CD3.EFF04840-- From nobody Tue Jun 29 02:58:08 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24263A2D7F for ; Tue, 29 Jun 2021 02:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPex1AFZ2Lxp for ; Tue, 29 Jun 2021 02:58:02 -0700 (PDT) Received: from smtpout1.mo529.mail-out.ovh.net (smtpout1.mo529.mail-out.ovh.net [178.32.125.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B062C3A2DA5 for ; Tue, 29 Jun 2021 02:57:57 -0700 (PDT) Received: from mxplan6.mail.ovh.net (unknown [10.109.156.3]) by mo529.mail-out.ovh.net (Postfix) with ESMTPS id 7BB31B13D4AE; Tue, 29 Jun 2021 11:57:54 +0200 (CEST) Received: from simonbernard.eu (37.59.142.96) by DAG3EX2.mxp6.local (172.16.2.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 29 Jun 2021 11:57:53 +0200 Authentication-Results: garm.ovh; auth=pass (GARM-96R0016d9b4aaa-3370-44c5-9c4d-76a3cebc5b21, 41D70A9821A63A1868E3E232E7381517373EE788) smtp.auth=contact@simonbernard.eu X-OVh-ClientIp: 91.174.163.99 To: Jon Shallow , References: <013501d76ccb$8e2be040$aa83a0c0$@jpshallow.com> From: Simon Bernard Message-ID: <6c9eed0f-7d66-812b-abd8-111162c0e7b3@simonbernard.eu> Date: Tue, 29 Jun 2021 11:57:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <013501d76ccb$8e2be040$aa83a0c0$@jpshallow.com> Content-Type: multipart/alternative; boundary="------------7B2457A49FD63164CD9E02D0" Content-Language: en-US X-Originating-IP: [37.59.142.96] X-ClientProxiedBy: DAG3EX1.mxp6.local (172.16.2.21) To DAG3EX2.mxp6.local (172.16.2.22) X-Ovh-Tracer-GUID: e5bdc3af-51b6-4ccb-81f4-bf6425719a1f X-Ovh-Tracer-Id: 17195306330418657434 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrfeehiedguddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtghisegrtderredtfeejnecuhfhrohhmpefuihhmohhnuceuvghrnhgrrhguuceotghonhhtrggtthesshhimhhonhgsvghrnhgrrhgurdgvuheqnecuggftrfgrthhtvghrnhepfedvffehfeegheffieegueetieekfeelvefhvdfgvdffvefhhffhjedvteethfegnecuffhomhgrihhnpehivghtfhdrohhrghenucfkpheptddrtddrtddrtddpfeejrdehledrudegvddrleeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepmhigphhlrghniedrmhgrihhlrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpegtohhnthgrtghtsehsihhmohhnsggvrhhnrghrugdrvghupdhrtghpthhtohepshhuphhjphhsqdhivghtfhesjhhpshhhrghllhhofidrtghomh Archived-At: Subject: Re: [core] More precision about CoAP Observe with FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 09:58:07 -0000 --------------7B2457A49FD63164CD9E02D0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Thx a lot for this clarification. Le 29/06/2021 à 11:45, Jon Shallow a écrit : > > Hi Simon, > > As per https://datatracker.ietf.org/doc/html/rfc8132#section-2 > the FEETCH > request body is a part of the cache key. > >    Depending on the response code as defined by [RFC7252 > ], the response > >    to a FETCH request is cacheable; the request body is part of the > >    cache key.  Specifically, 2.05 (Content) response codes (the > >    responses for which are cacheable) are a typical way to respond to a > >    FETCH request.  (Note that this aspect differs markedly from > >    [HTTP-SEARCH > ] and > also that caches that cannot use the request > >    payload as part of the cache key will not be able to cache responses > >    to FETCH requests at all.)  The Max-Age option in the response has > >    equivalent semantics to its use in a GET. > > So, different payloads would create different cache keys and hence > individually be unique. > > Regards > > Jon > > *From:*Simon Bernard [mailto: contact@simonbernard.eu] > *Sent:* 29 June 2021 10:19 > *To:* core@ietf.org WG > *Subject:* [core] More precision about CoAP Observe with FETCH > > Hi all, > >   The PATCH and FETCH Methods for the Constrained Application Protocol > (CoAP) (RFC8132 ) says > that FETCH can be used with RFC7641 > (Observing Resources > in CoAP) > > 2.4 .  > Working with Observe > >    The Observe option [RFC7641 ] can be used with a FETCH request as it > >    can be used with a GET request > >   But "CoAP Observe" seems to be designed with a "GET without payload" > in mind. >   E.g. it says : > > 3.1 . >  Request > >    A client registers its interest in a resource by issuing a GET > >    request with an Observe Option set to 0 (register).  If the server > >    returns a 2.xx response that includes an Observe Option as well, the > >    server has successfully added an entry with the client endpoint and > >    request token to the list of observers of the target resource, and > >    the client will be notified of changes to the resource state. > >    Like a fresh response can be used to satisfy a request without > >    contacting the server, the stream of updates resulting from one > >    observation request can be used to satisfy another (observation or > >    normal GET) request if the target resource is the same.*A client* > > *   MUST aggregate such requests and MUST NOT register more than > once for* > > *   the same target resource.  The target resource is identified > by all* > > *   options in the request that are part of the Cache-Key. This > includes,* > > *   for example, the full request URI and the Accept Option.* > > The target resource is not identified by the payload.  So 2 FETCH > requests on same resource with 2 different payload seem to not be > allowed ? > > Is it intended or just an oversight ? if this is intended, is there > any particular reason about this ? > > Simon > --------------7B2457A49FD63164CD9E02D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Thx a lot for this clarification.

Le 29/06/2021 à 11:45, Jon Shallow a écrit :

Hi Simon,

 

As per https://datatracker.ietf.org/doc/html/rfc8132#section-2 the FEETCH request body is a part of the cache key.

 

   Depending on the response code as defined by [RFC7252], the response

   to a FETCH request is cacheable; the request body is part of the

   cache key.  Specifically, 2.05 (Content) response codes (the

   responses for which are cacheable) are a typical way to respond to a

   FETCH request.  (Note that this aspect differs markedly from

   [HTTP-SEARCH] and also that caches that cannot use the request

   payload as part of the cache key will not be able to cache responses

   to FETCH requests at all.)  The Max-Age option in the response has

   equivalent semantics to its use in a GET.

 

So, different payloads would create different cache keys and hence individually be unique.

Regards

 

Jon

 

From: Simon Bernard [mailto: contact@simonbernard.eu]
Sent: 29 June 2021 10:19
To: core@ietf.org WG
Subject: [core] More precision about CoAP Observe with FETCH

 

Hi all,

  The PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) (RFC8132) says that FETCH can be used with RFC7641 (Observing Resources in CoAP)
  

2.4.  Working with Observe
 
   The Observe option [RFC7641] can be used with a FETCH request as it
   can be used with a GET request

  But "CoAP Observe" seems to be designed with a "GET without payload" in mind.
  E.g. it says : 

3.1.  Request
 
   A client registers its interest in a resource by issuing a GET
   request with an Observe Option set to 0 (register).  If the server
   returns a 2.xx response that includes an Observe Option as well, the
   server has successfully added an entry with the client endpoint and
   request token to the list of observers of the target resource, and
   the client will be notified of changes to the resource state.
 
   Like a fresh response can be used to satisfy a request without
   contacting the server, the stream of updates resulting from one
   observation request can be used to satisfy another (observation or
   normal GET) request if the target resource is the same.  A client
   MUST aggregate such requests and MUST NOT register more than once for
   the same target resource.  The target resource is identified by all
   options in the request that are part of the Cache-Key. This includes,
   for example, the full request URI and the Accept Option. 

The target resource is not identified by the payload.  So 2 FETCH requests on same resource with 2 different payload seem to not be allowed ?

Is it intended or just an oversight ? if this is intended, is there any particular reason about this ?

Simon

--------------7B2457A49FD63164CD9E02D0-- From nobody Tue Jun 29 03:13:49 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3EA3A2E50 for ; Tue, 29 Jun 2021 03:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 641jpgRrV69r for ; Tue, 29 Jun 2021 03:13:41 -0700 (PDT) Received: from smtpout1.mo529.mail-out.ovh.net (smtpout1.mo529.mail-out.ovh.net [178.32.125.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC523A2E4C for ; Tue, 29 Jun 2021 03:13:40 -0700 (PDT) Received: from mxplan6.mail.ovh.net (unknown [10.109.146.170]) by mo529.mail-out.ovh.net (Postfix) with ESMTPS id 37C0DB13E5F7; Tue, 29 Jun 2021 12:13:39 +0200 (CEST) Received: from simonbernard.eu (37.59.142.95) by DAG3EX2.mxp6.local (172.16.2.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 29 Jun 2021 12:13:38 +0200 Authentication-Results: garm.ovh; auth=pass (GARM-95G001bdb97ab5-60c5-4bd4-9cf8-d9f031731961, 41D70A9821A63A1868E3E232E7381517373EE788) smtp.auth=contact@simonbernard.eu X-OVh-ClientIp: 91.174.163.99 To: Jon Shallow , References: <013501d76ccb$8e2be040$aa83a0c0$@jpshallow.com> From: Simon Bernard Message-ID: Date: Tue, 29 Jun 2021 12:13:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <013501d76ccb$8e2be040$aa83a0c0$@jpshallow.com> Content-Type: multipart/alternative; boundary="------------5FD1D537C80EF07C77FB4F48" Content-Language: en-US X-Originating-IP: [37.59.142.95] X-ClientProxiedBy: DAG7EX2.mxp6.local (172.16.2.62) To DAG3EX2.mxp6.local (172.16.2.22) X-Ovh-Tracer-GUID: 2203c85a-c40c-41cc-b48d-0e544e183491 X-Ovh-Tracer-Id: 17461018707691976858 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrfeehiedguddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtghisegrtderredtfeejnecuhfhrohhmpefuihhmohhnuceuvghrnhgrrhguuceotghonhhtrggtthesshhimhhonhgsvghrnhgrrhgurdgvuheqnecuggftrfgrthhtvghrnhepfedvffehfeegheffieegueetieekfeelvefhvdfgvdffvefhhffhjedvteethfegnecuffhomhgrihhnpehivghtfhdrohhrghenucfkpheptddrtddrtddrtddpfeejrdehledrudegvddrleehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepmhigphhlrghniedrmhgrihhlrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpegtohhnthgrtghtsehsihhmohhnsggvrhhnrghrugdrvghupdhrtghpthhtohepshhuphhjphhsqdhivghtfhesjhhpshhhrghllhhofidrtghomh Archived-At: Subject: Re: [core] More precision about CoAP Observe with FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 10:13:48 -0000 --------------5FD1D537C80EF07C77FB4F48 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Jon,   Another question related to this topic (FETCH + Observe)   For an Active Cancel Observe request, RFC7641 says (https://datatracker.ietf.org/doc/html/rfc7641#section-3.6): > In some circumstances, it may be desirable to cancel an observation > and release the resources allocated by the server to it more eagerly. > In this case, a client MAY explicitly deregister by issuing a GET > request that has the Token field set to the token of the observation > to be cancelled and includes an Observe Option with the value set to > 1 (deregister). All other options MUST be identical to those in the > registration request except for the set of ETag Options. When the > server receives such a request, it will remove any matching entry > from the list of observers and process the GET request as usual. In case of usage of FETCH with payload. Should we also sent the payload used to establish the observe relation in this "cancel request" ? Simon Le 29/06/2021 à 11:45, Jon Shallow a écrit : > > Hi Simon, > > As per https://datatracker.ietf.org/doc/html/rfc8132#section-2 > the FEETCH > request body is a part of the cache key. > >    Depending on the response code as defined by [RFC7252 > ], the response > >    to a FETCH request is cacheable; the request body is part of the > >    cache key.  Specifically, 2.05 (Content) response codes (the > >    responses for which are cacheable) are a typical way to respond to a > >    FETCH request.  (Note that this aspect differs markedly from > >    [HTTP-SEARCH > ] and > also that caches that cannot use the request > >    payload as part of the cache key will not be able to cache responses > >    to FETCH requests at all.)  The Max-Age option in the response has > >    equivalent semantics to its use in a GET. > > So, different payloads would create different cache keys and hence > individually be unique. > > Regards > > Jon > > *From:*Simon Bernard [mailto: contact@simonbernard.eu] > *Sent:* 29 June 2021 10:19 > *To:* core@ietf.org WG > *Subject:* [core] More precision about CoAP Observe with FETCH > > Hi all, > >   The PATCH and FETCH Methods for the Constrained Application Protocol > (CoAP) (RFC8132 ) says > that FETCH can be used with RFC7641 > (Observing Resources > in CoAP) > > 2.4 .  > Working with Observe > >    The Observe option [RFC7641 ] can be used with a FETCH request as it > >    can be used with a GET request > >   But "CoAP Observe" seems to be designed with a "GET without payload" > in mind. >   E.g. it says : > > 3.1 . >  Request > >    A client registers its interest in a resource by issuing a GET > >    request with an Observe Option set to 0 (register).  If the server > >    returns a 2.xx response that includes an Observe Option as well, the > >    server has successfully added an entry with the client endpoint and > >    request token to the list of observers of the target resource, and > >    the client will be notified of changes to the resource state. > >    Like a fresh response can be used to satisfy a request without > >    contacting the server, the stream of updates resulting from one > >    observation request can be used to satisfy another (observation or > >    normal GET) request if the target resource is the same.*A client* > > *   MUST aggregate such requests and MUST NOT register more than > once for* > > *   the same target resource.  The target resource is identified > by all* > > *   options in the request that are part of the Cache-Key. This > includes,* > > *   for example, the full request URI and the Accept Option.* > > The target resource is not identified by the payload.  So 2 FETCH > requests on same resource with 2 different payload seem to not be > allowed ? > > Is it intended or just an oversight ? if this is intended, is there > any particular reason about this ? > > Simon > --------------5FD1D537C80EF07C77FB4F48 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi Jon,

  Another question related to this topic (FETCH + Observe)

  For an Active Cancel Observe request, RFC7641 says (https://datatracker.ietf.org/doc/html/rfc7641#section-3.6): 

   In some circumstances, it may be desirable to cancel an observation
   and release the resources allocated by the server to it more eagerly.
   In this case, a client MAY explicitly deregister by issuing a GET
   request that has the Token field set to the token of the observation
   to be cancelled and includes an Observe Option with the value set to
   1 (deregister).  All other options MUST be identical to those in the
   registration request except for the set of ETag Options.  When the
   server receives such a request, it will remove any matching entry
   from the list of observers and process the GET request as usual.

In case of usage of FETCH with payload. Should we also sent the payload used to establish the observe relation in this "cancel request" ?

Simon

Le 29/06/2021 à 11:45, Jon Shallow a écrit :

Hi Simon,

 

As per https://datatracker.ietf.org/doc/html/rfc8132#section-2 the FEETCH request body is a part of the cache key.

 

   Depending on the response code as defined by [RFC7252], the response

   to a FETCH request is cacheable; the request body is part of the

   cache key.  Specifically, 2.05 (Content) response codes (the

   responses for which are cacheable) are a typical way to respond to a

   FETCH request.  (Note that this aspect differs markedly from

   [HTTP-SEARCH] and also that caches that cannot use the request

   payload as part of the cache key will not be able to cache responses

   to FETCH requests at all.)  The Max-Age option in the response has

   equivalent semantics to its use in a GET.

 

So, different payloads would create different cache keys and hence individually be unique.

Regards

 

Jon

 

From: Simon Bernard [mailto: contact@simonbernard.eu]
Sent: 29 June 2021 10:19
To: core@ietf.org WG
Subject: [core] More precision about CoAP Observe with FETCH

 

Hi all,

  The PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) (RFC8132) says that FETCH can be used with RFC7641 (Observing Resources in CoAP)
  

2.4.  Working with Observe
 
   The Observe option [RFC7641] can be used with a FETCH request as it
   can be used with a GET request

  But "CoAP Observe" seems to be designed with a "GET without payload" in mind.
  E.g. it says : 

3.1.  Request
 
   A client registers its interest in a resource by issuing a GET
   request with an Observe Option set to 0 (register).  If the server
   returns a 2.xx response that includes an Observe Option as well, the
   server has successfully added an entry with the client endpoint and
   request token to the list of observers of the target resource, and
   the client will be notified of changes to the resource state.
 
   Like a fresh response can be used to satisfy a request without
   contacting the server, the stream of updates resulting from one
   observation request can be used to satisfy another (observation or
   normal GET) request if the target resource is the same.  A client
   MUST aggregate such requests and MUST NOT register more than once for
   the same target resource.  The target resource is identified by all
   options in the request that are part of the Cache-Key. This includes,
   for example, the full request URI and the Accept Option. 

The target resource is not identified by the payload.  So 2 FETCH requests on same resource with 2 different payload seem to not be allowed ?

Is it intended or just an oversight ? if this is intended, is there any particular reason about this ?

Simon

--------------5FD1D537C80EF07C77FB4F48-- From nobody Tue Jun 29 05:15:36 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FA03A3271 for ; Tue, 29 Jun 2021 05:15:34 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uW7cFZMUMk5K for ; Tue, 29 Jun 2021 05:15:30 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 ED89F3A3270 for ; Tue, 29 Jun 2021 05:15:29 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lyCeD-0004FW-2I; Tue, 29 Jun 2021 13:15:25 +0100 From: "Jon Shallow" To: "'Simon Bernard'" , References: <013501d76ccb$8e2be040$aa83a0c0$@jpshallow.com> In-Reply-To: Date: Tue, 29 Jun 2021 13:15:36 +0100 Message-ID: <01a601d76ce0$7795f770$66c1e650$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A7_01D76CE8.D95D93C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQICowpRfhMxcn6CYMw9eR2mIOGlfQIXqNQbAnRGGO6qsBrR4A== Content-Language: en-gb Archived-At: Subject: Re: [core] More precision about CoAP Observe with FETCH X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 12:15:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A7_01D76CE8.D95D93C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Simon, =20 Yes, because it is a part of the cache-key, you also need to send the = payload as well for the Observe cancel is my understanding. =20 Regard =20 Jon =20 From: Simon Bernard [mailto: contact@simonbernard.eu]=20 Sent: 29 June 2021 11:14 To: Jon Shallow; core@ietf.org Subject: Re: [core] More precision about CoAP Observe with FETCH =20 Hi Jon, Another question related to this topic (FETCH + Observe) For an Active Cancel Observe request, RFC7641 says = (https://datatracker.ietf.org/doc/html/rfc7641#section-3.6):=20 In some circumstances, it may be desirable to cancel an observation and release the resources allocated by the server to it more eagerly. In this case, a client MAY explicitly deregister by issuing a GET request that has the Token field set to the token of the observation to be cancelled and includes an Observe Option with the value set to 1 (deregister). All other options MUST be identical to those in the registration request except for the set of ETag Options. When the server receives such a request, it will remove any matching entry from the list of observers and process the GET request as usual. In case of usage of FETCH with payload. Should we also sent the payload = used to establish the observe relation in this "cancel request" ?=20 Simon Le 29/06/2021 =C3=A0 11:45, Jon Shallow a =C3=A9crit : Hi Simon, =20 As per https://datatracker.ietf.org/doc/html/rfc8132#section-2 the = FEETCH request body is a part of the cache key. =20 Depending on the response code as defined by [RFC7252 = ], the response to a FETCH request is cacheable; the request body is part of the cache key. Specifically, 2.05 (Content) response codes (the responses for which are cacheable) are a typical way to respond to a FETCH request. (Note that this aspect differs markedly from [HTTP-SEARCH = ] and = also that caches that cannot use the request payload as part of the cache key will not be able to cache responses to FETCH requests at all.) The Max-Age option in the response has equivalent semantics to its use in a GET. =20 So, different payloads would create different cache keys and hence = individually be unique. Regards =20 Jon =20 From: Simon Bernard [mailto: contact@simonbernard.eu]=20 Sent: 29 June 2021 10:19 To: core@ietf.org WG Subject: [core] More precision about CoAP Observe with FETCH =20 Hi all, The PATCH and FETCH Methods for the Constrained Application Protocol = (CoAP) (RFC8132 ) says = that FETCH can be used with RFC7641 = (Observing Resources in = CoAP) =20 2.4 . = Working with Observe =20 The Observe option [RFC7641 = ] can be used with a = FETCH request as it can be used with a GET request But "CoAP Observe" seems to be designed with a "GET without payload" = in mind. E.g. it says :=20 3.1 . = Request =20 A client registers its interest in a resource by issuing a GET request with an Observe Option set to 0 (register). If the server returns a 2.xx response that includes an Observe Option as well, the server has successfully added an entry with the client endpoint and request token to the list of observers of the target resource, and the client will be notified of changes to the resource state. =20 Like a fresh response can be used to satisfy a request without contacting the server, the stream of updates resulting from one observation request can be used to satisfy another (observation or normal GET) request if the target resource is the same. A client MUST aggregate such requests and MUST NOT register more than once for the same target resource. The target resource is identified by all options in the request that are part of the Cache-Key. This includes, for example, the full request URI and the Accept Option. =20 The target resource is not identified by the payload. So 2 FETCH = requests on same resource with 2 different payload seem to not be = allowed ?=20 Is it intended or just an oversight ? if this is intended, is there any = particular reason about this ?=20 Simon ------=_NextPart_000_01A7_01D76CE8.D95D93C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Simon,

 

Yes, because it is a part of the cache-key, you also need to send the = payload as well for the Observe cancel is my = understanding.

 

Regard

 

Jon

 

From:= Simon = Bernard [mailto: contact@simonbernard.eu]
Sent: 29 June 2021 = 11:14
To: Jon Shallow; core@ietf.org
Subject: Re: = [core] More precision about CoAP Observe with = FETCH

 

Hi Jon,

  Another = question related to this topic (FETCH + Observe)

  For an = Active Cancel Observe request, RFC7641 says (https:= //datatracker.ietf.org/doc/html/rfc7641#section-3.6): = 

=C2=A0=C2=A0=C2=A0In =
some circumstances, it may be desirable to cancel an =
observation
=C2=A0=C2=A0 and release the resources =
allocated by the server to it more =
eagerly.
=C2=A0=C2=A0 In this case, a client MAY =
explicitly deregister by issuing a GET
=C2=A0=C2=A0 =
request that has the Token field set to the token of the =
observation
=C2=A0=C2=A0 to be cancelled and =
includes an Observe Option with the value set =
to
=C2=A0=C2=A0 1 (deregister).=C2=A0 All other =
options MUST be identical to those in =
the
=C2=A0=C2=A0 registration request except for =
the set of ETag Options.=C2=A0 When =
the
=C2=A0=C2=A0 server receives such a request, it =
will remove any matching entry
=C2=A0=C2=A0 from =
the list of observers and process the GET request as =
usual.


In case of = usage of FETCH with payload. Should we also sent the payload used to = establish the observe relation in this "cancel request" ? =

Simon

Le 29/06/2021 = =C3=A0 11:45, Jon Shallow a = =C3=A9crit :

Hi Simon,

 

As per https://= datatracker.ietf.org/doc/html/rfc8132#section-2 the FEETCH request = body is a part of the cache key.

 

   Depending on the response code as = defined by [RFC7252], the response

   to a FETCH request is cacheable; = the request body is part of the

   cache key.  Specifically, = 2.05 (Content) response codes (the

   responses for which are = cacheable) are a typical way to respond to a

   FETCH request.  (Note that = this aspect differs markedly from

   [HT= TP-SEARCH] and also that caches that cannot use the = request

   payload as part of the cache key = will not be able to cache responses

   to FETCH requests at all.)  = The Max-Age option in the response has

   equivalent semantics to its use = in a GET.

 

So, different payloads would create different cache keys and hence = individually be unique.

Regards

 

Jon

 

From:= Simon = Bernard [mailto: contact@simonbernard.eu] =
Sent: 29 June 2021 10:19
To: core@ietf.org WG
Subject: = [core] More precision about CoAP Observe with = FETCH

 

Hi all,

  The = PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) = (RFC8132) = says that FETCH can be used with RFC7641 = (Observing Resources in CoAP)
  

2.4.  Working with =
Observe
 
 &nb=
sp; The Observe option [RFC7641] can be used with a FETCH request as =
it
   can be used with a GET =
request

  But = "CoAP Observe" seems to be designed with a "GET without = payload" in mind.
  E.g. it says : = 

3.1. =
 Request
 
&nb=
sp;  A client registers its interest in a resource by issuing a =
GET
   request with an Observe Option set =
to 0 (register).  If the server
   =
returns a 2.xx response that includes an Observe Option as well, =
the
   server has successfully added an =
entry with the client endpoint and
   =
request token to the list of observers of the target resource, =
and
   the client will be notified of =
changes to the resource =
state.
 
   =
Like a fresh response can be used to satisfy a request =
without
   contacting the server, the =
stream of updates resulting from one
   =
observation request can be used to satisfy another (observation =
or
   normal GET) request if the target =
resource is the same.  A =
client
   MUST aggregate such =
requests and MUST NOT register more than once =
for
   the same target =
resource.  The target resource is identified by =
all
   options in the request that =
are part of the Cache-Key. This =
includes,
   for example, the full =
request URI and the Accept Option.  =

The target resource is not identified = by the payload.  So 2 FETCH requests on same resource with 2 = different payload seem to not be allowed ?

Is it intended or = just an oversight ? if this is intended, is there any particular reason = about this ? =

Simon

------=_NextPart_000_01A7_01D76CE8.D95D93C0-- From nobody Tue Jun 29 10:09:56 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D313A3AFF; Tue, 29 Jun 2021 10:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLhsbalRQ_ul; Tue, 29 Jun 2021 10:09:49 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A63B3A3AFA; Tue, 29 Jun 2021 10:09:48 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 54C8A40128; Tue, 29 Jun 2021 19:09:45 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5D91674; Tue, 29 Jun 2021 19:09:44 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [141.244.80.208]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2162C26; Tue, 29 Jun 2021 19:09:44 +0200 (CEST) Received: (nullmailer pid 2044235 invoked by uid 1000); Tue, 29 Jun 2021 17:09:43 -0000 Date: Tue, 29 Jun 2021 19:09:43 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-yang-cbor@ietf.org Cc: core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I0oYkU6eSuT2R5G/" Content-Disposition: inline Archived-At: Subject: [core] core-yang-cbor-mapping: CBOR tag review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 17:09:54 -0000 --I0oYkU6eSuT2R5G/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello YANG authors, I've been asked by IANA to expert-review the tag allocations for yang-cbor-mapping, and while I do see no fundamental red flags (which would surprise me, given one of the registry experts is on the authors team), I'd like to understand better a few aspects of the registrations: * As I understand "YANG bits datatype" and "YANG enumeration datatype" from a cursory reading, these only exist to cover the corner cases where a numeric (be it compressed-bitfield or plain index, respectively) value doesn't cut it. When that corner case is hit, a compact representation is out of question (and if I were inclined to speculate I could imagine that if YANG were done with the benefit of hindsight, the unioned types would be somehow sorted to allow an unambiguious compact representation). My impression is that these would be used rarely in YANG models built for constrained devices, and when it does happen, can afford a place in the 1+2 range -- keeping the 1+1 for usages that *do* count bytes (which an application that can afford a literal "under-repair critical" probably does not). * On the same tags, could you elaborate a bit on why tags are necessary for these? The format appears to be comfortable with having type-based disambiguation in several places; why can't a text string like "under-repair critical" not indicate by its major type that it's a union's bit names and not its bit value? * For the tags "YANG identityref datatype" and "YANG instance-identifier", the reference given in the registration describes their content, but not how they are used. AIU they are primarily intended for expressing their tagged data in anyxml. If so, a note on that might be helpful, possibly along the lines of > Tags TBD43, TBD44 and TBD47 are used in CBOR encoded YANG trees to > disambiguate union items from the usual more compact > representations, and to disambiguate absolute SIDs from delta > encoded ones. > > TBD45 and TBD46 are defiend for use with anyxml (Section 4.6). Like for bits and enumerations, is this something you expect to find often in non-embedded-tailored YANG schemes? If not, they too might be good candidates for the 1+2 range. As said, none of these are showstoppers, but I'd appreciate some clarification. BR Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --I0oYkU6eSuT2R5G/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmDbU9QACgkQOY0REtOk veF3VRAAk2R53GN/0FsQzY0Fe/Bkv6c5QjPYxqIJyTg5wuyi6pcQ8UDbqODqu9Wc JYV2R62hYxUKM6sp2d10j290SBTXC2F5DcGRaG6EVGlxRQRS5KtusZAvYWKr8Ynv RZNE1aP04Id4AyywkkCda4EovuCUP/zRaYKFBVhrqbgLXmBBCxex2q/+wWKOC59a 07vlvMQxFosTNRdZtqcjeS6MfKskBebqfOciDZrPwWpxpz5WkNdNwN2nHVhyR+QZ quOXbasSsvaZBeYjaoRPjmdu7mORda4bMhjbxs2g/BtWBzHSMlzcDs80hEgvARvc JgV8a//Sw77LF4XD4Ocb2MReTydrV/z2i2efzm15jrhGL1hgfWrbfNbGPIrCeVSY K6h1ndVmNkXuiCQoWbfCe5quwg4bl3KYXVVYDy0f48ZavNp+c4rfbyvcx11XpPox r5izw6j5+Az9SX7x1O0kWdwBMJI6pXXz2DuZLZdrrOJhc3tTw1gVKenGdZsWftvX JsADP95mA9jFcneeUc1ag7BCgkjDwnP0ZzsEpgiJ+p1sD6vVfQZGTb1UtDmHDbLx Ttv/rhvFi4XdUELkCNBzgpaxYx6qPLbkIUdl61g/rEmPbzghaOTLCrqrdlMkJodT 9BRNKuMtwBK0MWxK0tSh4hdSaxX2PKaR/7xPWun+3ftjqXnf01g= =cCoo -----END PGP SIGNATURE----- --I0oYkU6eSuT2R5G/-- From nobody Tue Jun 29 11:14:33 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3971E3A3C9E; Tue, 29 Jun 2021 11:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPhC2EerntW5; Tue, 29 Jun 2021 11:14:29 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7F13A3C59; Tue, 29 Jun 2021 11:13:58 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 9647540128; Tue, 29 Jun 2021 20:13:51 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id D00BC74; Tue, 29 Jun 2021 20:13:50 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [141.244.80.208]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 817C826; Tue, 29 Jun 2021 20:13:50 +0200 (CEST) Received: (nullmailer pid 2053110 invoked by uid 1000); Tue, 29 Jun 2021 18:13:50 -0000 Date: Tue, 29 Jun 2021 20:13:50 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: draft-ietf-core-yang-cbor@ietf.org Cc: core@ietf.org Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Archived-At: Subject: Re: [core] core-yang-cbor-mapping: CBOR tag review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 18:14:32 -0000 Hello YANG authors, > I've been asked by IANA to expert-review the tag allocations for > yang-cbor-mapping, and while I do see no fundamental red flags (which > would surprise me, given one of the registry experts is on the authors > team), I'd like to understand better a few aspects of the registrations: there has been a mix-up -- the tags *are* already registered, so please disregard any questions as to the 1+1/1+2 range. The points about the internal references on usage stand (albeit more in a "commenter late to the party" capacity). A new point I should raise reviewing what will now be changes to the registry is the type changes: tags 43 and 44 used to tag bstr and uint, respectively. While there is no need in the RFC-to-be to dwell on its draft history: Have implementations of this document followed the changes that led to the altered tag payloads? If not, is there anything better than bailing that implementers can do when faced with the tags as they used to be used? BR Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom From nobody Wed Jun 30 13:45:30 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D228A3A29ED; Wed, 30 Jun 2021 13:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 74ZMnzxQZixB; Wed, 30 Jun 2021 13:45:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1631E3A29E9; Wed, 30 Jun 2021 13:45:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 552A9F40727; Wed, 30 Jun 2021 13:45:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, core@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210630204502.552A9F40727@rfc-editor.org> Date: Wed, 30 Jun 2021 13:45:02 -0700 (PDT) Archived-At: Subject: [core] =?utf-8?q?RFC_9039_on_Uniform_Resource_Names_for_Device_I?= =?utf-8?q?dentifiers?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 20:45:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9039 Title: Uniform Resource Names for Device Identifiers Author: J. Arkko, C. Jennings, Z. Shelby Status: Standards Track Stream: IETF Date: June 2021 Mailbox: jari.arkko@piuha.net, fluffy@iii.ca, zach@edgeimpulse.com Pages: 15 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-core-dev-urn-11.txt URL: https://www.rfc-editor.org/info/rfc9039 DOI: 10.17487/RFC9039 This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage or in equipment inventories. A URN-based representation can be passed along in applications that need the information. This document is a product of the Constrained RESTful Environments Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC