From nobody Wed May 1 17:05:42 2019 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 ABF3B120261; Wed, 1 May 2019 17:05:40 -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-multipart-ct@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155675554069.2851.9351849772053196736.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2019 17:05:40 -0700 Archived-At: Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-multipart-ct-03: (with DISCUSS and 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, 02 May 2019 00:05:41 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-core-multipart-ct-03: Discuss 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- It's not clear to me that we're really specifying the semantics of a single media-type. The introduction discusses how we may want multiple representations to appear in a sequence, potentially representing different content. Or we may have a set of related representations that conceptually are the same content (but are they literally the same resource, or related content?). And there is yet a third option -- one that I'm not sure I fully understand -- wherein the representation is not important, but rather which format is chosen of the several possibilities, to the extent that extreme compression of the representation is possible, with the compression just outputting the format indicator. I don't see that any of these three cases are mutually compatible with each other -- are we not defining three different semantical representations that share a common syntax? How does a receiver know which semantics to apply, if they share a common media-type codepoint? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The security considerations seem incomplete, at least given my understanding of the intended technical semantics for the media-type. Specifically, there is no discussion of how the recipient chooses which semantics to apply (and the risks of choosing incorrectly), or discussion of the latent risk when there are supposed to be multiple equivalent or related components but that's not validated or the recipient only acts on part of the data. From nobody Wed May 1 18:31:49 2019 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 DE47E1201A7 for ; Wed, 1 May 2019 18:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 nWggR2mbfwrl for ; Wed, 1 May 2019 18:31:47 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (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 89D9D120195 for ; Wed, 1 May 2019 18:31:45 -0700 (PDT) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-10v.sys.comcast.net with ESMTP id Los6hwZZOmCETM0ZchOhPA; Thu, 02 May 2019 01:31:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1556760704; bh=PcnbpiC2mMlkoirKIj562UR7ddZ7rWOB5ymj8Fk3kPM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=WdjjCscpxFne+oFLEGSp/OY1nLd/Fkv1AFhvc/eggLugTFMO7d0RTIdah+l+pe4IU elVMSloI5EYALiM+Y8PE8ehaNIHXhdrNMCrubvSclF3pV9HVtCqC7DgLrJcvXF4lOP YbOMBLvpE0uz7f/7qR1nSE1ikExXO3IAH2vhZZgDDfyqskmwYARKPswRQa/tFGRAof k3y7ceVah4NvUlLJWYtWat7qJUK9nyN0rDymbEVKl0zlw6T9nC9B7YxLEeg91ZFGyY v+h+Rz8aK4joSL/2X5S6/32FCQUOzRFOO1DWHqaqOWdxo1haLHF7axys+YOnJWkX5R QdT1HqgTNPg0g== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-17v.sys.comcast.net with ESMTPA id M0ZahruNfQaVjM0ZchlFBK; Thu, 02 May 2019 01:31:44 +0000 X-Xfinity-VMeta: sc=0;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id x421Ufaw014514; Wed, 1 May 2019 21:30:41 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x421Ufpg014511; Wed, 1 May 2019 21:30:41 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: draft-ietf-core-multipart-ct.all@ietf.org, core@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 01 May 2019 21:30:40 -0400 Message-ID: <87a7g5d4n3.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [core] Last call review of draft-ietf-core-multipart-ct-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: Thu, 02 May 2019 01:31:48 -0000 I'm no expert on this, but looking at section 3.1 of -03, I suspect the word that I've marked should be "Pending", not "Content". When a client registers to observe a resource [RFC7641] for which no representation is available yet, the server may send one or more 2.05 (Content) notifications before sending the first actual 2.05 ----^ (Content) or 2.03 (Valid) notification. The possible resulting sequence of notifications is shown in Figure 1. __________ __________ __________ | | | | | | ---->| 2.05 |---->| 2.05 / |---->| 4.xx / | | Pending | | 2.03 | | 5.xx | |__________| |__________| |__________| ^ \ \ ^ \ ^ \__/ \ \___/ / \_______________________/ Figure 2: Sequence of Notifications: The final colon on the figure's caption should probably also be removed. The example usage in 3.1 seems like it has some semantic complexities that are not being fixed here. It appears that the "observe" process returns a sequence of messages, and there is a complexity that arises if the server process is constrained to return a 2.05 Pending message before it knows what the resource-type of the observed resource is. The solution proposed here is to return an application/multipart-core with 0 components, and then later return an application/multipart-core with 1 component, which is the observed resource. The problem arises that the semantics of the notification are fixed by RFC 7641 section 3.2, "The only difference between a notification and a normal response is the presence of the Observe Option." I.e., the body of a 2.05 message must be the representation of the resource, not an application/multipart-core containing the representation of the resource. One possibility is to extend the semantics of RFC 7641 so that if a 2.05 response's body has Content-Format application/multipart-core, then the "value" being carried is by definition the first part of the multipart body. But that risks being non-upward-compatible for clients that have not implemented this convention. A better possibility would be to define a new value for the Observe Option of the GET request, 2, which requests registration but also specifies that each response will wrap the resource value in an application/multipart-core. In either way, there seems to be a need for a normative change to RFC 7641. Dale From nobody Wed May 1 21:34:13 2019 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 B0FDE12015D; Wed, 1 May 2019 21:34:11 -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, 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 EXRSq2BwkczH; Wed, 1 May 2019 21:34:09 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE8F12014B; Wed, 1 May 2019 21:34:08 -0700 (PDT) Received: from client-0215.vpn.uni-bremen.de (client-0215.vpn.uni-bremen.de [134.102.107.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44vj8G69plzyVW; Thu, 2 May 2019 06:34:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <87a7g5d4n3.fsf@hobgoblin.ariadne.com> Date: Thu, 2 May 2019 06:34:06 +0200 Cc: draft-ietf-core-multipart-ct.all@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 578464443.999827-56bc39a33563bcc235ba701b4781b96b Content-Transfer-Encoding: quoted-printable Message-Id: References: <87a7g5d4n3.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Last call review of draft-ietf-core-multipart-ct-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: Thu, 02 May 2019 04:34:12 -0000 Hi Dale, > On May 2, 2019, at 03:30, Dale R. Worley wrote: >=20 > I'm no expert on this, but looking at section 3.1 of -03, I suspect = the > word that I've marked should be "Pending", not "Content". >=20 > When a client registers to observe a resource [RFC7641] for which no > representation is available yet, the server may send one or more = 2.05 > (Content) notifications before sending the first actual 2.05 > ----^ > (Content) or 2.03 (Valid) notification. The possible resulting > sequence of notifications is shown in Figure 1. The =E2=80=9CContent=E2=80=9D is the translation of =E2=80=9C2.05=E2=80=9D= into English, as we tend to do when showing response codes. >=20 > __________ __________ __________ > | | | | | | > ---->| 2.05 |---->| 2.05 / |---->| 4.xx / | > | Pending | | 2.03 | | 5.xx | > |__________| |__________| |__________| > ^ \ \ ^ \ ^ > \__/ \ \___/ / > \_______________________/ >=20 > Figure 2: Sequence of Notifications: >=20 > The final colon on the figure=E2=80=99s caption should probably also = be removed. Yes. Done in https://github.com/core-wg/multipart-ct/tree/ietf-lc-fixes = now. > The example usage in 3.1 seems like it has some semantic complexities > that are not being fixed here. It appears that the "observe" process > returns a sequence of messages, and there is a complexity that arises = if > the server process is constrained to return a 2.05 Pending message > before it knows what the resource-type of the observed resource is. = The > solution proposed here is to return an application/multipart-core with = 0 > components, and then later return an application/multipart-core with 1 > component, which is the observed resource. >=20 > The problem arises that the semantics of the notification are fixed by > RFC 7641 section 3.2, "The only difference between a notification and = a > normal response is the presence of the Observe Option." I.e., the = body > of a 2.05 message must be the representation of the resource, not an > application/multipart-core containing the representation of the > resource. If your resource chooses to provide that as its representation, = everything is fine. (If it doesn=E2=80=99t, well, you aren=E2=80=99t using multipart-core.) > One possibility is to extend the semantics of RFC 7641 so that if a = 2.05 > response's body has Content-Format application/multipart-core, then = the > "value" being carried is by definition the first part of the multipart > body. But that risks being non-upward-compatible for clients that = have > not implemented this convention. >=20 > A better possibility would be to define a new value for the Observe > Option of the GET request, 2, which requests registration but also > specifies that each response will wrap the resource value in an > application/multipart-core. >=20 > In either way, there seems to be a need for a normative change to RFC > 7641. We designed this so that change is not needed. An Accept option with = multipart-core in it is all the signaling you=E2=80=99d need (if you = want to signal at all). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 1 22:05:16 2019 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 0EDD312025C; Wed, 1 May 2019 22:05: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] 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 79i6AO57Hn3y; Wed, 1 May 2019 22:05:13 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B539C1200EF; Wed, 1 May 2019 22:05:13 -0700 (PDT) Received: from client-0215.vpn.uni-bremen.de (client-0215.vpn.uni-bremen.de [134.102.107.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44vjr74mGMzySY; Thu, 2 May 2019 07:05:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <155664436774.7505.12604389698979572964.idtracker@ietfa.amsl.com> Date: Thu, 2 May 2019 07:05:11 +0200 Cc: The IESG , core-chairs@ietf.org, jaime.jimenez@ericsson.com, draft-ietf-core-multipart-ct@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 578466309.044995-610df1da9d7c050d5ea72ac68b8c6efd Content-Transfer-Encoding: quoted-printable Message-Id: References: <155664436774.7505.12604389698979572964.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Alissa Cooper's No Objection on draft-ietf-core-multipart-ct-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, 02 May 2019 05:05:15 -0000 Hi Alissa, thank you for your comments. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Please respond to the Gen-ART review. It seems the response e-mail describing how we acted on it got stuck in = processing. Will send later today. > =3D Section 2 =3D >=20 > "The second, fourth, sixth, etc. element is a > byte string containing a representation, or the value "null" if an > optional part is indicated as not given. The first, third, fifth, > etc. element is an unsigned integer specifying the content format ID > of the representation following it." >=20 > I think it would be more precise to refer to the "even-numbered = elements" and > the "odd-numbered elements" rather than enumerating the elements and = saying > =E2=80=9Cetc." The problem with =E2=80=9Ceven-numbered=E2=80=9D and =E2=80=9Codd-numbered= =E2=80=9D is that it isn=E2=80=99t explicit about counting from zero = (which is how I would read it, so first/third/fifth would be = =E2=80=9Ceven-numbered=E2=80=9D!) or counting from one (which also would = be natural for some people). Using the actual ordinals removes that = ambiguity, as ordinals count from one. With the rest of the text, the = example, and the CDDL, I believe this is a quite unambiguous way to = introduce the sequence. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 1 22:09:06 2019 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 15C3B1200EF; Wed, 1 May 2019 22:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8ZIjikCEksAn; Wed, 1 May 2019 22:09:02 -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 2D6D0120006; Wed, 1 May 2019 22:09:01 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4258qBS028582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 May 2019 01:08:54 -0400 Date: Thu, 2 May 2019 00:08:52 -0500 From: Benjamin Kaduk To: Carsten Bormann Cc: Alissa Cooper , draft-ietf-core-multipart-ct@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, The IESG , core@ietf.org Message-ID: <20190502050851.GC59871@kduck.mit.edu> References: <155664436774.7505.12604389698979572964.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Alissa Cooper's No Objection on draft-ietf-core-multipart-ct-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, 02 May 2019 05:09:04 -0000 On Thu, May 02, 2019 at 07:05:11AM +0200, Carsten Bormann wrote: > Hi Alissa, > > thank you for your comments. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Please respond to the Gen-ART review. > > It seems the response e-mail describing how we acted on it got stuck in processing. Will send later today. > > > = Section 2 = > > > > "The second, fourth, sixth, etc. element is a > > byte string containing a representation, or the value "null" if an > > optional part is indicated as not given. The first, third, fifth, > > etc. element is an unsigned integer specifying the content format ID > > of the representation following it." > > > > I think it would be more precise to refer to the "even-numbered elements" and > > the "odd-numbered elements" rather than enumerating the elements and saying > > “etc." > > The problem with “even-numbered” and “odd-numbered” is that it isn’t explicit about counting from zero (which is how I would read it, so first/third/fifth would be “even-numbered”!) or counting from one (which also would be natural for some people). Using the actual ordinals removes that ambiguity, as ordinals count from one. With the rest of the text, the example, and the CDDL, I believe this is a quite unambiguous way to introduce the sequence. FWIW, the current text managed to confuse me, as I kept looking for what the zeroth element was and why it was different from everything else. So maybe we can't make everyone happy. -Ben From nobody Wed May 1 22:23:36 2019 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 DB3A6120044; Wed, 1 May 2019 22:23:26 -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] 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 tk_FT17n6zn5; Wed, 1 May 2019 22:23:25 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7EF4120006; Wed, 1 May 2019 22:23:24 -0700 (PDT) Received: from client-0215.vpn.uni-bremen.de (client-0215.vpn.uni-bremen.de [134.102.107.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44vkF650kzzySR; Thu, 2 May 2019 07:23:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190502050851.GC59871@kduck.mit.edu> Date: Thu, 2 May 2019 07:23:22 +0200 Cc: Alissa Cooper , draft-ietf-core-multipart-ct@ietf.org, jaime.jimenez@ericsson.com, core-chairs@ietf.org, The IESG , core@ietf.org X-Mao-Original-Outgoing-Id: 578467400.058454-7245e5b76fa2a81f58a1d86b3d687a28 Content-Transfer-Encoding: quoted-printable Message-Id: <766B38CD-2E79-4997-AC08-CE9CD6A2E8F4@tzi.org> References: <155664436774.7505.12604389698979572964.idtracker@ietfa.amsl.com> <20190502050851.GC59871@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Alissa Cooper's No Objection on draft-ietf-core-multipart-ct-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, 02 May 2019 05:23:27 -0000 > On May 2, 2019, at 07:08, Benjamin Kaduk wrote: >=20 > On Thu, May 02, 2019 at 07:05:11AM +0200, Carsten Bormann wrote: >> Hi Alissa, >>=20 >> thank you for your comments. >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Please respond to the Gen-ART review. >>=20 >> It seems the response e-mail describing how we acted on it got stuck = in processing. Will send later today. >>=20 >>> =3D Section 2 =3D >>>=20 >>> "The second, fourth, sixth, etc. element is a >>> byte string containing a representation, or the value "null" if an >>> optional part is indicated as not given. The first, third, fifth, >>> etc. element is an unsigned integer specifying the content format = ID >>> of the representation following it." >>>=20 >>> I think it would be more precise to refer to the "even-numbered = elements" and >>> the "odd-numbered elements" rather than enumerating the elements and = saying >>> =E2=80=9Cetc." >>=20 >> The problem with =E2=80=9Ceven-numbered=E2=80=9D and = =E2=80=9Codd-numbered=E2=80=9D is that it isn=E2=80=99t explicit about = counting from zero (which is how I would read it, so first/third/fifth = would be =E2=80=9Ceven-numbered=E2=80=9D!) or counting from one (which = also would be natural for some people). Using the actual ordinals = removes that ambiguity, as ordinals count from one. With the rest of = the text, the example, and the CDDL, I believe this is a quite = unambiguous way to introduce the sequence. >=20 > FWIW, the current text managed to confuse me, as I kept looking for = what > the zeroth element was and why it was different from everything else. > So maybe we can=E2=80=99t make everyone happy. Interesting. Yes, some people do use ordinals starting from zero. So how about: Counting from zero, the odd-numbered elements are a byte string = containing a representation, or the value `null` if an optional part is indicated as not given. The (even-numbered) element preceding each of these is an unsigned = integer specifying the content format ID of the representation following it. Sigh. The CDDL is so much clearer :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 2 01:04:01 2019 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 C6F96120301; Thu, 2 May 2019 01:03:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <155678423180.24812.12944181740008384821.idtracker@ietfa.amsl.com> Date: Thu, 02 May 2019 01:03:51 -0700 Archived-At: Subject: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-multipart-ct-03=3A_=28with_COMMENT=29?= 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, 02 May 2019 08:03:52 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-core-multipart-ct-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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to the authors for their work. Short and clear document, I have appreciated the example of CBOR encoding. == comments == In section 2, I wonder the error in CBOR decoding: should it stop or completely ignore all parts of the message? Is there any use case where decoding only part of the messsage causes problem? == nits == section 2, s/ specification: An/ specification: an/ ? From nobody Thu May 2 05:41:15 2019 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 9C46A12032B; Thu, 2 May 2019 05:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=IrgElU8s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lIIfF4Pr 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 CFDD9gf572yn; Thu, 2 May 2019 05:41:06 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC54120110; Thu, 2 May 2019 05:41:06 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 23BF025B21; Thu, 2 May 2019 08:41:05 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Thu, 02 May 2019 08:41:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=lHG2vOIBluk1rJTncoFqRCLOlipD2G7 +OnsYEcuO6o4=; b=IrgElU8sIcj5S8mhldOZ8vebtRpv466c1FGZ4rJIE/FlgxJ McB84Ms2w9ZnyJ9CnKmYn+MLM43TKg0oJpki1XlwDnj5P0Fa4f9MclPB4l2VbEAw F+9yOYyk/Bq5Hi+Fzusg4igxxDxOPnxVDVeCvXYS3vgdIkUwavRqvioNTMP2Z0sh u9JoBDcYJkWRn0mCKq6QEzFMrVLFEmFy8TO1tvT918KqenbIUnhnQ5XpdmABviCb pcH740zte/XGdQWztcobmyUVLAqiEMccOfWbu5NR/Yb0BXJfgizgUXr+hZwVZwAm 5GIggUgDB1hNA0CK9QBK/TXJ1AAjE5P45TC3sDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=lHG2vO IBluk1rJTncoFqRCLOlipD2G7+OnsYEcuO6o4=; b=lIIfF4Pr1834qgKxsccYnq DE9P/e9YKQZBeAFVWllN0iQtJdDLY2fOO2rvyEcTA8U1sM2bPm8w+NOJpBRpqgiv O/BmH/G/Oy0fFAFPDhsRlYERPd/c22DjCOIjaM/m6VvFTInxXd9/ftNMHF3TwQWC uO9AMG5hHbTBT+CeTwaqw/rKjtXaxv+UzoJZHnKha13fnKh9l4vLzDuJ9bVsVSQ7 37GhjDCjUH36mBRecW45xIiOBL5gjT2G9D14K2HYLA10dId8YDAYQ4OvXMR9CoUb kOwq9Zv6cb6l9VU2b6flTSAYo4Nt5qumHlYx6KIUlS4IOBE+zVUoIudQ4T/tah7A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieelgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehlvgig vgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfh hmqeenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhm rghilhdrfhhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 81FFDD4938; Thu, 2 May 2019 08:41:04 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1 Mime-Version: 1.0 Message-Id: <459433ef-5cb5-4c3e-a32e-a5d063b1ccf0@www.fastmail.com> In-Reply-To: <155675554069.2851.9351849772053196736.idtracker@ietfa.amsl.com> References: <155675554069.2851.9351849772053196736.idtracker@ietfa.amsl.com> Date: Thu, 02 May 2019 08:40:40 -0400 From: "Alexey Melnikov" To: "Benjamin Kaduk" , "The IESG" Cc: core-chairs@ietf.org, =?UTF-8?Q?Jaime_Jim=C3=A9nez?= , draft-ietf-core-multipart-ct@ietf.org, core@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [core] =?utf-8?q?Benjamin_Kaduk=27s_Discuss_on_draft-ietf-core-m?= =?utf-8?q?ultipart-ct-03=3A_=28with_DISCUSS_and_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, 02 May 2019 12:41:08 -0000 Hi Benjamin, On Thu, May 2, 2019, at 1:05 AM, Benjamin Kaduk via Datatracker wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > It's not clear to me that we're really specifying the semantics of a > single media-type. The introduction discusses how we may want multiple > representations to appear in a sequence, potentially representing > different content. I think this is similar to multipart/mixed. > Or we may have a set of related representations that > conceptually are the same content (but are they literally the same > resource, or related content?). My understanding is that they are related contents. > And there is yet a third option -- one > that I'm not sure I fully understand -- wherein the representation is > not important, but rather which format is chosen of the several > possibilities, to the extent that extreme compression of the > representation is possible, with the compression just outputting the > format indicator. Hmm, I missed that. I think this is similar to multipart/alternative and I agree with you that this is separate semantics. If my understanding is correct, then I agree that this needs to be fixed. So either the 3rd choice should be out-of-scope or the document should define 2 media types for different semantics. > I don't see that any of these three cases are mutually compatible with > each other I think the first 2 are compatible. >-- are we not defining three different semantical > representations that share a common syntax? How does a receiver know > which semantics to apply, if they share a common media-type codepoint? Best Regards, Alexey From nobody Thu May 2 05:49:57 2019 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 D27E51200C5; Thu, 2 May 2019 05:49:49 -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, 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 6RuT4O8XjwLZ; Thu, 2 May 2019 05:49:47 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7146212002F; Thu, 2 May 2019 05:49:47 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44vw890pvhzybv; Thu, 2 May 2019 14:49:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <0E505663-91A8-4811-9D06-A1DA2774FD23@arm.com> Date: Thu, 2 May 2019 14:49:44 +0200 Cc: Adam Roach , The IESG , "draft-ietf-core-multipart-ct@ietf.org" , Jaime Jimenez , "core-chairs@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 578494182.71277-68c7fdbd134fe2a5bec45399a0f072d1 Content-Transfer-Encoding: quoted-printable Message-Id: <3864BB8E-729E-46C8-BCFF-47684C1062E0@tzi.org> References: <155660587850.12863.3531895290991565789.idtracker@ietfa.amsl.com> <0E505663-91A8-4811-9D06-A1DA2774FD23@arm.com> To: Thomas Fossati X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Adam Roach's No Objection on draft-ietf-core-multipart-ct-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, 02 May 2019 12:49:50 -0000 On Apr 30, 2019, at 15:57, Thomas Fossati = wrote: >=20 > Hi Adam, thanks for the comments. >=20 > =EF=BB=BFOn 30/04/2019, 07:31, "Adam Roach via Datatracker" = wrote: > = ---------------------------------------------------------------------- > COMMENT: > = ---------------------------------------------------------------------- >=20 > Thanks for the work everyone put in on this document. >=20 > The "Usage Examples" section seems a bit odd, since it only = describes the use of > this new content type for sending a response prior to the response = body becoming > available. The introduction does not give the impression that this = is the > primary use case -- it implies that this new format is primarily = intended to > be used in a similar fashion as the traditional multipart/* media = types. > Perhaps there should be some additional examples in section 3 that = outline these > more common cases? >=20 > Yes, it is correct to say that this is not the primary use case, and = yes, section 3.1 looks a bit lonesome... >=20 > I think we ended up like that as we felt like this was the only use = case that needed some kind of "visual" -- all the others being pretty = straightforward to grasp without any particular aid. >=20 > How about we add a bit of text at the top of sec 3 that articulates = the above rationale? Proposed change: = https://github.com/core-wg/multipart-ct/commit/b53b949b0d6cb3145b672627ad7= ec3d3fb3ac8b2 This focuses the section 3 on this one usage example, which is shown = because it might be non-obvious. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 2 06:05:12 2019 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 219A6120115; Thu, 2 May 2019 06:05:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <155680231113.24756.9200745714017967309.idtracker@ietfa.amsl.com> Date: Thu, 02 May 2019 06:05:11 -0700 Archived-At: Subject: [core] Magnus Westerlund's Discuss on draft-ietf-core-multipart-ct-03: (with DISCUSS) 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, 02 May 2019 13:05:11 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-core-multipart-ct-03: Discuss 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Are recursive application of the multipart format allowed? I don't find anyting disallowing that. I just want check that it is intentional before No Objection. From nobody Thu May 2 06:11:32 2019 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 0E0BF12035C; Thu, 2 May 2019 06:11:30 -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, 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 nFL5vtO2aC-G; Thu, 2 May 2019 06:11:28 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415B61200C5; Thu, 2 May 2019 06:11:28 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44vwd96xH4zyTP; Thu, 2 May 2019 15:11:25 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <459433ef-5cb5-4c3e-a32e-a5d063b1ccf0@www.fastmail.com> Date: Thu, 2 May 2019 15:11:25 +0200 Cc: Benjamin Kaduk , The IESG , draft-ietf-core-multipart-ct@ietf.org, =?utf-8?Q?Jaime_Jim=C3=A9nez?= , core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 578495483.345647-327e292a66b53fe2521b66b6de6d6796 Content-Transfer-Encoding: quoted-printable Message-Id: References: <155675554069.2851.9351849772053196736.idtracker@ietfa.amsl.com> <459433ef-5cb5-4c3e-a32e-a5d063b1ccf0@www.fastmail.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-multipart-ct-03: (with DISCUSS and 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, 02 May 2019 13:11:30 -0000 Hi Alexey, On May 2, 2019, at 14:40, Alexey Melnikov = wrote: >=20 > Hi Benjamin, >=20 > On Thu, May 2, 2019, at 1:05 AM, Benjamin Kaduk via Datatracker wrote: >=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> It's not clear to me that we're really specifying the semantics of a >> single media-type. The introduction discusses how we may want = multiple >> representations to appear in a sequence, potentially representing >> different content. >=20 > I think this is similar to multipart/mixed. We were indeed trying to follow the model of multipart/mixed. This offers a number of embedded representations the sequence of which = may or may not be important. >> Or we may have a set of related representations that >> conceptually are the same content (but are they literally the same >> resource, or related content?). >=20 > My understanding is that they are related contents. There is no promise that the related items are conceptually the same = content. The difference between the first situation and the second one mainly is = that the sequence is not important in the second (i.e., we are using the = sequence to describe a bag). >> And there is yet a third option -- one >> that I'm not sure I fully understand -- wherein the representation is >> not important, but rather which format is chosen of the several >> possibilities, to the extent that extreme compression of the >> representation is possible, with the compression just outputting the >> format indicator. >=20 > Hmm, I missed that. I think this is similar to multipart/alternative That wasn=E2=80=99t the intention. The choice in the third situation mentioned in the introduction is made = by the originator of the representation, not the receiver. The selected = representation is still packaged in an application/multipart-core = envelope so the media type does not need to diverge =E2=80=94 it is = essentially used as the (type!) union (a.k.a. choice) of the media types = that the application wants to be able to put in the envelope. We may have painted ourselves into a corner in RFC 7641 with the mandate = that the representations provided by an observable resource stay within = the same media type (content-format) over time. This makes it difficult = in CoAP to observe a resource that alternates between a =E2=80=9Cpending=E2= =80=9D and a =E2=80=9Cready=E2=80=9D state that have different = structures of their representation. Multipart-core can be used to = package either into the same media type. I don=E2=80=99t think the third situation has semantics that differ from = the first two. You still get a bag with a representation in it (or maybe none). You = still need to look into the bag to see what form it takes this time. = Actually, the second situation might also apply, so you might indeed get = a couple representations in certain instances because that=E2=80=99s = what best describes the resource at this particular time. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 2 06:14:03 2019 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 7521912036E; Thu, 2 May 2019 06:13:51 -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, 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 K0JIwC7GlpSd; Thu, 2 May 2019 06:13:49 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B8D120370; Thu, 2 May 2019 06:13:49 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44vwgv54hDzyZF; Thu, 2 May 2019 15:13:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <155680231113.24756.9200745714017967309.idtracker@ietfa.amsl.com> Date: Thu, 2 May 2019 15:13:47 +0200 Cc: The IESG , draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez , core-chairs@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 578495622.657848-cd8893cd7b9a69c0b19f49ab026032fc Content-Transfer-Encoding: quoted-printable Message-Id: <51EBA1D0-00B1-49DF-84CE-451D9F8E4929@tzi.org> References: <155680231113.24756.9200745714017967309.idtracker@ietfa.amsl.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Magnus Westerlund's Discuss on draft-ietf-core-multipart-ct-03: (with DISCUSS) 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, 02 May 2019 13:13:52 -0000 On May 2, 2019, at 15:05, Magnus Westerlund via Datatracker = wrote: >=20 > Magnus Westerlund has entered the following ballot position for > draft-ietf-core-multipart-ct-03: Discuss >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Are recursive application of the multipart format allowed? I don't = find anyting > disallowing that. Indeed, the intention was to provide full composability. (Whether recursion makes sense very often is hard to say now, but we = didn=E2=80=99t see a need for an arbitrary restriction based on a proof = by lack of imagination :-).) > I just want check that it is intentional before No Objection. Yes, intentional. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 2 06:17:48 2019 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 19A60120377; Thu, 2 May 2019 06:17:39 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=armh.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 ctzBTlMP6zrq; Thu, 2 May 2019 06:17:36 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150072.outbound.protection.outlook.com [40.107.15.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE9E120376; Thu, 2 May 2019 06:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1iYVLDGcXaQmmcqKnR3Vgp8NnxUB+bCzXQbPHScT2eQ=; b=S5rmPM7seDAhbJ1hWL0vmMNk5IngGygOnyKBMYoG8FfVeBC+L0ug7GRs7HUML+IS+gj3Bf3vt+GRxuQ6ZcZiYs2O2y4Jzysp9uZsjHu8VlV2h0rIGZhznWQ2vrQJ2Hcnhh7rjelTfrcfVk0LlJveAZpFdCwRrNA5aJbFepwbVmA= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.4.202) by AM6PR08MB3733.eurprd08.prod.outlook.com (20.178.88.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.10; Thu, 2 May 2019 13:17:33 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5482:1855:4483:98f1]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5482:1855:4483:98f1%5]) with mapi id 15.20.1856.008; Thu, 2 May 2019 13:17:33 +0000 From: Thomas Fossati To: Carsten Bormann , Magnus Westerlund CC: The IESG , "draft-ietf-core-multipart-ct@ietf.org" , Jaime Jimenez , "core-chairs@ietf.org" , "core@ietf.org" , Thomas Fossati Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-core-multipart-ct-03: (with DISCUSS) Thread-Index: AQHVAOevh34JU7oSXUqBxvKcVQmvuKZXz/CAgAAR0AA= Date: Thu, 2 May 2019 13:17:33 +0000 Message-ID: <8C70D651-ABCA-4ECB-BCA6-12B175669AAA@arm.com> References: <155680231113.24756.9200745714017967309.idtracker@ietfa.amsl.com> <51EBA1D0-00B1-49DF-84CE-451D9F8E4929@tzi.org> In-Reply-To: <51EBA1D0-00B1-49DF-84CE-451D9F8E4929@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [217.140.106.53] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 57de6fee-2b8e-42a3-babd-08d6cf008984 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB3733; x-ms-traffictypediagnostic: AM6PR08MB3733: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0025434D2D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(396003)(376002)(366004)(40434004)(189003)(199004)(26005)(186003)(6486002)(83716004)(305945005)(8676002)(6506007)(4326008)(102836004)(81156014)(11346002)(446003)(6512007)(5660300002)(82746002)(8936002)(81166006)(476003)(486006)(33656002)(6436002)(71190400001)(66066001)(68736007)(54906003)(316002)(76176011)(53546011)(72206003)(2616005)(110136005)(91956017)(2906002)(25786009)(6306002)(71200400001)(53936002)(86362001)(6246003)(14444005)(99286004)(229853002)(76116006)(478600001)(966005)(3846002)(256004)(5024004)(66556008)(66476007)(66946007)(73956011)(66446008)(7736002)(64756008)(36756003)(14454004)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3733; H:AM6PR08MB4231.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: R6EB/Zm+GbvbyHANmFai/56hvdrsyb+EtQaRRaYZMOppB9nZULNdmfbRnhQ6CXRR9kObgBtIifrK5bwwDFMTiFAbd/LoxcY6XAvJD0k7lYwGk7LQeOe9TRN30qXPPvtxpgpoJAARomoiKwsjWSDSFU4uBZtC3RVVooMhysGLxlFJjbzsecYB/oT03kfud+iCw75GI6jK446GdEwcd0/EWcNOjsD7zJq0zdYCPRCRnFuG4TqzdPjgC1XAvrRcyT1KItpVkXpN8vDaN6cjIt6zTgsG2g5wI8m/yX2tWE+ZIhsW5Z5w2oQGuyWao/wjUZuV6wNDSgUPmTRhFySO14CF7YdlQPmTxonmmuJrEP+aefWylNQPszFiucudc3r0QJ9Tq+SUSXadin742CLrFyAbFRnGB+GTslFbA+9CgGtLkW0= Content-Type: text/plain; charset="utf-8" Content-ID: <44E3310EE72E2E4BABE70C01F8BA3230@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 57de6fee-2b8e-42a3-babd-08d6cf008984 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 13:17:33.2409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3733 Archived-At: Subject: Re: [core] Magnus Westerlund's Discuss on draft-ietf-core-multipart-ct-03: (with DISCUSS) 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, 02 May 2019 13:17:39 -0000 SnVzdCB3YW50ZWQgdG8gYWRkIHRoYXQgSW4gdGhlIFNlY0NvbnMgd2Ugc3BlbGwgb3V0IHRoZSBl eHBsb2l0YXRpb24gcG90ZW50aWFsIGFzc29jaWF0ZWQgd2l0aCBuZXN0aW5nLg0KDQrvu79PbiAw Mi8wNS8yMDE5LCAxNDoxMywgIkNhcnN0ZW4gQm9ybWFubiIgPGNhYm9AdHppLm9yZz4gd3JvdGU6 DQoNCiAgICBPbiBNYXkgMiwgMjAxOSwgYXQgMTU6MDUsIE1hZ251cyBXZXN0ZXJsdW5kIHZpYSBE YXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQogICAgPg0KICAgID4gTWFnbnVz IFdlc3Rlcmx1bmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9y DQogICAgPiBkcmFmdC1pZXRmLWNvcmUtbXVsdGlwYXJ0LWN0LTAzOiBEaXNjdXNzDQogICAgPg0K ICAgID4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFj dCBhbmQgcmVwbHkgdG8gYWxsDQogICAgPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhl IFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KICAgID4gaW50cm9kdWN0 b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQogICAgPg0KICAgID4NCiAgICA+IFBsZWFzZSByZWZl ciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlh Lmh0bWwNCiAgICA+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQg Q09NTUVOVCBwb3NpdGlvbnMuDQogICAgPg0KICAgID4NCiAgICA+IFRoZSBkb2N1bWVudCwgYWxv bmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCiAgICA+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29yZS1tdWx0aXBh cnQtY3QvDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiBE SVNDVVNTOg0KICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4NCiAgICA+IEFyZSByZWN1cnNpdmUg YXBwbGljYXRpb24gb2YgdGhlIG11bHRpcGFydCBmb3JtYXQgYWxsb3dlZD8gSSBkb24ndCBmaW5k IGFueXRpbmcNCiAgICA+IGRpc2FsbG93aW5nIHRoYXQuDQoNCiAgICBJbmRlZWQsIHRoZSBpbnRl bnRpb24gd2FzIHRvIHByb3ZpZGUgZnVsbCBjb21wb3NhYmlsaXR5Lg0KICAgIChXaGV0aGVyIHJl Y3Vyc2lvbiBtYWtlcyBzZW5zZSB2ZXJ5IG9mdGVuIGlzIGhhcmQgdG8gc2F5IG5vdywgYnV0IHdl IGRpZG7igJl0IHNlZSBhIG5lZWQgZm9yIGFuIGFyYml0cmFyeSByZXN0cmljdGlvbiBiYXNlZCBv biBhIHByb29mIGJ5IGxhY2sgb2YgaW1hZ2luYXRpb24gOi0pLikNCg0KICAgID4gSSBqdXN0IHdh bnQgY2hlY2sgdGhhdCBpdCBpcyBpbnRlbnRpb25hbCBiZWZvcmUgTm8gT2JqZWN0aW9uLg0KDQog ICAgWWVzLCBpbnRlbnRpb25hbC4NCg0KICAgIEdyw7zDn2UsIENhcnN0ZW4NCg0KDQoNCg0KSU1Q T1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5m b3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Thu May 2 06:31:45 2019 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 AD25E120372; Thu, 2 May 2019 06:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 IGuovlXP7uuQ; Thu, 2 May 2019 06:31:37 -0700 (PDT) Received: from mail-it1-f193.google.com (mail-it1-f193.google.com [209.85.166.193]) (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 5AE96120135; Thu, 2 May 2019 06:31:37 -0700 (PDT) Received: by mail-it1-f193.google.com with SMTP id l10so3278726iti.3; Thu, 02 May 2019 06:31:37 -0700 (PDT) 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=FQCKlzM5rfByiRVRe4RzUM/P7JADY6C8VEWy/hjtsBQ=; b=VJVzRAsn0019aKtCncPQYkifMj+GlCBRMirTqpKUECkwsS1GIWLTMQsTUVmOk8WeY5 llEtvh9IsiHbUv6qKz2zyayQyq8CvlpcvfKs2IPyH3zKRRSQKI25X6hji8hFjMt0Pf9z tasR3fhQVpOQ1y1Oa0ThE1VLwqz++4jogfUHSJArmIJK5aIsj2pk3TXIIkxVpWnV06mb IHWmhsg5p/Fd4GjcDAttSI6X8mPQ1yNPykoJohbEhv++hH5W1miVQLWXJVisAvB0j14S kIRQuBdoUXEBTAfq6HH7M0EUuIHly/QeytB7xT60U17JuOLfLgX4G3sLQMbJQzy1bWFE BtCA== X-Gm-Message-State: APjAAAV21GquZrLaJSrfK5TVGKfBI+eJl0Xh89un6kfzTcC2EYBQu3A8 iyTldwbJ/UFhKBbE6YrptXyvkYNu2qG0IJO8L6E= X-Google-Smtp-Source: APXvYqxlo12qArhQDBgAoR2iSkSe6NQ6zApf4mLkpNPCSJJqOa1G2qZ+teMulCr1yloTm8H5OWyDInQz93I2SpaxWgo= X-Received: by 2002:a24:7dd2:: with SMTP id b201mr2617642itc.93.1556803896398; Thu, 02 May 2019 06:31:36 -0700 (PDT) MIME-Version: 1.0 References: <155664436774.7505.12604389698979572964.idtracker@ietfa.amsl.com> <20190502050851.GC59871@kduck.mit.edu> <766B38CD-2E79-4997-AC08-CE9CD6A2E8F4@tzi.org> In-Reply-To: <766B38CD-2E79-4997-AC08-CE9CD6A2E8F4@tzi.org> From: Barry Leiba Date: Thu, 2 May 2019 09:31:25 -0400 Message-ID: To: Carsten Bormann Cc: Benjamin Kaduk , jaime.jimenez@ericsson.com, draft-ietf-core-multipart-ct@ietf.org, Alissa Cooper , The IESG , core WG , core-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] Alissa Cooper's No Objection on draft-ietf-core-multipart-ct-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, 02 May 2019 13:31:39 -0000 > >>> "The second, fourth, sixth, etc. element is a > >>> byte string containing a representation, or the value "null" if an > >>> optional part is indicated as not given. The first, third, fifth, > >>> etc. element is an unsigned integer specifying the content format ID > >>> of the representation following it." > >>> > >>> I think it would be more precise to refer to the "even-numbered eleme= nts" and > >>> the "odd-numbered elements" rather than enumerating the elements and = saying > >>> =E2=80=9Cetc." > >> > >> The problem with =E2=80=9Ceven-numbered=E2=80=9D and =E2=80=9Codd-numb= ered=E2=80=9D is that it isn=E2=80=99t > >> explicit about counting from zero (which is how I would read it, so > >> first/third/fifth would be =E2=80=9Ceven-numbered=E2=80=9D!) or counti= ng from one > >> (which also would be natural for some people). Using the actual > >> ordinals removes that ambiguity, as ordinals count from one. With > >> the rest of the text, the example, and the CDDL, I believe this is a > >> quite unambiguous way to introduce the sequence. > > > > FWIW, the current text managed to confuse me, as I kept looking for wha= t > > the zeroth element was and why it was different from everything else. > > So maybe we can=E2=80=99t make everyone happy. > > Interesting. Yes, some people do use ordinals starting from zero. > > So how about: > > Counting from zero, the odd-numbered elements are a byte string containin= g > a representation, or the value `null` if an optional part is indicated > as not given. > The (even-numbered) element preceding each of these is an unsigned intege= r > specifying the content format ID of the representation following it. OOOOH, no, that's *horrible*. It will *never* work to call the 2nd and 4th elements "odd-numbered". You can't say that "counting from zero, zero is element one." You can have it both ways like this: NEW Each even-numbered element (second, fourth, sixth, etc.) is a byte string containing a representation, or the value "null" if an optional part is indicated as not given. Each odd-numbered element (first, third, fifth, etc.) is an unsigned integer specifying the content format ID of the representation following it. END Replacing "the" with "each" also makes it clearer. Barry From nobody Thu May 2 06:50:16 2019 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 DCBB9120135; Thu, 2 May 2019 06:50:04 -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, 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 D_xtfCKEQ8NM; Thu, 2 May 2019 06:50:02 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106C4120103; Thu, 2 May 2019 06:50:02 -0700 (PDT) Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44vxTh090dzyVZ; Thu, 2 May 2019 15:49:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <155454280808.21871.333722671657907840@ietfa.amsl.com> Date: Thu, 2 May 2019 15:49:59 +0200 Cc: gen-art@ietf.org, draft-ietf-core-multipart-ct.all@ietf.org, ietf@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 578497798.029436-ee86fd8b54c15ebf7f7cba6bb1a58e4f Content-Transfer-Encoding: quoted-printable Message-Id: <9440547E-E592-48BE-B344-4B5CD7E98474@tzi.org> References: <155454280808.21871.333722671657907840@ietfa.amsl.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Genart last call review of draft-ietf-core-multipart-ct-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: Thu, 02 May 2019 13:50:05 -0000 Hi Stewart, Thank you for the review. We already communicated about fixing one of = the items, but it seems the rest of our response never made it out. = Here goes=E2=80=A6 > On Apr 6, 2019, at 11:26, Stewart Bryant via Datatracker = wrote: >=20 > Reviewer: Stewart Bryant > Review result: Ready with Nits >=20 > 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. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-core-multipart-ct-03 > Reviewer: Stewart Bryant > Review Date: 2019-04-06 > IETF LC End Date: 2019-04-08 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > Apart from one figure that was difficult to understand and some = trivial nits > this is well written and is ready for publication. >=20 > Major issues: None >=20 > Minor issues: >=20 > __________ __________ __________ > | | | | | | > ---->| 2.05 |---->| 2.05 / |---->| 4.xx / | > | Pending | | 2.03 | | 5.xx | > |__________| |__________| |__________| > ^ \ \ ^ \ ^ > \__/ \ \___/ / > \_______________________/ >=20 > Figure 2: Sequence of Notifications: > SB> Not my specialty, but I don't see what message gets sent > SB> to who in the above and RFC7641 has no similar diagram. The intention of this figure is probably more apparent to someone = thinking in terms of CoAP notifications. All these notifications flow from the server to the client. RFC7641 does not have such a diagram because it doesn=E2=80=99t consider = sequences of notifications that differ in interesting ways, but this is = indeed a side view of the notification part of Figure 1 there=E2=80=A6 So we changed: The possible resulting sequence of notifications is shown in Figure 1. =E2=9E=94 A diagram depicting possible resulting sequences of notifications, identified by their respective response = code, is shown in Figure 1. = https://github.com/core-wg/multipart-ct/commit/f94dd670dde88e7234b227ccaca= db10660db489a This is now in branch ietf-lc-fixes on = https://github.com/core-wg/multipart-ct CI build in = https://core-wg.github.io/multipart-ct/ietf-lc-fixes/draft-ietf-core-multi= part-ct.html Diff in = https://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-ietf= -core-multipart-ct.txt&url2=3Dhttps://core-wg.github.io/multipart-ct/ietf-= lc-fixes/draft-ietf-core-multipart-ct.txt > Nits/editorial comments: > accompanying it. In such a case, the sequence in which these occur > may not be relevant to the application. This specification allows to > SB> typo - word missing > indicate that an optional part is not present by substituting a null > value for the representation of the part. >=20 [See previous message; also fixed in ietf-lc-fixes.] >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The collection is encoded as a CBOR [RFC7049] array with an even > SB> CBOR needs expanding on first use (it is not on the well known = list) > number of elements. (Sigh. You are right of course. Until that list is fixed, this is = probably best done by adding a sentence that indicates we are using = CBOR.) Also in = https://github.com/core-wg/multipart-ct/commit/f94dd670dde88e7234b227ccaca= db10660db489a > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Person & email address to contact for further information: > iesg&ietf.org > SB> Shouldn=E2=80=99t that be iesg@ietf.org? Yes, which will then be promptly turned back into the above by IANA (who = seems to try to spam-protect iesg@ietf.org :-). I hope the RFC editor = and IANA can bring this into what is today=E2=80=99s preferred format. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu May 2 07:43:28 2019 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 EC81A12038F; Thu, 2 May 2019 07:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 wHOQC7pD8jdl; Thu, 2 May 2019 07:43:17 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id BD02212013E; Thu, 2 May 2019 07:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1556808196; d=isode.com; s=june2016; i=@isode.com; bh=qyue2sRWi7GZl5wDQy6LlQiDhjmEZDr/fj3UsKLNhX4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=m/a7ZJIGviQm+dp9hFbQFB87wE48h/OtssVD3fh7YyTE/svBiCzurz5+lLpI2P0PG25MSj OFvwBkBJgo/dwA4k5EcjlI5YPvxh5X2pNk96H60eMix0dhPIdyc2JcP5jEMW8Vdl1dwRxH jLL+kmwcjrdfCNvgGhSUzATh+Y9303M=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 2 May 2019 15:43:15 +0100 To: =?UTF-8?Q?=c3=89ric_Vyncke?= , The IESG Cc: core-chairs@ietf.org, jaime.jimenez@ericsson.com, draft-ietf-core-multipart-ct@ietf.org, core@ietf.org References: <155678423180.24812.12944181740008384821.idtracker@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <39908791-1d26-f8a9-b30b-8b4792d35756@isode.com> Date: Thu, 2 May 2019 15:42:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 In-Reply-To: <155678423180.24812.12944181740008384821.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-multipart-ct-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, 02 May 2019 14:43:20 -0000 On 02/05/2019 09:03, =C3=89ric Vyncke via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to the authors for their work. Short and clear document, I have > appreciated the example of CBOR encoding. > > =3D=3D comments =3D=3D > > In section 2, I wonder the error in CBOR decoding: should it stop or compl= etely > ignore all parts of the message? Is there any use case where decoding only= part > of the messsage causes problem? I think this is rather implementation specific. Many implementations=20 would stop parsing on error, but many are unlikely to check the whole=20 payload for validity at CBOR level. From nobody Thu May 2 07:44:07 2019 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 66FCB120372; Thu, 2 May 2019 07:44:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-core-multipart-ct@ietf.org, Jaime Jimenez , core-chairs@ietf.org, jaime.jimenez@ericsson.com, core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <155680824541.24923.75461284773900533.idtracker@ietfa.amsl.com> Date: Thu, 02 May 2019 07:44:05 -0700 Archived-At: Subject: [core] Magnus Westerlund's No Objection on draft-ietf-core-multipart-ct-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, 02 May 2019 14:44:05 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-core-multipart-ct-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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-multipart-ct/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the rapid response. I am happy to clear. However, I think it would be good to be explict about that nesting is allowed in the definition even if the formal language implies it. From nobody Sat May 4 16:22:15 2019 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 8C32912008C; Sat, 4 May 2019 16:22:07 -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 ZIDcR06zo_h2; Sat, 4 May 2019 16:22:05 -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 17B2F12007A; Sat, 4 May 2019 16:22:04 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x44NLrP8000946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 4 May 2019 19:21:56 -0400 Date: Sat, 4 May 2019 18:21:53 -0500 From: Benjamin Kaduk To: Carsten Bormann Cc: Alexey Melnikov , The IESG , draft-ietf-core-multipart-ct@ietf.org, Jaime =?iso-8859-1?Q?Jim=E9nez?= , core-chairs@ietf.org, core@ietf.org Message-ID: <20190504232153.GA19805@kduck.mit.edu> References: <155675554069.2851.9351849772053196736.idtracker@ietfa.amsl.com> <459433ef-5cb5-4c3e-a32e-a5d063b1ccf0@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-multipart-ct-03: (with DISCUSS and 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: Sat, 04 May 2019 23:22:08 -0000 On Thu, May 02, 2019 at 03:11:25PM +0200, Carsten Bormann wrote: > Hi Alexey, > > On May 2, 2019, at 14:40, Alexey Melnikov wrote: > > > > Hi Benjamin, > > > > On Thu, May 2, 2019, at 1:05 AM, Benjamin Kaduk via Datatracker wrote: > > > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> It's not clear to me that we're really specifying the semantics of a > >> single media-type. The introduction discusses how we may want multiple > >> representations to appear in a sequence, potentially representing > >> different content. > > > > I think this is similar to multipart/mixed. > > We were indeed trying to follow the model of multipart/mixed. > This offers a number of embedded representations the sequence of which may or may not be important. > > >> Or we may have a set of related representations that > >> conceptually are the same content (but are they literally the same > >> resource, or related content?). > > > > My understanding is that they are related contents. > > There is no promise that the related items are conceptually the same content. > The difference between the first situation and the second one mainly is that the sequence is not important in the second (i.e., we are using the sequence to describe a bag). > > >> And there is yet a third option -- one > >> that I'm not sure I fully understand -- wherein the representation is > >> not important, but rather which format is chosen of the several > >> possibilities, to the extent that extreme compression of the > >> representation is possible, with the compression just outputting the > >> format indicator. > > > > Hmm, I missed that. I think this is similar to multipart/alternative > > That wasn’t the intention. I think that analogies to multipart/mixed and/or multipart/alternative would help the reviewer assess whether the document text succeeds at describing the intended behavior (though it's not clear that using such a reference to attempt to define the behavior by reference is a useful plan). > The choice in the third situation mentioned in the introduction is made by the originator of the representation, not the receiver. The selected representation is still packaged in an application/multipart-core envelope so the media type does not need to diverge — it is essentially used as the (type!) union (a.k.a. choice) of the media types that the application wants to be able to put in the envelope. > > We may have painted ourselves into a corner in RFC 7641 with the mandate that the representations provided by an observable resource stay within the same media type (content-format) over time. This makes it difficult in CoAP to observe a resource that alternates between a “pending” and a “ready” state that have different structures of their representation. Multipart-core can be used to package either into the same media type. So while this may not be quite multipart/alternative, there are still alternatives involved; they are just delievered in separate (streamed) responses, as opposed to together in the same one. That is, the alternation is over time and not at the choice of the recipient. > I don’t think the third situation has semantics that differ from the first two. > You still get a bag with a representation in it (or maybe none). You still need to look into the bag to see what form it takes this time. Actually, the second situation might also apply, so you might indeed get a couple representations in certain instances because that’s what best describes the resource at this particular time. I think it's important to be clear about whether the sequencing within a given content array is or is not semantically relevant, and under what conditions a recipient might only consult a subset of the array (multipart/alternative) vs. assembling a conglomerate from components of different types (multipart/mixed). -Ben From nobody Mon May 6 07:45:46 2019 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 7EAE612018E; Mon, 6 May 2019 07:45:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155715393742.6687.14477387050217659612@ietfa.amsl.com> Date: Mon, 06 May 2019 07:45:37 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-echo-request-tag-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: Mon, 06 May 2019 14:45:38 -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 : CoAP: Echo, Request-Tag, and Token Processing Authors : Christian Amsüss John Mattsson Göran Selander Filename : draft-ietf-core-echo-request-tag-05.txt Pages : 25 Date : 2019-05-06 Abstract: This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match Block-Wise message fragments belonging to the same request. The updated Token processing requirements for clients ensure secure binding of responses to requests when CoAP is used with security. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-05 https://datatracker.ietf.org/doc/html/draft-ietf-core-echo-request-tag-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-echo-request-tag-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 7 01:24:50 2019 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 4632612009E; Tue, 7 May 2019 01:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 5ZRK7gdiU8PX; Tue, 7 May 2019 01:24:34 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30082.outbound.protection.outlook.com [40.107.3.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBEE12001E; Tue, 7 May 2019 01:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=teqtRPBWGMnP1rY0Zp55DUP9HsPiOnHRCii2Uel1098=; b=PUNQOvoRTUDL3SA/bVXeVEwM61lJHx5dBJijDU2sxTrsh/SBw3oqWJKU0jK+Tkn2S0t7LR9g6D7s88bpuleBuM+ovyGpbj56qKM+PhHbqFYbdYpZcLsAaFODBUvzDvsKamvQZNzGEpn8Z0Xe0TuGfP6inUeu8ClHIJkopyxI1mE= Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.185.17) by HE1PR0701MB2249.eurprd07.prod.outlook.com (10.168.31.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.19; Tue, 7 May 2019 08:24:30 +0000 Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2130:5ad6:fafb:c4c8]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::2130:5ad6:fafb:c4c8%8]) with mapi id 15.20.1878.019; Tue, 7 May 2019 08:24:30 +0000 From: Francesca Palombini To: "cose@ietf.org" , "core@ietf.org WG" , "cbor@ietf.org" , "Ace@ietf.org" CC: Cose Chairs Wg , "core-chairs@ietf.org" , "cbor-chairs@ietf.org" , "ace-chairs@ietf.org" Thread-Topic: [Cbor] [Ace] Doodle poll for virtual interims Thread-Index: AQHVBK5K4v+s+vwmOEaJ9TA4LL9/TA== Date: Tue, 7 May 2019 08:24:30 +0000 Message-ID: <2101B222-960B-4378-9676-5A68BFE4315A@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b14bdf2-b34a-4b81-74e2-08d6d2c56da2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2249; x-ms-traffictypediagnostic: HE1PR0701MB2249: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(366004)(136003)(396003)(199004)(189003)(53754006)(54896002)(66066001)(66574012)(236005)(99286004)(5660300002)(2201001)(14454004)(7736002)(256004)(14444005)(102836004)(478600001)(6486002)(6306002)(6512007)(6506007)(8936002)(790700001)(3846002)(6116002)(606006)(53546011)(6246003)(966005)(53936002)(86362001)(68736007)(2501003)(486006)(73956011)(66946007)(66476007)(66556008)(64756008)(66446008)(76116006)(2616005)(476003)(71190400001)(26005)(33656002)(316002)(8676002)(83716004)(81166006)(4326008)(186003)(81156014)(71200400001)(450100002)(54906003)(36756003)(2906002)(110136005)(25786009)(229853002)(44832011)(82746002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2249; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: UaZAWx2boEcehQOdBjiGdfmIkO8cK96CGXgKkZqS1w911RLJMnED+4OUb08nDe59/tE+EiH3+wg7VJuc+BqrWkDg+C+vVx3jiX/HDLVYhrTenafrtYu5WY/cnrZNojXVHihkdPnINYaDp2IDDjOPXI8nn/Qd9XwBOqpzgzQW059RrsCTzCvO7d+y2l8NO+8kSSWp9DrpKckE3bFHadWWZdjfUr9VHkhXgkU+sUHgGveoKz6agbjQy2ODFa+0BBd3YxHz1RaahQmf6ksHhGmoweXXr0CMX+2sbCqB/F/8XSm0Hn0U6KmiUeNklN6uwhOjETUI4S6KiYemo9BgmpAqdbs4Njh27Fw3rcp8Kf6VnVejMF3s7A938KiPM8LLCczSMfa6jRCzW3+HwXa7YehFfaaGSplOak68kGkNNMeFA/w= Content-Type: multipart/alternative; boundary="_000_2101B222960B437896765A68BFE4315Aericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b14bdf2-b34a-4b81-74e2-08d6d2c56da2 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 08:24:30.7155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2249 Archived-At: Subject: Re: [core] [Cbor] [Ace] Doodle poll for virtual interims 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, 07 May 2019 08:24:37 -0000 --_000_2101B222960B437896765A68BFE4315Aericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGFuayB5b3UgdG8gdGhvc2UgcGFydGljaXBhdGluZyBpbiB0aGUgZG9vZGxl IHBvbGwsIGFuZCB0aGFua3MgdG8gbHB3YW4gV0cgZm9yIGFkanVzdGluZyB0aGVpciBpbnRlcmlt IHRpbWUgYXJvdW5kIG91ciBwcmVmZXJyZWQgdGltZSEgVGhlIHdpbm5pbmcgdGltZXNsb3QgaXMg dGhlIDE1OjAwIOKAkyAxNjozMCBVVEMuDQoNCkFzIGEgcmVzdWx0LCBDQk9SIFdHIHdpbGwgaGF2 ZSBjb25mZXJlbmNlIGNhbGxzIGV2ZXJ5IG90aGVyIFdlZG5lc2RheSBzdGFydGluZyBNYXkgMjJu ZCwgMTU6MDAgdG8gMTY6MDAgVVRDIDogaHR0cHM6Ly93d3cuZXBvY2hjb252ZXJ0ZXIuY29tL3Rp bWV6b25lcz9xPTE1NTg1MzcyMDAmdHo9RXVyb3BlJTJGQmVybGluDQoNClRoZSBTZWNyZXRhcmlh dCB3aWxsIGFubm91bmNlIHRoZSBjYWxscyBzb29uLCBidXQgaGVyZSBpcyBhIHN1bW1hcnk6DQoN CkRheTogZXZlcnkgb3RoZXIgV2VkbmVzZGF5IGJlZ2lubmluZyBvbiBNYXkgMjJuZA0KRGF0ZXM6 ICAyMiBNYXk7IDUsIDE5IEp1bmU7IDMsIDE3LCAzMSBKdWx5OyAxNCwgMjggQXVnOyAxMSwgMjUg U2VwdDsgOSwgMjMgT2N0OyA2IE5vdg0KVGltZTogMTU6MDAgdG8gMTY6MDAgVVRDIGZvciBhbGwg ZGF0ZXMgZXhjZXB0IDYgTm92OyA2IE5vdjogMTY6MDAg4oCTIDE3OjAwIFVUQw0KDQoqKiBOb3Rl IHRoYXQgbG9jYWwgdGltZSBpbiBOQSB3aWxsIGNoYW5nZSBmb3IgdGhlIDYgTm92IG1lZXRpbmcu IExvY2FsIHRpbWUgd2lsbCBub3QgY2hhbmdlIGluIEV1cm9wZS4gKioNCg0KV2Ugd2lsbCB1c2Ug dGhlIHdvcmtpbmcgZ3JvdXAgV2ViRXggZm9yIHRoZSBjYWxscy4gIFRoZSBJRVRGIFdlYkV4DQph Y2NvdW50IGRvZXMgbm90IGFsbG93IEludGVybmF0aW9uYWwgZGlhbGxpbmcgbm9yIFVTIHRvbGwg ZnJlZSAoIjgwMCINCm51bWJlcnMpLCBidXQgeW91IGNhbiB1c2UgdGhlIFdlYkV4IGFwcCB0byBj b25uZWN0IHlvdXIgZGV2aWNlIGF1ZGlvLA0KYW5kIHRoZXJlJ3MgYWxzbyB0aGUgb3B0aW9uIG9m IGNvbm5lY3Rpb24gZGlyZWN0bHkgZnJvbSB5b3VyIGJyb3dzZXINCmlmIHlvdXIgYnJvd3NlciBz dXBwb3J0cyBpdC4NCg0KV2ViRXggZGV0YWlscyB3aWxsIGJlIHNlbnQgdG8gdGhlIG1haWxpbmcg bGlzdCBiZWZvcmUgZWFjaCBjYWxsICh0aGUNCmRldGFpbHMgd2lsbCBiZSB0aGUgc2FtZSBmb3Ig YWxsIGNhbGxzLCBidXQgdGhlIG1lc3NhZ2VzIHdpbGwgc2VydmUgYXMNCnJlbWluZGVycykuDQoN Cg0KVGhhbmtzLA0KRnJhbmNlc2NhIChhcyBDQk9SIGNoYWlyKQ0KDQpGcm9tOiBDQk9SIDxjYm9y LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFu Y2VzY2EucGFsb21iaW5pQGVyaWNzc29uLmNvbT4NCkRhdGU6IE1vbmRheSwgMTUgQXByaWwgMjAx OSBhdCAxNzo0NA0KVG86IENvc2UgV2cgPGNvc2VAaWV0Zi5vcmc+LCAiY29yZUBpZXRmLm9yZyBX RyIgPGNvcmVAaWV0Zi5vcmc+LCAiY2JvckBpZXRmLm9yZyIgPGNib3JAaWV0Zi5vcmc+LCBBY2Ug V2cgPEFjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ2Jvcl0gW0FjZV0gRG9vZGxlIHBvbGwg Zm9yIHZpcnR1YWwgaW50ZXJpbXMNCg0KSGksDQoNClBsZWFzZSBlbnRlciB5b3VyIGF2YWlsYWJp bGl0eSBieSB0aGlzIEZyaWRheSwgQXByaWwgMTl0aDogaHR0cHM6Ly9kb29kbGUuY29tL3BvbGwv dmU3cm55YXJlcmkya3Flcg0KDQpBcyBLbGF1cyBzYWlkLCB0aGUgdGltZSBzbG90cyBhcmUgdG8g Y2hvc2UgZm9yIHdlZWtseSBtZWV0aW5ncywgc28gZGlzcmVnYXJkIHRoZSBleGFjdCBkYXRlcyBp biB0aGUgZG9vZGxlIHBvbGwsIGJ1dCBvbmx5IGNvbnNpZGVyIHRoZSBkYXkgb2YgdGhlIHdlZWsu DQoNClRoZSBnb2FsIGlzIHRvIHJlc3RhcnQgdGhlIG1lZXRpbmdzIGJ5IHRoZSAybmQgd2VlayBv ZiBNYXksIGFuZCB3ZSBuZWVkIGEgY291cGxlIG9mIHdlZWtzIHRvIHNldCBpdCB1cCB3aXRoIHRo ZSBTZWNyZXRhcmlhdC4NCg0KQWxzbyBub3RlIHRoYXQgdGhlIHRpbWVzbG90cyBhcmUgOTAgbWlu dXRlcyBsb25nLCB0byBhbGxvdyBmb3IgbG9uZ2VyIGludGVyaW0gdGltZSBpZiBuZWVkZWQuDQoN Cg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCk9uIDEzIEFwcmlsIDIwMTkgYXQgMTY6NDc6MDIgQ0VT VCwgS2xhdXMgSGFydGtlIDxoYXJ0a2VAcHJvamVjdGNvb2wuZGU+IHdyb3RlOg0KV2UgYXJlIGxv b2tpbmcgZm9yIGEgbmV3IHRpbWUgc2xvdCBmb3IgdGhlIENvUkUvQ0JPUi9DT1NFIHZpcnR1YWwN CmludGVyaW1zIHVudGlsIElFVEYgMTA1Lg0KDQpQcm9wb3NlZCBvcHRpb25zOg0KDQo3YW0gUERU IC8gMTBhbSBFRFQgLyA0cG0gQ0VTVCAvIDExcG0gSlNUDQo4YW0gUERUIC8gMTFhbSBFRFQgLyA1 cG0gQ0VTVCAvIDEybWlkbiBKU1QNCjlhbSBQRFQgLyAxMm5vb24gRURUIC8gNnBtIENFU1QgLyAx YW0gSlNUDQoxMGFtIFBEVCAvIDFwbSBFRFQgLyA3cG0gQ0VTVCAvIDJhbSBKU1QNCg0KVGhlIGlu dGVyaW1zIGFyZSBzY2hlZHVsZWQgdG8gYmUgd2Vla2x5LCBhbHRlcm5hdGluZyBiZXR3ZWVuIENv UkUgYW5kDQpDQk9SL0NPU0UgKGFuZCBhIGRhc2ggb2YgQUNFKS4NCg0KUGxlYXNlIHVzZSB0aGlz IGRvb2RsZSBwb2xsIHRvIGluZGljYXRlIHlvdXIgcHJlZmVyZW5jZToNCmh0dHBzOi8vZG9vZGxl LmNvbS9wb2xsL3ZlN3JueWFyZXJpMmtxZXINCg0KS2xhdXMNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFjZSBtYWlsaW5nIGxpc3QNCkFjZUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg== --_000_2101B222960B437896765A68BFE4315Aericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <0DC4CFE33C912F4A81C22865BB8BA8D3@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4ubnVsbA0KCXttc28tc3R5bGUt bmFtZTpudWxsO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoYW5rIHlvdSB0byB0aG9zZSBwYXJ0aWNpcGF0aW5nIGluIHRoZSBkb29kbGUgcG9sbCwgYW5k IHRoYW5rcyB0byBscHdhbiBXRyBmb3IgYWRqdXN0aW5nIHRoZWlyIGludGVyaW0gdGltZSBhcm91 bmQgb3VyIHByZWZlcnJlZCB0aW1lISBUaGUgd2lubmluZyB0aW1lc2xvdCBpcyB0aGUgMTU6MDAg 4oCTIDE2OjMwIFVUQy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgYSByZXN1bHQsIENCT1Ig V0cgd2lsbCBoYXZlIGNvbmZlcmVuY2UgY2FsbHMgZXZlcnkgb3RoZXIgV2VkbmVzZGF5IHN0YXJ0 aW5nIE1heSAyMm5kLCAxNTowMCB0byAxNjowMCBVVEMgOg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu ZXBvY2hjb252ZXJ0ZXIuY29tL3RpbWV6b25lcz9xPTE1NTg1MzcyMDAmYW1wO3R6PUV1cm9wZSUy RkJlcmxpbiI+DQpodHRwczovL3d3dy5lcG9jaGNvbnZlcnRlci5jb20vdGltZXpvbmVzP3E9MTU1 ODUzNzIwMCZhbXA7dHo9RXVyb3BlJTJGQmVybGluPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgU2VjcmV0YXJpYXQgd2lsbCBhbm5vdW5jZSB0aGUgY2FsbHMgc29vbiwgYnV0IGhlcmUg aXMgYSBzdW1tYXJ5OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXk6IGV2ZXJ5IG90aGVyIFdl ZG5lc2RheSBiZWdpbm5pbmcgb24gTWF5IDIybmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRhdGVzOiZuYnNwOyAyMiBNYXk7IDUsIDE5IEp1bmU7IDMsIDE3LCAzMSBKdWx5 OyAxNCwgMjggQXVnOyAxMSwgMjUgU2VwdDsgOSwgMjMgT2N0OyA2IE5vdjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGltZTogMTU6MDAgdG8gMTY6MDAgVVRDIGZvciBhbGwg ZGF0ZXMgZXhjZXB0IDYgTm92OyA2IE5vdjogMTY6MDAg4oCTIDE3OjAwIFVUQzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4qKiBOb3RlIHRoYXQgbG9jYWwgdGltZSBpbiBOQSB3aWxsIGNoYW5nZSBm b3IgdGhlIDYgTm92IG1lZXRpbmcuIExvY2FsIHRpbWUgd2lsbCBub3QgY2hhbmdlIGluIEV1cm9w ZS4gKio8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd2lsbCB1c2UgdGhlIHdvcmtpbmcgZ3Jv dXAgV2ViRXggZm9yIHRoZSBjYWxscy4mbmJzcDsgVGhlIElFVEYgV2ViRXg8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFjY291bnQgZG9lcyBub3QgYWxsb3cgSW50ZXJuYXRp b25hbCBkaWFsbGluZyBub3IgVVMgdG9sbCBmcmVlICgmcXVvdDs4MDAmcXVvdDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm51bWJlcnMpLCBidXQgeW91IGNhbiB1c2UgdGhl IFdlYkV4IGFwcCB0byBjb25uZWN0IHlvdXIgZGV2aWNlIGF1ZGlvLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHRoZXJlJ3MgYWxzbyB0aGUgb3B0aW9uIG9mIGNvbm5l Y3Rpb24gZGlyZWN0bHkgZnJvbSB5b3VyIGJyb3dzZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmlmIHlvdXIgYnJvd3NlciBzdXBwb3J0cyBpdC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2ViRXggZGV0YWlscyB3aWxsIGJlIHNlbnQgdG8gdGhlIG1haWxpbmcgbGlzdCBi ZWZvcmUgZWFjaCBjYWxsICh0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmRldGFpbHMgd2lsbCBiZSB0aGUgc2FtZSBmb3IgYWxsIGNhbGxzLCBidXQgdGhlIG1lc3NhZ2Vz IHdpbGwgc2VydmUgYXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJlbWlu ZGVycykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RnJhbmNlc2NhIChhcyBDQk9SIGNoYWlyKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+Q0JPUiAmbHQ7Y2Jvci1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBi ZWhhbGYgb2YgRnJhbmNlc2NhIFBhbG9tYmluaSAmbHQ7ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmlj c3Nvbi5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgMTUgQXByaWwgMjAxOSBhdCAx Nzo0NDxicj4NCjxiPlRvOiA8L2I+Q29zZSBXZyAmbHQ7Y29zZUBpZXRmLm9yZyZndDssICZxdW90 O2NvcmVAaWV0Zi5vcmcgV0cmcXVvdDsgJmx0O2NvcmVAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtjYm9y QGlldGYub3JnJnF1b3Q7ICZsdDtjYm9yQGlldGYub3JnJmd0OywgQWNlIFdnICZsdDtBY2VAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbQ2Jvcl0gW0FjZV0gRG9vZGxlIHBv bGwgZm9yIHZpcnR1YWwgaW50ZXJpbXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBlbnRlciB5b3VyIGF2YWlsYWJpbGl0eSBieSB0 aGlzIEZyaWRheSwgQXByaWwgMTl0aDombmJzcDtodHRwczovL2Rvb2RsZS5jb20vcG9sbC92ZTdy bnlhcmVyaTJrcWVyJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFzIEtsYXVzIHNhaWQsIHRoZSB0aW1lIHNsb3RzIGFyZSB0byBjaG9z ZSBmb3Igd2Vla2x5IG1lZXRpbmdzLCBzbyBkaXNyZWdhcmQgdGhlIGV4YWN0IGRhdGVzIGluIHRo ZSBkb29kbGUgcG9sbCwgYnV0IG9ubHkgY29uc2lkZXIgdGhlIGRheSBvZiB0aGUgd2Vlay48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGdv YWwgaXMgdG8gcmVzdGFydCB0aGUgbWVldGluZ3MgYnkgdGhlIDJuZCB3ZWVrIG9mIE1heSwgYW5k IHdlIG5lZWQgYSBjb3VwbGUgb2Ygd2Vla3MgdG8gc2V0IGl0IHVwIHdpdGggdGhlIFNlY3JldGFy aWF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BbHNvIG5vdGUgdGhhdCB0aGUgdGltZXNsb3RzIGFyZSA5MCBtaW51dGVzIGxvbmcsIHRvIGFs bG93IGZvciBsb25nZXIgaW50ZXJpbSB0aW1lIGlmIG5lZWRlZC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpUaGFua3MsIDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyYW5jZXNjYTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiAxMyBBcHJpbCAyMDE5IGF0IDE2OjQ3OjAyIENFU1QsIEtsYXVzIEhh cnRrZSAmbHQ7aGFydGtlQHByb2plY3Rjb29sLmRlJmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA4LjBwdDttYXJnaW4tbGVmdDow Y207bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgbG9va2luZyBmb3IgYSBu ZXcgdGltZSBzbG90IGZvciB0aGUgQ29SRS9DQk9SL0NPU0UgdmlydHVhbDxicj4NCmludGVyaW1z IHVudGlsIElFVEYgMTA1Ljxicj4NCjxicj4NClByb3Bvc2VkIG9wdGlvbnM6PGJyPg0KPGJyPg0K N2FtIFBEVCAvIDEwYW0gRURUIC8gNHBtIENFU1QgLyAxMXBtIEpTVDxicj4NCjhhbSBQRFQgLyAx MWFtIEVEVCAvIDVwbSBDRVNUIC8gMTJtaWRuIEpTVDxicj4NCjlhbSBQRFQgLyAxMm5vb24gRURU IC8gNnBtIENFU1QgLyAxYW0gSlNUPGJyPg0KMTBhbSBQRFQgLyAxcG0gRURUIC8gN3BtIENFU1Qg LyAyYW0gSlNUPGJyPg0KPGJyPg0KVGhlIGludGVyaW1zIGFyZSBzY2hlZHVsZWQgdG8gYmUgd2Vl a2x5LCBhbHRlcm5hdGluZyBiZXR3ZWVuIENvUkUgYW5kPGJyPg0KQ0JPUi9DT1NFIChhbmQgYSBk YXNoIG9mIEFDRSkuPGJyPg0KPGJyPg0KUGxlYXNlIHVzZSB0aGlzIGRvb2RsZSBwb2xsIHRvIGlu ZGljYXRlIHlvdXIgcHJlZmVyZW5jZTo8YnI+DQo8YSBocmVmPSJodHRwczovL2Rvb2RsZS5jb20v cG9sbC92ZTdybnlhcmVyaTJrcWVyIiB0YXJnZXQ9Il9CTEFOSyI+aHR0cHM6Ly9kb29kbGUuY29t L3BvbGwvdmU3cm55YXJlcmkya3FlcjwvYT48YnI+DQo8YnI+DQpLbGF1czxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQWNlIG1h aWxpbmcgbGlzdDxicj4NCkFjZUBpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlIiB0YXJnZXQ9Il9CTEFOSyI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_2101B222960B437896765A68BFE4315Aericssoncom_-- From nobody Tue May 7 05:41:55 2019 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 C6DCB120122; Tue, 7 May 2019 05:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=armh.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 e4xgwDzpftIw; Tue, 7 May 2019 05:41:43 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00048.outbound.protection.outlook.com [40.107.0.48]) (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 45092120119; Tue, 7 May 2019 05:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j1M5pmOyrEu4BOtBNWm2SmJ+mCysnbaLJfTtieeT9fE=; b=csUyjYUvzt0w1oSE3X74hzUkgZJqr1xLG8BLsKu5iO1JafRyNcovOHVyaqX1a02405mRZcfLVvpmeF3GmVXdZtFWVMKacTD9T3MhRX9IG4J45kUvR4CQhqhU4Vz03eKaXwaJKauDZ3mRNN8LW1GonK2cifTvAVMa9Up62nXqqE4= Received: from DBBPR08MB4539.eurprd08.prod.outlook.com (20.179.44.144) by DBBPR08MB4824.eurprd08.prod.outlook.com (20.179.46.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Tue, 7 May 2019 12:41:41 +0000 Received: from DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93]) by DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93%5]) with mapi id 15.20.1856.012; Tue, 7 May 2019 12:41:40 +0000 From: Hannes Tschofenig To: "ace@ietf.org" , "'core@ietf.org WG'" Thread-Topic: Joint IETF/IRTF - OMA SpecWorks Meeting Thread-Index: AdUE0KlI9KBqzI4iR+W4OYbK5l83jAAAVrjg Date: Tue, 7 May 2019 12:41:40 +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: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2d8fa423-0806-4c2e-b97b-08d6d2e95aa7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DBBPR08MB4824; x-ms-traffictypediagnostic: DBBPR08MB4824: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(136003)(366004)(376002)(40434004)(53754006)(189003)(199004)(606006)(316002)(446003)(229853002)(478600001)(5660300002)(11346002)(5024004)(99286004)(72206003)(476003)(86362001)(450100002)(52536014)(33656002)(790700001)(6116002)(3846002)(74316002)(7736002)(14454004)(2501003)(6436002)(2940100002)(486006)(966005)(7696005)(68736007)(26005)(8936002)(256004)(66946007)(9686003)(73956011)(66556008)(76116006)(6306002)(236005)(2473003)(66066001)(102836004)(55016002)(66446008)(64756008)(81166006)(8676002)(54896002)(81156014)(66476007)(14444005)(110136005)(186003)(2906002)(71200400001)(6506007)(25786009)(66574012)(76176011)(53546011)(71190400001)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4824; H:DBBPR08MB4539.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Psho8VKSwdCuvKHDiPJpWGGXsTIA9D1X1LHICtIogcDd+eDxUUSNXmDwprNZU+2QYgAr51LmbYwwH9S8oY7AUHWRpxp26dOuaiorpLqLbzb5U8MvjXRYuFEl4e9XrhL/e25r/2hzGvC2sDaf/61dLy19qhgxfPM22pU9izmsHv6JQeJsX5k4mLew9v9uuAGZeCOANFMHdP8w/PS3pqGnZBhMKIkMj5FnPx32BOTa0OTMxzIb2fPFYlNTnbB+gwRuS8RY7bJqlg/Qw7TUnDwn0gX3mMEbM/DhkEPE5P+0ApscO4hM1vRPTwmvuaxe188OV2/7LtIL2ZwKILPzfBWgRX8KB7Cya7eXTnxdU8bp1j+Zy9F9lPcokqrQM5yHtWsjinJ2reBIRY3js5Su4bONjYxviwFgeXrH2Sjol++kKNk= Content-Type: multipart/alternative; boundary="_000_DBBPR08MB453933085BF7E8D5E02CDAF6FA310DBBPR08MB4539eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d8fa423-0806-4c2e-b97b-08d6d2e95aa7 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 12:41:40.8977 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4824 Archived-At: Subject: [core] FW: Joint IETF/IRTF - OMA SpecWorks Meeting 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, 07 May 2019 12:41:46 -0000 --_000_DBBPR08MB453933085BF7E8D5E02CDAF6FA310DBBPR08MB4539eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI: I am forwarding the meeting announcement also to ACE and CORE because = there maybe interested parties in these groups as well. Everyone is welcome to join! From: T2TRG On Behalf Of Hannes Tschofenig Sent: Dienstag, 7. Mai 2019 14:39 To: T2TRG@irtf.org Cc: Ari Ker=E4nen Subject: [T2TRG] Joint IETF/IRTF - OMA SpecWorks Meeting Hi all, as Ari mentioned already we are planning to hold a joint meeting between OM= A SpecWorks (two groups, namely the device management & service enablement = working group and the IPSO working group) and interested participants of t= he IETF/IRTF. The meeting will take place Friday, July 19th - the Friday be= fore the IETF Hackathon/IETF 105 meeting starts. Ericsson is kindly hosting= this event in their Montreal office. The Ericsson office location is 8275 = Route Transcanadienne, Saint-Laurent, Quebec H4S-0B6: https://www.ericsson.= com/en/about-us/company-facts/ericsson-worldwide/canada For logistical reason please let us know whether you are interested to part= icipate in the joint IETF/IRTF-OMA meeting: https://doodle.com/poll/z6e8kzeke9r9bdyh The agenda will be very much like the one we put together for the joint IET= F/OMA conference call earlier this year where we talked about IETF drafts t= hat are utilized by LwM2M. A detailed agenda will be distributed in time f= or the meeting. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_DBBPR08MB453933085BF7E8D5E02CDAF6FA310DBBPR08MB4539eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

FYI: I am forwarding the meeting announcement also t= o ACE and CORE because there maybe interested parties in these groups as we= ll.

Everyone is welcome to join!

 

From: T2TRG <t2trg-bounces@irtf.org> On Behalf Of Hannes Tschofenig
Sent: Dienstag, 7. Mai 2019 14:39
To: T2TRG@irtf.org
Cc: Ari Ker=E4nen <ari.keranen@ERICSSON.COM>
Subject: [T2TRG] Joint IETF/IRTF - OMA SpecWorks Meeting<= /span>

 

Hi all,

 

as Ari mentioned already we are= planning to hold a joint meeting between OMA SpecWorks (two groups, namely= the device management & service enablement working group  and the= IPSO working group) and interested participants of the IETF/IRTF. The meeting will take place Friday, July 19t= h – the Friday before the IETF Hackathon/IETF 105 meeting start= s. Ericsson is kindly hosting this event in their Montrea= l office. The Ericsson office location is 8275 Route Transcanadienne, Saint-La= urent, Quebec H4S-0B6: https://www.ericsson.com/en/about-us/company-facts/ericsson-worldwide/canad= a

 

For logistical reason please let us know whether you= are interested to participate in the joint IETF/IRTF-OMA meeting:

https://doodle.com/poll/z6e8kzeke9r9bdyh

 

The agenda will be very much like the one we put tog= ether for the joint IETF/OMA conference call earlier this year where we tal= ked about IETF drafts that are utilized by LwM2M.  A detailed agenda will be distributed in time for the meeting.

 

Ciao

Hannes

IMPORTANT NOTICE: The contents of this email and any= attachments are confidential and may also be privileged. If you are not th= e intended recipient, please notify the sender immediately and do not discl= ose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Th= ank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_DBBPR08MB453933085BF7E8D5E02CDAF6FA310DBBPR08MB4539eurp_-- From nobody Wed May 15 01:49:00 2019 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 DEB451200BA; Wed, 15 May 2019 01:48:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155791013161.17517.18063516423141485095@ietfa.amsl.com> Date: Wed, 15 May 2019 01:48:51 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2019-05-29 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, 15 May 2019 08:48:52 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2019-05-29 from 15:00 to 16:30 Atlantic/Reykjavik. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 106, except during IETF 105. Day: every other Wednesday beginning on May 29 Dates: May 29; Jun 12, 26; Jul 10; Aug 7, 21; Sep 4, 18; Oct 2; Oct 16 from 15:00 UTC to 16:30 UTC; Oct 30, Nov 13 from 16:00 UTC to 17:30 UTC. Information about remote participation: WebEx details will be sent to the mailing list before each call. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the op From nobody Wed May 15 01:50:07 2019 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 18A3912029D; Wed, 15 May 2019 01:50:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155791020002.17474.4067492150223438710@ietfa.amsl.com> Date: Wed, 15 May 2019 01:50:00 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2019-06-12 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, 15 May 2019 08:50:06 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2019-06-12 from 15:00 to 16:30 Atlantic/Reykjavik. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 106, except during IETF 105. Day: every other Wednesday beginning on May 29 Dates: May 29; Jun 12, 26; Jul 10; Aug 7, 21; Sep 4, 18; Oct 2; Oct 16 from 15:00 UTC to 16:30 UTC; Oct 30, Nov 13 from 16:00 UTC to 17:30 UTC. Information about remote participation: WebEx details will be sent to the mailing list before each call. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the op From nobody Wed May 15 01:50:44 2019 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 3FE5B1202DC; Wed, 15 May 2019 01:50:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155791023420.17609.1944644838578516325@ietfa.amsl.com> Date: Wed, 15 May 2019 01:50:34 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2019-06-26 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, 15 May 2019 08:50:41 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2019-06-26 from 15:00 to 16:30 Atlantic/Reykjavik. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 106, except during IETF 105. Day: every other Wednesday beginning on May 29 Dates: May 29; Jun 12, 26; Jul 10; Aug 7, 21; Sep 4, 18; Oct 2; Oct 16 from 15:00 UTC to 16:30 UTC; Oct 30, Nov 13 from 16:00 UTC to 17:30 UTC. Information about remote participation: WebEx details will be sent to the mailing list before each call. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the op From nobody Wed May 15 01:51:00 2019 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 82E8C1202F8; Wed, 15 May 2019 01:50:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155791025445.17464.18082959572869534220@ietfa.amsl.com> Date: Wed, 15 May 2019 01:50:54 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2019-07-10 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, 15 May 2019 08:50:59 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2019-07-10 from 15:00 to 16:30 Atlantic/Reykjavik. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 106, except during IETF 105. Day: every other Wednesday beginning on May 29 Dates: May 29; Jun 12, 26; Jul 10; Aug 7, 21; Sep 4, 18; Oct 2; Oct 16 from 15:00 UTC to 16:30 UTC; Oct 30, Nov 13 from 16:00 UTC to 17:30 UTC. Information about remote participation: WebEx details will be sent to the mailing list before each call. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the op From nobody Wed May 15 01:52:04 2019 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 931A11202DA; Wed, 15 May 2019 01:51:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155791030854.17661.14392832536708278988@ietfa.amsl.com> Date: Wed, 15 May 2019 01:51:48 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2019-08-07 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, 15 May 2019 08:52:02 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2019-08-07 from 15:00 to 16:30 Atlantic/Reykjavik. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 106, except during IETF 105. Day: every other Wednesday beginning on May 29 Dates: May 29; Jun 12, 26; Jul 10; Aug 7, 21; Sep 4, 18; Oct 2; Oct 16 from 15:00 UTC to 16:30 UTC; Oct 30, Nov 13 from 16:00 UTC to 17:30 UTC. Information about remote participation: WebEx details will be sent to the mailing list before each call. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the op From nobody Wed May 15 01:52:20 2019 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 631D41202E3; Wed, 15 May 2019 01:52:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155791033434.17537.12964035090937814977@ietfa.amsl.com> Date: Wed, 15 May 2019 01:52:14 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2019-08-21 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, 15 May 2019 08:52:19 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2019-08-21 from 15:00 to 16:30 Atlantic/Reykjavik. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 106, except during IETF 105. Day: every other Wednesday beginning on May 29 Dates: May 29; Jun 12, 26; Jul 10; Aug 7, 21; Sep 4, 18; Oct 2; Oct 16 from 15:00 UTC to 16:30 UTC; Oct 30, Nov 13 from 16:00 UTC to 17:30 UTC. Information about remote participation: WebEx details will be sent to the mailing list before each call. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the op From nobody Wed May 15 01:52:52 2019 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 029BA12023C; Wed, 15 May 2019 01:52:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155791036196.17649.15397414929780651566@ietfa.amsl.com> Date: Wed, 15 May 2019 01:52:42 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2019-09-04 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, 15 May 2019 08:52:50 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2019-09-04 from 15:00 to 16:30 Atlantic/Reykjavik. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 106, except during IETF 105. Day: every other Wednesday beginning on May 29 Dates: May 29; Jun 12, 26; Jul 10; Aug 7, 21; Sep 4, 18; Oct 2; Oct 16 from 15:00 UTC to 16:30 UTC; Oct 30, Nov 13 from 16:00 UTC to 17:30 UTC. Information about remote participation: WebEx details will be sent to the mailing list before each call. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the op From nobody Wed May 15 01:53:05 2019 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 9E252120294; Wed, 15 May 2019 01:52:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155791037855.17561.7652489682916119276@ietfa.amsl.com> Date: Wed, 15 May 2019 01:52:58 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2019-09-18 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, 15 May 2019 08:53:04 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2019-09-18 from 15:00 to 16:30 Atlantic/Reykjavik. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 106, except during IETF 105. Day: every other Wednesday beginning on May 29 Dates: May 29; Jun 12, 26; Jul 10; Aug 7, 21; Sep 4, 18; Oct 2; Oct 16 from 15:00 UTC to 16:30 UTC; Oct 30, Nov 13 from 16:00 UTC to 17:30 UTC. Information about remote participation: WebEx details will be sent to the mailing list before each call. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the op From nobody Wed May 15 01:53:40 2019 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 786E01202A4; Wed, 15 May 2019 01:53:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155791040440.17657.17181129788377108750@ietfa.amsl.com> Date: Wed, 15 May 2019 01:53:24 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2019-10-02 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, 15 May 2019 08:53:32 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2019-10-02 from 15:00 to 16:30 Atlantic/Reykjavik. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 106, except during IETF 105. Day: every other Wednesday beginning on May 29 Dates: May 29; Jun 12, 26; Jul 10; Aug 7, 21; Sep 4, 18; Oct 2; Oct 16 from 15:00 UTC to 16:30 UTC; Oct 30, Nov 13 from 16:00 UTC to 17:30 UTC. Information about remote participation: WebEx details will be sent to the mailing list before each call. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the op From nobody Wed May 15 01:53:54 2019 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 C4A6912031C; Wed, 15 May 2019 01:53:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155791041575.17474.7416333530697113358@ietfa.amsl.com> Date: Wed, 15 May 2019 01:53:35 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2019-10-16 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, 15 May 2019 08:53:41 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2019-10-16 from 15:00 to 16:30 Atlantic/Reykjavik. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 106, except during IETF 105. Day: every other Wednesday beginning on May 29 Dates: May 29; Jun 12, 26; Jul 10; Aug 7, 21; Sep 4, 18; Oct 2; Oct 16 from 15:00 UTC to 16:30 UTC; Oct 30, Nov 13 from 16:00 UTC to 17:30 UTC. Information about remote participation: WebEx details will be sent to the mailing list before each call. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the op From nobody Wed May 15 01:54:01 2019 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 973A2120326; Wed, 15 May 2019 01:53:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155791042957.17673.12084761689390260392@ietfa.amsl.com> Date: Wed, 15 May 2019 01:53:49 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2019-10-30 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, 15 May 2019 08:53:55 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2019-10-30 from 16:00 to 17:30 Atlantic/Reykjavik. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 106, except during IETF 105. Day: every other Wednesday beginning on May 29 Dates: May 29; Jun 12, 26; Jul 10; Aug 7, 21; Sep 4, 18; Oct 2; Oct 16 from 15:00 UTC to 16:30 UTC; Oct 30, Nov 13 from 16:00 UTC to 17:30 UTC. Information about remote participation: WebEx details will be sent to the mailing list before each call. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the op From nobody Wed May 15 01:54:16 2019 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 E2029120331; Wed, 15 May 2019 01:54:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: core@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155791044988.17529.11361021161189017355@ietfa.amsl.com> Date: Wed, 15 May 2019 01:54:09 -0700 Archived-At: Subject: [core] Constrained RESTful Environments (core) WG Virtual Meeting: 2019-11-13 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, 15 May 2019 08:54:15 -0000 The Constrained RESTful Environments (core) Working Group will hold a virtual interim meeting on 2019-11-13 from 16:00 to 17:30 Atlantic/Reykjavik. Agenda: The CoRE working group will have conference calls running every two weeks until IETF 106, except during IETF 105. Day: every other Wednesday beginning on May 29 Dates: May 29; Jun 12, 26; Jul 10; Aug 7, 21; Sep 4, 18; Oct 2; Oct 16 from 15:00 UTC to 16:30 UTC; Oct 30, Nov 13 from 16:00 UTC to 17:30 UTC. Information about remote participation: WebEx details will be sent to the mailing list before each call. We will use the working group WebEx for the calls. The IETF WebEx account does not allow International dialing nor US toll free ("800" numbers), but you can use the WebEx app (e.g., on your smartphone) to connect your device audio, and there's also the op From nobody Wed May 15 12:35:07 2019 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 5917912015C for ; Wed, 15 May 2019 12:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 SJQkfLUvlubC for ; Wed, 15 May 2019 12:35:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B561200F1 for ; Wed, 15 May 2019 12:35:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 879B038271 for ; Wed, 15 May 2019 15:34:14 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6C65AE3B; Wed, 15 May 2019 15:34:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6A04FA2 for ; Wed, 15 May 2019 15:34:59 -0400 (EDT) From: Michael Richardson To: core@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] yang-cbor and core-sid comments 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, 15 May 2019 19:35:05 -0000 --=-=-= Content-Type: text/plain In my listening in catch-up, just got to: https://youtu.be/2EP-qms-IEU?t=5245 which is Alex Pelov on YANG-CBOR status. I'm okay with things that change the SID files, as early adopters are going to have to deal with some changes anyway, and so we need to pin things down without automation today. So if there are changes, then please don't rush, let's think them through. Let's also think about if we can arrange to pin things. We have some interop to report from the Fairhair Alliance constrained voucher work that occured March 25/26. This was between open source and vendor-proprietary. We would have four or five participants, but we had layer-3 issues that prevented it. I think that the "work that will be done before the end of the week" is included in the updates to sid-06? I don't think that I understood the IANA conversation that was reported on. (Also, I've been falling off IETF lists due to new spam filter, so I may have missed something, feel free to tell me so) I'm so glad that this is advancing. I reviewed the changes between: draft-ietf-core-sid-05.txt and -06: I found the text improved by the use of Appendix C. I would like to know if the WG will grandfather the draft-ietf-anima-constrained-voucher use of the comi.space allocation, or if we need to renumber, and if so, how can we do this soonest, as we have multiple implementers with running code. Given that the 3rd party registries are now out of scope. I also looked at draft-ietf-core-yang-cbor-07 and draft-ietf-core-yang-cbor-10: I looked again at the enumeration support, trying to remember why did not use it before in constrained-voucher. Perhaps we still can/should. It is unclear if refinement of a yang module can add value{} statements. I feel insecure relying on RFC7950 9.6.4.2 algorithm. I wouldn't mind using SIDs for enumerations as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzcaeMACgkQgItw+93Q 3WUOkwf+MDxlz19EFyBMpdbptM2cJAA5LdKjvqFWAqA8/o2h7IKrtTPi6d/rUUvC 9b3FIdXkutGGAlNFqDOoaxYhGKbtOTTuOWvbbQG2bqz6CBdVT7DW1fZIRHylsoCQ vNZk0unvneqaVA6yzSNodrAud44QLytC1vZKwBSjlNpGEG0nlfwrv9G/7mmdOSqp cH+eaMjg0U6RoxbZBR2UXh6Y6NJ0mibq2ZH9Rvcn3QbVKCvIc571CyNEVnrPxxzn gEDhrSdiDsN0JiI/lfIhpG9WpNk001tJFxpfvAzw0GVpGF1QRPOW7LtsoYe7UE5n vc0HCQxQ/Mw+2oBKqOR7bvmyP2CcUw== =g6Nd -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 15 12:59:56 2019 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 A061812022D for ; Wed, 15 May 2019 12:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 lKXDWgSxecMe for ; Wed, 15 May 2019 12:59:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B6B6120147 for ; Wed, 15 May 2019 12:59:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1D8C83826C for ; Wed, 15 May 2019 15:59:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F12A9E3B; Wed, 15 May 2019 15:59:49 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EE9DAA2 for ; Wed, 15 May 2019 15:59:49 -0400 (EDT) From: Michael Richardson To: core@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] raza-ace-cbor-certificates 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, 15 May 2019 19:59:54 -0000 --=-=-= Content-Type: text/plain If we transcode ASN.1 to CBOR rather than DER in a way that preserves the signature, then I think we miss all opportunities to throw away the DER code. If we can outsource this to a third party to verify, we can just throw the DER itself to the third party, and wrap it in a RESTful COAP interface. I see two issues with PKIX certificates: a) DNs never made any sense in 1980 when a company could have three people named John Smith, and they make even less sense now that we have 10,000 light bulbs whose name is "serialNumber=XXXXX" b) while subject DNs can be empty, issuer DNs can't be empty if you want to verify the certificate. Finding the public key of the issuer to verify the certificate is annoying and often non-trivial. There are PKIX extensions to deal with this, but they aren't mandatory. These are essentially issues with how the certificate semantics are encoded into the ASN.1, not really a problem with the DER itself. The lack of good DER encoders/decoders (I've never seen a pull parser, I'm sure Heimdal includes one, but I've never seen it) is the PITA. I couldn't figure out what the conclusion of your slides were, btw. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzcb7UACgkQgItw+93Q 3WVtgwf9Hk21ZPxB5Npl7iROZ4t2ucirtlXh99CVw8NXsKDELw0LQDY4GIb7qxNA XUW6kwt29j1+XDY4zoeqnr+4p/l+fp4wcv9CIQiPhuocpap9pL3PzeNHbNbWpvwG J20fgsoNM1rDyVZUB4z0ApFx2n/2SdmI4gs2sp9RiyqPKqUXJmaetH7cbyIbe9Z+ F4jg5+480vaY9+DP1cJeXgSz58ZkbBFHVsFoiHgssvl8M7TIZ71WnpCAnfCpz0zA 6EcF0iGMMfeoeVNcdGxjM1R49wKYtHsW+wVrFP+ax1bQ0NL/+5SqEPxSMhun8Vyp VsUYZyBACJ5WLCWlIbJov9wYEApNqA== =RT4D -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 15 13:15:25 2019 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 60C2F12010E; Wed, 15 May 2019 13:15:23 -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: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: core@ietf.org Message-ID: <155795132330.30726.4357976693276528974@ietfa.amsl.com> Date: Wed, 15 May 2019 13:15:23 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-comi-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: Wed, 15 May 2019 20:15:23 -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 : CoAP Management Interface Authors : Michel Veillette Peter van der Stok Alexander Pelov Andy Bierman Filename : draft-ietf-core-comi-05.txt Pages : 50 Date : 2019-05-15 Abstract: This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CoMI). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CoMI uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. The complete solution composed of CoMI, [I-D.ietf-core-yang-cbor] and [I-D.ietf-core-sid] is called CORECONF. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-comi/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-comi-05 https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-comi-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 15 13:27:56 2019 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 EB2B31200A2 for ; Wed, 15 May 2019 13:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.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 0SmDYq6-kQQJ for ; Wed, 15 May 2019 13:27:51 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05on071d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe50::71d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F75E1200B4 for ; Wed, 15 May 2019 13:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-Trilliant-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pwkiu1bRr1WW3oI5ncsPv+BSAJC8jBBqd+UJG6KeEJQ=; b=A0EO2QLAWuCyZdnGZy6KmSDgW8Qb8bsku07KTsrH8b8z2bSehSDcIr8Jk7dkSRWnmAPDVFNtUz3mECqP46Bg8hS/ZMlSx8PgPeRRXf72Xx/9SYCBrQCF1W7wKrdPgiy5GaHg+ymZX5MpKrfHvpfb/5J81EeEuXaYz1r6S0HFIRs= Received: from BL0PR06MB5042.namprd06.prod.outlook.com (10.167.240.31) by BL0PR06MB4881.namprd06.prod.outlook.com (10.167.233.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.25; Wed, 15 May 2019 20:27:48 +0000 Received: from BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::5cf9:87fa:4815:56f4]) by BL0PR06MB5042.namprd06.prod.outlook.com ([fe80::5cf9:87fa:4815:56f4%5]) with mapi id 15.20.1900.010; Wed, 15 May 2019 20:27:48 +0000 From: Michel Veillette To: Michael Richardson , "core@ietf.org" Thread-Topic: [core] yang-cbor and core-sid comments Thread-Index: AQHVC1VUGRY41HfbjkOjefzHzEYUv6ZsoRng Date: Wed, 15 May 2019 20:27:48 +0000 Message-ID: References: <4502.1557948899@localhost> In-Reply-To: <4502.1557948899@localhost> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliant.com; x-originating-ip: [207.96.192.122] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 822b2461-8cbc-458a-540f-08d6d973cc01 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BL0PR06MB4881; x-ms-traffictypediagnostic: BL0PR06MB4881: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0038DE95A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39850400004)(376002)(396003)(136003)(346002)(13464003)(51444003)(199004)(189003)(52314003)(45080400002)(14454004)(81156014)(74316002)(186003)(81166006)(71200400001)(71190400001)(99286004)(52536014)(66556008)(66476007)(66446008)(66066001)(8936002)(26005)(446003)(76116006)(9686003)(8676002)(73956011)(6306002)(86362001)(5660300002)(76176011)(7696005)(55016002)(11346002)(64756008)(66946007)(256004)(102836004)(110136005)(2501003)(25786009)(316002)(53546011)(6246003)(486006)(53936002)(476003)(966005)(72206003)(7736002)(33656002)(305945005)(6436002)(6116002)(2906002)(3846002)(6506007)(68736007)(478600001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4881; H:BL0PR06MB5042.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: trilliant.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cTRkG+ETDDkT/1eKbpG5uVyEgK2ol5eDKrRowMPchITjt+zx1/dofcsYDpgHO5Q/8XaV0TDnzOILAUleR7P5mKoW2im2SSMl4OBNGVGJR3nA7Ri9ptSVbTDO4MDPGF3oNQ9CyhSeQQ+9KfW8xZGRvClQ+DujbCZ5XIgC2fH87fvAgRL6BL0dHjVD2IIZ+6Y8MDII1dnFchBFIRNU8lpttIS1RMLiLOmslGcpSZT0bCtha0oK0Jv3cPcH3eBM7NWC31iQYTWY1fsG3+5mM3pVVrC0hqmmdKagovk/8NSEImokB2DsC+tjwo1gVC3Pk94a15ojgwhHobtHhoSbN+GL0F99nOMVJ16P0Y6KTnZxCU2McEBJSaEzivfPtPh9s1eSVcPa8Axi5oOd502VuPqWc+11ESrXD1oeFZjnzSAeCxg= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Trilliant.com X-MS-Exchange-CrossTenant-Network-Message-Id: 822b2461-8cbc-458a-540f-08d6d973cc01 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2019 20:27:48.5599 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4881 Archived-At: Subject: Re: [core] yang-cbor and core-sid comments 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, 15 May 2019 20:27:55 -0000 Hi Michael About "Given that the 3rd party registries are now out of scope." What do you means exactly? The "SID Mega-Range" registry (https://tools.ietf.org/html/draft-ietf-core-= sid-06#section-6.2.2) is still supported for the delegation of the manageme= nt of a block of SIDs to third parties (e.g. SDOs, registrars, etc). Regards, Michel -----Original Message----- From: core On Behalf Of Michael Richardson Sent: Wednesday, May 15, 2019 3:35 PM To: core@ietf.org Subject: [core] yang-cbor and core-sid comments In my listening in catch-up, just got to: https://can01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fyout= u.be%2F2EP-qms-IEU%3Ft%3D5245&data=3D02%7C01%7C%7C586dcdea3a064da2e9830= 8d6d96c7501%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636935457191339911= &sdata=3DvU0SQ0%2FEQ7npVt2D3XFxxYZEj6TbsFVVOTMmo%2BxXM5M%3D&reserve= d=3D0 which is Alex Pelov on YANG-CBOR status. I'm okay with things that change the SID files, as early adopters are going= to have to deal with some changes anyway, and so we need to pin things dow= n without automation today. So if there are changes, then please don't rus= h, let's think them through. Let's also think about if we can arrange to pin things. We have some interop to report from the Fairhair Alliance constrained vouch= er work that occured March 25/26. This was between open source and vendor-= proprietary. We would have four or five participants, but we had layer-3 issues that prevented it. I think that the "work that will be done before the end of the week" is included in the updates to sid-06? I don't think that I understood the IANA conversation that was reported on. (Also, I've been falling off IETF lists due to new spam filter, so I may ha= ve missed something, feel free to tell me so) I'm so glad that this is advancing. I reviewed the changes between: draft-ietf-core-sid-05.txt and -06: I found the text improved by the use of Appendix C. I would like to know if the WG will grandfather the draft-ietf-anima-constr= ained-voucher use of the comi.space allocation, or if we need to renumber, = and if so, how can we do this soonest, as we have multiple implementers wit= h running code. Given that the 3rd party registries are now out of scope. I also looked at draft-ietf-core-yang-cbor-07 and draft-ietf-core-yang-cbor= -10: I looked again at the enumeration support, trying to remember why did not u= se it before in constrained-voucher. Perhaps we still can/should. It is unclear if refinement of a yang module can add value{} statements. I feel insecure relying on RFC7950 9.6.4.2 algorithm. I wouldn't mind using SIDs for enumerations as well. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Wed May 15 15:08:38 2019 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 57F59120221 for ; Wed, 15 May 2019 15:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 SiUMt0UQ2NLN for ; Wed, 15 May 2019 15:08:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5022412001B for ; Wed, 15 May 2019 15:08:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9E5EC38271; Wed, 15 May 2019 18:07:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BE5B4E3B; Wed, 15 May 2019 18:08:26 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BBF05A5; Wed, 15 May 2019 18:08:26 -0400 (EDT) From: Michael Richardson To: Michel Veillette cc: "core\@ietf.org" In-Reply-To: References: <4502.1557948899@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] yang-cbor and core-sid comments 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, 15 May 2019 22:08:37 -0000 --=-=-= Content-Type: text/plain Michel Veillette wrote: > About "Given that the 3rd party registries are now out of scope." Hmm. I thought I understood that from one of the slides. https://youtu.be/2EP-qms-IEU?t=5245 I thought it said that on slide "SID changes in future v06" Looking again... seems I misunderstood! I still don't know what will happen to comi.space allocated ranges. Sorry for confusion! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzcjdoACgkQgItw+93Q 3WW1HAf/XpB3YDMe1bme1msz+KMsb+ZdylImK3zYJjNKBITm/ozwh1UJmJ8u1kK9 mNKJNADCfKMljFej6XeCUPq66+GGLr0FJUDlDdrBNJqn22NUOKoSE4wGNj1MeS+x OG62V+scKEic9nNXAXzROw3P6Q11sRJJSwu7X5ifBK0sKk6I5o1F+XwCd9MrbATC kow1+Gxq+5dtEfrCPZIpkwxWkNtZBUPY4hH+4YZbU1Aj3knlBxblhJtpIKD6wf6C ZR7Q8oVTKoLsUdFoFOw2ohD4XtiIII+fkBLdp3HppSWqnu9Bg/2N6lWgmFKWQtsf P8Cdm1nr2xVKH0yB9EOzfMdXvXv4jQ== =gFC2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed May 22 02:04:03 2019 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 A147F1200FF for ; Wed, 22 May 2019 02:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.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 v_0FYZKEoYtN for ; Wed, 22 May 2019 02:03:59 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0220.hostedemail.com [216.40.44.220]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9AE1200B1 for ; Wed, 22 May 2019 02:03:59 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id 8B8E1180A812C; Wed, 22 May 2019 09:03:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=iwNYye1+gILGTIjpZN 8pjozBb+V+zxjVYNoO7tJvI24=; b=ZazbUgJzrJQhdEEVbeP0sDZ/9W4ic/vadS wgN+FEI211318KOBHYtDjIwaPeyHxglqWTIh5SXIqYJuUV1kilJxDJm9pEBlUoWT hpy1gs76oA9UdcBNyAlM8/pQ5CUzEmyYlCR4m7KeD8tRj3eXS2jaxShQMCNTBk9f NM2fQXLkM= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 2, -9, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::, RULES_HIT:1:2:41:46:72:150:152:273:355:379:582:800:960:962:967:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1712:1730:1776:1792:2068:2069:2198:2199:2525:2527:2528:2553:2557:2559:2566:2682:2685:2692:2693:2859:2900:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3148:3586:3622:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4049:4250:4321:4362:4425:4605:4860:5007:6117:6119:6261:6657:6659:6678:6691:7464:7774:7875:7903:8583:8603:9010:9025:9036:9040:9177:10346:10848:11232:11658:11914:11984:12043:12114:12291:12295:12379:12438:12555:12663:12683:12740:12895:12986:13139:13237:13255:13846:14096:14149:21060:21063:21080:21324:21433:21451:21627:21740:30029:30054:30060:30062:30070:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none X-HE-Tag: range77_79cfcd4dbae4b X-Filterd-Recvd-Size: 12655 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf16.hostedemail.com (Postfix) with ESMTPA; Wed, 22 May 2019 09:03:57 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_d2ecb6a05a9aad50e7975456d00f515a" Date: Wed, 22 May 2019 11:03:56 +0200 From: Peter van der Stok To: Ted Lemon Cc: core@ietf.org, Stuart Cheshire Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <02585a832a91742de93f6d311259ae61@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [83.201.248.185] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 22 May 2019 09:04:02 -0000 --=_d2ecb6a05a9aad50e7975456d00f515a Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Ted, thanks for your comments, and apologies for the late reaction. Some discussions were needed. please see below; Greetings, peter Ted Lemon schreef op 2019-03-25 14:06: > On Mar 21, 2019, at 5:32 PM, Jaime Jiménez wrote: > >> Please take some time to carefully review the latest version and provide feedback by 2019-04-17 , specially those of you that contribute to other organisations that make use of some version of the document. > > Carsten asked me to look at the CORE server discovery text. It mostly looks good, although I don't understand why there are so many options. If the intention is to have different profiles for different types of constrained networks, it would be good to say that explicitly. It doesn't make much sense to pre-configure _devices_ to discover the resource directory using different mechanisms. If that is really what is intended, then how this is going to be managed should be discussed. > > > The intention is not to specify a set of normative profiles but to guide implementers and users of the resource directory, dependent on their installation. The text can be used to check the presence of at least one of the mentioned facilities before installing and using a resource directory in a given installation. We think this text is helpful because installations can be very different and many bundary conditions need to be satified in, for example, a building control installation. > The text of section 4.1 is proposed to be: > > A (re-)starting device may want to find one or more resource > directories for discovery purposes. Dependent on the operational > conditions, one or more of the techniques below apply. The use of > DNS-SD [RFC6763] is described in [I-D.ietf-core-rd-dns-sd]. > > The device may be pre-configured to exercise specific mechanisms for > finding the resource directory > > > The text about DNSSD is somewhat problematic: > > 3. It may be configured to use a service discovery mechanism such as > DNS-SD [RFC6763 [1]]. The present specification suggests configuring > > the service with name rd._sub._coap._udp, preferably within the > > domain of the querying nodes. > > DNSSD works by first enumerating services, then choosing a service from among those services, then connecting to that service. It looks like the idea here is that the default server name will be "rd", but that isn't stated explicitly. Some discussion about how devices are suppose to choose between advertised RD servers is necessary here. If the intention is that only one RD server ever be present or discoverable, then you could say that enumeration is not done at all, but then this isn't much different than just using DNS to resolve the hostname. > > > We intend to broach this subject in the rd-dns-sd draft. Point 3 in section 4.1 of RD draft is therefore suppressed. > Indeed the procedure for discovering a dns-sd service is the one you describe. > Extra text is needed in rd-dns-sd draft to cover the case that not only the services described in the RD are discoverable via DNS but also the RD itself. > > Thanks for pointing this out > > > Based on the discussions that I've had in certain other standards bodies on how to use Core RD, I think that leaving this very loosely specified is probably not the right thing to do. If in fact the intention is that other per-network-type specifications will decide how Core RD servers will be discovered on networks of the type discussed by those specifications, then this document should be written to explicitly support that use. If this is the case, what is said here isn't general enough. > > I'm writing this with the goal of starting the discussion, rather than saying what needs to be said, because I haven't been privy to the discussion that led to the text as it is written in the current document. It would help to understand what the authors/wg had in mind when this text was written. > > Thanks! > Thanks, > > Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Links: ------ [1] https://tools.ietf.org/html/rfc6763 --=_d2ecb6a05a9aad50e7975456d00f515a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Ted,

thanks for your comments, and apologies for the late rea= ction.
Some discussions were needed.

please see below;

Greetings, 

peter

Ted Lemon schreef op 2019-03-25 14:06:

On Mar 21, 2019, at 5:32 PM, Jaime Jiménez <jaime.jimenez@ericsson= =2Ecom> wrote:
Please take some time to carefully rev= iew the latest version and provide feedback by , specially those of you that co= ntribute to other organisations that make use of some version of the docume= nt.
Carsten asked me to look at the CORE server discovery text.   It = mostly looks good, although I don't understand why there are so many option= s.   If the intention is to have different profiles for different type= s of constrained networks, it would be good to say that explicitly.   = It doesn't make much sense to pre-configure devices to discover = the resource directory using different mechanisms.   If that is really= what is intended, then how this is going to be managed should be discussed= =2E

<pvds>
The intention is not to specify a set of n= ormative profiles but to guide implementers and users of the resource direc= tory, dependent on their installation. The text can be used to check the pr= esence of at least one of the mentioned facilities before installing and us= ing a resource directory in a given installation. We think this text is hel= pful because installations can be very different and many bundary condition= s need to be satified in, for example, a building control installation.
The text of section 4.1 is proposed to be:

  A (re-)starting device may want to find one or more resource
   directories for discovery purposes.  Dependent on the o= perational
   conditions, one or more of the techniques bel= ow apply.  The use of
   DNS-SD [RFC6763] is described= in [I-D.ietf-core-rd-dns-sd].

   The device may be = pre-configured to exercise specific mechanisms for
   findi= ng the resource directory

</pvds>
The text about DNSSD is somewhat p= roblematic:
 
   3.  It may be configured to use a servi=
ce discovery mechanism such as
       DNS-SD [=
RFC6763].  The present specification suggests configuring
    =
   the service with name rd._sub._coap._udp, preferably within the

       domain of the querying nodes.
 
DNSSD works by first enumerating services, then choosing a service fro= m among those services, then connecting to that service.  It looks lik= e the idea here is that the default server name will be "rd", but that isn'= t stated explicitly.   Some discussion about how devices are suppose t= o choose between advertised RD servers is necessary here.   If the int= ention is that only one RD server ever be present or discoverable, then you= could say that enumeration is not done at all, but then this isn't much di= fferent than just using DNS to resolve the hostname.

<pvds>= ;
We intend to broach this subject in the rd-dns-sd draft. Point 3 in = section 4.1 of RD draft is therefore suppressed.
Indeed the procedure = for discovering a dns-sd service is the one you describe. 
Extra = text is needed in rd-dns-sd draft to cover the case that not only the servi= ces described in the RD are discoverable via DNS but also the RD itself.
Thanks for pointing this out
</pvds>
 
Based on the discussions that I've had in certain other standards bodi= es on how to use Core RD, I think that leaving this very loosely specified = is probably not the right thing to do.   If in fact the intention is t= hat other per-network-type specifications will decide how Core RD servers w= ill be discovered on networks of the type discussed by those specifications= , then this document should be written to explicitly support that use. &nbs= p; If this is the case, what is said here isn't general enough.
 
I'm writing this with the goal of starting the discussion, rather than= saying what needs to be said, because I haven't been privy to the discussi= on that led to the text as it is written in the current document.   It= would help to understand what the authors/wg had in mind when this text wa= s written.
 
Thanks!
 
Thanks,

Peter
= _______________________________________________
core mailing list
core@ietf.org https://www.ietf.org/mailman/listinfo/core
--=_d2ecb6a05a9aad50e7975456d00f515a-- From nobody Wed May 22 06:22:56 2019 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 38C7312004F for ; Wed, 22 May 2019 06:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ytzg5u9HccBg for ; Wed, 22 May 2019 06:22:50 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 9F99D120033 for ; Wed, 22 May 2019 06:22:49 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id n134so1660583lfn.11 for ; Wed, 22 May 2019 06:22:49 -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=posx3TvxLfFZ6jFg3l3QMVQ2JTCuz7ypTGmI/BcvMps=; b=F269q3AEAQB5UgxAn3pndxGLwlMKhf0KBZnaselWFtYjV64iflJRBzVJsNixktpPnX u+TcwLiKuwF3C8O1/19mzyCOmeowu4mcf432lThcSxyJ5pi+BUxvgDkvqvFDGdHRb+p3 7tNy5NbgLn/S4MUFFkhjLkk2Rr4EHRDeJEFainPz26VLswmlD2bfHmixr+Yib1ON8z+6 rn7pl3Q/MF9m8KgwAKtjpx/VFNJ+LduRYFKo3/dyliWBc5i6zLHIRtLRg3jdbiM6wuRd AARdEkHD3HVNYa6tBw2ZBpkDtlHtGPUfmybOuWdFU9DXl5ceASHrdFoLZcr/Hh0dggAb uvUw== 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=posx3TvxLfFZ6jFg3l3QMVQ2JTCuz7ypTGmI/BcvMps=; b=P612lwJXqD1klIB/6Iv5PLtcMAzKWg/Igkj8QKThQzrDWszIHn73VmzuMowWZB8tH4 NtMZoFuLx4ZAGRbAd7E0XWdDbfmfZjdafpwU3ZrKcuGso6Nj2PlBVVtKrq7ukIMB1xMo ZZ8agU1gNi8dm3yTXN2rPJJjB+HXXl3qcBwIAyaQWU3gF6UwDMYjjJCPv4ejLWvXYu+n S364X3mot8mEP8YYWRHJM2mLIYmWexhTiybJCVd0DavlrGiJoKYDttW1S2LBJEXW2kW8 m51JKRWmFWYS+bBZ0exY9aWUKiLjuC7XHvR07oSr4GG5XChOO9LPbLA0L2BqZwZxQug/ T/8A== X-Gm-Message-State: APjAAAV/yjB4CIVwkPXR+aoB9+ou+LP08Pvh++h40GkbV8MBsSwEWwrA TixLIN3IqMHxjghbbL++y3jjdmY7twy1XFPoca0= X-Google-Smtp-Source: APXvYqyU8iPJ+Y6ke94NxwHnDpT9MRDem/Rkka4tCrVWSGanacWnrv/6wWg+g3TZreeaWYv5Ztnv8LRZLf+RTGebrMw= X-Received: by 2002:ac2:5626:: with SMTP id b6mr18464209lff.82.1558531367931; Wed, 22 May 2019 06:22:47 -0700 (PDT) MIME-Version: 1.0 References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> In-Reply-To: <02585a832a91742de93f6d311259ae61@bbhmail.nl> From: Badis Djamaa Date: Wed, 22 May 2019 15:22:08 +0200 Message-ID: To: consultancy@vanderstok.org, =?UTF-8?Q?Christian_Ams=C3=BCss?= Cc: Ted Lemon , Stuart Cheshire , core@ietf.org Content-Type: multipart/alternative; boundary="0000000000008e9913058979dcf4" Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 22 May 2019 13:22:52 -0000 --0000000000008e9913058979dcf4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Chairs, RD authors, members, Thank you for raising this point concerning section 4 of CoRE-RD draft. Indeed, besides the diversity of options, there are also performance issues, especially with the CoAP resource discovery approach. To deal with this, we have proposed a new announce-based mechanism to discover RD server(s) [1]. Section 1.3 of [1] points out some potential shortcomings of section 4 of CoRE-RD and motivates the need of an announce-based mechanism that can be generalized to announce other links (please see the discussion = in [2]). [1]: https://tools.ietf.org/html/draft-djamaa-core-proactive-rd-discovery-0= 0 [2]: https://mailarchive.ietf.org/arch/msg/core/s8bjwXJeipCm2PNkE_mS16GGBFw All the best, Badis On Wed, 22 May 2019 at 11:04, Peter van der Stok wrote: > Hi Ted, > > thanks for your comments, and apologies for the late reaction. > Some discussions were needed. > > please see below; > > Greetings, > > peter > > Ted Lemon schreef op 2019-03-25 14:06: > > On Mar 21, 2019, at 5:32 PM, Jaime Jim=C3=A9nez > wrote: > > Please take some time to carefully review the latest version and provide > feedback by *2019-04-17* , specially those of you that contribute to > other organisations that make use of some version of the document. > > Carsten asked me to look at the CORE server discovery text. It mostly > looks good, although I don't understand why there are so many options. = If > the intention is to have different profiles for different types of > constrained networks, it would be good to say that explicitly. It doesn= 't > make much sense to pre-configure *devices* to discover the resource > directory using different mechanisms. If that is really what is intende= d, > then how this is going to be managed should be discussed. > > > The intention is not to specify a set of normative profiles but to guide > implementers and users of the resource directory, dependent on their > installation. The text can be used to check the presence of at least one = of > the mentioned facilities before installing and using a resource directory > in a given installation. We think this text is helpful because > installations can be very different and many bundary conditions need to b= e > satified in, for example, a building control installation. > The text of section 4.1 is proposed to be: > > A (re-)starting device may want to find one or more resource > directories for discovery purposes. Dependent on the operational > conditions, one or more of the techniques below apply. The use of > DNS-SD [RFC6763] is described in [I-D.ietf-core-rd-dns-sd]. > > The device may be pre-configured to exercise specific mechanisms for > finding the resource directory > > > The text about DNSSD is somewhat problematic: > > > 3. It may be configured to use a service discovery mechanism such as > DNS-SD [RFC6763 ]. The prese= nt specification suggests configuring > > the service with name rd._sub._coap._udp, preferably within the > > domain of the querying nodes. > > > DNSSD works by first enumerating services, then choosing a service from > among those services, then connecting to that service. It looks like the > idea here is that the default server name will be "rd", but that isn't > stated explicitly. Some discussion about how devices are suppose to > choose between advertised RD servers is necessary here. If the intentio= n > is that only one RD server ever be present or discoverable, then you coul= d > say that enumeration is not done at all, but then this isn't much differe= nt > than just using DNS to resolve the hostname. > > > We intend to broach this subject in the rd-dns-sd draft. Point 3 in > section 4.1 of RD draft is therefore suppressed. > Indeed the procedure for discovering a dns-sd service is the one you > describe. > Extra text is needed in rd-dns-sd draft to cover the case that not only > the services described in the RD are discoverable via DNS but also the RD > itself. > > Thanks for pointing this out > > > Based on the discussions that I've had in certain other standards bodies > on how to use Core RD, I think that leaving this very loosely specified i= s > probably not the right thing to do. If in fact the intention is that > other per-network-type specifications will decide how Core RD servers wil= l > be discovered on networks of the type discussed by those specifications, > then this document should be written to explicitly support that use. If > this is the case, what is said here isn't general enough. > > I'm writing this with the goal of starting the discussion, rather than > saying what needs to be said, because I haven't been privy to the > discussion that led to the text as it is written in the current document. > It would help to understand what the authors/wg had in mind when this tex= t > was written. > > Thanks! > > Thanks, > > Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --0000000000008e9913058979dcf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Chairs, RD authors, members,

Thank you for raising this point concerning section 4 of CoRE-RD draf= t. Indeed, besides the diversity of options, there are also performance iss= ues, especially with the CoAP resource discovery approach. To deal with thi= s, we have proposed a new announce-based mechanism to discover RD server(s)= [1]. Section 1.3 of [1] points out some potential shortcomings of section = 4 of CoRE-RD and motivates the need of an announce-based mechanism that can= be generalized to announce other links (please see the discussion in [2]).




On Wed, 22 May 2019 at 11:04, Peter van der Stok <stokcons@bbhmail.nl> wrote:
Hi Ted,

thanks for your comments, and apologies for the late reactio= n.
Some discussions were needed.

please see below;

Greetin= gs,=C2=A0

peter

Ted Lemon schreef op 2019-03-25 14:06:

On Mar 21, 2019, at 5:32 PM, Jaime Jim=C3=A9nez = <jaime.jimenez@ericsson.com> wrote:
Please take some time to carefully review the latest versio= n and provide feedback by=C2=A02019-04-17=C2=A0, specially those of you that co= ntribute to other organisations that make use of some version of the docume= nt.
Carsten asked me to look at the CORE server discovery text. =C2=A0 It = mostly looks good, although I don't understand why there are so many op= tions. =C2=A0 If the intention is to have different profiles for different = types of constrained networks, it would be good to say that explicitly. =C2= =A0 It doesn't make much sense to pre-configure devices=C2=A0to disco= ver the resource directory using different mechanisms. =C2=A0 If that is re= ally what is intended, then how this is going to be managed should be discu= ssed.

<pvds>
The intention is not to specify a set of norma= tive profiles but to guide implementers and users of the resource directory= , dependent on their installation. The text can be used to check the presen= ce of at least one of the mentioned facilities before installing and using = a resource directory in a given installation. We think this text is helpful= because installations can be very different and many bundary conditions ne= ed to be satified in, for example, a building control installation.
The = text of section 4.1 is proposed to be:

=C2=A0 A (re-)starting device may want to find one or more resource
= =C2=A0 =C2=A0directories for discovery purposes.=C2=A0 Dependent on the ope= rational
=C2=A0=C2=A0 conditions, one or more of the techniques below a= pply.=C2=A0 The use of
=C2=A0=C2=A0 DNS-SD [RFC6763] is described in [I= -D.ietf-core-rd-dns-sd].

=C2=A0=C2=A0 The device may be pre-config= ured to exercise specific mechanisms for
=C2=A0=C2=A0 finding the resou= rce directory

</pvds>

The text about DNSSD is somewhat pro= blematic:
=C2=A0
   3.  It may be configured to use a service di=
scovery mechanism such as
       DNS-SD [=
RFC6763].  The present specification suggests configuring
       the =
service with name rd._sub._coap._udp, preferably within the

       domain of the querying nodes.
=C2=A0
DNSSD works by first enumerating services, then choosing a service fro= m among those services, then connecting to that service.=C2=A0 It looks lik= e the idea here is that the default server name will be "rd", but= that isn't stated explicitly. =C2=A0 Some discussion about how devices= are suppose to choose between advertised RD servers is necessary here. =C2= =A0 If the intention is that only one RD server ever be present or discover= able, then you could say that enumeration is not done at all, but then this= isn't much different than just using DNS to resolve the hostname.
<= br><pvds>
We intend to broach this subject in the rd-dns-sd draft.= Point 3 in section 4.1 of RD draft is therefore suppressed.
Indeed the = procedure for discovering a dns-sd service is the one you describe.=C2=A0Extra text is needed in rd-dns-sd draft to cover the case that not only t= he services described in the RD are discoverable via DNS but also the RD it= self.

Thanks for pointing this out
</pvds>
=C2=A0
Based on the discussions that I've had in certain other standards = bodies on how to use Core RD, I think that leaving this very loosely specif= ied is probably not the right thing to do. =C2=A0 If in fact the intention = is that other per-network-type specifications will decide how Core RD serve= rs will be discovered on networks of the type discussed by those specificat= ions, then this document should be written to explicitly support that use. = =C2=A0 If this is the case, what is said here isn't general enough.
=C2=A0
I'm writing this with the goal of starting the discussion, rather = than saying what needs to be said, because I haven't been privy to the = discussion that led to the text as it is written in the current document. = =C2=A0 It would help to understand what the authors/wg had in mind when thi= s text was written.
=C2=A0
Thanks!
=C2=A0
Thanks,

Peter
_______________________________________________ core mailing list
core@ietf.org
https://www.ietf= .org/mailman/listinfo/core
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--0000000000008e9913058979dcf4-- From nobody Wed May 22 06:52:12 2019 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 990B71200CC for ; Wed, 22 May 2019 06:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=fugue-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 7ay6vGLUsIoB for ; Wed, 22 May 2019 06:51:59 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 239821201A8 for ; Wed, 22 May 2019 06:51:59 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id o7so2405881qtp.4 for ; Wed, 22 May 2019 06:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gUyVVzIjFawpX4jae8TCO9VXlZs57g7qGepa9zFhhEQ=; b=tfpDu6uKF48WmEdoB1zWAg45xFxgguxUHWtS9L5ZA4HTY8umKSi9C2xWaaiEQ6q5dF quQnJOJeY9XIw0V1g5qFFRyhBtKQI4yzmsvF/JHKSiad3wBM2zMiPSVGPQh0VnD5vuDm 3urds/vFij2ikrIB2ERbdKlduuBAB45+IYBL1+U+WFphradxx/X40P+zU5B2tVOTxnPg x12c5AaxFokxHMjk58ykazKnUFWoiBCOWLziy2qG2zoX7a47/YFvBeM24qhlyf9q5YEV 3gaN7DZe1BskvXcHbyehEE+zd7vEq3mPO+t/9lQ7bL/OSHYW8YRTxwR69UhCZCrEa9Bb QjLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gUyVVzIjFawpX4jae8TCO9VXlZs57g7qGepa9zFhhEQ=; b=bQtTpzTRSy1E6bOjvbpkAjlSjW7gsOu2d2KS7hYu9K/TFVlyA6S7R0Hai9QuapXdUq GEYlI8tSSkvztiQZdY5tKDkQVNLlHozn2QPhM5fiHvn+icf3v5I429z1B8yqXQJgtXtJ UQRZIIqbfv59XLnbTb320fNQ67M34uqNllpG9VtVsi6Lz2ndmLwLJM1L+CdBvTR7Sc8C UCXKUlSyqClgGVF2IdRrlWnEuVfkuEfgcu79O1MuZi7QBuyZT0L/FB6TqwMGWORyjONd 49lRrGX86fvQxzi15XwfYpFmCjFxoq33ZFOsM/jDlA2fqfMxzMvrCUeVE1npVRWMcyD9 lqIw== X-Gm-Message-State: APjAAAX1BSkvOOjJtrYBXUqonpvIvdflieZsGPP4/ZoTv43yWWxu9MVy Vpavhpwn8aHkjlMQu/RCUZV8Ig== X-Google-Smtp-Source: APXvYqwmP6UKxVobU1w23HBJwIPRj7BN8gd4E7cft5J2pI7fpQqJt7tnLfz36Z2XwvhutIthwbX4Fw== X-Received: by 2002:ac8:379a:: with SMTP id d26mr57315070qtc.21.1558533118151; Wed, 22 May 2019 06:51:58 -0700 (PDT) Received: from [10.0.10.34] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id l40sm15551501qtc.32.2019.05.22.06.51.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 06:51:57 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_663A72CE-6B27-45F3-9D2A-E431AC893958" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Wed, 22 May 2019 09:51:55 -0400 In-Reply-To: <02585a832a91742de93f6d311259ae61@bbhmail.nl> Cc: core@ietf.org, Stuart Cheshire To: consultancy@vanderstok.org References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 22 May 2019 13:52:11 -0000 --Apple-Mail=_663A72CE-6B27-45F3-9D2A-E431AC893958 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 22, 2019, at 5:03 AM, Peter van der Stok = wrote: Thanks for getting back to me=E2=80=94I know that there are a lot of = demands on our time, so there=E2=80=99s no need to apologize for being = asynchronous! :) >> The intention is not to specify a set of normative profiles but to = guide implementers and users of the resource directory, dependent on = their installation. The text can be used to check the presence of at = least one of the mentioned facilities before installing and using a = resource directory in a given installation. We think this text is = helpful because installations can be very different and many bundary = conditions need to be satified in, for example, a building control = installation. The problem with this approach is that as an implementor, I have no idea = what to do. If you aren=E2=80=99t solving my problem, then you should = explicitly say that you aren=E2=80=99t solving my problem, so that I=E2=80= =99m not left wondering. :) However, to be clear, I am not really suggesting that you say nothing. = I am suggesting that we figure out what the correct thing is to say, so = that implementors are not left guessing. There is a huge problem in = the IoT space with solutions that use existing standards in incompatible = ways, so that even though everybody can say =E2=80=9Cwe=E2=80=99re = standards compliant,=E2=80=9D there is no interoperability.=20 If this isn=E2=80=99t addressed in IETF specifications, it=E2=80=99s = unlikely to be addressed anywhere, because the IETF is the only place I = know of where general interoperability is an explicit goal. The issue = is that each individual IoT stack vendor is happy to simply have their = own infrastructure solution that interoperates with devices that = implement their stack. But as a network owner, I may either choose to = or be forced to install devices that use different IoT stacks on my = network. The network infrastructure standards, of which Core RD is = clearly one, should support each stack I need to support, and not = require that I implement separate infrastructure for each stack. I think pointing to the core-rd-dns-sd document isn=E2=80=99t a bad = thing, but I don=E2=80=99t think that document actually does what you = think it does, so there may be some new expectation-setting exercise = required. --Apple-Mail=_663A72CE-6B27-45F3-9D2A-E431AC893958 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = May 22, 2019, at 5:03 AM, Peter van der Stok <stokcons@bbhmail.nl>= wrote:

Thanks for = getting back to me=E2=80=94I know that there are a lot of demands on our = time, so there=E2=80=99s no need to apologize for being asynchronous! = :)

The intention is not to specify = a set of normative profiles but to guide implementers and users of the = resource directory, dependent on their installation. The text can be = used to check the presence of at least one of the mentioned facilities = before installing and using a resource directory in a given = installation. We think this text is helpful because installations can be = very different and many bundary conditions need to be satified in, for = example, a building control = installation.

The problem with this approach is that as an = implementor, I have no idea what to do.   If you aren=E2=80=99t = solving my problem, then you should explicitly say that you aren=E2=80=99t= solving my problem, so that I=E2=80=99m not left wondering. = :)

However, to be clear, I am not = really suggesting that you say nothing.   I am suggesting that we = figure out what the correct thing is to say, so that implementors are = not left guessing.   There is a huge problem in the IoT space with = solutions that use existing standards in incompatible ways, so that even = though everybody can say =E2=80=9Cwe=E2=80=99re standards compliant,=E2=80= =9D there is no interoperability. 

If this isn=E2=80=99t addressed in IETF = specifications, it=E2=80=99s unlikely to be addressed anywhere, because = the IETF is the only place I know of where general interoperability is = an explicit goal.   The issue is that each individual IoT stack = vendor is happy to simply have their own infrastructure solution that = interoperates with devices that implement their stack.   But as a = network owner, I may either choose to or be forced to install devices = that use different IoT stacks on my network.   The network = infrastructure standards, of which Core RD is clearly one, should = support each stack I need to support, and not require that I implement = separate infrastructure for each stack.

I think pointing to the core-rd-dns-sd document = isn=E2=80=99t a bad thing, but I don=E2=80=99t think that document = actually does what you think it does, so there may be some new = expectation-setting exercise required.

= --Apple-Mail=_663A72CE-6B27-45F3-9D2A-E431AC893958-- From nobody Thu May 23 00:08:21 2019 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 9246612008D for ; Thu, 23 May 2019 00:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.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 eNvLog1TMbT5 for ; Thu, 23 May 2019 00:08:16 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90B41200D6 for ; Thu, 23 May 2019 00:08:16 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay07.hostedemail.com (Postfix) with ESMTP id 50E8D181D3402; Thu, 23 May 2019 07:08:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=Xi1MZbNEOgzrzkHYOm +Jixex4spz0G57MiK2FxqFOJE=; b=HobXswgeJizSzZr+WORNe1bjocz1pbMn+B mBBSkryJif7NLH+4CmPZVgihKIz/Rlwyvf3vS69OSyZIv2mWFbnlxKvYwax5chNc TAnJ+cGJ8j/LCcSD6IEEyrR8EPZ1cdjM1YJlgi+9w+Je0eqVTqf8o5JvGEkKl84T xCdiuX318= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 10, 1, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:1:2:41:46:72:150:152:355:379:582:800:960:962:967:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1606:1730:1776:1792:2198:2199:2527:2528:2553:2557:2559:2562:2741:3138:3139:3140:3141:3142:3586:3622:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:4321:4470:4823:5007:6117:6261:6298:6657:6678:7774:7875:7903:8531:8603:9040:9177:10004:10848:11232:11658:11914:11984:12043:12114:12555:12663:12740:12895:12986:13139:13141:13161:13229:13230:13255:13439:14096:14149:21060:21080:21433:21451:21625:21740:21790:21810:21881:30054:30070:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:26, LUA_SUMMARY:none X-HE-Tag: list07_2ae718079194a X-Filterd-Recvd-Size: 10285 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf02.hostedemail.com (Postfix) with ESMTPA; Thu, 23 May 2019 07:08:14 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_0a0536e0bc305ee62ebd662f2fa3b3ed" Date: Thu, 23 May 2019 09:08:14 +0200 From: Peter van der Stok To: Ted Lemon Cc: consultancy@vanderstok.org, core@ietf.org, Stuart Cheshire Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> Message-ID: <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [86.203.245.197] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 23 May 2019 07:08:19 -0000 --=_0a0536e0bc305ee62ebd662f2fa3b3ed Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Ted, The central phrase being: "The problem with this approach is that as an implementor, I have no idea what to do", I like to elaborate a bit my view. For me it is not an implementation problem but a box configuration problem. Let me cite two not completely fitting analogies: the plethora of YANG modules, the plethora of communication standards. Dependent of the type of router (home-net market or ISP market), the router is configured with a set of YANG modules. A smartphone, PC or tablet is equipped with a an appropriate set of communication interfaces. Interoprability is assured by the implementer for a given interface or YANG module. Going back to the RD. Interoperability is assured by the implementer for a given discovery method. SDOs (e.g. Faihair, Thread, OMA, and others )currently specify and certify Internet stacks based on a selection of IETF standards. This selection partially determines the set of appropriate discovery methods. Actually, the SDO may select the RD being part of that stack and also specify the required discovery method. Does that make sense? If so, should I mention in the text that a selection of supported discovery methods for a given RD configuration may be specified by a SDO? Cheerio, Peter Ted Lemon schreef op 2019-05-22 15:51: > On May 22, 2019, at 5:03 AM, Peter van der Stok wrote: > > Thanks for getting back to me--I know that there are a lot of demands on our time, so there's no need to apologize for being asynchronous! :) > > The intention is not to specify a set of normative profiles but to guide implementers and users of the resource directory, dependent on their installation. The text can be used to check the presence of at least one of the mentioned facilities before installing and using a resource directory in a given installation. We think this text is helpful because installations can be very different and many bundary conditions need to be satified in, for example, a building control installation. The problem with this approach is that as an implementor, I have no idea what to do. If you aren't solving my problem, then you should explicitly say that you aren't solving my problem, so that I'm not left wondering. :) However, to be clear, I am not really suggesting that you say nothing. I am suggesting that we figure out what the correct thing is to say, so that implementors are not left guessing. There is a huge problem in the IoT space with solutions that use existing standards in incompatible ways, so that even though everybody can say "we're standards compliant," there is no interoperability. If this isn't addressed in IETF specifications, it's unlikely to be addressed anywhere, because the IETF is the only place I know of where general interoperability is an explicit goal. The issue is that each individual IoT stack vendor is happy to simply have their own infrastructure solution that interoperates with devices that implement their stack. But as a network owner, I may either choose to or be forced to install devices that use different IoT stacks on my network. The network infrastructure standards, of which Core RD is clearly one, should support each stack I need to support, and not require that I implement separate infrastructure for each stack. I think pointing to the core-rd-dns-sd document isn't a bad thing, but I don't think that document actually does what you think it does, so there may be some new expectation-setting exercise required. --=_0a0536e0bc305ee62ebd662f2fa3b3ed Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Ted,

The central phrase being:
"The problem with t= his approach is that as an implementor, I have no idea what to do", I like = to elaborate a bit my view.

For me it is not an implement= ation problem but a box configuration problem.
Let me cite two not com= pletely fitting analogies: the plethora of YANG modules, the plethora of co= mmunication standards.

Dependent of the type of router (home-net= market or ISP market), the router is configured with a set of YANG modules= =2E
A smartphone, PC or tablet is equipped with a an appropriate set o= f communication interfaces.
Interoprability is assured by the implemen= ter for a given interface or YANG module.

Going back to the RD= =2E Interoperability is assured by the implementer for a given discovery me= thod.
SDOs (e.g. Faihair, Thread, OMA, and others )currently specify a= nd certify Internet stacks based on a selection of IETF standards. This sel= ection partially determines the set of appropriate discovery methods. Actua= lly, the SDO may select the RD being part of that stack and also specify th= e required discovery method.

Does that make sense?

If= so, should I mention in the text that a selection of supported discovery m= ethods for a given RD configuration may be specified by a SDO?

C= heerio,

Peter

Ted Lemon schreef op 2019-05-22 15:51:

On May 22, 2019, at 5:03 AM, Peter van der Stok <stokcons@bbhmail.nl> wro= te:
 
Thanks for getting back to me—I know that there are a lot of dem= ands on our time, so there's no need to apologize for being asynchronous! := )

 
If this isn't addressed in IETF specifications, it's unlikely to be ad= dressed anywhere, because the IETF is the only place I know of where genera= l interoperability is an explicit goal.   The issue is that each indiv= idual IoT stack vendor is happy to simply have their own infrastructure sol= ution that interoperates with devices that implement their stack.   Bu= t as a network owner, I may either choose to or be forced to install device= s that use different IoT stacks on my network.   The network infrastru= cture standards, of which Core RD is clearly one, should support each stack= I need to support, and not require that I implement separate infrastructur= e for each stack.
 
I think pointing to the core-rd-dns-sd document isn't a bad thing, but= I don't think that document actually does what you think it does, so there= may be some new expectation-setting exercise required.
 
--=_0a0536e0bc305ee62ebd662f2fa3b3ed-- From nobody Thu May 23 06:27:23 2019 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 913211200B3 for ; Thu, 23 May 2019 06:27:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 PQPepdSQBst2 for ; Thu, 23 May 2019 06:27:19 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 8E9AD120048 for ; Thu, 23 May 2019 06:27:19 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id z19so3808194qtz.13 for ; Thu, 23 May 2019 06:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gipmwGQ1ua/zBBu+zku0MfiKNEfEmU/FnOvu0L6gR1c=; b=sO5UXvYuLuUdEUz6yZRNKuix7Q+LD8PkKP/5qH0GuC3tbtMe3zAJh6PDYdliw8etO0 OtZwSXQZSxDqIJi/68QQO7CJ5laIzdqGDjM03Kpg5zhkUaU2K+AA8m4X79gyKuxseoeK OTfsXRyaHySAAhhzfISmneUtG3Eha8Z4I0JEV4jsGpWu4LAJFOszi6j10v9x2wu4tEfm BKL//P0mHZq6Jv8H396YNwNgIZ/aMUk+GgUJSMvk/2XWRZ+Wjm30HftXke/lOTXmzRI4 eVV10kYRJWmzvPpbTdDyzGJ9lQqN8Ck7xktlTzpy9Aun33M/qSR9rm45Le6/Dii5oDtP kMbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gipmwGQ1ua/zBBu+zku0MfiKNEfEmU/FnOvu0L6gR1c=; b=ZYa5twb/wId7AUQaBMEvIoRIohCBU3iL5bzNKcqKYuarlNi5oNQmqhSar4Bxepo5UZ 5oxSoNfxHUDJbczYxN5tBtl+lh5f/5m6d2Kd2cCJpsCDoj4bSyleEiN7W50W5j7MAbIZ A8OhzNmpxD9Gi40xlpkAXEWhA9ak3SWNJUVokXVJfajjxRi824Wgay8XRby4SMLmppLi v9thQRcBa8sY3d+tahztJIs6iUuBqPE6iBEhfQ+zX6Y9eNRXkHoDfx/g7/WBPbT63J5q 5gDFwqyMZ0l8kcbasuJiW3QDaLMrnmx0iOjIx/kahIb9ZnPLqx7Ru4gbhCJGWOj3WUPV 33zw== X-Gm-Message-State: APjAAAWjxmbmji6I5VWZumj53It08m99blQ+xaC1Wu4LAZg/RInTGMhB P1azR4ULIunaRBzNEQNDrO457Q== X-Google-Smtp-Source: APXvYqwUWokxmtvCc/Z4azbs9/nSYmSk7mgcy2ThjDOgDyEklbFggr3lKHFR928ZjPbJ/2wmOrvH2A== X-Received: by 2002:ac8:2ca5:: with SMTP id 34mr153468qtw.246.1558618038465; Thu, 23 May 2019 06:27:18 -0700 (PDT) Received: from [10.0.30.16] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id d30sm13366923qtc.93.2019.05.23.06.27.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 May 2019 06:27:17 -0700 (PDT) From: Ted Lemon Message-Id: <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8CDC1789-D0E3-4AB0-8DEB-29EFC01FF63D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Thu, 23 May 2019 09:27:14 -0400 In-Reply-To: <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> Cc: core@ietf.org, Stuart Cheshire To: consultancy@vanderstok.org References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 23 May 2019 13:27:21 -0000 --Apple-Mail=_8CDC1789-D0E3-4AB0-8DEB-29EFC01FF63D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 23, 2019, at 3:08 AM, Peter van der Stok = wrote: > If so, should I mention in the text that a selection of supported = discovery methods for a given RD configuration may be specified by a = SDO? If that is what you intend to have happen, then yes, you should say that = explicitly. You might also explicitly discuss the problems with doing = that: Increased complexity of deployments Lack of interoperability Likelihood of infrastructure (as opposed to leaf) devices not actually = supporting all the possible discovery methods I suspect the reason we=E2=80=99re having this conversation is that we = don=E2=80=99t yet know what to recommend, and that=E2=80=99s = understandable. But the reason I=E2=80=99m pushing the point is = because at some point it would be of great benefit to the end-user to be = able to say what to do. Leaving it up to each app-layer vendor is not = a good solution. So if this document is not going to say what to do, = we should at least be thinking in terms of discovering what we should = recommend, and not simply decide that we are not going to solve that = problem. --Apple-Mail=_8CDC1789-D0E3-4AB0-8DEB-29EFC01FF63D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = May 23, 2019, at 3:08 AM, Peter van der Stok <stokcons@bbhmail.nl>= wrote:
If so, should I mention in the text that a selection of = supported discovery methods for a given RD configuration may be = specified by a SDO?

If that is what you intend to have happen, then yes, you = should say that explicitly.   You might also explicitly discuss the = problems with doing that:
  • Increased complexity of = deployments
  • Lack of interoperability
  • Likelihood of infrastructure (as opposed to leaf) devices not = actually supporting all the possible discovery methods

I suspect the reason = we=E2=80=99re having this conversation is that we don=E2=80=99t yet know = what to recommend, and that=E2=80=99s understandable.   But the = reason I=E2=80=99m pushing the point is because at some point it would = be of great benefit to the end-user to be able to say what to do.   = Leaving it up to each app-layer vendor is not a good solution.   So = if this document is not going to say what to do, we should at least be = thinking in terms of discovering what we should recommend, and not = simply decide that we are not going to solve that = problem.

= --Apple-Mail=_8CDC1789-D0E3-4AB0-8DEB-29EFC01FF63D-- From nobody Fri May 24 02:24:42 2019 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 45C841200E0 for ; Fri, 24 May 2019 02:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.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 kjRoIX4ifDCt for ; Fri, 24 May 2019 02:24:39 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B5712009C for ; Fri, 24 May 2019 02:24:38 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id ABB99837F24D; Fri, 24 May 2019 09:24:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=9pqpaceYUWcVwCimGQ v5JlXWaTUux/eNl3sAhVp3rOQ=; b=qF0Lz/+nmIU9iXs+fku/bzfyLe8N11zyJU tbpkBOp6GMMO1N2K9O6RWu2B9kodEFn/4ZLySpsRLyr/KsD9vC3EbTKUdHkFwaBj HA3O+8GddTFDQynBasczinWK6bQmv8GGsm8nZeehzdu9yKdAUpqPuZ+3fDTEvdFS 0fhkBtZfY= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 10, 1, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:46:72:150:152:355:379:421:582:800:960:962:967:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1730:1776:1792:2198:2199:2527:2528:2553:2557:2559:2562:2693:3138:3139:3140:3141:3142:3353:3586:3622:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:4117:4250:4321:4362:4470:5007:6117:6119:6261:6298:6657:6659:6678:7875:7903:8603:8957:9036:9177:10004:10400:10848:11232:11658:11914:11984:12043:12114:12555:12663:12740:12895:12986:13071:13137:13139:13146:13150:13161:13229:13230:13231:13255:13439:14039:14040:14093:14096:14180:14181:14721:21060:21080:21433:21451:21625:21740:21795:21810:30003:30054:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:27, LUA_SUMMARY:none X-HE-Tag: knee26_7faa737f6de4d X-Filterd-Recvd-Size: 6580 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf06.hostedemail.com (Postfix) with ESMTPA; Fri, 24 May 2019 09:24:37 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_262b012a03669233e645905c7b4bbbf2" Date: Fri, 24 May 2019 11:24:36 +0200 From: Peter van der Stok To: Ted Lemon Cc: consultancy@vanderstok.org, core@ietf.org, Stuart Cheshire Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com> References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [86.203.245.197] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 24 May 2019 09:24:41 -0000 --=_262b012a03669233e645905c7b4bbbf2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Ted, thanks for the feedback. I was thinking of the following recommendations (based on my background and experience) for the RD discovery. Given the large range of deployment conditions, the use of conditional recommendations seemed appropriate. In managed networks which are (often) not connected to a border router, the use of a preconfigured address is recommended. In managed networks with border routers that need stand-alone-operation, the RDA0 option recommended. The use of multicast discovery in mesh networks is NOT recommended. The use of DNS facilities is described in draft-ietf-core-rd-dns-sd. Comments on these recommendations will be appreciated. Peter Ted Lemon schreef op 2019-05-23 15:27: > On May 23, 2019, at 3:08 AM, Peter van der Stok wrote: > >> If so, should I mention in the text that a selection of supported discovery methods for a given RD configuration may be specified by a SDO? > > If that is what you intend to have happen, then yes, you should say that explicitly. You might also explicitly discuss the problems with doing that: > > * Increased complexity of deployments > * Lack of interoperability > * Likelihood of infrastructure (as opposed to leaf) devices not actually supporting all the possible discovery methods > > I suspect the reason we're having this conversation is that we don't yet know what to recommend, and that's understandable. But the reason I'm pushing the point is because at some point it would be of great benefit to the end-user to be able to say what to do. Leaving it up to each app-layer vendor is not a good solution. So if this document is not going to say what to do, we should at least be thinking in terms of discovering what we should recommend, and not simply decide that we are not going to solve that problem. --=_262b012a03669233e645905c7b4bbbf2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Ted,

thanks for the feedback. 

I was thinking= of the following recommendations (based on my background and experience) f= or the RD discovery.
Given the large range of deployment conditions, t= he use of conditional recommendations seemed appropriate.

In man= aged networks which are (often) not connected to a border router, the use o= f a preconfigured address is recommended.
In managed networks with bo= rder routers that need stand-alone-operation, the RDA0 option recommended= =2E
The use of multicast discovery in mesh networks is NOT recommended= =2E The use of DNS facilities is described in draft-ietf-core-rd-dns-sd.
Comments on these recommendations will be appreciated.

= Peter

Ted Lemon schreef op 2019-05-23 15:27:

On May 23, 2019, at 3:08 AM, Peter van der Stok <stokcons@bbhmail.nl> wro= te:
If so, should I mention in the text that a se= lection of supported discovery methods for a given RD configuration may be = specified by a SDO?

If that is what you intend to have happen, then yes, you should say th= at explicitly.   You might also explicitly discuss the problems with d= oing that:
  • Increased complexity of deployments
  • Lack of interoperability
  • Likelihood of infrastructure (as opposed to leaf) devices not actually = supporting all the possible discovery methods
 
I suspect the reason we're having this conversation is that we don't y= et know what to recommend, and that's understandable.   But the reason= I'm pushing the point is because at some point it would be of great benefi= t to the end-user to be able to say what to do.   Leaving it up to eac= h app-layer vendor is not a good solution.   So if this document is no= t going to say what to do, we should at least be thinking in terms of disco= vering what we should recommend, and not simply decide that we are not goin= g to solve that problem.
 
--=_262b012a03669233e645905c7b4bbbf2-- From nobody Fri May 24 06:11:45 2019 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 5B5FB120144 for ; Fri, 24 May 2019 06:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=fugue-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 Kis_ad41HNxO for ; Fri, 24 May 2019 06:11:42 -0700 (PDT) Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) (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 74637120092 for ; Fri, 24 May 2019 06:11:42 -0700 (PDT) Received: by mail-vs1-xe43.google.com with SMTP id x8so5677839vsx.13 for ; Fri, 24 May 2019 06:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=12ampARo2rfbQp0dI4xFCkRCRbAxk+1oaG6umjLcpX8=; b=xD7w8aEbZ1l0UETBFEPjdtEWv15tD8l7BuSlYxXw3KaWJU9DK5FNEvZrfo1Y3Y5WnY Xcssq9p4ppaUEn7H/QIIvpZnDqIKPHM1AcbBm7FzEXI7jB46d/PFnNbXwdFF0K1Gytcv 6QQpr7k2Wsqj8rK+gyYO8gZaa+5xFllqIevW2XXm6nSMH1fOk47SImKSs3mHqLtjetO6 IKBUOwwWr4iDOfv9mUhGQ4XhdQwfKXr5azEiy32QGyWd08grfvmQbmXYM0ZWBG53nt5f pzAQG06dl3DFRfl7xFbtewZdPdBWTpxHftRC1vVF2SpVdqKL6KNQEaU9iINvr+p/0d2s aEKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=12ampARo2rfbQp0dI4xFCkRCRbAxk+1oaG6umjLcpX8=; b=poSQHhQRlEfuMvZX8IPUnRdmr76ndCY017J5eGkP5HrLeEfmo3+5zPVcfTQSYb0kfk ZIVCYOITSFZ4E8ot8/OTu1p5z7SK5R8p1aGFOzjFQWzkknJZ3nXHm+SQ1T0fo4tMqETu OYUibSnLQahYq+s6YVnd6dBKDVm6Q4qBh24+5uONwq/WvSGMvoFBtpd4+prrr0ZPGznW /79CQ4XhHkJGoAUQWVgYNGB8xTiPp02g0FseOJChVC546TAloefXH8JqrnEzXY7rGyF7 QqV+yk1qRTvmAsfiGgwZmq7SCXlNBEJP45xw9M/1mheHNBIkS8T1OMQ6+b0Y++XBynfQ wyag== X-Gm-Message-State: APjAAAUNXTRMWWEaLwIt8EWgPyK55KOuyCKv8DQdWaHmZlvftxPbeRsu yumAkyzDt399DBONuqLm7t2kIg== X-Google-Smtp-Source: APXvYqxKIurGOGwTg7DgILxEZvCu0uxUEJIt/WkffHCbKYncxL1aAWSrImOCbOvmbead0rjWkPOXNA== X-Received: by 2002:a67:ee12:: with SMTP id f18mr37395541vsp.158.1558703501313; Fri, 24 May 2019 06:11:41 -0700 (PDT) Received: from [10.0.30.16] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id s65sm2442944vkd.36.2019.05.24.06.11.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 06:11:40 -0700 (PDT) From: Ted Lemon Message-Id: <33B4FD70-E650-47E4-A603-BD4928E4C47F@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_764683C1-3FFB-44FD-973E-E8DF679F10A1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Fri, 24 May 2019 09:11:38 -0400 In-Reply-To: Cc: core@ietf.org, Stuart Cheshire To: consultancy@vanderstok.org References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com> X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 24 May 2019 13:11:44 -0000 --Apple-Mail=_764683C1-3FFB-44FD-973E-E8DF679F10A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 24, 2019, at 5:24 AM, Peter van der Stok = wrote: > In managed networks which are (often) not connected to a border = router, the use of a preconfigured address is recommended.=20 I can=E2=80=99t think of a time when this would be the right = recommendation. Just because there is no border router doesn=E2=80=99t = mean that there isn=E2=80=99t a service discovery mechanism. If you = have something on the network providing core RD service, then you have a = =E2=80=9Cserver,=E2=80=9D and that =E2=80=9Cserver=E2=80=9D should also = be able to provice service discovery. DNS-SD is actually a pretty easy = way to do this=E2=80=94presumably you=E2=80=99re already configuring a = DNS server in RA or DHCP, and if not it=E2=80=99s easy to do, and you = don=E2=80=99t need to write any new specifications. The server can be = very lightweight. If manual configuration is indicated, then what should be configured is = the hostname of the RD server, not the IP address, which is simply too = likely to change. This avoids the risk that you would have to go out = and manually reconfigure every device on the network when you change = your network configuration.=20 But really, the RDA0 works just fine in this case, and that=E2=80=99s = what I=E2=80=99d recommend if I were writing the document, unless you = are thinking that on a network of this type, hosts are just = communicating using link-local addresses. If they are using mesh-local = addresses, then whatever mechanism configures mesh-local addressing = should also be able to convey the RD IP address. > In managed networks with border routers that need = stand-alone-operation, the RDA0 option recommended. Sure. > The use of multicast discovery in mesh networks is NOT recommended. = The use of DNS facilities is described in draft-ietf-core-rd-dns-sd. Yup. --Apple-Mail=_764683C1-3FFB-44FD-973E-E8DF679F10A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = May 24, 2019, at 5:24 AM, Peter van der Stok <stokcons@bbhmail.nl>= wrote:
In managed networks which are (often) not connected to a = border router, the use of a preconfigured address is recommended. 

I can=E2=80=99t think of a time when this would be the = right recommendation.   Just because there is no border router = doesn=E2=80=99t mean that there isn=E2=80=99t a service discovery = mechanism.   If you have something on the network providing core RD = service, then you have a =E2=80=9Cserver,=E2=80=9D and that =E2=80=9Cserve= r=E2=80=9D should also be able to provice service discovery.   = DNS-SD is actually a pretty easy way to do this=E2=80=94presumably = you=E2=80=99re already configuring a DNS server in RA or DHCP, and if = not it=E2=80=99s easy to do, and you don=E2=80=99t need to write any new = specifications.   The server can be very lightweight.

If manual configuration is indicated, then what = should be configured is the hostname of the RD server, not the IP = address, which is simply too likely to change.   This avoids the = risk that you would have to go out and manually reconfigure every device = on the network when you change your network = configuration. 

But really, the = RDA0 works just fine in this case, and that=E2=80=99s what I=E2=80=99d = recommend if I were writing the document, unless you are thinking that = on a network of this type, hosts are just communicating using link-local = addresses.   If they are using mesh-local addresses, then whatever = mechanism configures mesh-local addressing should also be able to convey = the RD IP address.

In managed = networks with border routers that need stand-alone-operation, the RDA0 = option recommended.

Sure.

The use of = multicast discovery in mesh networks is NOT recommended. The use of DNS = facilities is described in = draft-ietf-core-rd-dns-sd.

Yup.

= --Apple-Mail=_764683C1-3FFB-44FD-973E-E8DF679F10A1-- From nobody Mon May 27 00:31:40 2019 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 12F5C1200E9 for ; Mon, 27 May 2019 00:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.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 7Y3BehSkL6On for ; Mon, 27 May 2019 00:31:36 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0103.hostedemail.com [216.40.44.103]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6606120099 for ; Mon, 27 May 2019 00:31:36 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay04.hostedemail.com (Postfix) with ESMTP id 4B74B180A812A; Mon, 27 May 2019 07:31:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=XIxdoTS8uT4vT3fXI1 MfdpV4J3MyC1YIFJzB7k6VwdY=; b=cdng4JKlY9d70Md9oZ70tlHCPVsgks2fF5 uM+MRL/8PiDtvqgTqtsicHUT8yD8UL2p8APcPCfBEsS9fQw4bpfN4yWLkPGs+ov3 CATIvJ9IfuTMGkuxuhlCS8yDSGder/3F0a0hSjEcij+ySPgYzGdNAAq/igkUBFBI 1cI5mbquU= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 10, 1, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:46:72:150:152:355:379:582:800:960:962:967:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1544:1575:1588:1589:1592:1594:1711:1730:1776:1792:2198:2199:2527:2528:2553:2557:2559:2562:2900:2902:2912:3138:3139:3140:3141:3142:3354:3586:3622:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:4119:4250:4321:5007:6117:6119:6261:6298:6657:6678:7875:7903:8603:9036:9177:10004:10226:10848:11232:11657:11658:11914:11984:12043:12050:12114:12555:12740:12895:12986:13139:13161:13229:13255:13439:14093:14096:14180:14181:14721:21060:21063:21080:21433:21451:21625:21740:21810:30003:30030:30054:30070:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:25, LUA_SUMMARY:none X-HE-Tag: knee85_2ae5459d9ca0b X-Filterd-Recvd-Size: 8800 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf07.hostedemail.com (Postfix) with ESMTPA; Mon, 27 May 2019 07:31:34 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_8b985c6dc90bc80c6de7f1a77b7de365" Date: Mon, 27 May 2019 09:31:34 +0200 From: Peter van der Stok To: Ted Lemon Cc: consultancy@vanderstok.org, core@ietf.org, Stuart Cheshire Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <33B4FD70-E650-47E4-A603-BD4928E4C47F@fugue.com> References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com> <33B4FD70-E650-47E4-A603-BD4928E4C47F@fugue.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [86.203.245.197] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 27 May 2019 07:31:39 -0000 --=_8b985c6dc90bc80c6de7f1a77b7de365 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Ted, The use cases for networks without border router are; A mesh network configured on a gletcher in the Alps to measure the ice movements. A mesh network dropped from a plane over a forest. A mesh network in a building under construction not connected to any outside service. For example, in those cases a border router is present once a month for a few hours to read out data. No RDA0 option, avoid multicast, no host names. Therefore, the configured RD IP address seems reasonable. Peter Ted Lemon schreef op 2019-05-24 15:11: > On May 24, 2019, at 5:24 AM, Peter van der Stok wrote: > >> In managed networks which are (often) not connected to a border router, the use of a preconfigured address is recommended. > > I can't think of a time when this would be the right recommendation. Just because there is no border router doesn't mean that there isn't a service discovery mechanism. If you have something on the network providing core RD service, then you have a "server," and that "server" should also be able to provice service discovery. DNS-SD is actually a pretty easy way to do this--presumably you're already configuring a DNS server in RA or DHCP, and if not it's easy to do, and you don't need to write any new specifications. The server can be very lightweight. > > If manual configuration is indicated, then what should be configured is the hostname of the RD server, not the IP address, which is simply too likely to change. This avoids the risk that you would have to go out and manually reconfigure every device on the network when you change your network configuration. > > But really, the RDA0 works just fine in this case, and that's what I'd recommend if I were writing the document, unless you are thinking that on a network of this type, hosts are just communicating using link-local addresses. If they are using mesh-local addresses, then whatever mechanism configures mesh-local addressing should also be able to convey the RD IP address. > >> In managed networks with border routers that need stand-alone-operation, the RDA0 option recommended. > > Sure. > >> The use of multicast discovery in mesh networks is NOT recommended. The use of DNS facilities is described in draft-ietf-core-rd-dns-sd. > > Yup. --=_8b985c6dc90bc80c6de7f1a77b7de365 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Ted,

The use cases for networks without border router are;A mesh network configured on a gletcher in the Alps to measure the ice m= ovements.
A mesh network dropped from a plane over a forest.
A me= sh network in a building under construction not connected to any outside se= rvice.

For example, in those cases a border router is present on= ce a month for a few hours to read out data.

No RDA0 option,&nbs= p; avoid multicast, no host names. Therefore, the configured RD IP address = seems reasonable. 

Peter

Ted Lemon schreef op 2019-05-24 15:11:

On May 24, 2019, at 5:24 AM, Peter van der Stok <stokcons@bbhmail.nl> wro= te:
In managed networks which are (often) not con= nected to a border router, the use of a preconfigured address is recommende= d. 
 
I can't think of a time when this would be the right recommendation.  = Just because there is no border router doesn't mean that there isn't a ser= vice discovery mechanism.   If you have something on the network provi= ding core RD service, then you have a "server," and that "server" should al= so be able to provice service discovery.   DNS-SD is actually a pretty= easy way to do this—presumably you're already configuring a DNS serv= er in RA or DHCP, and if not it's easy to do, and you don't need to write a= ny new specifications.   The server can be very lightweight.
 
If manual configuration is indicated, then what should be configured i= s the hostname of the RD server, not the IP address, which is simply too li= kely to change.   This avoids the risk that you would have to go out a= nd manually reconfigure every device on the network when you change your ne= twork configuration. 
 
But really, the RDA0 works just fine in this case, and that's what I'd= recommend if I were writing the document, unless you are thinking that on = a network of this type, hosts are just communicating using link-local addre= sses.   If they are using mesh-local addresses, then whatever mechanis= m configures mesh-local addressing should also be able to convey the RD IP = address.

In managed networks with border routers that = need stand-alone-operation, the RDA0 option recommended.
 
Sure.

The use of multicast discovery in mesh networ= ks is NOT recommended. The use of DNS facilities is described in draft-ietf= -core-rd-dns-sd.

Yup.
 
--=_8b985c6dc90bc80c6de7f1a77b7de365-- From joel.hoglund@gmail.com Mon May 27 00:11:47 2019 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 DFE9012004C for ; Mon, 27 May 2019 00:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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, T_KAM_HTML_FONT_INVALID=0.01] 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 NFxwbBipRuVc for ; Mon, 27 May 2019 00:11:46 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 A2A3812006D for ; Mon, 27 May 2019 00:11:45 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id p26so25240108edr.2 for ; Mon, 27 May 2019 00:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LYTo1yCIW3hzqyQdx4XI2Knxi8vD0KhoJqS+LBY1OWE=; b=hirhkuXKZqPIQ589ZBL58CUTQXm3qTb6x/7cjFWKkuZFLVU+5vKqGmALKxILQrpk3p 3BB21H4fAB8yLJBc0x6prFGMjeExY70NCHh3AuDJusE7Id9qzTyG0X8O1Qai4Vi9cSvK khOgE24+xjduDyMdbKJgTd71ydC70dDhJq/s7vDnxWSGfAqVG9GujPtX5cV5o+QLEfIY PAMzfdwlMwJ4cqygvuKqjIvnz+aFXrmn8kFCEAVKYG8Q2J7cjzjezF2PsQeVeuJ3VI47 2U8F6YZmmhG0s8QUecTP2RxV03OStsISRU5/c5ePlCxITvpSoZToQlTSlfK6TNj3MYJi DVSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LYTo1yCIW3hzqyQdx4XI2Knxi8vD0KhoJqS+LBY1OWE=; b=ogkBiUwvUd2xsQRegPjRhGpHu+wc631LrbidPtqb1cwHolE0+941voA0yCBBB8RKUO z/0fkqWQ29lKmbDM/hqIKof1h/VN4/RgwvxPQpD1Hxxwl4K6xxpWOodsoH5z+dCIsrhY ryRpexb2NhzDaOt5BfPIQiHeOpz7k4mkMrITjsmLco3tHgT5UQKX40kzUkcIQyBDsWir uLxGMR4qaqr/XHVV5nSEpkJk5wfT6F/HuxCR9Fddvn+pWhrRaasLN4qAkyXlU0enPyUz gXrrJ9yaJjuViFnreZFiCVILwaPkzYpbM5sgQbVA4Pn4XMeAh9Hn/I0/4T73Tj8bJug7 RPbA== X-Gm-Message-State: APjAAAUn21RLRBEt4FuEUqQGZhaNd/9V6lld6aGUyi36wMsDXscG/il4 6MP/KGumObW9LNNS6wlbXETTGF3IhoZtbbH28zIE8Z4w X-Google-Smtp-Source: APXvYqxpOn/xyR3I+gJLxzas6ru8v8fEbA9x/jy3OyzBRp2IvlfF9G5KXIeUt7aigHNLeooBeTj5e6lUQ02ynZkyNhU= X-Received: by 2002:a50:913d:: with SMTP id e58mr121326275eda.107.1558941103821; Mon, 27 May 2019 00:11:43 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Joel_H=C3=B6glund?= Date: Mon, 27 May 2019 09:11:32 +0200 Message-ID: To: core@ietf.org Content-Type: multipart/alternative; boundary="000000000000b818320589d942f3" Archived-At: Subject: [core] Reply to comments on raza-ace-cbor-certificates 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, 27 May 2019 07:51:18 -0000 --000000000000b818320589d942f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michael, Thanks for the comments, sorry for late response. Please find responses inline below. =E2=80=9CIf we transcode ASN.1 to CBOR rather than DER in a way that preser= ves the signature, then I think we miss all opportunities to throw away the DER code.=E2=80=9D This is a valid remark, in the sense that a signature, which is computed and added as a part of an original -- profiled but uncompressed -- certificate structure, can only be verified after recreating the original uncompressed structure. =E2=80=9CIf we can outsource this to a third party to verify, we can just t= hrow the DER itself to the third party, and wrap it in a RESTful COAP interface.=E2= =80=9D One of our goals is to keep end to end security. Which means we generally don=E2=80=99t want to outsource anything / to be forced to trust additional parties. Our discussions have been along the lines that the cbor encoding c= ould become a native encoding option, in which case the ASN1-DER encoding could be skipped and the signature computed and added directly on the smaller cbor encoded data structure. But I don=E2=80=99t see that neither the curre= nt =E2=80=9Cneeds to recreate the initial structure=E2=80=9D nor a native impl= ementation would rule out outsourcing verification to third parties, if one would want that. =E2=80=9CI see two issues with PKIX certificates: a) DNs never made any sense in 1980 when a company could have three people named John Smith, and they make even less sense now that we have 10,000 light bulbs whose name is "serialNumber=3DXXXXX" b) while subject DNs can be empty, issuer DNs can't be empty if you want to verify the certificate.Finding the public key of the issuer to verify the certificate is annoying and often non-trivial. There are PKIX extensions to deal with this, but they aren't mandatory. These are essentially issues with how the certificate semantics are encoded into the ASN.1, not really a problem with the DER itself. The lack of good DER encoders/decoders (I've never seen a pull parser, I'm sure Heimdal includes one, but I've never seen it) is the PITA.=E2=80=9D We haven=E2=80=99t addressed how an IoT client should act if it does not al= ready have a relevant certificate/the relevant public key of the issuer of a certificate that it needs to verify, or the reverse. I have assumed this to be separate issues. As long as the subject and issuer can be uniquely identified within their target scope (which might or might not be the entire internet), I don=E2=80=99t think our proposal is making the problems= he describes worse. But I=E2=80=99m happy to hear more opinions if you think t= here are details regarding this we should expand or try to clarify. The certificates we have used as basis for the comparisons made in the draft are taken from IoT security projects we have been working with. We welcome if other working group members want to contribute additional examples of relevant certificates to compare with. "I couldn't figure out what the conclusion of your slides were, btw." I agree it was not spelled out sufficiently clear. The main conclusions are= : 1. We can significantly reduce message overhead of X.509 certificates which is beneficial when transported over constrained networks. Indeed, substantially better than e.g. the TLS compression scheme zlib (see draft-ietf-tls-certificate-compression) as we show in the next version of the draft. 2. CAs can maintain their current X.509 based infrastructure and include this as a compression front end. 3. The certificate format is a candidate native format for IoT device certificates. This would require changes in the CA, but would reduce processing and memory use in particular in the IoT device which does not require ASN.1 or DER. The compression step provides a migration path where the CAs and device manufacturers can support compressed standard X.509 and native CBOR certificates in parallel (e.g. different device batches) Best Regards Joel H=C3=B6glund --000000000000b818320589d942f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Michae= l,


Thanks fo= r the comments, sorry for late response. Please find responses inline below= .


=E2=80=9CIf we transcode ASN.1 to CBOR rather than DER in a way tha= t preserves the signature, then I think we miss all opportunities to throw = away the DER code.=E2=80=9D


This is a valid remark, in the sense that a signature, whic= h is computed and added as a part of an original -- profiled but uncompress= ed -- certificate structure, can only be verified after recreating the orig= inal uncompressed structure.


=E2=80=9CIf we can outsource this to a = third party to verify, we can just throw the DER itself to the third party,= and wrap it in a RESTful COAP interface.=E2=80=9D


One of our goals is to keep end to e= nd security. Which means we generally don=E2=80=99t want to outsource anyth= ing / to be forced to trust additional parties. Our discussions have been a= long the lines that the cbor encoding could become a native encoding option, in which case the = ASN1-DER encoding could be skipped and the signature computed and added dir= ectly on the smaller cbor encoded data structure. But I don=E2=80=99t see t= hat neither the current =E2=80=9Cneeds to recreate the initial structure=E2= =80=9D nor a native implementation would rule out outsourcing verification = to third parties, if one would want that.


=E2=80=9CI see two issues w= ith PKIX certificates:


a) DNs never made any sense in 1980 when a com= pany could have three people named John Smith, and they make even less sense now tha= t we have= 10,000 light bulbs whose name is "serialNumber=3DXXXXX"

b) whi= le subject DNs can be empty, issuer DNs can't be empty if you want to v= erify the certificate.Finding the public key of the issuer to verify the ce= rtificate is annoying and often non-trivial. There are PKIX extensions to d= eal with this, but they aren't mandatory.


These are essentially i= ssues with how the certificate semantics are encoded into the ASN.1, not re= ally a problem with the DER itself. The lack of good DER encoders/decoders = (I've never seen a pull parser, I'm sure Heimdal includes one, but = I've never seen it) is the PITA.=E2=80=9D


We haven=E2=80=99t addressed how an IoT c= lient should act if it does not already have a relevant certificate/the rel= evant public key of the issuer of a certificate that it needs to verify, or= the reverse. I have assumed this to be separate issues. As long as the sub= ject and issuer can be uniquely identified within their target scope (which= might or might not be the entire internet), I don=E2=80=99t think our prop= osal is making the problems he describes worse. But I=E2=80=99m happy to he= ar more opinions if you think there are details regarding this we should ex= pand or try to clarify.


The certificates we have used as basis for the comparisons made= in the draft are taken from IoT security projects we have been working wit= h. We welcome if other working group members want to contribute additional = examples of relevant certificates to compare with.



"I couldn't figure out = what the conclusion of your slides were, btw."


I agree it was not spelled out suff= iciently clear. The main conclusions are:


1. We can significantly reduce message overhe= ad of X.509 certificates which is beneficial when transported over constrai= ned networks.=C2=A0 Indeed, substantially better than e.g. the TLS compress= ion scheme zlib (see draft-ietf-tls-certificate-compression) as we show in = the next version of the draft.


2. CAs can maintain their current X.509 based infrastru= cture and include this as a compression front end.


3. The certificate format is a candi= date native format for IoT device certificates. This would require changes = in the CA, but would reduce processing and memory use in particular in the = IoT device which does not require ASN.1 or DER. The compression step provid= es a migration path where the CAs and device manufacturers can support comp= ressed standard X.509 and native CBOR certificates in parallel (e.g. differ= ent device batches)


Best Regards

Joel H=C3=B6glund
<= /div> --000000000000b818320589d942f3-- From nobody Tue May 28 01:15:27 2019 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 3F6D81200C4 for ; Tue, 28 May 2019 01:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nFNuUYpgmDvw for ; Tue, 28 May 2019 01:15:18 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 45DE51200EF for ; Tue, 28 May 2019 01:15:18 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id n5so8857387ioc.7 for ; Tue, 28 May 2019 01:15:18 -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=jpFRgU3NumrlpybG1ExByXyNfmEiNiiN2skDpybHBgg=; b=JnRpb0wg69dNZQwFjNhhfRNyFGOMNeW+R0zTHLEU7q++/7TqAMO7K8J/SEzgSi3uGI ANtdagYPDMDLY0Htqqy0K+uvKwJ0Qfz6ux3xgJj1b76V1sbBjQ3CTBfzVa3C3zyohUPU rBKk3rwMbZ31rPoyHEP2Q5g0HZdIVZGHSAMuX/MZFjpFJqpBSEJ5xMYsl5UkAjNIxCJo 2ASVwjqmwZaxsG5HrCkw72Xjltab4xYaw0x1avyEpSDx166sMK5/MQbEneCZHXa5wLYI wwjWb3v/rz+ud7GoyAoTzpLi0xpJptpO27moiV920hRS20hPM5skalpVnilJb7w1kZkp XGPA== 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=jpFRgU3NumrlpybG1ExByXyNfmEiNiiN2skDpybHBgg=; b=IcmaLvNbd8poM+WHHiNB9x1CfQRyP1f0sf5D7ZEsVnNChOjPb53r0fCklIdUrkH08a PUT5zne8fY93hhbaz4B/8N7Gdl9a2w2/T3+/dHCBvHptJhxMFt6fIO4S4YtazSq9glEs 75jZNm20qPrfq4o1ZhxyZ5iE9HZ1Lgtuo4BeID8vcd0e5bBz9RarVkFcBMGOOyYMSmV+ HofZXVSGWxCAfSHS1N4V9oE6O4YW4Iz7A7iIuZ1Ze6vbXghk1fA13cfR/W7jljSPv7x0 gXEwGqmQtR/vX1zR723TmyQ4WdoFBH2gJ9l8waAq/a6yrgGpnX0Hc6BhMDKMr2AoLu71 qEIA== X-Gm-Message-State: APjAAAVHKptuYqiBiOZNg+DV80QTccL7Q/WujFqJwbVF5Y0jpGhXCYMV PNpGr4N6parszC3CUZPiWJGwcjTZWLIunKqs5D52QucMDgI= X-Google-Smtp-Source: APXvYqySkhdj5q+GVA6g4f4BVTujCOgWmV8KKrcwJWfEk2F+ynSIIK2RUfwid/iJf4dr9KRACSboQIdLkkrCCfL6kRc= X-Received: by 2002:a05:6602:2252:: with SMTP id o18mr1547145ioo.63.1559031317306; Tue, 28 May 2019 01:15:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Pelov Date: Tue, 28 May 2019 10:15:06 +0200 Message-ID: To: "core@ietf.org WG (core@ietf.org)" Cc: lp-wan Content-Type: multipart/alternative; boundary="000000000000dcbc1e0589ee43f3" Archived-At: Subject: [core] Fwd: WGLC on SCHC for CoAP 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, 28 May 2019 08:15:21 -0000 --000000000000dcbc1e0589ee43f3 Content-Type: text/plain; charset="UTF-8" Dear CoRE WG, The LPWAN WG has started the WGLC of SCHC for CoAP. The document is now considered stable with many examples and working code using it. The group has decided to not boil the ocean and have an all-encompassing CoAP compression mechanism. It is however at an excellent maturity level. Please, review the document if you have not done it until now, and provide your comments or feedback by the end of the WGLC. The authors and the Chairs would be happy to have your input by the deadline and provide extensions if there are timely remarks. The deadline is in two weeks time (June 11, 23h55 CEST). There is a virtual interim meeting of the LPWAN WG tomorrow (May 29th), 16h-17h CEST. The authors will be present and there will be a slot for discussion, so consider this as an excellent opportunity to jump-start your review. Regards, The LPWAN WG Chairs ---------- Forwarded message --------- From: Alexander Pelov Date: Tue, May 28, 2019 at 10:04 AM Subject: WGLC on SCHC for CoAP To: lp-wan Dear LPWAN WG, This is the Working Group Last Call for the SCHC CoAP document. We have discussed during IETF 104, as well as during our last interim meeting that the document has reached the level of maturity we expect from it. The document can be found on the Datatracker : https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/ and is now in it's -07 release. Please provide any comments, additional reviews or feedback on the document by June 11, 23h55 CEST when the WGLC will end (2 weeks from now). Cheers, Pascal and Alexander --000000000000dcbc1e0589ee43f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear CoRE WG,

The LPWAN WG has started = the WGLC of SCHC for CoAP.

The document is now con= sidered stable with many examples and working code using it.
The = group has decided to not boil the ocean and have an all-encompassing CoAP c= ompression mechanism. It is however at an excellent maturity level.

Please, review the document if you have not done it until= now, and provide your comments or feedback by the end of the WGLC.

The authors and the Chairs would be happy to have your in= put by the deadline and provide extensions if there are timely remarks.

The deadline is in two weeks time (June 11, 23h55 CES= T).=C2=A0

There is a virtual interim meeting of th= e LPWAN WG tomorrow (May 29th), 16h-17h CEST. The authors will be present a= nd there will be a slot for discussion, so consider this as an excellent op= portunity to jump-start your review.=C2=A0

Regards= ,
The LPWAN WG Chairs


---------- Forwarded mes= sage ---------
From: Ale= xander Pelov <a= @ackl.io>
Date: Tue, May 28, 2019 at 10:04 AM
Subject: = WGLC on SCHC for CoAP
To: lp-wan <= lp-wan@ietf.org>


Dear LPWAN WG,
This is the Working Group Last Call for the SCHC CoAP docu= ment.

We have discussed during IETF 104, as well a= s during our last interim meeting that the document has reached the level o= f maturity we expect from it.

The document can be = found on the Datatracker :=C2=A0https://datatr= acker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/=C2=A0and is= now in it's -07 release.

Please provide any c= omments, additional reviews or feedback on the document by June 11, 23h55 C= EST when the WGLC will end (2 weeks from now).

Che= ers,
Pascal and Alexander

--000000000000dcbc1e0589ee43f3-- From nobody Tue May 28 10:43:36 2019 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 5F984120048 for ; Tue, 28 May 2019 10:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_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=fugue-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 REU6kZ_xCf4e for ; Tue, 28 May 2019 10:43:32 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 11613120123 for ; Tue, 28 May 2019 10:43:32 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id h2so8354090pgg.1 for ; Tue, 28 May 2019 10:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Hn8UP2qpDulgsqVcPWYXv/krPGjHNWpvw8c371w8fF0=; b=1vBYQVnt5bZYRXUcrSAt9M13k5ZBkrc7MXtdaD9ZjGbAffGK+pfDIb+ddE/OmnEcYH GiQ8c4NKXMo1Ws4szrFnjPMUdxKwcjh6BuKSzhiynYY47ZaIBv8pmxGmKzwxpj+cGg2l XswUhOm9mbkOhVasokU0XPXCE3AtJgVmGo3xSIpMYlOTAgmSdKL2z/OiKzORLZsRXJKv x08B6OyAfXtBC67J5O2vgrYH5gcPkMDGw4THmJt4JaLIDCLOIf+ZnbR6hp7sI8YUt9oS D/BLZ9AaSC7cq+g6VxEStxXX9lDKqy00/eFgjXY2v/uHNuRDyZfHO1g6NAiq11fdHl5d zaaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Hn8UP2qpDulgsqVcPWYXv/krPGjHNWpvw8c371w8fF0=; b=rlDXeVEyXzjui4/nIn7MHGanzFRHDoADbe911M4h2D79SX52YAHOCQe93h5IZfDGgi +Tv1duWKkcDjWfi54pAwz45PRfCW0wp4GxoR7tN4Dp2snJlTNIfnLkXPIe9CUzov16TT E0M972MpsZ8H8QseQeYn8Wv3TlfJP0OHkFNWWQDJHjudbN+XAMUX53niKQr6x4FnE5Yg LyvZ9beooh21o2PU9DyfMMoZ0GgXZMS2JrloLFLmq6rp4ZQgLO7NqolAYGgLNu30VhS6 I87BOYTVEyWTCBRauPKWwA0nUwyLlfGPOW4lsVZzsRvVh53LzThSIsMXmBUwJRECQW45 uANw== X-Gm-Message-State: APjAAAVEB0XMxGQxJRT1ucMQt3mZCSl+/uyTVxCHWUKlPRFf9h+gBQM1 /Lg//umtkmrgw68gFtG078DATA== X-Google-Smtp-Source: APXvYqxn5UmKm1dpEUA8DFwwgOuEbU6IkSuYbci805qZBzJwiHBTe6X8v0hpRjx5+Ay2hkoJ5/L3OA== X-Received: by 2002:a63:1657:: with SMTP id 23mr79788466pgw.98.1559065410697; Tue, 28 May 2019 10:43:30 -0700 (PDT) Received: from [17.230.170.110] ([17.230.170.110]) by smtp.gmail.com with ESMTPSA id b21sm19207098pfb.46.2019.05.28.10.43.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 May 2019 10:43:29 -0700 (PDT) From: Ted Lemon Message-Id: <137192BD-7638-4D2E-A6E5-E1618499366F@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3DDD7066-0767-494C-9CB7-91BBFE6C2FEE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Tue, 28 May 2019 10:43:28 -0700 In-Reply-To: Cc: core@ietf.org, Stuart Cheshire To: consultancy@vanderstok.org References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com> <33B4FD70-E650-47E4-A603-BD4928E4C47F@fugue.com> X-Mailer: Apple Mail (2.3445.104.2) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 28 May 2019 17:43:34 -0000 --Apple-Mail=_3DDD7066-0767-494C-9CB7-91BBFE6C2FEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 27, 2019, at 12:31 AM, Peter van der Stok = wrote: > For example, in those cases a border router is present once a month = for a few hours to read out data. > No RDA0 option, avoid multicast, no host names. Therefore, the = configured RD IP address seems reasonable.=20 Isn=E2=80=99t it the case generally that in order for the device to know = that there is a BR present, the BR has to do some kind of multicast? --Apple-Mail=_3DDD7066-0767-494C-9CB7-91BBFE6C2FEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = May 27, 2019, at 12:31 AM, Peter van der Stok <stokcons@bbhmail.nl>= wrote:
For example, in those cases a border router is present once a = month for a few hours to read out data.
No RDA0 option,  avoid = multicast, no host names. Therefore, the configured RD IP address seems = reasonable. 

Isn=E2=80=99t it the case generally that in order for the = device to know that there is a BR present, the BR has to do some kind of = multicast?

= --Apple-Mail=_3DDD7066-0767-494C-9CB7-91BBFE6C2FEE-- From nobody Wed May 29 00:49:43 2019 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 6C1C212016C for ; Wed, 29 May 2019 00:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.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 BXpihy4TiJc3 for ; Wed, 29 May 2019 00:49:31 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0007.hostedemail.com [216.40.44.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B2012015D for ; Wed, 29 May 2019 00:49:30 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id 17B858368EED; Wed, 29 May 2019 07:49:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=ZPp1MhPKLBt1y7YpCD /2n0UfrHNlu/hkP4hYx50YJ5I=; b=Hkzy5yQ7SN/aFZ4IVJyWGKmm+XQxV6HyH8 1K632BidWItXRUGlovcomSSfhj12lRM83WEu9QynafTJI5it+swziDY8nobW/UUG n86Ex9RjipJn3j6/jEENgask4P/TmPFrVYfjFCD00cQJ2M/FMnO2hsPXulnhtoXo qE8JZ7aRk= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 10, 1, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:46:72:150:152:355:379:582:800:960:962:967:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1542:1575:1588:1589:1592:1594:1711:1730:1776:1792:2198:2199:2527:2528:2553:2557:2559:2562:2731:2902:3138:3139:3140:3141:3142:3352:3586:3622:3769:3865:3866:3867:3868:3870:3871:3872:3874:4250:4321:4891:5007:6117:6119:6261:6298:6657:6678:7464:7875:7903:7904:8603:9036:9177:10004:10400:10848:11232:11658:11914:11984:12043:12050:12114:12295:12555:12740:12895:12986:13071:13139:13161:13229:13255:13439:14093:14096:14180:14181:14721:21060:21063:21080:21324:21433:21451:21625:21740:21810:30003:30006:30030:30041:30054:30070:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:24, LUA_SUMMARY:none X-HE-Tag: club41_188ac7a58a415 X-Filterd-Recvd-Size: 5766 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf14.hostedemail.com (Postfix) with ESMTPA; Wed, 29 May 2019 07:49:28 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_8496bfe58f590551e8aabb2d9afe0c68" Date: Wed, 29 May 2019 09:49:28 +0200 From: Peter van der Stok To: Ted Lemon Cc: consultancy@vanderstok.org, core@ietf.org, Stuart Cheshire Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <137192BD-7638-4D2E-A6E5-E1618499366F@fugue.com> References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com> <33B4FD70-E650-47E4-A603-BD4928E4C47F@fugue.com> <137192BD-7638-4D2E-A6E5-E1618499366F@fugue.com> Message-ID: <0d20366a188573397f9e98e4f8adc8e2@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [86.203.245.197] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 29 May 2019 07:49:42 -0000 --=_8496bfe58f590551e8aabb2d9afe0c68 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII HI Ted, RFC 6775 explicitly discourages multicast over the mesh network. Neighbour discovery is done with link-local broadcast, replaced with unicast whenever possible. In the mesk all 6LR know the addresses of their neighbouring 6LR. The 6LBR only needs to know the addresses of the neigbouring 6LR, obtained with with one broadcast and n unicasts. Sending a multicast form each node to learn the address of the RD generates many more messages in a multihop mesh. Does this answer the question below? Greetings, Peter Ted Lemon schreef op 2019-05-28 19:43: > On May 27, 2019, at 12:31 AM, Peter van der Stok wrote: > >> For example, in those cases a border router is present once a month for a few hours to read out data. >> No RDA0 option, avoid multicast, no host names. Therefore, the configured RD IP address seems reasonable. > > Isn't it the case generally that in order for the device to know that there is a BR present, the BR has to do some kind of multicast? --=_8496bfe58f590551e8aabb2d9afe0c68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 HI Ted,

RFC 6775 explicitly discourages multicast over the mesh = network.
Neighbour discovery is done with link-local broadcast, replac= ed with unicast whenever possible.
In the mesk all 6LR know the addres= ses of their neighbouring 6LR.
The 6LBR only needs to know the address= es of the neigbouring 6LR, obtained with with one broadcast and n unicasts= =2E

Sending a multicast form each node to learn the address of t= he RD generates many more messages in a multihop mesh.

Does this= answer the question below?

Greetings,

Peter

Ted Lemon schreef op 2019-05-28 19:43:

On May 27, 2019, at 12:31 AM, Peter van der Stok <stokcons@bbhmail.nl> wr= ote:
For example, in those cases a border router i= s present once a month for a few hours to read out data.
No = RDA0 option,  avoid multicast, no host names. Therefore, the configure= d RD IP address seems reasonable. 

Isn't it the case generally that in order for the device to know that = there is a BR present, the BR has to do some kind of multicast?
 
--=_8496bfe58f590551e8aabb2d9afe0c68-- From nobody Wed May 29 06:17:25 2019 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 22A8E12006B for ; Wed, 29 May 2019 06:17:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 HntoABGpaS9u for ; Wed, 29 May 2019 06:17:21 -0700 (PDT) Received: from sjmda12.webex.com (sjmda12.webex.com [64.68.124.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2FAC120106 for ; Wed, 29 May 2019 06:17:19 -0700 (PDT) Received: from rva2rmd101.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda12.webex.com (Postfix) with ESMTP id 750A4300004C for ; Wed, 29 May 2019 13:17:19 +0000 (GMT) Received: from rva2rmd101.webex.com (localhost [127.0.0.1]) by rva2rmd101.webex.com (Postfix) with ESMTP id 301AFC058C for ; Wed, 29 May 2019 13:17:19 +0000 (GMT) Date: Wed, 29 May 2019 13:17:19 +0000 (GMT) From: CORE Working Group Reply-To: core-chairs@ietf.org To: core@ietf.org Message-ID: <1575373672.762531559135839195.JavaMail.nobody@rva2rmd101.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_152504_567075164.1559135839195" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=129422503524183502, X-WBX-TID=2gw7cfjhxa3warsbwec39a2lkr6ekz7y6xoxrovvf3svv49xzsxdllx2, X-WBX-RID=0a72ce8f10a143b1b1f24a517d97248a, X-WBX-SVC:Meeting Center, X-WBX-TT:Meeting Invitation, Date:Wed May 29 13:17:19 GMT 2019 reminder-3.32.0-2232 Archived-At: Subject: [core] Webex meeting invitation: Virtual Interim 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, 29 May 2019 13:17:23 -0000 ------=_Part_152504_567075164.1559135839195 Content-Type: multipart/Alternative; boundary="----=_Part_152505_615212062.1559135839195" ------=_Part_152505_615212062.1559135839195 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKQ09SRSBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJl eCBtZWV0aW5nLgoKClZpcnR1YWwgSW50ZXJpbQpPY2N1cnMgZXZlcnkgMiB3ZWVrKHMpIG9uIFdl ZG5lc2RheSBlZmZlY3RpdmUgV2VkbmVzZGF5LCAyOS4gTWF5IDIwMTkgdW50aWwgV2VkbmVzZGF5 LCAxMy4gTm92ZW1iZXIgMjAxOSBmcm9tIDE3OjAwIHRvIDE4OjMwLCAoVVRDKzAwOjAwKSBNb25y b3ZpYSwgUmV5a2phdmlrCjE3OjAwICB8ICBHcmVlbndpY2ggVGltZSAoUmV5a2phdmlrLCBHTVQp ICB8ICAxIGhyIDMwIG1pbnMKTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQ4IDYzNiA2 MDkgCk1lZXRpbmcgcGFzc3dvcmQ6IGNvbnN0cmFpbmVkCgoKCkFkZCB0byBDYWxlbmRhcgpodHRw czovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMTExMTI4MDM4ODMwOTRjOGRmMzVm MjNkODNiNmM4NDgNCg0KV2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhlIG1lZXRpbmcuCmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0yNWNiM2M2NjM1YzM2NWNlN2I4ZDdlMjMx MTUyZTZlZgoKDQpKT0lOIEJZIFBIT05FDQoxLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVt YmVyIChVUy9DYW5hZGEpClRhcCBoZXJlIHRvIGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9z dHMgbm90IHN1cHBvcnRlZCk6IHRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0ODYzNjYwOSUy MyUyMyowMSoKDQoNCgpDYW4ndCBqb2luIHRoZSBtZWV0aW5nPwpodHRwczovL2NvbGxhYm9yYXRp b25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NQoKCklNUE9SVEFOVCBOT1RJQ0U6 IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3Ro ZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdo aWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhp cyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4g SWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29u Y2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi4K ------=_Part_152505_615212062.1559135839195 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KZGl2LHAsdGQsc3BhbiB7d29yZC13cmFwOiBicmVhay13 b3JkO3dvcmQtYnJlYWs6IG5vcm1hbDt9Cgp0YWJsZSB7Ym9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0 ZTsgYm9yZGVyOiAwO2JvcmRlci1zcGFjaW5nOiAwO2JvcmRlci1jb2xvcjogd2hpdGU7IHdpZHRo OjEwMCUhaW1wb3J0YW50O3dpZHRoOjUyNXB4OyBtYXgtd2lkdGg6MTAwJSFpbXBvcnRhbnQ7IG1p bi13aWR0aDogMjc5cHghaW1wb3J0YW50O30KdHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEg e2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGlu ZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHlsZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9 IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRyPgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9w OjVweDsiPgogICAgICAgIDx0YWJsZSBzdHlsZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVw eCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJCQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgog ICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1p bHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgogICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8 L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQt c2l6ZTogMTVweDtmb250LWZhbWlseTogQXJpYWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDox MHB4OyI+CiAgICAgICAgICAgICAgICBDT1JFIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8g am9pbiB0aGlzIFdlYmV4IG1lZXRpbmcuCiAgICAgICAgICAgICAgICAJICAgICAgICAgICA8L3Rk PgogICAgICA8L3RyPgo8L3RhYmxlPgoKCgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDog MjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJ CQkJCQk8dGFibGUgIHdpZHRoPSIxMDAlIj4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9 ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjojNEQ0RDREIj4KCQkJCQkJCQkJPGI+VmlydHVhbCBJbnRl cmltPC9iPgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJn aW46MHB4Ij4KCQkJCQkJCQk8dGQ+T2NjdXJzIGV2ZXJ5IDIgd2VlayhzKSBvbiBXZWRuZXNkYXkg ZWZmZWN0aXZlIFdlZG5lc2RheSwgMjkuIE1heSAyMDE5IHVudGlsIFdlZG5lc2RheSwgMTMuIE5v dmVtYmVyIDIwMTkgZnJvbSAxNzowMCB0byAxODozMCwgKFVUQyswMDowMCkgTW9ucm92aWEsIFJl eWtqYXZpawoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJn aW46MHB4Ij4KCQkJCQkJCQk8dGQ+MTc6MDAmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7R3JlZW53 aWNoIFRpbWUgKFJleWtqYXZpaywgR01UKSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsxIGhyIDMw IG1pbnMKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCgkJCQkJCTx0 YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRy PgoJCQkJCQkJCTx0ZD4KCQkJCQkJCQkJTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQ4 IDYzNiA2MDkKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCQkJCQkJ CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgoJ CQkJCQkJPHRyPgoJCQkJCQkJCTx0ZD5NZWV0aW5nIHBhc3N3b3JkOiBjb25zdHJhaW5lZDwvdGQ+ CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoKCgo8YnI+PEZPTlQgc2l6ZT0iMiIgQ09MT1I9 IiNGRjAwMDAiPjwvRk9OVD48YnI+CgoJCgoJCQk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdo dDogMjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+ CgkJCTx0YWJsZSBzdHlsZT0nd2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDsnPjx0cj48 dGQgc3R5bGU9J3dpZHRoOmF1dG8haW1wb3J0YW50OyAnPjx0YWJsZSBib3JkZXI9JzAnIGNlbGxw YWRkaW5nPScwJyBjZWxsc3BhY2luZz0nMCcgc3R5bGU9J3dpZHRoOmF1dG87d2lkdGg6YXV0byFp bXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojMDQ4Y2JmOyBib3JkZXI6MnB4IHNvbGlkICMwNDhj YmY7bWluLXdpZHRoOiAxODZweCFpbXBvcnRhbnQ7Jz48dHI+PHRkIGFsaWduPSdjZW50ZXInIHN0 eWxlPSdwYWRkaW5nOjE0cHggMjBweCAxNHB4IDIwcHg7Jz48YSBocmVmPSdodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMTExMTI4MDM4ODMwOTRjOGRmMzVmMjNkODNiNmM4 NDgnIHN0eWxlPSdjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9u Om5vbmU7Jz5BZGQgdG8gQ2FsZW5kYXI8L2E+IDwvdGQ+PC90cj48L3RhYmxlPjwvdGQ+PHRkIHN0 eWxlPSd3aWR0aDphdXRvIWltcG9ydGFudDsnPjx0YWJsZSBib3JkZXI9JzAnIGNlbGxwYWRkaW5n PScwJyBjZWxsc3BhY2luZz0nMCcgc3R5bGU9J3dpZHRoOmF1dG87d2lkdGg6YXV0byFpbXBvcnRh bnQ7bWluLXdpZHRoOjE4NnB4IWltcG9ydGFudDsnPjx0cj48dGQgc3R5bGU9J3BhZGRpbmctbGVm dDoxNnB4Oyc+V2hlbiBpdCdzIHRpbWUsIDxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9qLnBocD9NVElEPW0yNWNiM2M2NjM1YzM2NWNlN2I4ZDdlMjMxMTUyZTZlZiIgc3R5bGU9 ImNvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29yYXRpb246bm9uZTsiPmpvaW4gdGhlIG1lZXRpbmc8 L2E+LjwvdGQ+PC90cj48L3RhYmxlPjwvdGQ+PC90cj48L3RhYmxlPgoJCQk8dGFibGU+PHRyIHN0 eWxlPSJsaW5lLWhlaWdodDogMjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+CgoKCQoKCTx0YWJsZT48dGJvZHk+PHRyPjx0ZCBzdHlsZT0iZm9udC1z aXplOjE2cHgiPjxiPkpvaW4gYnkgcGhvbmU8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2lu OjBweCI+PHRkPjxiPjxhIGhyZWY9J3RlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0ODYzNjYw OSUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBBRkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7 Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8 L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PC90ZD48L3RyPjwvdGJvZHk+PC90 YWJsZT4KCjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJo ZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+Cjx0YWJsZT4KICAgIDx0cj4KICAg ICAgIDx0ZCBzdHlsZT0iZm9udC1zaXplOiAxM3B4O2ZvbnQtZmFtaWx5OiBBcmlhbDtjb2xvcjog IzY2NjY2NjsiPgoJICAgICAgICA8YSBocmVmPSJodHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNp c2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NSIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25l O2ZvbnQtc2l6ZToxM3B4O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMwMEFGRjk7Zm9udC1jb2xv cjojMDBBRkY5OyI+CgkgICAgICAgIAlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPwoJICAgICAgICA8 L2E+CgkJPC90ZD4KICAgIDwvdHI+CjwvdGFibGU+Cjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVp Z2h0OiAxMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MTBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFi bGU+CgkJCQkJCTx0YWJsZT4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6 ZToxMnB4O2NvbG9yOiAjQTBBMEEwOyI+CgkJCQkJCQkJCUlNUE9SVEFOVCBOT1RJQ0U6IFBsZWFz ZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5m b3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1h eSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNz aW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91 IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMg d2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L3RkPgoJCQkJCQkJPC90 cj4KCQkJCQkJPC90YWJsZT4KCQkJCTwvdGQ+CgkJCTwvdHI+CgkJPC90YWJsZT4KCTwvdGQ+CiAg IDwvdHI+CjwvdGFibGU+Cg== ------=_Part_152505_615212062.1559135839195-- ------=_Part_152504_567075164.1559135839195 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL1JleWtqYXZpaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96 b25laW5mby9BdGxhbnRpYy9SZXlramF2aWsNClgtTElDLUxPQ0FUSU9OOkF0bGFudGljL1JleWtq YXZpaw0KQkVHSU46U1RBTkRBUkQNClRaT0ZGU0VURlJPTTotMDEyOA0KVFpPRkZTRVRUTzotMDEw MA0KVFpOQU1FOi0wMQ0KRFRTVEFSVDoxOTA4MDEwMVQwMDAwMDANClJEQVRFOjE5MDgwMTAxVDAw MDAwMA0KRU5EOlNUQU5EQVJEDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wMTAwDQpU Wk9GRlNFVFRPOiswMDAwDQpUWk5BTUU6KzAwDQpEVFNUQVJUOjE5MTcwMjE5VDIzMDAwMA0KUkRB VEU6MTkxNzAyMTlUMjMwMDAwDQpSREFURToxOTE4MDIxOVQyMzAwMDANClJEQVRFOjE5MTkwMjE5 VDIzMDAwMA0KUkRBVEU6MTkyMTAzMTlUMjMwMDAwDQpSREFURToxOTM5MDQyOVQyMzAwMDANClJE QVRFOjE5NDAwMjI1VDAyMDAwMA0KUkRBVEU6MTk0MTAzMDJUMDEwMDAwDQpSREFURToxOTQyMDMw OFQwMTAwMDANClJEQVRFOjE5NDMwMzA3VDAxMDAwMA0KUkRBVEU6MTk0NDAzMDVUMDEwMDAwDQpS REFURToxOTQ1MDMwNFQwMTAwMDANClJEQVRFOjE5NDYwMzAzVDAxMDAwMA0KUkRBVEU6MTk0NzA0 MDZUMDEwMDAwDQpSREFURToxOTQ4MDQwNFQwMTAwMDANClJEQVRFOjE5NDkwNDAzVDAxMDAwMA0K UkRBVEU6MTk1MDA0MDJUMDEwMDAwDQpSREFURToxOTUxMDQwMVQwMTAwMDANClJEQVRFOjE5NTIw NDA2VDAxMDAwMA0KUkRBVEU6MTk1MzA0MDVUMDEwMDAwDQpSREFURToxOTU0MDQwNFQwMTAwMDAN ClJEQVRFOjE5NTUwNDAzVDAxMDAwMA0KUkRBVEU6MTk1NjA0MDFUMDEwMDAwDQpSREFURToxOTU3 MDQwN1QwMTAwMDANClJEQVRFOjE5NTgwNDA2VDAxMDAwMA0KUkRBVEU6MTk1OTA0MDVUMDEwMDAw DQpSREFURToxOTYwMDQwM1QwMTAwMDANClJEQVRFOjE5NjEwNDAyVDAxMDAwMA0KUkRBVEU6MTk2 MjA0MDFUMDEwMDAwDQpSREFURToxOTYzMDQwN1QwMTAwMDANClJEQVRFOjE5NjQwNDA1VDAxMDAw MA0KUkRBVEU6MTk2NTA0MDRUMDEwMDAwDQpSREFURToxOTY2MDQwM1QwMTAwMDANClJEQVRFOjE5 NjcwNDAyVDAxMDAwMA0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRGUk9N OiswMDAwDQpUWk9GRlNFVFRPOi0wMTAwDQpUWk5BTUU6LTAxDQpEVFNUQVJUOjE5MTcxMDIxVDAx MDAwMA0KUkRBVEU6MTkxNzEwMjFUMDEwMDAwDQpSREFURToxOTE4MTExNlQwMTAwMDANClJEQVRF OjE5MTkxMTE2VDAxMDAwMA0KUkRBVEU6MTkyMTA2MjNUMDEwMDAwDQpSREFURToxOTM5MTAyOVQw MjAwMDANClJEQVRFOjE5NDAxMTAzVDAyMDAwMA0KUkRBVEU6MTk0MTExMDJUMDIwMDAwDQpSREFU RToxOTQyMTAyNVQwMjAwMDANClJEQVRFOjE5NDMxMDI0VDAyMDAwMA0KUkRBVEU6MTk0NDEwMjJU MDIwMDAwDQpSREFURToxOTQ1MTAyOFQwMjAwMDANClJEQVRFOjE5NDYxMDI3VDAyMDAwMA0KUkRB VEU6MTk0NzEwMjZUMDIwMDAwDQpSREFURToxOTQ4MTAyNFQwMjAwMDANClJEQVRFOjE5NDkxMDMw VDAyMDAwMA0KUkRBVEU6MTk1MDEwMjJUMDIwMDAwDQpSREFURToxOTUxMTAyOFQwMjAwMDANClJE QVRFOjE5NTIxMDI2VDAyMDAwMA0KUkRBVEU6MTk1MzEwMjVUMDIwMDAwDQpSREFURToxOTU0MTAy NFQwMjAwMDANClJEQVRFOjE5NTUxMDIzVDAyMDAwMA0KUkRBVEU6MTk1NjEwMjhUMDIwMDAwDQpS REFURToxOTU3MTAyN1QwMjAwMDANClJEQVRFOjE5NTgxMDI2VDAyMDAwMA0KUkRBVEU6MTk1OTEw MjVUMDIwMDAwDQpSREFURToxOTYwMTAyM1QwMjAwMDANClJEQVRFOjE5NjExMDIyVDAyMDAwMA0K UkRBVEU6MTk2MjEwMjhUMDIwMDAwDQpSREFURToxOTYzMTAyN1QwMjAwMDANClJEQVRFOjE5NjQx MDI1VDAyMDAwMA0KUkRBVEU6MTk2NTEwMjRUMDIwMDAwDQpSREFURToxOTY2MTAyM1QwMjAwMDAN ClJEQVRFOjE5NjcxMDI5VDAyMDAwMA0KRU5EOlNUQU5EQVJEDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wMTAwDQpUWk9GRlNFVFRPOiswMDAwDQpUWk5BTUU6R01UDQpEVFNUQVJUOjE5 NjgwNDA3VDAxMDAwMA0KUkRBVEU6MTk2ODA0MDdUMDEwMDAwDQpFTkQ6U1RBTkRBUkQNCkVORDpW VElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KRFRTVEFNUDoyMDE5MDUyOVQxMzE3MTlaDQpBVFRFTkRF RTtDTj0iIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOmNvcmVAaWV0Zi5v cmcNCk9SR0FOSVpFUjtDTj0iQ09SRSBXb3JraW5nIEdyb3VwIjpNQUlMVE86Y29yZS1jaGFpcnNA aWV0Zi5vcmcNCkRUU1RBUlQ7VFpJRD1BdGxhbnRpYy9SZXlramF2aWs6MjAxOTA1MjlUMTcwMDAw DQpEVEVORDtUWklEPUF0bGFudGljL1JleWtqYXZpazoyMDE5MDUyOVQxODMwMDANCkxPQ0FUSU9O Omh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zg0KVFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU1 OTEzNTgzOQ0KVUlEOmYyNjM5OGJjLTg4YzctNGJiZS04MTY3LTIxYmVhMjY1MDc3NA0KREVTQ1JJ UFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9qLnBocD9NVElEPW0yNWNiM2M2NjM1YzM2NWNlN2I4ZDdlMjMxMTUyZTZlZlxuTWVldGlu ZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQ4IDYzNiA2MDlcbk1lZXRpbmcgcGFzc3dvcmQ6IGNv bnN0cmFpbmVkXG5cblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUgcGhvbmVzIG9u bHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDg2 MzY2MDklMjMlMjMqMDEqXG5cblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczov L2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklN UE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93 cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8g YmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIu IEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1 Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBk aXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vz c2lvbi5cbg0KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFD RT0iQVJJQUwiPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+XG4JCTxhIGhyZWY9Imh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0yNWNiM2M2NjM1YzM2NWNlN2I4 ZDdlMjMxMTUyZTZlZiI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFs Ij5Kb2luIFdlYmV4IG1lZXRpbmc8L0ZPTlQ+PC9hPlxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJ CQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDggNjM2IDYwOTwvRk9OVD5cbgkJCQkJ PC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJCVxuCQkJPHRhYmxlPjx0cj48dGQ+PEZP TlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3Jk OjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj5jb25zdHJhaW5lZDwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT5cbgkJPC9GT05UPlxuPGJy PjxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIj48L0ZPTlQ+PGJyPlxuPEZPTlQgU0laRT0i MSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPlxuXG5cbiZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBT SVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIx LTY1MC00NzktMzIwOCwsKjAxKjY0ODYzNjYwOSUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBB RkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwt aW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0i MiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJS PlxuXG5cblxuCSZuYnNwOzxCUj5cbgk8YSBocmVmPSJodHRwczovL2NvbGxhYm9yYXRpb25oZWxw LmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NSI+XG4JPEZPTlQgU0laRT0iMSIgQ09MT1I9 IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5DYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD48L2E+ XG4JJm5ic3A7PEJSPiZuYnNwOzxCUj5cblxuPEZPTlQgQ09MT1I9IiNBMEEwQTAiIHNpemU9IjEi IEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2Vi ZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5n IHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGlu IGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2Fs bHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBi ZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8g bm90IGpvaW4gdGhlIHNlc3Npb24uPC9GT05UPlxuPC9GT05UPlxuDQpTVU1NQVJZOlZpcnR1YWwg SW50ZXJpbQ0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpSUlVMRTpGUkVRPVdFRUtMWTtXS1NU PVNVO1VOVElMPTIwMTkxMTEzO0lOVEVSVkFMPTI7QllEQVk9V0UNCkJFR0lOOlZBTEFSTQ0KVFJJ R0dFUjotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJlbWluZGVyDQpFTkQ6VkFM QVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= ------=_Part_152504_567075164.1559135839195-- From nobody Wed May 29 06:56:53 2019 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 A5959120120 for ; Wed, 29 May 2019 06:56:50 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 vfhYb2JbE4Ve for ; Wed, 29 May 2019 06:56:48 -0700 (PDT) Received: from sjmda11.webex.com (sjmda11.webex.com [64.68.124.128]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A903912010C for ; Wed, 29 May 2019 06:56:48 -0700 (PDT) Received: from rva2rmd101.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda11.webex.com (Postfix) with ESMTP id 24B1F300005F for ; Wed, 29 May 2019 13:56:48 +0000 (GMT) Received: from rva2rmd101.webex.com (localhost [127.0.0.1]) by rva2rmd101.webex.com (Postfix) with ESMTP id D3CD4C058C for ; Wed, 29 May 2019 13:56:47 +0000 (GMT) Date: Wed, 29 May 2019 13:56:47 +0000 (GMT) From: CORE Working Group Reply-To: core-chairs@ietf.org To: core@ietf.org Message-ID: <880105127.785171559138207866.JavaMail.nobody@rva2rmd101.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_157031_2067056334.1559138207866" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=129422503524183502, X-WBX-TID=2fg69556dpwbfmy65jyr9ekehmj6ghirynm09kk084fzvc2utcprk7cp, X-WBX-RID=f4266d18f4434878b4683aa3c492c54f, X-WBX-SVC:Meeting Center, X-WBX-TT:Updated Meeting Invitation, Date:Wed May 29 13:56:47 GMT 2019 reminder-3.32.0-2232 Archived-At: Subject: [core] Webex meeting changed: Virtual Interim 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, 29 May 2019 13:56:51 -0000 ------=_Part_157031_2067056334.1559138207866 Content-Type: multipart/Alternative; boundary="----=_Part_157032_946608289.1559138207866" ------=_Part_157032_946608289.1559138207866 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKQ09SRSBXb3JraW5nIEdyb3VwIGNoYW5nZWQgdGhlIFdlYmV4IG1lZXRpbmcgaW5m b3JtYXRpb24uCgoKVmlydHVhbCBJbnRlcmltCk9jY3VycyBldmVyeSAyIHdlZWsocykgb24gV2Vk bmVzZGF5IGVmZmVjdGl2ZSBXZWRuZXNkYXksIDI5LiBNYXkgMjAxOSB1bnRpbCBXZWRuZXNkYXks IDEzLiBOb3ZlbWJlciAyMDE5IGZyb20gMTU6MDAgdG8gMTY6MzAsIChVVEMrMDA6MDApIE1vbnJv dmlhLCBSZXlramF2aWsKMTU6MDAgIHwgIEdyZWVud2ljaCBUaW1lIChSZXlramF2aWssIEdNVCkg IHwgIDEgaHIgMzAgbWlucwpNZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDggNjM2IDYw OSAKTWVldGluZyBwYXNzd29yZDogY29uc3RyYWluZWQKCgoKQWRkIHRvIENhbGVuZGFyCmh0dHBz Oi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW01MzBiMDJiZDcwOWY0OTcwNGMwYzcw ZjVlM2IwZWVjZg0KDQpXaGVuIGl0J3MgdGltZSwgam9pbiB0aGUgbWVldGluZy4KaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTI1Y2IzYzY2MzVjMzY1Y2U3YjhkN2UyMzEx NTJlNmVmCgoNCkpPSU4gQlkgUEhPTkUNCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSkKVGFwIGhlcmUgdG8gY2FsbCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0 cyBub3Qgc3VwcG9ydGVkKTogdGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQ4NjM2NjA5JTIz JTIzKjAxKgoNCg0KCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/Cmh0dHBzOi8vY29sbGFib3JhdGlv bmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1CgoKSU1QT1JUQU5UIE5PVElDRTog UGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhl ciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hp Y2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlz IHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJ ZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25j ZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLgo= ------=_Part_157032_946608289.1559138207866 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KZGl2LHAsdGQsc3BhbiB7d29yZC13cmFwOiBicmVhay13 b3JkO3dvcmQtYnJlYWs6IG5vcm1hbDt9Cgp0YWJsZSB7Ym9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0 ZTsgYm9yZGVyOiAwO2JvcmRlci1zcGFjaW5nOiAwO2JvcmRlci1jb2xvcjogd2hpdGU7IHdpZHRo OjEwMCUhaW1wb3J0YW50O3dpZHRoOjUyNXB4OyBtYXgtd2lkdGg6MTAwJSFpbXBvcnRhbnQ7IG1p bi13aWR0aDogMjc5cHghaW1wb3J0YW50O30KdHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEg e2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGlu ZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHlsZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9 IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRyPgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9w OjVweDsiPgogICAgICAgIDx0YWJsZSBzdHlsZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVw eCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJCQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgog ICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1p bHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgogICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8 L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQt c2l6ZTogMTVweDtmb250LWZhbWlseTogQXJpYWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDox MHB4OyI+CiAgICAgICAgICAgICAgICBDT1JFIFdvcmtpbmcgR3JvdXAgY2hhbmdlZCB0aGUgV2Vi ZXggbWVldGluZyBpbmZvcm1hdGlvbi4KICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+ CiAgICAgIDwvdHI+CjwvdGFibGU+CgoKCjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJ CQkJCTx0YWJsZSAgd2lkdGg9IjEwMCUiPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0i Zm9udC1zaXplOjE2cHg7IGNvbG9yOiM0RDRENEQiPgoJCQkJCQkJCQk8Yj5WaXJ0dWFsIEludGVy aW08L2I+CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdp bjowcHgiPgoJCQkJCQkJCTx0ZD5PY2N1cnMgZXZlcnkgMiB3ZWVrKHMpIG9uIFdlZG5lc2RheSBl ZmZlY3RpdmUgV2VkbmVzZGF5LCAyOS4gTWF5IDIwMTkgdW50aWwgV2VkbmVzZGF5LCAxMy4gTm92 ZW1iZXIgMjAxOSBmcm9tIDE1OjAwIHRvIDE2OjMwLCAoVVRDKzAwOjAwKSBNb25yb3ZpYSwgUmV5 a2phdmlrCgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdp bjowcHgiPgoJCQkJCQkJCTx0ZD4xNTowMCZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDtHcmVlbndp Y2ggVGltZSAoUmV5a2phdmlrLCBHTVQpJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzEgaHIgMzAg bWlucwoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoKCQkJCQkJPHRh YmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJCQkJCQk8dHI+ CgkJCQkJCQkJPHRkPgoJCQkJCQkJCQlNZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDgg NjM2IDYwOQoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJCQkK CQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFudCI+CgkJ CQkJCQk8dHI+CgkJCQkJCQkJPHRkPk1lZXRpbmcgcGFzc3dvcmQ6IGNvbnN0cmFpbmVkPC90ZD4K CQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFibGU+CgoKCjxicj48Rk9OVCBzaXplPSIyIiBDT0xPUj0i I0ZGMDAwMCI+PC9GT05UPjxicj4KCgkKCgkJCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0 OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4K CQkJPHRhYmxlIHN0eWxlPSd3aWR0aDphdXRvO3dpZHRoOmF1dG8haW1wb3J0YW50Oyc+PHRyPjx0 ZCBzdHlsZT0nd2lkdGg6YXV0byFpbXBvcnRhbnQ7ICc+PHRhYmxlIGJvcmRlcj0nMCcgY2VsbHBh ZGRpbmc9JzAnIGNlbGxzcGFjaW5nPScwJyBzdHlsZT0nd2lkdGg6YXV0bzt3aWR0aDphdXRvIWlt cG9ydGFudDtiYWNrZ3JvdW5kLWNvbG9yOiMwNDhjYmY7IGJvcmRlcjoycHggc29saWQgIzA0OGNi ZjttaW4td2lkdGg6IDE4NnB4IWltcG9ydGFudDsnPjx0cj48dGQgYWxpZ249J2NlbnRlcicgc3R5 bGU9J3BhZGRpbmc6MTRweCAyMHB4IDE0cHggMjBweDsnPjxhIGhyZWY9J2h0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW01MzBiMDJiZDcwOWY0OTcwNGMwYzcwZjVlM2IwZWVj Zicgc3R5bGU9J2NvbG9yOiNGRkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRpb246 bm9uZTsnPkFkZCB0byBDYWxlbmRhcjwvYT4gPC90ZD48L3RyPjwvdGFibGU+PC90ZD48dGQgc3R5 bGU9J3dpZHRoOmF1dG8haW1wb3J0YW50Oyc+PHRhYmxlIGJvcmRlcj0nMCcgY2VsbHBhZGRpbmc9 JzAnIGNlbGxzcGFjaW5nPScwJyBzdHlsZT0nd2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFu dDttaW4td2lkdGg6MTg2cHghaW1wb3J0YW50Oyc+PHRyPjx0ZCBzdHlsZT0ncGFkZGluZy1sZWZ0 OjE2cHg7Jz5XaGVuIGl0J3MgdGltZSwgPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bTI1Y2IzYzY2MzVjMzY1Y2U3YjhkN2UyMzExNTJlNmVmIiBzdHlsZT0i Y29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3JhdGlvbjpub25lOyI+am9pbiB0aGUgbWVldGluZzwv YT4uPC90ZD48L3RyPjwvdGFibGU+PC90ZD48L3RyPjwvdGFibGU+CgkJCTx0YWJsZT48dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+PC90YWJsZT4KCgoJCgoJPHRhYmxlPjx0Ym9keT48dHI+PHRkIHN0eWxlPSJmb250LXNp emU6MTZweCI+PGI+Sm9pbiBieSBwaG9uZTwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46 MHB4Ij48dGQ+PGI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQ4NjM2NjA5 JTIzJTIzKjAxKicgc3R5bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29yYXRpb246bm9uZTsn PjEtNjUwLTQ3OS0zMjA4PC9hPjwvYj4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwv dGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48L3RkPjwvdHI+PC90Ym9keT48L3Rh YmxlPgoKPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9Imhl aWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPgogICAgPHRyPgogICAg ICAgPHRkIHN0eWxlPSJmb250LXNpemU6IDEzcHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiAj NjY2NjY2OyI+CgkgICAgICAgIDxhIGhyZWY9Imh0dHBzOi8vY29sbGFib3JhdGlvbmhlbHAuY2lz Y28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1IiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7 Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzAwQUZGOTtmb250LWNvbG9y OiMwMEFGRjk7Ij4KCSAgICAgICAgCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/CgkgICAgICAgIDwv YT4KCQk8L3RkPgogICAgPC90cj4KPC90YWJsZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWln aHQ6IDEwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoxMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJs ZT4KCQkJCQkJPHRhYmxlPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXpl OjEycHg7Y29sb3I6ICNBMEEwQTA7Ij4KCQkJCQkJCQkJSU1QT1JUQU5UIE5PVElDRTogUGxlYXNl IG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZv cm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5 IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Np b24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3Ug ZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3 aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLjwvdGQ+CgkJCQkJCQk8L3Ry PgoJCQkJCQk8L3RhYmxlPgoJCQkJPC90ZD4KCQkJPC90cj4KCQk8L3RhYmxlPgoJPC90ZD4KICAg PC90cj4KPC90YWJsZT4K ------=_Part_157032_946608289.1559138207866-- ------=_Part_157031_2067056334.1559138207866 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkF0bGFudGljL1JleWtqYXZpaw0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96 b25laW5mby9BdGxhbnRpYy9SZXlramF2aWsNClgtTElDLUxPQ0FUSU9OOkF0bGFudGljL1JleWtq YXZpaw0KQkVHSU46U1RBTkRBUkQNClRaT0ZGU0VURlJPTTotMDEyOA0KVFpPRkZTRVRUTzotMDEw MA0KVFpOQU1FOi0wMQ0KRFRTVEFSVDoxOTA4MDEwMVQwMDAwMDANClJEQVRFOjE5MDgwMTAxVDAw MDAwMA0KRU5EOlNUQU5EQVJEDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wMTAwDQpU Wk9GRlNFVFRPOiswMDAwDQpUWk5BTUU6KzAwDQpEVFNUQVJUOjE5MTcwMjE5VDIzMDAwMA0KUkRB VEU6MTkxNzAyMTlUMjMwMDAwDQpSREFURToxOTE4MDIxOVQyMzAwMDANClJEQVRFOjE5MTkwMjE5 VDIzMDAwMA0KUkRBVEU6MTkyMTAzMTlUMjMwMDAwDQpSREFURToxOTM5MDQyOVQyMzAwMDANClJE QVRFOjE5NDAwMjI1VDAyMDAwMA0KUkRBVEU6MTk0MTAzMDJUMDEwMDAwDQpSREFURToxOTQyMDMw OFQwMTAwMDANClJEQVRFOjE5NDMwMzA3VDAxMDAwMA0KUkRBVEU6MTk0NDAzMDVUMDEwMDAwDQpS REFURToxOTQ1MDMwNFQwMTAwMDANClJEQVRFOjE5NDYwMzAzVDAxMDAwMA0KUkRBVEU6MTk0NzA0 MDZUMDEwMDAwDQpSREFURToxOTQ4MDQwNFQwMTAwMDANClJEQVRFOjE5NDkwNDAzVDAxMDAwMA0K UkRBVEU6MTk1MDA0MDJUMDEwMDAwDQpSREFURToxOTUxMDQwMVQwMTAwMDANClJEQVRFOjE5NTIw NDA2VDAxMDAwMA0KUkRBVEU6MTk1MzA0MDVUMDEwMDAwDQpSREFURToxOTU0MDQwNFQwMTAwMDAN ClJEQVRFOjE5NTUwNDAzVDAxMDAwMA0KUkRBVEU6MTk1NjA0MDFUMDEwMDAwDQpSREFURToxOTU3 MDQwN1QwMTAwMDANClJEQVRFOjE5NTgwNDA2VDAxMDAwMA0KUkRBVEU6MTk1OTA0MDVUMDEwMDAw DQpSREFURToxOTYwMDQwM1QwMTAwMDANClJEQVRFOjE5NjEwNDAyVDAxMDAwMA0KUkRBVEU6MTk2 MjA0MDFUMDEwMDAwDQpSREFURToxOTYzMDQwN1QwMTAwMDANClJEQVRFOjE5NjQwNDA1VDAxMDAw MA0KUkRBVEU6MTk2NTA0MDRUMDEwMDAwDQpSREFURToxOTY2MDQwM1QwMTAwMDANClJEQVRFOjE5 NjcwNDAyVDAxMDAwMA0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpPRkZTRVRGUk9N OiswMDAwDQpUWk9GRlNFVFRPOi0wMTAwDQpUWk5BTUU6LTAxDQpEVFNUQVJUOjE5MTcxMDIxVDAx MDAwMA0KUkRBVEU6MTkxNzEwMjFUMDEwMDAwDQpSREFURToxOTE4MTExNlQwMTAwMDANClJEQVRF OjE5MTkxMTE2VDAxMDAwMA0KUkRBVEU6MTkyMTA2MjNUMDEwMDAwDQpSREFURToxOTM5MTAyOVQw MjAwMDANClJEQVRFOjE5NDAxMTAzVDAyMDAwMA0KUkRBVEU6MTk0MTExMDJUMDIwMDAwDQpSREFU RToxOTQyMTAyNVQwMjAwMDANClJEQVRFOjE5NDMxMDI0VDAyMDAwMA0KUkRBVEU6MTk0NDEwMjJU MDIwMDAwDQpSREFURToxOTQ1MTAyOFQwMjAwMDANClJEQVRFOjE5NDYxMDI3VDAyMDAwMA0KUkRB VEU6MTk0NzEwMjZUMDIwMDAwDQpSREFURToxOTQ4MTAyNFQwMjAwMDANClJEQVRFOjE5NDkxMDMw VDAyMDAwMA0KUkRBVEU6MTk1MDEwMjJUMDIwMDAwDQpSREFURToxOTUxMTAyOFQwMjAwMDANClJE QVRFOjE5NTIxMDI2VDAyMDAwMA0KUkRBVEU6MTk1MzEwMjVUMDIwMDAwDQpSREFURToxOTU0MTAy NFQwMjAwMDANClJEQVRFOjE5NTUxMDIzVDAyMDAwMA0KUkRBVEU6MTk1NjEwMjhUMDIwMDAwDQpS REFURToxOTU3MTAyN1QwMjAwMDANClJEQVRFOjE5NTgxMDI2VDAyMDAwMA0KUkRBVEU6MTk1OTEw MjVUMDIwMDAwDQpSREFURToxOTYwMTAyM1QwMjAwMDANClJEQVRFOjE5NjExMDIyVDAyMDAwMA0K UkRBVEU6MTk2MjEwMjhUMDIwMDAwDQpSREFURToxOTYzMTAyN1QwMjAwMDANClJEQVRFOjE5NjQx MDI1VDAyMDAwMA0KUkRBVEU6MTk2NTEwMjRUMDIwMDAwDQpSREFURToxOTY2MTAyM1QwMjAwMDAN ClJEQVRFOjE5NjcxMDI5VDAyMDAwMA0KRU5EOlNUQU5EQVJEDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wMTAwDQpUWk9GRlNFVFRPOiswMDAwDQpUWk5BTUU6R01UDQpEVFNUQVJUOjE5 NjgwNDA3VDAxMDAwMA0KUkRBVEU6MTk2ODA0MDdUMDEwMDAwDQpFTkQ6U1RBTkRBUkQNCkVORDpW VElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KRFRTVEFNUDoyMDE5MDUyOVQxMzU2NDdaDQpBVFRFTkRF RTtDTj0iIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOmNvcmVAaWV0Zi5v cmcNCk9SR0FOSVpFUjtDTj0iQ09SRSBXb3JraW5nIEdyb3VwIjpNQUlMVE86Y29yZS1jaGFpcnNA aWV0Zi5vcmcNCkRUU1RBUlQ7VFpJRD1BdGxhbnRpYy9SZXlramF2aWs6MjAxOTA1MjlUMTUwMDAw DQpEVEVORDtUWklEPUF0bGFudGljL1JleWtqYXZpazoyMDE5MDUyOVQxNjMwMDANCkxPQ0FUSU9O Omh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zg0KVFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MTU1 OTEzODIwNw0KVUlEOmYyNjM5OGJjLTg4YzctNGJiZS04MTY3LTIxYmVhMjY1MDc3NA0KREVTQ1JJ UFRJT046XG5cblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9qLnBocD9NVElEPW0yNWNiM2M2NjM1YzM2NWNlN2I4ZDdlMjMxMTUyZTZlZlxuTWVldGlu ZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQ4IDYzNiA2MDlcbk1lZXRpbmcgcGFzc3dvcmQ6IGNv bnN0cmFpbmVkXG5cblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpXG5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUgcGhvbmVzIG9u bHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDg2 MzY2MDklMjMlMjMqMDEqXG5cblxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/XG5odHRwczov L2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NVxuXG5cbklN UE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93 cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8g YmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIu IEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1 Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBk aXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vz c2lvbi5cbg0KWC1BTFQtREVTQztGTVRUWVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFD RT0iQVJJQUwiPlxuXG48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+XG4JCTxhIGhyZWY9Imh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0yNWNiM2M2NjM1YzM2NWNlN2I4 ZDdlMjMxMTUyZTZlZiI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFs Ij5Kb2luIFdlYmV4IG1lZXRpbmc8L0ZPTlQ+PC9hPlxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJ CQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFs Ij5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDggNjM2IDYwOTwvRk9OVD5cbgkJCQkJ PC90ZD5cbgkJCQk8L3RyPlxuCQkJPC90YWJsZT5cbgkJCVxuCQkJPHRhYmxlPjx0cj48dGQ+PEZP TlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3Jk OjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj5jb25zdHJhaW5lZDwvRk9OVD48L3RkPjwvdHI+PC90YWJsZT5cbgkJPC9GT05UPlxuPGJy PjxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIj48L0ZPTlQ+PGJyPlxuPEZPTlQgU0laRT0i MSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPlxuXG5cbiZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBT SVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxiPjxhIGhyZWY9J3RlbDolMkIx LTY1MC00NzktMzIwOCwsKjAxKjY0ODYzNjYwOSUyMyUyMyowMSonIHN0eWxlPSdjb2xvcjojMDBB RkY5OyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Jz4xLTY1MC00NzktMzIwODwvYT48L2I+IENhbGwt aW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0i MiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48L0ZPTlQ+Jm5ic3A7IDxCUj48QlI+PEJS PlxuXG5cblxuCSZuYnNwOzxCUj5cbgk8YSBocmVmPSJodHRwczovL2NvbGxhYm9yYXRpb25oZWxw LmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAyOTA1NSI+XG4JPEZPTlQgU0laRT0iMSIgQ09MT1I9 IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5DYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD48L2E+ XG4JJm5ic3A7PEJSPiZuYnNwOzxCUj5cblxuPEZPTlQgQ09MT1I9IiNBMEEwQTAiIHNpemU9IjEi IEZBQ0U9ImFyaWFsIj5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2Vi ZXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5n IHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGlu IGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2Fs bHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBi ZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8g bm90IGpvaW4gdGhlIHNlc3Npb24uPC9GT05UPlxuPC9GT05UPlxuDQpTVU1NQVJZOlZpcnR1YWwg SW50ZXJpbQ0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpSUlVMRTpGUkVRPVdFRUtMWTtXS1NU PVNVO1VOVElMPTIwMTkxMTEzO0lOVEVSVkFMPTI7QllEQVk9V0UNCkJFR0lOOlZBTEFSTQ0KVFJJ R0dFUjotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBUSU9OOlJlbWluZGVyDQpFTkQ6VkFM QVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= ------=_Part_157031_2067056334.1559138207866-- From nobody Wed May 29 07:32:46 2019 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 51EB312010C for ; Wed, 29 May 2019 07:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 3pxgnl_Aqh4Q for ; Wed, 29 May 2019 07:32:43 -0700 (PDT) Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1994312004E for ; Wed, 29 May 2019 07:32:43 -0700 (PDT) Received: from [192.168.217.119] (p54A6C998.dip0.t-ipconnect.de [84.166.201.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45DY8T4Xmbz106l; Wed, 29 May 2019 16:32:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann X-Priority: 3 In-Reply-To: <1575373672.762531559135839195.JavaMail.nobody@rva2rmd101.webex.com> Date: Wed, 29 May 2019 16:32:41 +0200 X-Mao-Original-Outgoing-Id: 580833159.065767-4f572acda8b9615592d853deefccc88a Content-Transfer-Encoding: quoted-printable Message-Id: References: <1575373672.762531559135839195.JavaMail.nobody@rva2rmd101.webex.com> To: core X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [core] Webex meeting invitation: Virtual Interim 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, 29 May 2019 14:32:44 -0000 On May 29, 2019, at 15:17, CORE Working Group = wrote: >=20 > Occurs every 2 week(s) on Wednesday effective Wednesday, 29. May 2019 = until Wednesday, 13. November 2019 from 17:00 to 18:30, (UTC+00:00) = Monrovia, Reykjavik As you can see, I put the original Webex scheduling into the wrong time = slot. You should all have received an updated Webex scheduling that is for the = right time slot, 1500Z (which is 1700 CEST). A while ago we had on interim that was mostly devoted to looking at the = state of the large number of documents related to the WG, and at the end = people surprisingly said that was a useful meeting. I plan to do this = again, today. We might pick up some morsels of technical content in the = process, too. So my short agenda proposal is: =E2=80=94 RFC 8613-to-be =F0=9F=8E=89=F0=9F=8E=B6=F0=9F=8D=BB=F0=9F=A4=BE=F0= =9F=8F=BB=E2=80=8D=E2=99=80=EF=B8=8F (OSCORE) =E2=80=94 lpwan: SCHC-COAP WGLC, Reviewers needed (including the OSCORE = part) =E2=80=94 CoRE Document status Gr=C3=BC=C3=9Fe, Carsten From nobody Wed May 29 08:05:50 2019 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 AA17A12015C for ; Wed, 29 May 2019 08:05: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 W-y6BDwGTNpq for ; Wed, 29 May 2019 08:05:45 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 72A63120156 for ; Wed, 29 May 2019 08:05:45 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id e7so705760pln.4 for ; Wed, 29 May 2019 08:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rgXuZiLkJD+9S0r/A3dS0ihW5cTEPOUfCQ3AXnlAhnQ=; b=CpaL/j8VLLO0MDEbXVFelnY/XvEbpsj9NbwRyctX8eJxdukubB/VrCfEJZyjmm0nuu BgeBSRNFBuhFe2IePfX2gwP2P3j2ZA9AyP2SjCGRa4VgELjry5gv/8Xj1YR7LVN4e8MI x3/TZHEz43bNrgTrNdNXHr7zVAMW0BUFIQ0jrnHUIuTljhUnB+Ur2hhgG7b+I6lok9OX 7UZv/HgPgB6vsXe0BaQsHeJKwjwznGO2MPQuG6cAgnKd6OSKoRz4u62GmQpQqFg4qu3Q syNGT6YEouOQRJelFGpAX7YdRuIygLAdQBOcDxPH6f/M7XavKTdG7IJ7Ui8IsuVqWln2 ohHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rgXuZiLkJD+9S0r/A3dS0ihW5cTEPOUfCQ3AXnlAhnQ=; b=rkmz5YoOV4T//Z5EtAN2v9Rn6bUtVPouC++8not4mhdB8tOXDoR1m9o+yzvF8EdQuX rpEjm4qWS0yhSX7MLZbS8Ee/2HYJawVyNoWilDQ/irC3j6lvg3oqdDog/SEyZ9kS+Rch b5ExHojwzWaqzMkgwhW+RI2kIdmhpUhXsLmSLxA9fhm5jUbWSdPQ3ddNUBvtEKcuSICF yPdoCUMrWI1SKVLe5N/r/F+kAm+EYLweRr2/k09ZPnnXw+MPhvsak0gt1aC7eNZ7a0Yb lQJ09bB+gG5lxqBJcoGOSZGclfkVMHakyYdpCkQLRJh2VDbKG/IxuzxBEFw3fcdkwiw8 jzSQ== X-Gm-Message-State: APjAAAWo8hcOkgeAHmswucA6eaJJDBwR4+J2MPEMEcZVMgmtkpREifkr uHjjEvLpZN2BmtXbPc33vzDbdA== X-Google-Smtp-Source: APXvYqxuVegSXcPDbZU/7iN6wy+D5NlBuGHUl9uIuzo+hZ1X8eIIaZMJF7KNz/JSd/+Csu1opPx5IQ== X-Received: by 2002:a17:902:4283:: with SMTP id h3mr120023167pld.214.1559142344737; Wed, 29 May 2019 08:05:44 -0700 (PDT) Received: from [10.20.12.34] ([12.217.162.130]) by smtp.gmail.com with ESMTPSA id a30sm12332117pje.4.2019.05.29.08.05.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 May 2019 08:05:44 -0700 (PDT) From: Ted Lemon Message-Id: <34EE8F1D-62E6-4C8C-B967-834BAF1FFFAF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F6D4C5FA-780B-4D0B-8B24-42ACA92D89AA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 29 May 2019 08:05:42 -0700 In-Reply-To: <0d20366a188573397f9e98e4f8adc8e2@bbhmail.nl> Cc: core@ietf.org, Stuart Cheshire To: consultancy@vanderstok.org References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com> <33B4FD70-E650-47E4-A603-BD4928E4C47F@fugue.com> <137192BD-7638-4D2E-A6E5-E1618499366F@fugue.com> <0d20366a188573397f9e98e4f8adc8e2@bbhmail.nl> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 29 May 2019 15:05:48 -0000 --Apple-Mail=_F6D4C5FA-780B-4D0B-8B24-42ACA92D89AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 29, 2019, at 12:49 AM, Peter van der Stok = wrote: > The 6LBR only needs to know the addresses of the neigbouring 6LR, = obtained with with one broadcast and n unicasts. A broadcast is a multicast that goes to every station. This is what I = mean. If the sometimes-on router finds nodes this way, then it can = send them the information they need to talk to the Core RD. If instead = the nodes are all configured with an address for the Core RD, this = limits flexibility to no good purpose. In this situation, if there is = no space in the initial announcement for a Core RD server IP address, = then defaulting to sending the Core RD messages to the router seems like = it would be the right behavior. Sending it to some other = pre-configured address sounds like a maintenance nightmare. --Apple-Mail=_F6D4C5FA-780B-4D0B-8B24-42ACA92D89AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = May 29, 2019, at 12:49 AM, Peter van der Stok <stokcons@bbhmail.nl>= wrote:
The 6LBR only needs to know the addresses of the neigbouring = 6LR, obtained with with one broadcast and n unicasts.

A broadcast is a multicast that goes to every = station.   This is what I mean.   If the sometimes-on router = finds nodes this way, then it can send them the information they need to = talk to the Core RD.   If instead the nodes are all configured with = an address for the Core RD, this limits flexibility to no good purpose. =  In this situation, if there is no space in the initial = announcement for a Core RD server IP address, then defaulting to sending = the Core RD messages to the router seems like it would be the right = behavior.   Sending it to some other pre-configured address sounds = like a maintenance nightmare.

= --Apple-Mail=_F6D4C5FA-780B-4D0B-8B24-42ACA92D89AA-- From nobody Wed May 29 08:23:23 2019 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 B45AC120154 for ; Wed, 29 May 2019 08:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.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 x8J_airZ732g for ; Wed, 29 May 2019 08:23:19 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0045.hostedemail.com [216.40.44.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C01F12015E for ; Wed, 29 May 2019 08:23:19 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 3D094182CED5B; Wed, 29 May 2019 15:23:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=ZpD3+iUeiwFuQfLfmX FQo6tcQ8mPao92gFQt+9gDt2s=; b=J92q2c31AsY5/7P65+/Zh5Py0Jzji12K8P U/9feYxEMwrDkBFrQvVJBLkAq7kvC6CJHKF2ycK2uVvqnsYmt0KgvifucFZFor3v /FUglkSo6YtEQBc6St/dFDQvJDaxLnjfo2IiTT4Fq6uDJdm6Zja8Y9Zgq2rEAsrs 5bni34kCY= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 10, 1, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:46:72:150:152:355:379:582:800:960:962:967:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1542:1575:1588:1589:1592:1594:1711:1730:1776:1792:2198:2199:2527:2528:2553:2557:2559:2562:2892:2914:3138:3139:3140:3141:3142:3352:3586:3769:3865:3866:3867:3868:3870:3871:3872:3874:4250:4321:5007:6117:6261:6298:6657:6678:7875:7903:7904:8603:9036:9177:10004:10400:10848:11232:11658:11914:11984:12043:12114:12555:12740:12895:12986:13139:13255:13439:14093:14096:14181:14721:21080:21324:21433:21451:21625:21740:21810:30003:30054:30075:30083:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:32, LUA_SUMMARY:none X-HE-Tag: roof46_39e35978be505 X-Filterd-Recvd-Size: 5442 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf06.hostedemail.com (Postfix) with ESMTPA; Wed, 29 May 2019 15:23:17 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a6c51f7e244d8e7b745ba3451a284ac5" Date: Wed, 29 May 2019 17:23:17 +0200 From: Peter van der Stok To: Ted Lemon Cc: consultancy@vanderstok.org, core@ietf.org, Stuart Cheshire Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <34EE8F1D-62E6-4C8C-B967-834BAF1FFFAF@fugue.com> References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com> <33B4FD70-E650-47E4-A603-BD4928E4C47F@fugue.com> <137192BD-7638-4D2E-A6E5-E1618499366F@fugue.com> <0d20366a188573397f9e98e4f8adc8e2@bbhmail.nl> <34EE8F1D-62E6-4C8C-B967-834BAF1FFFAF@fugue.com> Message-ID: X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [86.203.245.197] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 29 May 2019 15:23:22 -0000 --=_a6c51f7e244d8e7b745ba3451a284ac5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII >> Nodes want to use the RD before the 6LBR is connected. >> Another suggestion is then: >> >> In managed networks before connection to the border router, the temporary use of a preconfigured address is recommended. Ted Lemon schreef op 2019-05-29 17:05: > On May 29, 2019, at 12:49 AM, Peter van der Stok wrote: > >> The 6LBR only needs to know the addresses of the neigbouring 6LR, obtained with with one broadcast and n unicasts. > > A broadcast is a multicast that goes to every station. This is what I mean. If the sometimes-on router finds nodes this way, then it can send them the information they need to talk to the Core RD. If instead the nodes are all configured with an address for the Core RD, this limits flexibility to no good purpose. In this situation, if there is no space in the initial announcement for a Core RD server IP address, then defaulting to sending the Core RD messages to the router seems like it would be the right behavior. Sending it to some other pre-configured address sounds like a maintenance nightmare. --=_a6c51f7e244d8e7b745ba3451a284ac5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
Nodes want to use the RD before the 6LBR is connected.
Anot= her suggestion is then:

In managed networks before connection to= the border router, the temporary use of a preconfigured address is recomme= nded.

Ted Lemon schreef op 2019-05-29 17:05:

On May 29, 2019, at 12:49 AM, Peter van der Stok <stokcons@bbhmail.nl> wr= ote:
The 6LBR only needs to know the addresses of = the neigbouring 6LR, obtained with with one broadcast and n unicasts.

A broadcast is a multicast that goes to every station.   This is = what I mean.   If the sometimes-on router finds nodes this way, then i= t can send them the information they need to talk to the Core RD.   If= instead the nodes are all configured with an address for the Core RD, this= limits flexibility to no good purpose.  In this situation, if there i= s no space in the initial announcement for a Core RD server IP address, the= n defaulting to sending the Core RD messages to the router seems like it wo= uld be the right behavior.   Sending it to some other pre-configured a= ddress sounds like a maintenance nightmare.
 
--=_a6c51f7e244d8e7b745ba3451a284ac5-- From nobody Wed May 29 10:04:38 2019 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 AB40D12016B for ; Wed, 29 May 2019 10:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 Va6qVvfUCG1W for ; Wed, 29 May 2019 10:04:34 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7FB120155 for ; Wed, 29 May 2019 10:04:34 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id w34so235506pga.12 for ; Wed, 29 May 2019 10:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RiuBch/JU2rkYTkY8JHl6Fj7hlZEFfBftB8yJ6IbFIc=; b=z4UzI4upweMVPUtPfmXjwAPnl6It9Hyvb7JHIvwrOtirCC4aCEFyiS0Zur/sF+Vlrw k93GRe48Z69OVrSSETe3MGjSSlQ2EBSfqAIp/g/UD6kBlqyQDzUxtNRf1qVGbUBZAHmO I4qVYg6u8Le9a4nifW7mWrsopP4uKZHeqtVSqub8QeInLJfiwSyIqF2wE54vGa/maHON yxA3n9ZNPlOHGgXR+S9QhbrZ72DrQE+6JDzKCnyZOPqcBqAA2/PvwK8kUjurQm6YPgaJ H/InE+xBHmJ9ovrwYQ/if+ZHdGdehctpIV8sabsGUZHw4++n3vOI0NJD4ks0QtYzLUSg R3+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RiuBch/JU2rkYTkY8JHl6Fj7hlZEFfBftB8yJ6IbFIc=; b=I0PCVhw/YOqBLlavn2pIo4BFkiIAOw9/F5o8XosUFwwIESGLs2A8TXG57YCe73iuHL VUY/hyaF1L9OVg+6/12txbMe0L8K2nEtZgS9V3v71l4qIj5jtlmuG+lXcAl/XMBBR/PK /EVDUt/jr+epGML/Ls7LQItfJkNi8BRNjX5i6c7cWlQr87vpUraVGaERTLq+GZyFcbGD gunwP4xpFyriEUtTojb2q2r8bnjR/Lm94HTr6hxYpeFMzxY9lOFpeMu4c9YIcac4UzaN X5GDzjkXV2vIai4KueYx43ktegacp/42Ug39kc76o8GsRFYwaqIoDyV8OelDdlWbPGhq oFtg== X-Gm-Message-State: APjAAAWcdNQzr7Y0js8c5a6WjT5AAXlGA9XVaIk4ygv+E7MTI9TB83MT ZJYEY8inmSn4BSErMguoXIeltA== X-Google-Smtp-Source: APXvYqwTpHu3fOOhq4l3syDQEO+zbuqvnTusQv8ZCYELTCCNa0PW/8FAfcrbVuAIv77Ezarq4JyG7w== X-Received: by 2002:a17:90a:26af:: with SMTP id m44mr5589635pje.57.1559149473535; Wed, 29 May 2019 10:04:33 -0700 (PDT) Received: from [17.230.171.24] ([17.230.171.24]) by smtp.gmail.com with ESMTPSA id i9sm89339pjd.29.2019.05.29.10.04.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 May 2019 10:04:32 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_04556D8D-12CC-4F04-9140-E1BA3A674B4E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 29 May 2019 10:04:28 -0700 In-Reply-To: Cc: core@ietf.org, Stuart Cheshire To: consultancy@vanderstok.org References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com> <33B4FD70-E650-47E4-A603-BD4928E4C47F@fugue.com> <137192BD-7638-4D2E-A6E5-E1618499366F@fugue.com> <0d20366a188573397f9e98e4f8adc8e2@bbhmail.nl> <34EE8F1D-62E6-4C8C-B967-834BAF1FFFAF@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 29 May 2019 17:04:37 -0000 --Apple-Mail=_04556D8D-12CC-4F04-9140-E1BA3A674B4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 29, 2019, at 8:23 AM, Peter van der Stok = wrote: >>> Nodes want to use the RD before the 6LBR is connected. Hm, okay. That=E2=80=99s the piece I was missing. So there is some = infrastructure, just no external connection? Or there is no = infrastructure, just nodes that find each other? I think these are two = separate use cases. The use case I thought you were talking about is = where there are nodes that don=E2=80=99t see each other, but do see the = border router as it flies over/drives by/whatever. I suppose another = use case is where the leaf node is mobile, and the network = infrastructure that it sees changes over time: sometimes nothing, = sometimes ranger station 1, sometimes ranger station 2, etc. IOW it would be good to enumerate these use cases in more detail, and = then ask the question, how can I best configure this network, for each = such use case. --Apple-Mail=_04556D8D-12CC-4F04-9140-E1BA3A674B4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = May 29, 2019, at 8:23 AM, Peter van der Stok <stokcons@bbhmail.nl>= wrote:
Nodes want to use the RD before the 6LBR is = connected.

Hm, okay.   That=E2=80=99s = the piece I was missing.   So there is some infrastructure, just no = external connection?   Or there is no infrastructure, just nodes = that find each other?   I think these are = two separate use cases.   The use case I thought you were talking = about is where there are nodes that don=E2=80=99t see each other, but do = see the border router as it flies over/drives by/whatever.   I = suppose another use case is where the leaf node is mobile, and the = network infrastructure that it sees changes over time: sometimes = nothing, sometimes ranger station 1, sometimes ranger station 2, = etc.

IOW it = would be good to enumerate these use cases in more detail, and then ask = the question, how can I best configure this network, for each such use = case.

= --Apple-Mail=_04556D8D-12CC-4F04-9140-E1BA3A674B4E-- From nobody Wed May 29 10:56:23 2019 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 1BB5612006E; Wed, 29 May 2019 10:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr 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 nPx-ypasRk9y; Wed, 29 May 2019 10:56:18 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC3A12002F; Wed, 29 May 2019 10:56:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 418C081886; Wed, 29 May 2019 19:56:16 +0200 (CEST) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id BKqcsI8EHxOM; Wed, 29 May 2019 19:56:15 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 708C2818A1; Wed, 29 May 2019 19:56:15 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr 708C2818A1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1559152575; bh=i4cITa9eRbRXoJC/36dZ8bmJQOMIESy0yw6fq1Zu0eU=; h=MIME-Version:From:Date:Message-ID:To; b=S33nXBXaAJ6BA8tkS3oKO7v9pBF0bpji4h/Th+apn7OlZxhHPhh4W1zR6S9frq1zc DoWTTrlKxrVdub5bQt8cvI/aqw+50xnKWLVNdAliI8c+nKY4GbUvZxdXiGZEs0B2lc 1PY6wj5cfsmhtY069kozmhn2/mXqnyBeb7+kxvqg= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id 06Wcxt1lNA6C; Wed, 29 May 2019 19:56:15 +0200 (CEST) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 1D7B681886; Wed, 29 May 2019 19:56:15 +0200 (CEST) Received: by mail-io1-f42.google.com with SMTP id e5so2650902iok.4; Wed, 29 May 2019 10:56:15 -0700 (PDT) X-Gm-Message-State: APjAAAXAOXnW34yZX2kT7/S8MNqqmbt4CGxIZAOmncpsgWmkGM2lIgJa G2u/MsWTxFXmSWwBQX15u9HYmTHxNsyyYbYr2bc= X-Google-Smtp-Source: APXvYqy9rc8FJaooWiSQibsbodweS1/cGVET0mEhqITs8Wx4cPfQ6JCc9R3sh8xj0khuX+tvdH2IYD1K2uQWgd+s6po= X-Received: by 2002:a5d:8447:: with SMTP id w7mr5047369ior.197.1559152573767; Wed, 29 May 2019 10:56:13 -0700 (PDT) MIME-Version: 1.0 References: <155915229337.5461.11045326859886255040.idtracker@ietfa.amsl.com> In-Reply-To: <155915229337.5461.11045326859886255040.idtracker@ietfa.amsl.com> From: Laurent Toutain Date: Wed, 29 May 2019 19:55:25 +0200 X-Gmail-Original-Message-ID: Message-ID: To: lp-wan , "core@ietf.org WG" Content-Type: multipart/alternative; boundary="0000000000004f6426058a0a7fff" Archived-At: Subject: [core] Fwd: New Version Notification for draft-ietf-lpwan-coap-static-context-hc-08.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: Wed, 29 May 2019 17:56:21 -0000 --0000000000004f6426058a0a7fff Content-Type: text/plain; charset="UTF-8" Hi, We have issued a new version of the SCHC coap compression to remove an artifact due to a bad github manipulation. Laurent ---------- Forwarded message --------- From: Date: Wed, May 29, 2019 at 7:51 PM Subject: New Version Notification for draft-ietf-lpwan-coap-static-context-hc-08.txt To: Laurent Toutain , Ana Minaburo < ana@ackl.io>, Ricardo Andreasen , Laurent Toutain < laurent.toutain@imt-atlantique.fr>, A new version of I-D, draft-ietf-lpwan-coap-static-context-hc-08.txt has been successfully submitted by Laurent Toutain and posted to the IETF repository. Name: draft-ietf-lpwan-coap-static-context-hc Revision: 08 Title: LPWAN Static Context Header Compression (SCHC) for CoAP Document date: 2019-05-29 Group: lpwan Pages: 29 URL: https://www.ietf.org/internet-drafts/draft-ietf-lpwan-coap-static-context-hc-08.txt Status: https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/ Htmlized: https://tools.ietf.org/html/draft-ietf-lpwan-coap-static-context-hc-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-coap-static-context-hc Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-coap-static-context-hc-08 Abstract: This draft defines the way SCHC header compression can be applied to CoAP headers. The CoAP header structure differs from IPv6 and UDP protocols since CoAP uses a flexible header with a variable number of options themselves of variable length. The CoAP protocol is asymmetric in its message format, the format of the header packet in the request messages is different from that in the response messages. Most of the compression mechanisms have been introduced in [I-D.ietf-lpwan-ipv6-static-context-hc], this document explains how to use the SCHC compression for CoAP. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --0000000000004f6426058a0a7fff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We have issued a new ver= sion of the SCHC coap compression to remove an artifact due to a bad github= manipulation.

Laurent

---------- Forward= ed message ---------
From: <internet-drafts@ietf.org>
Date: Wed, = May 29, 2019 at 7:51 PM
Subject: New Version Notification for draft-ietf= -lpwan-coap-static-context-hc-08.txt
To: Laurent Toutain <Laurent.Toutain@imt-atlantique.fr= >, Ana Minaburo <ana@ackl.io&g= t;, Ricardo Andreasen <randrease= n@fi.uba.ar>, Laurent Toutain <laurent.toutain@imt-atlantique.fr>, <lpwan-chairs@ietf.org>


A new version of I-D, draft-ietf-lpwan-coap-static-context-hc-08.txt
has been successfully submitted by Laurent Toutain and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-lpwan-coap-static-= context-hc
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A008
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LPWAN Static Context Header Compre= ssion (SCHC) for CoAP
Document date:=C2=A0 2019-05-29
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lpwan
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 29
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-iet= f-lpwan-coap-static-context-hc-08.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static= -context-hc/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-lpwan-coap-static-context-hc-0= 8
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-coap-st= atic-context-hc
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lpwa= n-coap-static-context-hc-08

Abstract:
=C2=A0 =C2=A0This draft defines the way SCHC header compression can be appl= ied to
=C2=A0 =C2=A0CoAP headers.=C2=A0 The CoAP header structure differs from IPv= 6 and UDP
=C2=A0 =C2=A0protocols since CoAP
=C2=A0 =C2=A0uses a flexible header with a variable number of options thems= elves
=C2=A0 =C2=A0of variable length.=C2=A0 The CoAP protocol is asymmetric in i= ts message
=C2=A0 =C2=A0format, the format of the header packet in the request message= s is
=C2=A0 =C2=A0different from that in the response messages.=C2=A0 Most of th= e
=C2=A0 =C2=A0compression mechanisms have been introduced in
=C2=A0 =C2=A0[I-D.ietf-lpwan-ipv6-static-context-hc], this document explain= s how
=C2=A0 =C2=A0to use the SCHC compression for CoAP.




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

The IETF Secretariat

--0000000000004f6426058a0a7fff-- From nobody Wed May 29 14:56:53 2019 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 24A51120096; Wed, 29 May 2019 14:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.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 UucaL4HNTrXG; Wed, 29 May 2019 14:56:41 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40113.outbound.protection.outlook.com [40.107.4.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E25120134; Wed, 29 May 2019 14:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector1-iotconsultancynl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pRlXgDqqNObYHLPhJOvo+uHSMYJ0lH1ahH7uKLyqSQg=; b=CaZm14PzH54+NThQNYFAURoyO5KxgZrvatVXaY7v8+VER0haxOlAgTaW8NGQnWzF0IywXCI818WxJTl+eD7oWx/wuCmL/YvL52iFWOaMBgXB7onPYr/oUqvglsjEGvDmDDkP++rMgJgLYKZdWQzEoURFyuvGNbAKOnQcxQxDak8= Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (10.161.89.148) by AM5P190MB0563.EURP190.PROD.OUTLOOK.COM (10.161.66.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.16; Wed, 29 May 2019 21:56:37 +0000 Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::9b3:4a09:dfc8:6487]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::9b3:4a09:dfc8:6487%7]) with mapi id 15.20.1943.016; Wed, 29 May 2019 21:56:37 +0000 From: Esko Dijk To: Jim Schaad , "draft-dijk-core-groupcomm-bis@ietf.org" CC: "ace@ietf.org" , "core@ietf.org" Thread-Topic: Comments about draft-dijk-core-groupcomm-bis-00 Thread-Index: AdUUNPLwUpqoK9aaSuCnTZIzn4sN5wCM6LAw Date: Wed, 29 May 2019 21:56:36 +0000 Message-ID: References: <017f01d515a6$ed172890$c74579b0$@augustcellars.com> In-Reply-To: <017f01d515a6$ed172890$c74579b0$@augustcellars.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl; x-originating-ip: [2001:1c02:3101:4800:24b6:8e23:9589:19c9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f1874771-b2ec-432b-cb91-08d6e48085c6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7193020); SRVR:AM5P190MB0563; x-ms-traffictypediagnostic: AM5P190MB0563: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0052308DC6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39830400003)(136003)(396003)(376002)(366004)(199004)(189003)(13464003)(7736002)(76176011)(305945005)(52536014)(9686003)(2501003)(54906003)(316002)(6246003)(6506007)(110136005)(86362001)(6116002)(71200400001)(8936002)(53936002)(186003)(71190400001)(8676002)(99286004)(7696005)(55016002)(33656002)(81156014)(53546011)(81166006)(2906002)(74316002)(256004)(4326008)(486006)(476003)(102836004)(508600001)(44832011)(14444005)(25786009)(4743002)(229853002)(46003)(74482002)(5660300002)(446003)(11346002)(66946007)(76116006)(68736007)(73956011)(66476007)(66556008)(64756008)(66446008)(6436002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5P190MB0563; H:AM5P190MB0275.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4eughSPM45rXqkoM9JP4oeG9AIgZcMAPjLeE/38z8gOK85/M5DnaxwZUDVZG0AOWXVtanDkDRAwnYp8K+61cMqqnr+OfkidLIz3hVmNrpC0LhKYjL6WS6FXzrgwZ1922lhCQ9A1FYk2SLDQWKjAIIYYf9ILJZbBIYPUetnFBdqv1TV2BiMUoBnSwNqBt1KsxY6u6kah4oz7m5PWwS5cp6vnlEU4/FAYJjuF5+9/koNB/6yPWpjNMlpkDyZUYjWSSbEjoApWDmG68vl5o42fVCmo0Tmtimm97+3Q41gwx+JA8q/LRDLWmWRGz1UOig1PPOL/ELxw75sHm43Cjsgjob3n4V12jEhRwt/w0ZJM041ztXyhcXILY4bRjzmiYG/FcTGVYIm8VXPShlkPID3Q82m8pfZot/sCPS+1vKKFfkyw= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-Network-Message-Id: f1874771-b2ec-432b-cb91-08d6e48085c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2019 21:56:36.9386 (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: esko.dijk@iotconsultancy.nl X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0563 Archived-At: Subject: Re: [core] Comments about draft-dijk-core-groupcomm-bis-00 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, 29 May 2019 21:56:45 -0000 SGVsbG8gSmltLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMgLSB0aGUgYXV0aG9ycyBhcmUg bm93IGxvb2tpbmcgaW50byB0aGVzZSBhbmQgd2UnbGwgcmVwbHkgYWdhaW4gYXMgc29vbiBhcyB3 ZSBoYXZlIGFuc3dlcnMuICBJIGFsc28gY29weSB0aGlzIHRvIHRoZSBDb1JFIFdHIGxpc3Q7IGFz IHRoZSBkcmFmdCB0YXJnZXRzIHRoZSBDb1JFIFdHLg0KDQpFc2tvDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPiAN ClNlbnQ6IFdlZG5lc2RheSwgTWF5IDI5LCAyMDE5IDAwOjQ1DQpUbzogZHJhZnQtZGlqay1jb3Jl LWdyb3VwY29tbS1iaXNAaWV0Zi5vcmcNCkNjOiBhY2VAaWV0Zi5vcmcNClN1YmplY3Q6IENvbW1l bnRzIGFib3V0IGRyYWZ0LWRpamstY29yZS1ncm91cGNvbW0tYmlzLTAwIA0KDQpDb21tZW50cyBv biB0aGlzIGRyYWZ0Lg0KDQoxLiAgSSBoYXZlIGFuIGV4aXN0ZW50aWFsIHByb2JsZW0gd2l0aCB0 aGlzIGRvY3VtZW50LiAgVGhpcyBpcyBhIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudCB0aGF0IGlz IGNsYWltaW5nIHRvIGRvIGFuIHVwZGF0ZSB0byBhbiBleHBlcmltZW50YWwgZHJhZnQuDQpIb3dl dmVyLCB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IEkgd291bGQgbm90IGV4cGVjdCB0byBiZSBkb25l IGFuZCBpdCBpcyBub3QgY2xlYXIganVzdCB3aGF0IHRoZSB1cGRhdGVzIHRvIHRoYXQgZG9jdW1l bnQgYXJlIGFuZCBob3cgb25lIHdvdWxkIG1ha2UNCmVkaXRzIHRvIHRoYXQgZG9jdW1lbnQgaW4g b3JkZXIgdG8gYXBwbHkgdGhlIHVwZGF0ZXMuICAgTXkgZ2VuZXJhbA0KZXhwZWN0YXRpb24gZm9y IGFuIGV4cGVyaW1lbnRhbCBkb2N1bWVudCBpcyB0aGF0IGl0IHdvdWxkIGJlIDEpIGRlY2xhcmVk IGEgZmFpbHVyZSBhbmQga2lsbGVkLCAyKSBkZWNsYXJlIGEgcGFydGlhbCBzdWNjZXNzIGFuZCB1 cGRhdGVkIGZvciBhIG5ldyBleHBlcmltZW50IChhbmQgdGh1cyBhIG5ldyBleHBlcmltZW50YWwg ZG9jdW1lbnQpIG9yIDMpIGRlY2xhcmUgYSByZXNvdW5kaW5nIHN1Y2Nlc3MgdGhlbiByZXBsYWNl ZCB3aXRoIGVpdGhlciBhIHN0YW5kYXJkcyBvciBpbmZvcm1hdGlvbiBkb2N1bWVudC4gIA0KDQoy LiAgWW91IGFyZSBjbGFpbWluZyB0byB1cGRhdGUgUkZDIDc2NDEsIGJ1dCBpdCBpcyBub3QgY2xl YXIgdG8gbWUgd2hhdCBpcyBiZWluZyB1cGRhdGVkIGFuZCBqdXN0IHdoYXQgdGhlIGltcGxpY2F0 aW9ucyBvZiBkb2luZyB0aGlzIHVwZGF0ZSBhcmUuICBBcyBhbiBleGFtcGxlIG9mIHRoZSB0eXBl cyBvZiB0aGluZyB0aGF0IHNob3VsZCBiZSBjbGFyaWZpZWQgYXJlOg0KKiAgSWYgYSBzZXJ2ZXIg ZG9lcyBub3QgcmV0dXJuIGEgcmVzcG9uc2UsIHNob3VsZCBpdCBzZXR1cCB0byBkbyBhIGxhdGVy IG9ic2VydmUgb3BlcmF0aW9uPw0KKiAgTW9yZSBpbmZvcm1hdGlvbiBvbiBob3cgY29ycmVsYXRp b24gc2hvdWxkIGJlIGRvbmUgd2l0aCByZXNwb25zZXMuICBBcyBhbiBleGFtcGxlLCBpZiB5b3Ug ZG8gdW5hcnkgb2JzZXJ2ZSBhbmQgdGhlIHJlc3BvbnNlIGlzIHJvdXRlZCB0aHJvdWdoIGEgcHJv eHksIHRoZXJlIGFyZSBubyBwcm9ibGVtcyBhcyBsb25nIGFzIHRoZSByZXNwb25zZXMgYXJlIG5v dCBsYXRlciByZS1yb3V0ZWQgdGhyb3VnaCBhIG5ldyBwcm94eS4gIEhvd2V2ZXIgZm9yIG11bHRp Y2FzdCwgaWYgeW91IGhhdmUgdHdvIGRpZmZlcmVudCBzZXJ2ZXJzIG9uIHRoZSBmYXIgc2lkZSBv ZiBhIHByb3h5IGhvdyBkb2VzIG9uZSBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoZSB0d28gb2YgdGhl bSBpZiBldmVyeXRoaW5nIGlzIGNvbWluZyB0aHJvdWdoIGEgc2luZ2xlIHByb3h5Pw0KDQozLiAg VGhlIGludHJvZHVjdGlvbiBkb2VzIG5vdCBhY2tub3dsZWRnZSB0aGF0IHRoZSBzYW1lIHRoaW5n IGNhbiBiZSBkb25lIHZpYSBwdWItc3ViLiAgSXQgaXMgb2sgdG8gZGVjbGFyZSB0aGlzIG91dCBv ZiBzY29wZSBidXQgaXQgbmVlZHMgdG8gYmUgZG9uZSBpbiB1cCBmcm9udCBpbiB0aGUgaW50cm9k dWN0aW9uIChhbmQgcHJvYmFibHkgYWxzbyBpbiB0aGUgYWJzdHJhY3QpLg0KDQo0LiAgSSBhbSBu b3Qgc3VyZSB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIHNheSBvbmUgc2hvdWxkIGJlIGZhbWlsaWFy IHdpdGggdGVybXMgZnJvbSBHcm91cCBPU0NPUkUgYXMgb25lIHdvdWxkIGV4cGVjdCB0aGlzIHRv IGJlIGZyb20gdGhlIGdlbmVyYWwgdG8gdGhlIHNwZWNpZmljIGZvciB0ZXJtaW5vbG9neSBub3Qg dGhlIG90aGVyIHdheSBhcm91bmQuDQoNCjUuICBJbiBzZWN0aW9uIDIuMS4xIC0geW91IHNob3Vs ZCBzdGF0ZSB0aGF0IHRoZSBjZW50cmFsaXplZCBkaXJlY3Rvcnkgd291bGQgYmUgcHJlLWNvbmZp Z3VyZWQgaW4gdGhlIGRldmljZS4NCg0KNi4gSW4gc2VjdGlvbiAyLjEuMSAtIERvIHdlIGhhdmUg YW55IHNldCBvZiBwcm9wZXJ0aWVzIHRoYXQgYXJlIGNvbW1vbmx5IGRlZmluZWQgZm9yIGRvaW5n IHRoaXM/ICBTZXJ2aWNlcyBpbiB0aGUgZm9ybSBvZiByZXNvdXJjZXMgYXJlIGVhc3kgdG8gdW5k ZXJzdGFuZCBidXQgSSBkb24ndCBrbm93IGhvdyB0byBkbyB0aGlzIGVhc2lseS4NCg0KNy4gSW4g c2VjdGlvbiAyLjMgLSBJdCB3b3VsZCBtYWtlIHNlbnNlIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4g dGhlIGNhc2VzIG9mIGFubm91bmNpbmcgYSBzb2Z0d2FyZSB1cGRhdGUgaXMgYXZhaWxhYmxlIGFu ZCBhY3R1YWxseSBkaXN0cmlidXRpbmcgdGhlIHNvZnR3YXJlIHVwZGF0ZSBieSBtdWx0aWNhc3Qu DQoNCjguIFNlY3Rpb24gMy4xLjEgLSBJdCBzaG91bGQgcG90ZW50aWFsbHkgYmUgc3RhdGVkIGhl cmUsIGJ1dCBkZWZpbml0ZWx5IHNvbWV3aGVyZSB0aGF0IGZvciBub24tc2VjdXJlIGdyb3VwcyBt ZW1iZXJzaGlwIGluIHRoZSBncm91cCBpcyBkZWZpbmVkIGJ5IGFuIGVuZHBvaW50IGFuZCBub3Qg YnkgYSBjZW50cmFsIGVuZHBvaW50LiAgVGhpcyBpcyBpbXBvcnRhbnQgaW4gdGVybXMgb2Ygc29t ZWJvZHkgImF0dGFja2luZyIgYSBub24tc2VjdXJlIGdyb3VwLg0KDQo5LiAgU2VjdGlvbiAzLjEu MiAtIEl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gcG9pbnQgdG8gZ3JvdXAgbmFtaW5nIGFzIHBhcnQg b2YgYSBkaXJlY3RvcnkgYXMgd2VsbCBhcyBiZWluZyBmb3IgRE5TLiAgDQoNCjEwLiAgU2VjdGlv biAzLjEuMyAtIE9uZSBvZiB0aGUgdGhpbmdzIHRoYXQgSSBoYWQgYSBwcm9ibGVtIHdpdGggd2hl biBpbXBsZW1lbnRhdGlvbiBncm91cCBicm9hZGNhc3Qgd2FzIHRyeWluZyB0byBkZWNpZGUgd2hp Y2ggb2YgdGhlIGRpZmZlcmVudCBsb2NhbCBncm91cHMgc2hvdWxkIGJlIHVzZWQgZm9yIGFuIElQ djYgbXVsdGljYXN0IGFkZHJlc3MuICBBIG51bWJlciBvZiB0aGVzZSBkaWZmZXJlbnQgZ3JvdXBz IGFyZSBkZWZpbmVkIGZvciBDb0FQIGFuZCBhIGRpc2N1c3Npb24gb2YgdGhlIGRpZmZlcmVuY2Vz IG9yIGEgcG9pbnRlciB0byB0aGUgZGlmZmVyZW5jZXMgd291bGQgYmUgdXNlZnVsLg0KDQoxMS4g U2VjdGlvbiAzLjIuMSAtIEFub3RoZXIgaXNzdWUgdG8gaGlnaGxpZ2h0IHdpdGggdG9rZW5zIGlz IHRoYXQgaW4gdGhlIHVuaWNhc3QgY2FzZSwgdGhlIHJlc3BvbnNlIGlzIGV4cGVjdGVkIHRvIGNv bWUgaW4gb24gdGhlIHNhbWUgY29ubmVjdGlvbiBpdCB3YXMgc2VudCBvbi4gIFRodXMgdHdvIGRp ZmZlcmVudCBjb25uZWN0aW9ucyBjYW4gcmUtdXNlIHRoZSBzYW1lIHRva2VuIHdpdGhvdXQgYW55 IHByb2JsZW1zLiAgVGhhdCBpcyBub3QgdHJ1ZSBmb3IgbXVsdGljYXN0IGFzIHRoZSBjb25uZWN0 aW9uIGl0IGNvbWVzIGl0IG9uIHdpbGwsIGJ5IGRlZmluaXRpb24sIG5vdCBiZSB0aGUgb25lIGl0 IHdhcyBzZW50IG9uLg0KDQoxMi4gU2VjdGlvbiAzLjIuMSAtIE1pZ2h0IHdhbnQgdG8gbWVudGlv biB0aGUgdXNlIG9mIEFjY2VwdCBhcyBvbmUgd2F5IHRvIHRoaW5rIGFib3V0IHNlcnZlciByZXNw b25zZSBkZWxheSBhcyB5b3UgYXQgbGVhc3Qga25vdyB0aGF0IHlvdSBhcmUgZXhwZWN0aW5nIGEg cmVzcG9uc2UgZnJvbSB0aGUgc2VydmVyIGlmIHlvdSBoYXZlIHJlY2VpdmVkIGFuIGFjY2VwdC4N Cg0KMTMuIFNlY3Rpb24gMy4yLjMgLSBOZWVkIHRvIHRhbGsgYWJvdXQgbXVsdGljYXN0IG1lc3Nh Z2VzLCBwcm94aWVzIGFuZCBjYWNoaW5nIG9mIHJlc3VsdHMuDQoNCjE0LiBTZWN0aW9uIDMuMi41 IC0gRG9lcyBSRkM3NjQxIGRlZmluZSBiZWhhdmlvciBhYm91dCByZWNlaXZpbmcgYSAiZHVwbGlj YXRlIiBvYnNlcnZlciByZXF1ZXN0PyAgV291bGQgeW91IHJlcGx5IGEgc2Vjb25kIHRpbWUgb3Ig bm90PyANCg0KMTUuIFNlY3Rpb24gNi4xIC0gbmV4dCB0byBsYXN0IHBhcmFncmFwaCAtIC92YWx1 ZXMgZG9lcyBub3QvdmFsdWVzLCBidXQgZG9lcyBub3QvDQoNCjE2LiBTZWN0aW9uIDYuMiAtIFNo b3VsZCBoYXZlIGEgY29uc2lkZXJhdGlvbiBhYm91dCB0aGUgc3BlZWQgb2YgcmUta2V5aW5nIHZz IHRoZSBmcmVxdWVuY3kgb2Ygam9pbnMvbGVhdmVzLg0KDQpKaW0NCg0KDQo= From nobody Thu May 30 00:29:44 2019 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 9F95412004F for ; Thu, 30 May 2019 00:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.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 7UlTPapSDtIa for ; Thu, 30 May 2019 00:29:40 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0155.hostedemail.com [216.40.44.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC1512006F for ; Thu, 30 May 2019 00:29:39 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay01.hostedemail.com (Postfix) with ESMTP id C6B50100E86C5; Thu, 30 May 2019 07:29:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=5IYs0rZxj8/Awk4NOA nXLrqGRsYyESD6aAB4f062B9I=; b=AR0nKyJEIsQlnLdwgINoLBHmRERqRkGcru piOeajm3IjTpKOpm98Faf0dQLk9OJdWouuarvxvXpme8yfzMMIv90P67ASFnEPFo LkAHri6gKL4UyL4fKsyi65y4hUngSW/gKZTd0Y60k8RT0woiZ1Jd/mC/yyTlUU55 F7p5gRZlQ= X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Spam-Summary: 10, 1, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:46:72:150:152:355:379:582:800:960:962:967:973:983:988:989:1152:1189:1208:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1535:1543:1575:1588:1589:1592:1594:1711:1730:1776:1792:2194:2198:2199:2200:2527:2528:2553:2557:2559:2562:2692:2693:3138:3139:3140:3141:3142:3354:3586:3622:3769:3865:3866:3867:3868:3870:3871:3872:3873:3874:4118:4250:4321:4362:5007:6117:6119:6261:6298:6657:6659:6678:6691:7875:7903:8603:9108:9177:10004:10400:10848:11232:11657:11658:11914:11984:12043:12114:12555:12740:12895:12986:13071:13139:13161:13229:13255:13439:14093:14096:14180:14181:14721:21060:21080:21324:21433:21451:21625:21740:21810:30003:30028:30041:30054:30062:30090, 0, RBL:216.40.42.5:@bbhmail.nl:.lbl8.mailshell.net-62.8.55.100 66.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:24, LUA_SUMMARY:none X-HE-Tag: way45_370cc6d881d23 X-Filterd-Recvd-Size: 7811 Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf07.hostedemail.com (Postfix) with ESMTPA; Thu, 30 May 2019 07:29:38 +0000 (UTC) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_4d4c7d7b21ea987deff445fc2961626e" Date: Thu, 30 May 2019 09:29:37 +0200 From: Peter van der Stok To: Ted Lemon Cc: consultancy@vanderstok.org, core@ietf.org, Stuart Cheshire Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <02585a832a91742de93f6d311259ae61@bbhmail.nl> <498bff27c1804f08365f0e11e6d24050@bbhmail.nl> <32B6BB77-91AA-4F85-B5EA-6AC8C6407F7F@fugue.com> <33B4FD70-E650-47E4-A603-BD4928E4C47F@fugue.com> <137192BD-7638-4D2E-A6E5-E1618499366F@fugue.com> <0d20366a188573397f9e98e4f8adc8e2@bbhmail.nl> <34EE8F1D-62E6-4C8C-B967-834BAF1FFFAF@fugue.com> Message-ID: <4afdae3b6feeddb3af3b276188f97b30@bbhmail.nl> X-Sender: stokcons@bbhmail.nl User-Agent: Roundcube Webmail/1.2.7 X-Originating-IP: [86.203.99.87] Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_for_Resource_Directory?= 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, 30 May 2019 07:29:43 -0000 --=_4d4c7d7b21ea987deff445fc2961626e Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Ted, thanks for the dissection of use cases. The ones I understand: 1a) no infrastructure with nodes that see each other. 1b) followed by nodes that see each other connected to an infrastructure with border router (possibly intermittently) 2) nodes that see each other connected to an infrastructure with border router (possibly intermittently) Where 1b and 2 are actually identical; and 1b does not necessarily follow 1a. The intermittent connection to the border router is not important because from the first connection to the 6LBR, the 6LR remember the border router options. When different border routers fly over, it wil be difficult to to instruct them all what the RD address is. (not clear what to recommend here, I prefer to leave that out) When nodes do not see each other, the presence of an RD is irrelevant. The case that a node migrates from one infrastructure to the next is beyond my competence. That was a use case for home networks with DNS support? I will add some phrases to the building control section to make the connection to (absence of) the infrastructure clearer. Any other suggestions? Peter Ted Lemon schreef op 2019-05-29 19:04: > On May 29, 2019, at 8:23 AM, Peter van der Stok wrote: > > Nodes want to use the RD before the 6LBR is connected. Hm, okay. That's the piece I was missing. So there is some infrastructure, just no external connection? Or there is no infrastructure, just nodes that find each other? I _think_ these are two separate use cases. The use case I thought you were talking about is where there are nodes that don't see each other, but do see the border router as it flies over/drives by/whatever. I suppose another use case is where the leaf node is mobile, and the network infrastructure that it sees changes over time: sometimes nothing, sometimes ranger station 1, sometimes ranger station 2, etc. IOW it would be good to enumerate these use cases in more detail, and then ask the question, how can I best configure this network, for each such use case. --=_4d4c7d7b21ea987deff445fc2961626e Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Ted,

thanks for the dissection of use cases. The ones I under= stand:

1a) no infrastructure with nodes that see each other.
1b) followed by nodes that see each other connected to an infrastructure = with border router (possibly intermittently)
2) nodes that see each ot= her connected to an infrastructure with border router (possibly intermitten= tly)

Where 1b and 2 are actually identical; and 1b does not nece= ssarily follow 1a.

The intermittent connection to the border rou= ter is not important because from the first connection to the 6LBR, the 6LR= remember the border router options.

When different border route= rs fly over, it wil be difficult to to instruct them all what the RD addres= s is. (not clear what to recommend here, I prefer to leave that out)
<= br />When nodes do not see each other, the presence of an RD is irrelevant= =2E

The case that a node migrates from one infrastructure to the= next is beyond my competence. That was a use case for home networks with D= NS support?

I will add some phrases to the building control sect= ion to make the connection to (absence of) the infrastructure clearer.

Any other suggestions?

Peter

Ted Lemon schreef op 2019-05-29 19:04:

On May 29, 2019, at 8:23 AM, Peter van der Stok <stokcons@bbhmail.nl> wro= te:
Nodes want to use the RD before the 6LBR is connected.

Hm, okay.   That's the piece I was missing.   So there is so= me infrastructure, just no external connection?   Or there is no infra= structure, just nodes that find each other?   I think th= ese are two separate use cases.   The use case I thought you were talk= ing about is where there are nodes that don't see each other, but do see th= e border router as it flies over/drives by/whatever.   I suppose anoth= er use case is where the leaf node is mobile, and the network infrastructur= e that it sees changes over time: sometimes nothing, sometimes ranger stati= on 1, sometimes ranger station 2, etc.
 
IOW it would be good to enumerate these use cases in more detail, and = then ask the question, how can I best configure this network, for each such= use case.
 
--=_4d4c7d7b21ea987deff445fc2961626e-- From nobody Thu May 30 04:52:55 2019 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 E834C120100; Thu, 30 May 2019 04:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 rP8Y98uzPvhQ; Thu, 30 May 2019 04:52:45 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 2CCD1120019; Thu, 30 May 2019 04:52:45 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id n5so4779712ioc.7; Thu, 30 May 2019 04:52:45 -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:content-transfer-encoding; bh=i9eTVyUSyrgQSPCmuIj3P77o2iCO+rOZZsUvNMASEPA=; b=nwoLVeBncQlMiJYNvQ5qo9M8kupTJ+5GDqt//70Jc3NvPUFxc13JySz94q4esf21Ng 2Zm46sdSmTtPhRQQEIWXpXXZJtEbe4OuaZ++fMqzGbooPT106RuSk2v7M2vVTbkeP3Ho 2+l9AxKUhZEa5BAupKf7ihDbBCt92JT2ZU771/0AvzkZrAt3OAjiKhl44XB/c8xCdJC+ fokV8+pTbQLrdTssoZgmYK846UOKtoJ9dgElWy8kqbgXU1xNtjA8852pn3f3DCtGvQAi EHSJtEREG/PQ102YaJJMAcUqQOg0X43D4ww1oWnkg3oPH7GHiANvaYoH1OhLV3xpkih9 tNvA== 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=i9eTVyUSyrgQSPCmuIj3P77o2iCO+rOZZsUvNMASEPA=; b=HYe1uwvK3uLrLhYWBAWpEEg94KLCBqyNJh81NExyCwCeuQYpusfK1aV3L4KBt9JpkV 0wFdbtsWaXL89pkhRDwiaLcaFnEShG3M5501DikNGnvwfeQRfG4aOUGM4XTN1/AswSEW zpkgNIPTo9H/RwRMZQuRpaKjpL7Waizi2u8he9iKRFRdbEzrP1a15dxLFJ+w3r7AxKSI 6dUnXavXMv5f2deyABaBKZiR9M8qCUl0OZlc2bMY7Wn9aNKPPuqQ+eLLGU3vKxCXiPg0 Fhtq92gG3bQKfP2RCKJUyxKRf5iottsFGyq/b1ZV8usBKVb1KoRKfyFqRacqvz1SCt+4 PPIQ== X-Gm-Message-State: APjAAAVncw2tRuU5Y9nCg3UF0UR2Rvf08jwCxX1z2iDsGbx3e3GGmXBq oPC+8CJ5j1VqUXT47HRpvubmIrebB+39T2SEzbA= X-Google-Smtp-Source: APXvYqzmdgbWmv16OkO2S3gJzTRyw61C3Z9e77bL8DykIQxxnsx7ocuYhYHps1dlWjyYT/VTCM1/1eZ4lysabL0+JIE= X-Received: by 2002:a6b:7d49:: with SMTP id d9mr2546238ioq.50.1559217164511; Thu, 30 May 2019 04:52:44 -0700 (PDT) MIME-Version: 1.0 References: <155915229337.5461.11045326859886255040.idtracker@ietfa.amsl.com> In-Reply-To: From: Thomas Fossati Date: Thu, 30 May 2019 12:52:33 +0100 Message-ID: To: Laurent Toutain Cc: lp-wan , "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [core] Fwd: New Version Notification for draft-ietf-lpwan-coap-static-context-hc-08.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: Thu, 30 May 2019 11:52:47 -0000 Hi Laurent, On Wed, May 29, 2019 at 6:56 PM Laurent Toutain wrote: > We have issued a new version of the SCHC coap compression > to remove an artifact due to a bad github manipulation. I have taken a look at the draft but since I cannot claim compression expertise I will only provide a couple of high level comments: - Sec 3: "a proxy placed before the compressor may change some field value". You should qualify the "proxy" as a "CoAP proxy, explicitly selected by the client" to avoid any ambiguity -- we certainly don't want to recommend middle-box interference :-) - Sec 4.1: "This field is bidirectional and MUST be elided during the SCHC compression". This is a dangerous statement as it leads us straight into CoAP ossification territory. If you want SCHC to work with CoAP v1 only what you really want to say here is "SHCH compression MUST NOT be applied to CoAP packets with version different from v1". Granted that, a SCHC box deployed today could sit in the field happily ever after. If not, when a new CoAP version is rolled out, endpoints wouldn=E2=80=99t be able to use this new version on any path crossing an SCHC box. Cheers!