From nobody Sat Jul 1 04:42:31 2017 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 4DE7512EBFE; Sat, 1 Jul 2017 04:42:30 -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.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149890935029.489.17808988617837918050@ietfa.amsl.com> Date: Sat, 01 Jul 2017 04:42:30 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-object-security-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jul 2017 11:42:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments of the IETF. Title : Object Security of CoAP (OSCOAP) Authors : Göran Selander John Mattsson Francesca Palombini Ludwig Seitz Filename : draft-ietf-core-object-security-04.txt Pages : 44 Date : 2017-07-01 Abstract: This document defines Object Security of CoAP (OSCOAP), a method for application layer protection of the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE). OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure message binding. OSCOAP is designed for constrained nodes and networks and can be used across intermediaries and over any layer. The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-object-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-object-security-04 https://datatracker.ietf.org/doc/html/draft-ietf-core-object-security-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-object-security-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 1 23:25:44 2017 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 92E4B129B5D; Sat, 1 Jul 2017 23:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 Cs7XXjUKUCCg; Sat, 1 Jul 2017 23:25:41 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BAB11200F1; Sat, 1 Jul 2017 23:25:41 -0700 (PDT) Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1498976729; h=from:subject:to:date:message-id; bh=eX3mhST3fTXsRVBvw9qCBCFQiRgU+nSO3KQycken2Mw=; b=b8Ej3WD9gz9mWoRbSuLyQLUhQS8YlYdozY4eBPH7KNjt9xq1jofFWsRS0DP+cKgh/WzRko4QeXR eBT/RbB0rdSFp221f0TfHGHsk3hr9shBphUnPZHJ0e9FW4AcbO30ANtqDC+VwDFx9oQWJ3CRAONhP MVFcqdA1g98h98TSq1t+QLcQJ69ljV59/mWdXeKox2ljrjeB9FtwItvexQnp2OV5XFujisnLhnRfz /3BzGjsdsYWvFw7wX/LQ9G21oQPlXYA+E7UInJ+3uZHz9bES2RuNAiK4IFcVSAqWYKlxOzYDdXwoM d57HEZoCyIe486VT/IJ01V9aPqZl3welpARg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 1 Jul 2017 23:25:28 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 1 Jul 2017 23:25:26 -0700 From: Jim Schaad To: CC: Date: Sat, 1 Jul 2017 23:25:30 -0700 Message-ID: <00e101d2f2fc$023b0b30$06b12190$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdLy+OzNkdImdXNSTKuMxHZBEjhwYg== X-Originating-IP: [24.21.96.37] Archived-At: Subject: [core] draft-ietf-core-links-json X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 06:25:43 -0000 While I realize this document is with the IESG, I was trying to work on my link format implementation so I decided to read this document to see if I could get it implemented for CBOR at the same time. While doing this I came up with the following: 1. I believe that it would be worthwhile to say why the decision not to encode items which match the "Cardinal" rule are not using the CBOR integer types. If I made a guess I would guess it is because JSON does not handle integers correctly but I do not know that for a fact. If this was used then the encoding would be smaller. 2. I would like to verify that the following was intended. In the CDDL, value appears to be able to support an array that contains both strings and Booleans mixed together. That seems to be a strange source and I don't know it is real. Jim From nobody Sun Jul 2 00:23:23 2017 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 D8B7A12EB34; Sun, 2 Jul 2017 00:23:22 -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 cAr0BWkmOKdh; Sun, 2 Jul 2017 00:23:20 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 1F2C712EB31; Sun, 2 Jul 2017 00:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v627N4Hc014762; Sun, 2 Jul 2017 09:23:04 +0200 (CEST) Received: from client-0239.vpn.uni-bremen.de (client-0239.vpn.uni-bremen.de [134.102.107.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3x0hZ04bTDzDKrx; Sun, 2 Jul 2017 09:23:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <00e101d2f2fc$023b0b30$06b12190$@augustcellars.com> Date: Sun, 2 Jul 2017 09:23:03 +0200 Cc: draft-ietf-core-links-json@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 520672983.547293-1c7a4be3246a1dc7ef4afba94b6ef9b5 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00e101d2f2fc$023b0b30$06b12190$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-links-json X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 07:23:23 -0000 On Jul 2, 2017, at 08:25, Jim Schaad wrote: >=20 > While I realize this document is with the IESG, I was trying to work = on my > link format implementation so I decided to read this document to see = if I > could get it implemented for CBOR at the same time. While doing this = I came > up with the following: >=20 > 1. I believe that it would be worthwhile to say why the decision not = to > encode items which match the "Cardinal" rule are not using the CBOR = integer > types. If I made a guess I would guess it is because JSON does not = handle > integers correctly but I do not know that for a fact. If this was = used then > the encoding would be smaller. Well, we do say: Note that the conversion is unable to convert the string-valued "ct" attribute to a number, which would be the natural type for a Content-Format value; similarly, both "foo" values are treated as strings independently of whether they are quoted or numeric in syntax. We do not quite say a lot about why. RFC 6690 core-link does not have = type information, and we don=E2=80=99t know whether foo=3D3 means that foo is the number 3 or that foo is a text string that happens = to byte wise the same as the string representation of the number 3. So = all items are represented as text strings (or true, if there is no value = given). > 2. I would like to verify that the following was intended. In the = CDDL, > value appears to be able to support an array that contains both = strings and > Booleans mixed together. That seems to be a strange source and I = don't know > it is real. How do you encode ;foo=3D1;foo;foo;foo=3D=E2=80=9CWirtshaus=E2=80=9D;foo= ? The reference implementation says: [ { "href": "http://example.com", "foo": [ "1", true, true, "Wirtshaus", true ] } ] But I note that the reference implementation doesn=E2=80=99t correctly = handle the conversion back to link-format, so we=E2=80=99ll need to fix = this. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 2 01:10:06 2017 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 1E9FF12EBF9; Sun, 2 Jul 2017 01:10:05 -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 DszhnFBxJGcH; Sun, 2 Jul 2017 01:10:03 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 698DF128AB0; Sun, 2 Jul 2017 01:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6289OmK019014; Sun, 2 Jul 2017 10:09:24 +0200 (CEST) Received: from client-0001.vpn.uni-bremen.de (client-0001.vpn.uni-bremen.de [134.102.107.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3x0jbS50zlzDKs8; Sun, 2 Jul 2017 10:09:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Sun, 2 Jul 2017 10:09:23 +0200 Cc: draft-ietf-core-links-json@ietf.org, core@ietf.org X-Mao-Original-Outgoing-Id: 520675763.355448-cda2fa1414cffb9487d163ed005c3475 Content-Transfer-Encoding: quoted-printable Message-Id: <8EC7986B-2E1F-4C93-9BD3-B7A94404E629@tzi.org> References: <00e101d2f2fc$023b0b30$06b12190$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-ietf-core-links-json X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 08:10:05 -0000 On Jul 2, 2017, at 09:23, Carsten Bormann wrote: >=20 > But I note that the reference implementation doesn=E2=80=99t correctly = handle the conversion back to link-format, so we=E2=80=99ll need to fix = this. Fixed in: https://svn.tools.ietf.org/svn/wg/core Specifically https://svn.tools.ietf.org/svn/wg/core/link-format.rb and the formatted result: https://svn.tools.ietf.org/svn/wg/core/draft-ietf-core-links-json-xx.txt (No change needed for this to the markdown sources, which are also = there.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 2 11:39:39 2017 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 C23A312EE44; Sun, 2 Jul 2017 11:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 13rgl9I4ylDR; Sun, 2 Jul 2017 11:39:28 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A8112ECC4; Sun, 2 Jul 2017 11:39:27 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499020755; h=from:subject:to:date:message-id; bh=db/mwkKaQ7L04s/dcMgHfPAQp8dX0i805L3cE0Akv9s=; b=g/sdmH21NCcrJGwQONcIOh/R10hBVBeG9sLGUHHwZORthp5RAbKUnVbZOzO1Jw35oNf1hNj6htv c9TwiDmh1gzk+1ex4CZPcUvULqncZoTEhY6Jy5IrNRp1EyUBEPg7cuk+Mhqrb5t3onxumo9T0GpK5 lFTiZWwSogO+WqFK87SBY10dKSWSj6silXM69DkHOUSswkngdwuJw0vNm89RVxAeCNPJKh/gaXlll TZtScaGggAc1A7UKX/4QS8p5HIZDFB/W39gU1jbXrTsIFphQD3mZRboDFDJlokGEKtg5NP4y1UP4k sCJ8wDmbaKYMpF0tf8JM54nzCT77I/UwFP+A== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 2 Jul 2017 11:39:14 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 2 Jul 2017 11:39:13 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: , References: <00e101d2f2fc$023b0b30$06b12190$@augustcellars.com> In-Reply-To: Date: Sun, 2 Jul 2017 11:39:17 -0700 Message-ID: <010501d2f362$84d23940$8e76abc0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJ5bJhwvPCRxkD78dxctlAKUw9PwAG02+m0oOZCGFA= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] draft-ietf-core-links-json X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 18:39:38 -0000 -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: Sunday, July 2, 2017 12:23 AM To: Jim Schaad Cc: draft-ietf-core-links-json@ietf.org; core@ietf.org Subject: Re: [core] draft-ietf-core-links-json On Jul 2, 2017, at 08:25, Jim Schaad wrote: >=20 > While I realize this document is with the IESG, I was trying to work=20 > on my link format implementation so I decided to read this document to = > see if I could get it implemented for CBOR at the same time. While=20 > doing this I came up with the following: >=20 > 1. I believe that it would be worthwhile to say why the decision not=20 > to encode items which match the "Cardinal" rule are not using the CBOR = > integer types. If I made a guess I would guess it is because JSON=20 > does not handle integers correctly but I do not know that for a fact. = > If this was used then the encoding would be smaller. Well, we do say: Note that the conversion is unable to convert the string-valued "ct" attribute to a number, which would be the natural type for a = Content-Format value; similarly, both "foo" values are treated as = strings independently of whether they are quoted or numeric in syntax. We do not quite say a lot about why. RFC 6690 core-link does not have = type information, and we don=E2=80=99t know whether foo=3D3 means that foo is the number 3 or that foo is a text string that happens = to byte wise the same as the string representation of the number 3. So = all items are represented as text strings (or true, if there is no value = given). [JLS] If it looks like a duck.... =20 I would probably have expected to see the statement about the = conversions in section 2.2 on the information model and not appended to = the end of an example section. Yes I did see the text and that was part = of why I was looking for a rational. =20 I don't need one, it is just a "nice to have". > 2. I would like to verify that the following was intended. In the=20 > CDDL, value appears to be able to support an array that contains both=20 > strings and Booleans mixed together. That seems to be a strange=20 > source and I don't know it is real. How do you encode ;foo=3D1;foo;foo;foo=3D=E2=80=9CWirtshaus=E2=80=9D;fo= o [JLS] I would probably say that this is invalid and scream bloody = murder. I had thought of this case and decided that it was bloody = stupid and I did not care if it was supported or not. That said, I was = just verifying author intent so it is not a problem for me. Jim ? The reference implementation says: [ { "href": "http://example.com", "foo": [ "1", true, true, "Wirtshaus", true ] } ] But I note that the reference implementation doesn=E2=80=99t correctly = handle the conversion back to link-format, so we=E2=80=99ll need to fix = this. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 3 03:26:45 2017 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 4B7FF131540 for ; Mon, 3 Jul 2017 03:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0PugUbKmx9m0 for ; Mon, 3 Jul 2017 03:26:40 -0700 (PDT) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [139.15.237.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 B595B12EC1C for ; Mon, 3 Jul 2017 03:26:40 -0700 (PDT) Received: from vsmta14.fe.internet.bosch.com (unknown [10.4.98.54]) by imta24.fe.bosch.de (Postfix) with ESMTP id 5DB5BD80079 for ; Mon, 3 Jul 2017 12:26:20 +0200 (CEST) Received: from SI-MBX1028.de.bosch.com (vsgw23.fe.internet.bosch.com [10.4.98.23]) by vsmta14.fe.internet.bosch.com (Postfix) with ESMTP id 3DE27A40407 for ; Mon, 3 Jul 2017 12:26:20 +0200 (CEST) Received: from FE-MBX1027.de.bosch.com (10.3.230.85) by SI-MBX1028.de.bosch.com (10.3.230.42) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 3 Jul 2017 12:26:19 +0200 Received: from FE-MBX1027.de.bosch.com ([fe80::e193:5977:194:af]) by FE-MBX1027.de.bosch.com ([fe80::e193:5977:194:af%16]) with mapi id 15.00.1236.000; Mon, 3 Jul 2017 12:26:19 +0200 From: "Kraus Achim (INST/ECS4)" To: "core@ietf.org" Thread-Topic: RFC6690 / 4.1. / interpretation of "search is a 1-element list" and {?search*} Thread-Index: AdLz5Oo/NgqdzxG8QhePnDeC9BYSBw== Date: Mon, 3 Jul 2017 10:26:19 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.22.84.74] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-23172.006 X-TMASE-MatchedRID: +SgbN5bOySBnuEpLNqEJssRS0pbiOfKbrrEvQogcy/FZLD9SNJ9sEnG3 IDkkj7AXzdUqNcSyJGckTpaDR3J9kOmFJKXVTT2daUe/i9AephOEfPcTMr/8fNTVzfvwECh5ViU w5w1aVIQv50wt3En5kDfvy4G6ykS5cvDWv1EqA6DI89FT1JwQNYYrUBjVTlyzqnMXQU3aA1CjvJ AEm9HZuLmBZRJK277mfyYDewMOrQDJzqAJgIs7jt0H8LFZNFG7hqz53n/yPnp47dEso4LpoaS4f SrJurS1odQsbs4XzPV0ZvZ3yx7c97oOfFLgUu3n Archived-At: Subject: [core] RFC6690 / 4.1. / interpretation of "search is a 1-element list" and {?search*} X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jul 2017 10:26:43 -0000 Hi all, after receiving a PR in an open source project, I'm not sure, what=20 RFC6690, 4.1 Query Filtering, exactly defines for the provided "search". >From the RFC: > /.well-known/core{?search*} > > where the variable "search" is a 1-element list that has a single name/va= lue pair Does this specify "a single 1-element list" at all,=20 or does the "*" behind the "search" in "{?search*}" specify a list of "1-el= ement lists"? If multiple "1-element lists" are specified, how is their matching defined? Are multiple searches "or" or "and" related? Mit freundlichen Gr=FC=DFen / Best regards Achim Kraus (INST/ECS4)=20 Bosch=A0Software Innovations=A0GmbH | Stuttgarter Stra=DFe 130 | 71332 Waib= lingen | GERMANY | www.bosch-si.com Tel. +49 711 811-58139 | Fax +49 711 811-58200 | achim.kraus@bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B=20 Gesch=E4ftsf=FChrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn=20 From nobody Mon Jul 3 13:09:40 2017 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 915321317AA; Mon, 3 Jul 2017 13:09:33 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149911257356.22722.5116552878549698625@ietfa.amsl.com> Date: Mon, 03 Jul 2017 13:09:33 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-senml-10.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:09:34 -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 of the IETF. Title : Media Types for Sensor Measurement Lists (SenML) Authors : Cullen Jennings Zach Shelby Jari Arkko Ari Keranen Carsten Bormann Filename : draft-ietf-core-senml-10.txt Pages : 46 Date : 2017-07-03 Abstract: This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-senml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-senml-10 https://datatracker.ietf.org/doc/html/draft-ietf-core-senml-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-senml-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 13:37:16 2017 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 B3EFA120454; Mon, 3 Jul 2017 13:37:13 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149911423368.22817.6993375314152787137@ietfa.amsl.com> Date: Mon, 03 Jul 2017 13:37:13 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-links-json-09.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 20:37:14 -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 of the IETF. Title : Representing Constrained RESTful Environments (CoRE) Link Format in JSON and CBOR Authors : Kepeng LI Akbar Rahman Carsten Bormann Filename : draft-ietf-core-links-json-09.txt Pages : 19 Date : 2017-07-03 Abstract: JavaScript Object Notation, JSON (RFC7159) is a text-based data format which is popular for Web based data exchange. Concise Binary Object Representation, CBOR (RFC7049) is a binary data format which has been optimized for data exchange for the Internet of Things (IoT). For many IoT scenarios, CBOR formats will be preferred since it can help decrease transmission payload sizes as well as implementation code sizes compared to other data formats. Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (RFC6690). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON, and similarly, inside constrained environments, in CBOR. This specification defines a common format for this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-links-json/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-links-json-09 https://datatracker.ietf.org/doc/html/draft-ietf-core-links-json-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-links-json-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 14:49:49 2017 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 5C75013157D; Mon, 3 Jul 2017 14:49:42 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149911858234.22774.6347445727990369714@ietfa.amsl.com> Date: Mon, 03 Jul 2017 14:49:42 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-resource-directory-11.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 21:49:42 -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 of the IETF. Title : CoRE Resource Directory Authors : Zach Shelby Michael Koster Carsten Bormann Peter van der Stok Christian Amsüss Filename : draft-ietf-core-resource-directory-11.txt Pages : 53 Date : 2017-07-03 Abstract: In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-resource-directory-11 https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 16:29:50 2017 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 4AB5413171F; Mon, 3 Jul 2017 16:29:42 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912458228.16104.13496123140866466222@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:29:42 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-rd-dns-sd-00.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:29:42 -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 of the IETF. Title : CoRE Resource Directory: DNS-SD mapping Authors : Kerry Lynn Peter van der Stok Michael Koster Christian Amsüss Filename : draft-ietf-core-rd-dns-sd-00.txt Pages : 10 Date : 2017-07-03 Abstract: TBD The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-rd-dns-sd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-rd-dns-sd-00 https://datatracker.ietf.org/doc/html/draft-ietf-core-rd-dns-sd-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 16:58:41 2017 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 1E25E13181C; Mon, 3 Jul 2017 16:58:37 -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.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912631709.15899.16297373023187659990@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:58:37 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-coap-pubsub-02.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:58:37 -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 of the IETF. Title : Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) Authors : Michael Koster Ari Keranen Jaime Jimenez Filename : draft-ietf-core-coap-pubsub-02.txt Pages : 23 Date : 2017-07-03 Abstract: The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-core-coap-pubsub-02 https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-coap-pubsub-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 5 04:23:52 2017 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 26CBE131CA2 for ; Wed, 5 Jul 2017 04:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 wmiFgUxliV1o for ; Wed, 5 Jul 2017 04:23:48 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.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 42251131C9A for ; Wed, 5 Jul 2017 04:23:47 -0700 (PDT) X-AuditID: c1b4fb30-71bff70000001664-8e-595ccc417b3c Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 18.9A.05732.14CCC595; Wed, 5 Jul 2017 13:23:45 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.42]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Wed, 5 Jul 2017 13:23:45 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" CC: Carsten Bormann , "draft-ietf-core-coap-senml@ietf.org" Thread-Topic: =?utf-8?B?8J+UlCBXR0xDIG9uIGRyYWZ0LWlldGYtY29yZS1jb2FwLXNlbm1s?= Thread-Index: AQHS9YEpx1mKBvRbS0erW9/y34h5MQ== Date: Wed, 5 Jul 2017 11:23:45 +0000 Message-ID: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/signed; boundary="Apple-Mail=_99371835-F10C-4EE7-83C8-F6374346495E"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUyM2J7oK7jmZhIg4utlhZHptxltdj3dj2z xdd3P9kdmD2WLPnJ5DFtUWYAUxSXTUpqTmZZapG+XQJXxpcvJ9gLltlVXP/cwtjA2GvdxcjJ ISFgIrH2+VbGLkYuDiGBI4wSb47vY4dwFjFKTLhxhQ2kik3AWeLTs0Z2EFtEQE2iddIrsDiz QKHE+o2/weLCAp4SU0+sYYGo8ZNoPngNytaTmPb2BSOIzSKgInG86QgziM0rYC+xff0SsDmM AmIS30+tYYKYKS5x68l8JojrRCQeXjzNBmGLSrx8/I8VwlaS+LHhEgvIocwCUxglJl/7ww4x VFDi5MwnLBMYhWYhmTULWd0sJHUQRUkS73dfY4OwtSWWLXzNDGFrSuzvXs6CKa4h0fltIiuE bSrx+uhHRgjbWmLGr4NQcxQlpnQ/ZF/AyL2KUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzAq D275bbCD8eVzx0OMAhyMSjy8y7bGRAqxJpYVV+YeYlQBmvNow+oLjFIsefl5qUoivGongdK8 KYmVValF+fFFpTmpxYcYpTlYlMR5HfddiBASSE8sSc1OTS1ILYLJMnFwSjUwtvH/Cy1/lPys e7NGafu+B71FdT89rt+5nfhc0PHM9fpV26f7ZXUkbN+49+RnszapEOtJE1JdWgNf91c2HI1f wyHNt5pFcPen5FUL4kPK56VP2Vpv0nJ6j+ax8AXRivMy76Rt/sywxa3Ca+Xhz5Z37oixsSlv +L/S8Y70UYOjnic8vv/aeWiSlxJLcUaioRZzUXEiABodwevSAgAA Archived-At: Subject: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 11:23:50 -0000 --Apple-Mail=_99371835-F10C-4EE7-83C8-F6374346495E Content-Type: multipart/alternative; boundary="Apple-Mail=_F0FDF60C-4023-487A-A08D-3DD3B9BE9165" --Apple-Mail=_F0FDF60C-4023-487A-A08D-3DD3B9BE9165 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear CoRE WG, The core-senml draft has gotten to a state that the authors feel is in = good shape for WGLC.=20 We will do a 2 week WGLC before next IETF.=20 https://tools.ietf.org/html/draft-ietf-core-senml-10 Best Regards, - - Jaime Jim=C3=A9nez= --Apple-Mail=_F0FDF60C-4023-487A-A08D-3DD3B9BE9165 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear CoRE = WG,

The = core-senml draft has gotten to a state that the authors feel is in good = shape for WGLC. 
We will do a 2 week WGLC before = next IETF. 

https://tools.ietf.org/html/draft-ietf-core-senml-10

Best = Regards,
- - Jaime Jim=C3=A9nez
= --Apple-Mail=_F0FDF60C-4023-487A-A08D-3DD3B9BE9165-- --Apple-Mail=_99371835-F10C-4EE7-83C8-F6374346495E Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMrTCCBe8w ggPXoAMCAQICEGjDnK4TEsyfW0+Qr43kvSowDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjA5MTMy MzExWhcNMTcxMjA5MTMyMzEwWjBpMREwDwYDVQQKDAhFcmljc3NvbjEXMBUGA1UEAwwOSmFpbWUg Smltw6luZXoxKTAnBgkqhkiG9w0BCQEWGmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdlamFqaW1uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9DiTCOChb1bYXyr VSnjxfVxZ+NGqajFezGGSWAWycgkTkiVdHu7Ek89luoUCU9D8KukeSlzeIFu+TdcANzelWOUqm53 Dh64KfoutxkI1g1FOk8+o45tjBFqw7xknXyEUhZ9/XLqaXuRdw7sCvO91Z05R37hwGhscO7M0fgv lRtWBxaqbC/Ikvjo+PPqt5zpx+GFaqsJ0+4ZQWjrb6I+8e8EAxCpLqB9HmCAztI+zog/tzaSDQdd gQVjLDAndvnKRziQvOrYc5kvJHkXzLcWITDYmi5pZrgNRBJL2poiwSopQPlF5bGjaRYu2WBytXe2 SDEj1viuqpae1vxy7+AdUwIDAQABo4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwJQYDVR0RBB4wHIEaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20wVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBQ58oLpEh/5VlA3MqHd3ggGy2cPpzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBABcJc9IVKYtDtvxGDcoFbAFvNeiH +bRaEu1d9BWRhjtb8ZAU586LmsSwblH+2rbFRtisroKUwq7tZyjQtCrL7Rma0yM74p5PNZ7sGfmz yNZT33hfTZEDo7bjKdaUg0ELBzQvttjIIr7tBVf9cpdOAyOkGn3oqGEomPizRDiKrXBD3V8oMibX nQDb90hg8TJmLb9mqyaRnu1ztxV2585qJUXXPAt1v6qUy23V+tmOE7JzMxrQwa5UupoS/muaQSsR 7Evde7pXBg8jERM7o4VZJIA7LI55ogyb37O7W2zhITXzbHgjQzLoS6MonjIPegCv3pLgdLx0zXhp SUT19qg2LmX1sXTxLJBSJp5eev+x8B7H14taM8FpsAVGLccstjPuxOabdmNNaEvfSBL7GPtQ5Sil DTMdbxhtuFPlP+1p4tPC6A/85YQozqTKCgk28emo8UupTt28DZgfP5b7xpBbnrsA/2aRYpmV2Ay8 BOd8g4O+ZP0WZD9/vPddUDBYPpJiSulKe6uj15vsiiBY4D272VS0dMpwXOvmkKKS/ZAmarywk0hy bl2mb+GW456+N8CESWD4JIHABoXxVAaa0GdGEyL1lSEmw7jOU2h5UAhlhHqPudpSoaLJgqateP2C hWYGv/DwkR9bVpuO8k1ohfjJA4n0qgxfOkWU23sZgo6495KjMIIGtjCCBJ6gAwIBAgIRAKAMy8yb mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP 5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1 41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9 kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg 36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ 6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5 tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6 n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApIC AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA3MDUxMTIzNDRaMCMGCSqGSIb3DQEJBDEWBBT2 FOZ7nDcuzbYqurWOikZYhBkdTDBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLMn1tPkK+N5L0q MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjANBgkqhkiG9w0BAQEFAASC AQB375+AnBhyXaXCVTLlr02s/i/0n7uNUr8285SIWtdk5i91N79APboxPVvd8y9aDp3FqGmFMHri 4rnxSGJR3A8F+U+RPNQvcjOVAKeg4Odt1sGT9Uawssk0yGgq6xK9CSNlkG60KNjCdgJN8OI+NOil PJwH9dN1R0J7pMW7cpPLRCFU56pPzrC+cHgNGN0zDJCeKtjwy07yTCzji+Q9W4Xfpv4BGAe1w1gV jkRHujZAPvvKp60scgF1/yCOmrb5tLQH36qAISPKEIArDTA0B3uF3WkTRRE8+bbp9fyKIbjzRJuB VeonGzFFW9uI6zZM5P02LhvWrwlqnTWJpNbmv/9PAAAAAAAA --Apple-Mail=_99371835-F10C-4EE7-83C8-F6374346495E-- From nobody Wed Jul 5 06:38:34 2017 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 5049E132A29 for ; Wed, 5 Jul 2017 06:38:33 -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 bc17Hidv0ZOZ for ; Wed, 5 Jul 2017 06:38:32 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 ABEFC131CF3 for ; Wed, 5 Jul 2017 06:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v65DcQJo024278; Wed, 5 Jul 2017 15:38:26 +0200 (CEST) Received: from [IPv6:2001:638:708:18::55] (unknown [IPv6:2001:638:708:18::55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3x2hlk6ZQyz3b57; Wed, 5 Jul 2017 15:38:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> Date: Wed, 5 Jul 2017 15:38:26 +0200 Cc: "core@ietf.org WG" , "draft-ietf-core-coap-senml@ietf.org" X-Mao-Original-Outgoing-Id: 520954706.230088-dc3fdf0977f9d81bb898544f4459f697 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> To: =?utf-8?Q?Jaime_Jim=C3=A9nez?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 13:38:33 -0000 On Jul 5, 2017, at 13:23, Jaime Jim=C3=A9nez = wrote: >=20 > Dear CoRE WG, >=20 > The core-senml draft has gotten to a state that the authors feel is in = good shape for WGLC.=20 > We will do a 2 week WGLC before next IETF.=20 >=20 > https://tools.ietf.org/html/draft-ietf-core-senml-10 As an author, let me add: One question that we also want to decide in this WGLC is whether to keep = the link extension in this Proposed-Standard-to-be, or whether it merits = its own document. It is not in the same state of completion as the rest = of the document, and it has served a bit of its purpose making sure that = the extension mechanism is in place and can be used. It=E2=80=99s just = that the extension itself may not yet be ready for prime time, and it = may become better from spending a bit more time in a separate document. Please send your comments on this question as well as the typical WGLC = comments to core@ietf.org (or, for purely editorial comments, to = draft-ietf-core-senml@ietf.org, but do indicate that you have read the = document to core@ietf.org). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 5 11:42:41 2017 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 4C017131DB9 for ; Wed, 5 Jul 2017 11:42:40 -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 dY-9TbOZ3DqK for ; Wed, 5 Jul 2017 11:42:38 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 1B60712EC1B for ; Wed, 5 Jul 2017 11:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v65IgY2X026116 for ; Wed, 5 Jul 2017 20:42:35 +0200 (CEST) Received: from [192.168.217.124] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3x2qVf5Rljz3bCT; Wed, 5 Jul 2017 20:42:34 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 520972953.282136-acf420954bff85e0650563bcee8d68fc Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 5 Jul 2017 20:42:33 +0200 Message-Id: <18D94075-7E1F-4D64-A370-41EC40643CBB@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] Agenda planning for CoRE @ IETF99 in Prague X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 18:42:40 -0000 A super-drafty agenda based on what has been submitted is at: https://datatracker.ietf.org/meeting/99/agenda/core/ Those who want to run slots: Please =E2=80=94 check the objectives we have guessed (or supply ones where we = haven=E2=80=99t) =E2=80=94 estimate how much time the slot will need =E2=80=94 agree who should run which slot =E2=80=94 send a message with this information to core-chairs@ietf.org If you think there should be a slot on a subject and the document is not = listed (or is listed under =E2=80=98no time this time=E2=80=99), please = answer these questions, too. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 6 05:00:16 2017 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 A7AFB12EB2B for ; Thu, 6 Jul 2017 05:00: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 d-9y1zE6vgtV for ; Thu, 6 Jul 2017 05:00:13 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 DC62313155F for ; Thu, 6 Jul 2017 05:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v66C09Pp005920 for ; Thu, 6 Jul 2017 14:00:09 +0200 (CEST) Received: from client-0194.vpn.uni-bremen.de (client-0194.vpn.uni-bremen.de [134.102.107.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3x3GWs3GBGz3Yyj; Thu, 6 Jul 2017 14:00:09 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <18D94075-7E1F-4D64-A370-41EC40643CBB@tzi.org> Date: Thu, 6 Jul 2017 14:00:08 +0200 X-Mao-Original-Outgoing-Id: 521035208.449849-95c709e92e4353435e112c4862e85815 Content-Transfer-Encoding: quoted-printable Message-Id: <8F5CD351-2D38-4A61-B472-DA8BE43431F3@tzi.org> References: <18D94075-7E1F-4D64-A370-41EC40643CBB@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Agenda planning for CoRE @ IETF99 in Prague X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 06 Jul 2017 12:00:16 -0000 On Jul 5, 2017, at 20:42, Carsten Bormann wrote: >=20 > A super-drafty agenda based on what has been submitted is at: >=20 > https://datatracker.ietf.org/meeting/99/agenda/core/ Update available; I started moving things based on preferences of people = and started allocating time. We have 40 minutes flextime on Wednesday, but we have 30 minutes = overtime on Friday. So something may have to move back to Wednesday. = Maybe SenML will have a slightly shortened WGLC=E2=80=A6. But even that = is not enough. (Broken record mode:) > Those who want to run slots: Please >=20 > =E2=80=94 check the objectives we have guessed (or supply ones where = we haven=E2=80=99t) > =E2=80=94 estimate how much time the slot will need > =E2=80=94 agree who should run which slot > =E2=80=94 send a message with this information to core-chairs@ietf.org >=20 > If you think there should be a slot on a subject and the document is = not listed (or is listed under =E2=80=98no time this time=E2=80=99), = please answer these questions, too. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 7 19:08:32 2017 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 1C1C3131559 for ; Fri, 7 Jul 2017 19:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 ivd6vV1kC4RO for ; Fri, 7 Jul 2017 19:08:30 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807EE13154E for ; Fri, 7 Jul 2017 19:08:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499479695; h=from:subject:to:date:message-id; bh=qdDxqYZjCd31sK/2G5mXamgS9buIFT/uKNTViiKsE3U=; b=SBFTL4lBkYKWtFp+MUCvTPLqIIPc6U3AZvCBHlnXIOXV1xKW82Rbx+Sm0HhQiER8Z13ZbVK/qUP VBhQKUCTAJf72uDvKssK/amXYyX09ASMrwxg3nTW2r+dNZvEWOlbsyH/sOQNPxeDkBcoHZU8CRxxU oZAp/kqtZFVNDxT3JgpsLQC6r0Qd7xt1y4WxU/QztlFQ6wFPYhl33yiJcp2H5hHSuDuRNN7Erruym xSNjF/BabKPzcLb0ehYO04nCWI8bkAwvM3l/8CtxJllrLgN432WJJ0hjTK74JR6YpJy4gGAqIfX+Q HuX5SCIXwOUHYAT98H7ZOFmUW+A5guuyifWQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Jul 2017 19:08:15 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Jul 2017 19:08:15 -0700 From: Jim Schaad To: Date: Fri, 7 Jul 2017 19:08:21 -0700 Message-ID: <02b301d2f78f$14aad650$3e0082f0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdL3fat3MQkflgWmTNOu0xyqxwm5jA== X-Originating-IP: [24.21.96.37] Archived-At: Subject: [core] Web Link Attribute parsing problems X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jul 2017 02:08:32 -0000 I have been going through my code base looking to get draft-ietf-core-links-json implemented as well as making sure that my implementation of RFC 6690 (CoRE Link Format). At this point in time, I cannot see anyway to future proof my implementation of this code because of how RFC 6690 decided to address a compression optimization. My code currently does not do a good job of deciding which attributes are to be split when they are space separated (i.e. 'rt') and which should be kept as a single string (i.e. 'title'). I can easily get a list of the things that should be treated in which direction right now, however going forward into the future that will not be the case. When the code sees a new link, it will not know what the correct processing is in the event that a space occurs in the value field. As an example of what I am looking at. I get a new WebLink with the attribute of ct=0;bletch="foo bar" I then get a discovery query get /.well-known/core?bletch="foo" is "googoo" supposed to be a match or not? If it is a single string, ala 'title', then it is not a match. If it is space separated attibutes, ala 'rt', then it is a match. Is there a recommended way to proceed? Jim From nobody Fri Jul 7 21:01:09 2017 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 B6804127201 for ; Fri, 7 Jul 2017 21:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[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 ZaiYhsYcRnOM for ; Fri, 7 Jul 2017 21:01:06 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 A16ED126C2F for ; Fri, 7 Jul 2017 21:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6840RBm010845; Sat, 8 Jul 2017 06:00:27 +0200 (CEST) Received: from client-0003.vpn.uni-bremen.de (client-0003.vpn.uni-bremen.de [134.102.107.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3x4HnR2h7nz3ZWM; Sat, 8 Jul 2017 06:00:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <02b301d2f78f$14aad650$3e0082f0$@augustcellars.com> Date: Sat, 8 Jul 2017 06:00:26 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 521179226.139943-7c305af7fe4c705ce9c4be5d5910e539 Content-Transfer-Encoding: quoted-printable Message-Id: References: <02b301d2f78f$14aad650$3e0082f0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Web Link Attribute parsing problems X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 08 Jul 2017 04:01:08 -0000 Hi Jim, It is indeed a weakness of RFC 6690 that it does not define a way to = find out which future attributes are going to be space-separated lists = and which ones aren=E2=80=99t. (It is hinting at using this for = "relation-type attributes=E2=80=9D, but there is no way to guess whether = that is the case for an attribute unknown to the parser.) > Is there a recommended way to proceed? Implementation-wise, I would give the application a way to provide a = list of attribute names for =E2=80=9Crelation-type attributes=E2=80=9D. = Beyond that, I also don=E2=80=99t know how to implement functions such = as discovery queries without that semantic knowledge. Maybe we should at least press forward with having a registry for = attributes; the space-separatedness can then be a column in the = registration template. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jul 10 11:57:14 2017 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 DA110131874; Mon, 10 Jul 2017 11:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 9hMUswyI0IH1; Mon, 10 Jul 2017 11:57:10 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F2D131872; Mon, 10 Jul 2017 11:57:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499713017; h=from:subject:to:date:message-id; bh=WMI5V6gxRyL3FtbQTYSfKq3/JO5AD/ZI5QhmcN79Hmc=; b=VEZLFzASOZY30heJtISc/x70XF3xk4Gbmwir4kd9LziKf9r1Ekovn83yehV18ahW/x8t6I2U0N4 3s45L+Uo0FZTyxg6BW2nC0XBwXucTRz/NbJOLnpFhMCUhoSwg40O3num2awFH+8fHr7UQljzhMtfA KZnbn+vv9zxNE4ITd/lPeAq98a/ekk44Gr4Fner6COZd+OAvLhGM5417i6Dvz/umiioOh3x8FUtZU NKRWRef/YO0FudyhugADtuvV+q1uA3Vcoe+CQAgRE1p8OKQjxdg9WkcYXxphMCKdyPy3z4jTCnEGj 3cU92R5GpPnUGAX4QodFBbQigKPaZqli0H3w== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Jul 2017 11:56:56 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Jul 2017 11:56:52 -0700 From: Jim Schaad To: CC: Date: Mon, 10 Jul 2017 11:57:00 -0700 Message-ID: <03c301d2f9ae$51878f70$f496ae50$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdL4FZVMYBxUua5bSXutzLPiLJWlnA== X-Originating-IP: [24.21.96.37] Archived-At: Subject: [core] Review on draft-ietf-core-coap-pubsub-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 10 Jul 2017 18:57:13 -0000 Status: This document is not yet ready for a WGLC in my opinion. I have copied forward some comments from past reviews where I have not seem them addressed or do not believe that they are sufficiently dealt with. * Section 3.4 - s/are hosted at the broker and all clients using the broker share/are hosted by a broker and all clients using that broker share/ - a) you can have multiple brokers and b) the name spaces in that case are going to be distinct and potentially overlapping in name w/different values. * Section 3.4 - "zero or more stored representations with a content-format" I think this is supposed to be "zero or more values - one content-format". But the first time I read this, I read this as" zero or more representations - each representation has a content format - may be zero or one (?) value". I always worry about what is "current" not what is "history" and assume that observe is correctly implemented. Note this does go back to the question of "is this a queue of values" that Hannes has raised in the past. * Section 4.2 - cut and paste error for topic and q as template variables. I believe that q should be removed from the template as it makes no sense. * Section 4.2 - Is the following legal for payload of a create ";ct=50" - this is a legal link but may not be legal for creation of a topic. * Section 4.2 - Is the following legal for the payload of a create ";ct=50" - The text current says the target of the link is a "URI formatted string" rather than a fragment. * Section 4.2 - I cannot tell if the requirement for returning 4.04 (not found) is new in this document or should be part of RFC 6690 or not. I cannot seem to find this requirement in that document. Are you sure you want to do this rather than just return an empty content? Should there be an errata on RFC 6690? * Section 4.2 - There is an implicit statement in section 4.3 that a single content type is expected. However, there is no explicit statement here that a request with multiple content types is forbidden. Is there really a requirement that a single content type be required when creating a topic? What happens if no 'ct' is specified? * Section 4.3 - Is a server supposed to accept a publish operation to a non-existent location with a POST method? * Section 4.3 - Is there any reason to accept publish via POST and not PUT? Or the other way around? * Section 4.3 - If no Max-Age is on the publish request, should the default value be used or should an infinite value (i.e. absent) be used. If a Max-Age was supplied at the time the subject was created, does that change things? If a publish is done with a Max-Age greater than that provided at creation, what should happen. Which wins? * Section 4.3 - Copy and paste error on the topic and q template variables. Does 'q' even make sense here? * Section 4.3 - Text dealing with propagating publish events up the tree to keep nodes alive is missing. * Section 4.4 - Copy and paste error on the topic and q template variables. Does 'q' even make sense here? * Section 4.4 - Is it permitted that a broker remove a subscription due to lack of ACK for a CON w/o sending the "unsubscribed" message? The document does not seem to allow that. * Section 4.5 - Copy and paste error on the topic and q template variables. Does 'q' even make sense here? * Section 4.6 - Copy and paste error on the topic and q template variables. Does 'q' even make sense here? * Section 4.7 - Is remove recursive? * Section 4.7 - What would the correct content be to send an unsubscribe notification on a remove operation? '2.07 no content' or '2.02' deleted or '4.04' not found? * Section 8 - If enforcing access policies is of importance, how are they set? * Section 8 - It may be that '4.01 Unauthorized' is a better response than '4.04 Not Found' in some cases. Doing this does not allow for probing of what topics exist when one does not have access to the directory of topics. * Consider the following scenario - Create node foo - ct=40, Max-Age=10 - Create node foo/bar - ct=0, Max-Age=20 - Publish to foo/bar @ time=5 When you get to time=15, should the node foo be deleted or does the max-age of foo/bar change that answer? * Currently an application can use CON to ensure that a server will get a message in the long run. The fact that this is no doable here should be briefly discussed as an client cannot know that a server has or has not received a message. Minor: * Section 3.4 - s$"EP-33543/sen$"/EP-35543/sen$ - either that or remove the leading slash for sensors Philosophy problem: I am not happy with the way that 2119 language is sprinkled throughout this document. That is not a statement that you need to change it, but it is a request that you revisit and look at what is there. * MUST and SHOULD statements need to be able to have some type of test written from them. If you cannot write a test, then using the key words is probably incorrect. * SHOULD and MAY statements ought to have some type of language about when the action under consideration would not be done. * MAY statements are almost always a waste of time and should be written in a different manner. * Consider the first sentence in section 4.3. Is there a reason why this is not changed to "This section is optional to implement." and leave it at that? * Consider the second sentence in section 4.3. It implies that there is a third method that the client can use to publish, what is that method? I don't currently know of one. This saying "A client uses the POST or PUT method to publish ..." seems to be an adequate statement w/o the MAY. * Once upon a time, there was a requirement to extract and test all of the MUSTs in a document and a strong suggestion to test all of the SHOULDs in a document. Too many make things hard to see if you have adequate coverage. Too few and you might not have interop working correctly. In many cases, a MUST can be expressed w/o the key work. Consider the 2.04 sentence in section 4.3 paragraph 1 - It can be written as "The broker returns a "2.04 Changed" response if the publish request is accepted". This has the same information as the current statement but w/o the MUST. The two following sentences should probably also be a MUST type statement so that a client knows what is going on rather than returning something strange. (That can be countered in the case of '4.04 Not Found' to maybe be '4.01 Unauthorized' as a reasonable response to prevent knowledge of what topics exist.) Jim From nobody Mon Jul 10 13:21:27 2017 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 31E4712F258; Mon, 10 Jul 2017 13:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 Uj5imn9pBaTx; Mon, 10 Jul 2017 13:21:24 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BF11318A9; Mon, 10 Jul 2017 13:21:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499718062; h=from:subject:to:date:message-id; bh=ctZV/nbiK5VWIAkFX8fJw/FpYbz0JuVfePjllTmbUnE=; b=MdTJLcnvHTm/127/v8UkhO6290urv+k49yaPe+AsVQGD85dW01Fp1uYcUgySqPFXbzSJa1zG2su HhFWYUOuJfLSP6ub7zC4rpD6Il3+y3IgKJ0LInRxK5lhI6CqzumyZRMbfN+wMRTtDGnU/Rcp3tNNR PAC83zhJZAieell1H7dwvoKGZsch6eZuJupaDnWvZ7CzL6SxOvPHZhUA1KT3AlFZR9DXgg4I4Sric T6+0mJ6KcjfnZWeYeGptgNxo2GHOcGzVUv4fbSdj+Lo82QQnOnP6d1gedV0B3jpEQjX2Wrc/UClK4 HZgAYb7H8QGPs4vIJngN+p7KRCLT+Mm0XXnA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Jul 2017 13:21:02 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Jul 2017 13:20:58 -0700 From: Jim Schaad To: CC: Date: Mon, 10 Jul 2017 13:21:06 -0700 Message-ID: <03d901d2f9ba$1164fcf0$342ef6d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdL5tFMStCdiHSWoSUiI/Jk3ZA+n4Q== X-Originating-IP: [24.21.96.37] Archived-At: Subject: [core] draft-amsuess-core-repeat-request-tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 10 Jul 2017 20:21:25 -0000 I have some comments on the draft based on a first read. * Section 2.1 - Why is this a 64-bit value? In the case of end-to-end security, this could be a single byte assuming that only 256 requests would be outstanding for that security context. * Section 2.1 - The fact that you need to distinguish between the name of the option and the bit flags indicates that the name should probably be changed. I need to sit down and work out the flows for the Request-Tag and ETag options. I think that there may be a missing security consideration on ETag, but I need to figure out exactly how things work first. jim From nobody Mon Jul 10 23:16:57 2017 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 DE5BB131452; Mon, 10 Jul 2017 23:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YwB5LXSUgyx7; Mon, 10 Jul 2017 23:16:53 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.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 5C563131447; Mon, 10 Jul 2017 23:16:53 -0700 (PDT) X-AuditID: c1b4fb30-71bff70000001664-ab-59646d53d7aa Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6D.64.05732.35D64695; Tue, 11 Jul 2017 08:16:51 +0200 (CEST) Received: from ESESSMB107.ericsson.se ([169.254.7.42]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Tue, 11 Jul 2017 08:16:51 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , "draft-amsuess-core-repeat-request-tag@ietf.org" CC: "core@ietf.org" Thread-Topic: draft-amsuess-core-repeat-request-tag Thread-Index: AdL5tFMStCdiHSWoSUiI/Jk3ZA+n4QAWPSKA Date: Tue, 11 Jul 2017 06:16:51 +0000 Message-ID: References: <03d901d2f9ba$1164fcf0$342ef6d0$@augustcellars.com> In-Reply-To: <03d901d2f9ba$1164fcf0$342ef6d0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2K7tG5wbkqkwe5fGhb73q5ntth2dh+r xerp39kcmD02zpnO5rFkyU+mAKYoLpuU1JzMstQifbsEroyuSSvZC26IVOz5doK9gXGKSBcj J4eEgInEt40bWLoYuTiEBI4wSlzfdZAJJCEksJhRYsU0PRCbTcBF4kHDIyaQIhGBPkaJNVum MoIkmAWUJY7PPswKYgsLGEtM7F/BDmKLAE39+ngdE4RtJHHk8G+gGg4OFgFVib3dXiAmr4CF xPJDihCr7CV+7WxhBrE5BRwkbrS/ApvOKCAm8f3UGiaITeISt57MZ4K4WUBiyZ7zzBC2qMTL x//ALhAV0JPY29POBhFXklh7eDsLyCpmAU2J9bv0IcZYSxyfupENwlaUmNL9EOxgXgFBiZMz n7BMYBSfhWTbLITuWUi6ZyHpnoWkewEj6ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwJg7 uOW3wQ7Gl88dDzEKcDAq8fCWWyVHCrEmlhVX5h5ilOBgVhLhNfNOiRTiTUmsrEotyo8vKs1J LT7EKM3BoiTO67jvQoSQQHpiSWp2ampBahFMlomDU6qB0ZFbc2GD7cWpRfe3ljNkm6jKrHYu f3cxUVZImdPFa/X+V/cef59y3lJ79q3yKosF6iEvX6U57zFs6wu9zh1qel90m/C6eP1sgXtC s3YGL15wTFs6d9KDCwkevkdr+ptV5sz+yRH9cr/XxqZU9w+yG/UPHfBivm7g/arcvm6v8efZ rVYc92SfKLEUZyQaajEXFScCADccLXq1AgAA Archived-At: Subject: Re: [core] draft-amsuess-core-repeat-request-tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 11 Jul 2017 06:16:56 -0000 DQpHb29kIGNvbW1lbnRzLCBpbmxpbmUuDQoNCk9uIDIwMTctMDctMTAgMjI6MjEsICJKaW0gU2No YWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQoNCj5JIGhhdmUgc29tZSBjb21t ZW50cyBvbiB0aGUgZHJhZnQgYmFzZWQgb24gYSBmaXJzdCByZWFkLg0KPg0KPg0KPiogU2VjdGlv biAyLjEgLSBXaHkgaXMgdGhpcyBhIDY0LWJpdCB2YWx1ZT8gIEluIHRoZSBjYXNlIG9mIGVuZC10 by1lbmQNCj5zZWN1cml0eSwgdGhpcyBjb3VsZCBiZSBhIHNpbmdsZSBieXRlIGFzc3VtaW5nIHRo YXQgb25seSAyNTYgcmVxdWVzdHMNCj53b3VsZA0KPmJlIG91dHN0YW5kaW5nIGZvciB0aGF0IHNl Y3VyaXR5IGNvbnRleHQuDQoNClJlbWVtYmVyIHRoYXQgb25lIHVzZSBvZiB0aGlzIG9wdGlvbiBp cyBmb3Igc2VjdXJlbHkgc3luY2hyb25pc2luZyBzdGF0ZSwNCmUuZy4gYSBzZXF1ZW5jZSBudW1i ZXIgdG8gcHJldmVudCBmcm9tIGEgcmVwbGF5IGF0dGFjayBpbiBjYXNlIG9mIGxvc3Mgb2YNCnBv d2VyLiBJZiB3ZSB0aGluayB0aGF0IHNlcXVlbmNlIG51bWJlcnMgY2FuIGJlIHVzZWQgaW4gYSBz aW1wbGUgd2F5IHRvDQpwcmV2ZW50IHRoaXMsIHRoZW4gd2Ugc2hvdWxkIHByb2JhYmx5IGRvIHRo YXQgaW4gdGhlIGZpcnN0IHBsYWNlIDotKQ0KDQpXZSBkaWQgY29uc2lkZXIgbW9yZSBjb21wbGlj YXRlZCBwcm9jZXNzaW5nIGFuZCBzbWFsbGVyIHZhbHVlIGJ1dCB0aGVuDQpzZXR0bGVkIGZvciB0 aGUgc2ltcGxlIHByb3RvY29sIGFuZCB0aGUgbGFyZ2VyIHZhbHVlLiBJZiB5b3UgdGhpbmsgdGhp cw0KY2FuIGJlIG1hZGUgc2ltcGxlIGVub3VnaCBieSBqdXN0IGVudW1lcmF0aW5nIHZhbHVlcyBw bGVhc2UgbWFrZSBhIHB1bGwNCnJlcXVlc3QuDQoNCj4NCj4qIFNlY3Rpb24gMi4xIC0gVGhlIGZh Y3QgdGhhdCB5b3UgbmVlZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoZSBuYW1lIG9mDQo+dGhl IG9wdGlvbiBhbmQgdGhlIGJpdCBmbGFncyBpbmRpY2F0ZXMgdGhhdCB0aGUgbmFtZSBzaG91bGQg cHJvYmFibHkgYmUNCj5jaGFuZ2VkLg0KDQpJdCBtYXkgYmUgb2J2aW91cywgYnV0IHdlIGRpZG7i gJl0IHRoaW5rIGFib3V0IGl0IHVudGlsIGp1c3QgYmVmb3JlDQpzdWJtaXNzaW9uIHRoYXQgdGhl cmUgbWF5IGJlIGEgcG90ZW50aWFsIGNvbmZ1c2lvbiBiZXR3ZWVuIHRoZSBuYW1lIG9mIHRoZQ0K b3B0aW9uIOKAnFJlcGVhdOKAnSBhbmQgdGhlIHByb3BlcnR5IG9mIGFuIG9wdGlvbiBiZWluZyDi gJxSZXBlYXRhYmxl4oCdLCB3aGljaCBpcw0KdGhlIHJlYXNvbiBmb3IgdGhlIHRleHQgaW4gMi4x LiBJZiBwZW9wbGUgdGhpbmsgdGhpcyBpcyBhbiBpc3N1ZSB3ZSBzaG91bGQNCm9mIGNvdXJzZSBj aGFuZ2UgdGhlIG5hbWUuIChMZXQncyB0YWtlIHRoZSBkaXNjdXNzaW9uIG9mIHdoYXQgdGhlIG5h bWUNCnNob3VsZCBiZSBvZmYtbGlzdCwgc2luY2UgdGhlcmUgaXMgYSB0ZW5kZW5jeSB0byBzcGVu ZCBtb3JlIHRpbWUgbmFtaW5nDQp0aGluZ3MgcmF0aGVyIHRoYW4gZGlzY3Vzc2luZyBob3cgdGhp bmdzIHdvcmsgOi0pDQoNCj4NCj5JIG5lZWQgdG8gc2l0IGRvd24gYW5kIHdvcmsgb3V0IHRoZSBm bG93cyBmb3IgdGhlIFJlcXVlc3QtVGFnIGFuZCBFVGFnDQo+b3B0aW9ucy4gIEkgdGhpbmsgdGhh dCB0aGVyZSBtYXkgYmUgYSBtaXNzaW5nIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gb24NCj5FVGFn LCBidXQgSSBuZWVkIHRvIGZpZ3VyZSBvdXQgZXhhY3RseSBob3cgdGhpbmdzIHdvcmsgZmlyc3Qu DQoNClBsZWFzZSBkbywgdGhlIGFuYWxvZ3kgYmV0d2VlbiBSZXF1ZXN0LVRhZyBhbmQgRVRhZyBp cyBhbm90aGVyIHRoaW5nIHdlDQpoYXZlIGJlZW4gdGhpbmtpbmcgYWJvdXQuIENocmlzdGlhbiBt YXkgd2FudCB0byBhZGQgc29tZXRoaW5nIGhlcmUuDQoNClRoYW5rcw0KR8O2cmFuDQoNCg0K From nobody Wed Jul 12 12:50:22 2017 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 EDB3312EC17 for ; Wed, 12 Jul 2017 12:50:20 -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 lz-Fji7s5Ruy for ; Wed, 12 Jul 2017 12:50:20 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 992BA129B34 for ; Wed, 12 Jul 2017 12:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6CJoGh7010639 for ; Wed, 12 Jul 2017 21:50:16 +0200 (CEST) Received: from client-0027.vpn.uni-bremen.de (client-0027.vpn.uni-bremen.de [134.102.107.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3x78gX3xjQzDK8G; Wed, 12 Jul 2017 21:50:16 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 521581815.840347-7f7ecde5ca293d1d603f0661af6b6af0 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Jul 2017 21:50:16 +0200 Message-Id: <16B657AC-B2BC-42B2-AD6C-62AE19B97808@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] Come Out and Play X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 12 Jul 2017 19:50:21 -0000 If you have trouble remembering what =E2=80=9CCoAP=E2=80=9D stands for: http://brooklynreporter.com/story/brooklynites-gearing-come-play-dumbo/ I think that phrase actually makes a great sequel to the 1990s slogan of = =E2=80=9CPlug and Play=E2=80=9D :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 13 05:39:59 2017 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 2C33012EC13; Thu, 13 Jul 2017 05:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dW82U1aALNAF; Thu, 13 Jul 2017 05:39:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9BAC131A67; Thu, 13 Jul 2017 05:39:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKH65020; Thu, 13 Jul 2017 12:39:45 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 13 Jul 2017 13:39:43 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.147]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0301.000; Thu, 13 Jul 2017 18:09:31 +0530 From: Raja ashok To: "goran.selander@ericsson.com" , "draft-ietf-core-object-security@ietf.org" CC: "core@ietf.org" Thread-Topic: Doubts in draft-ietf-core-object-security Thread-Index: AdL71RHIJFGFQkrRQUCixg0rsoEXNA== Date: Thu, 13 Jul 2017 12:39:30 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.121] Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E22F904DBLREML503MBXchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59676A12.0008, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.9.147, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 11a094cf15b1d63189deee1ecffba018 Archived-At: Subject: [core] Doubts in draft-ietf-core-object-security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 12:39:58 -0000 --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E22F904DBLREML503MBXchi_ Content-Type: multipart/alternative; boundary="_000_FDFEA8C9B9B6BD4685DCC959079C81F5E22F904DBLREML503MBXchi_" --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E22F904DBLREML503MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgR29lcmFuIFNlbGFuZGVyLA0KDQpJIGhhdmUgZ29uZSB0aHJvdWdoIHRoZSBPU0NPQVAgYW5k IEVESE9DIGRyYWZ0cy4gQW5kIEkgYW0gaGF2aW5nIGZldyBkb3VidHMgaW4gaXQuIFBsZWFzZSBw cm92aWRlIHlvdXIgY29tbWVudHMgb24gaXQuDQoNClRoaXMgc3BlY2lmaWNhdGlvbiBtYWtlcyBo YW5kc2hha2UoRURIT0MpIGZvciBkZXJpdmluZyBtYXN0ZXIgc2VjcmV0IGFzIG9wdGlvbmFsLiBB bmQgYWxzbyBhIGNvbnN0cmFpbnQgbm9kZSBjYW4gc2tpcCBoYW5kc2hha2UgYW5kIGVzdGFibGlz aCBhIHNlY3VyZSBjaGFubmVsIGlmIG1hc3RlciBzZWNyZXQgaXMgcHJlY29uZmlndXJlZC4NCg0K VGhpcyBtYXkgbWFrZSBhIGNvbnN0cmFpbnQgbm9kZSB0byB1c2Ugc2FtZSBzZXNzaW9uIGtleXMg KHNlbmRlciBhbmQgcmVjZWl2ZXIga2V5KSBmb3IgbG9uZ2VyIGR1cmF0aW9uLCBpZiBzZXF1ZW5j ZSBudW1iZXIgaXMgbm90IGV4aGF1c3RlZC4gT25seSBzb2x1dGlvbiBmb3IgcmVuZXdpbmcgc2Vz c2lvbiBrZXkgaXMgdG8gbmVnb3RpYXRlIG5ldyBtYXN0ZXIgc2VjcmV0IGJ5IHVzaW5nIEVESE9D LiBCdXQgRURIT0Mgc3VwcG9ydHMgb25seSBQU0tfRUNESEUgYW5kIEVDRFNBX0VDREhFIG1lY2hh bmlzbS4gSGVyZSBJIGZlZWwgd2UgYXJlIG1pc3NpbmcgUFNLIHdpdGhvdXQgKEVDKURIRSBtZWNo YW5pc20gZm9yIGVzdGFibGlzaGluZyBzZWN1cmUgY2hhbm5lbC4gSSBtZWFuIHdlIGFyZSBtaXNz aW5nIFRMU19QU0tfV0lUSF9BRVNfMTI4X0NDTV84IGtpbmQgb2YgbWVjaGFuaXNtLg0KDQpJbiBE VExTLCBUTFNfUFNLX1dJVEhfQUVTXzEyOF9DQ01fOCB1c2VzIHNhbWUgUFNLIGV2ZXJ5IHRpbWUg Zm9yIGRlcml2aW5nIHNlc3Npb24ga2V5cywgYW5kIGl0IGRvZXNuoa90IHN1cHBvcnQgUEZTLiBC dXQgdGhlIHNlc3Npb24ga2V5IGRlcml2ZWQgaXMgZGlmZmVyZW50IGV2ZXJ5IHRpbWUgd2l0aCB0 aGUgaGVscCBvZiBjbGllbnQgYW5kIHNlcnZlciByYW5kb20uDQoNClNvIEkgZmVlbCB3ZSBjYW4g Y29uc2lkZXIgb2YgZXhjaGFuZ2luZyByYW5kb20gbnVtYmVyIGFsc28gYWxvbmcgd2l0aCBLSUQg YW5kIFBhcnRpYWwgSVYgaW4gdGhlIDFzdCBSZXF1ZXN0IGFuZCBSZXNwb25zZS4gVG8gYWNoaWV2 ZSBUTFNfUFNLX1dJVEhfQUVTXzEyOF9DQ01fOCBraW5kIG9mIG1lY2hhbmlzbSBpbiBPU0NvQVAg d2l0aG91dCBFQ0RIRSBleGNoYW5nZS4gRm9yIHRoaXMgYW55d2F5IHdlIGhhdmUgdG8gY29uc2lk ZXIgbXVsdGlwbGUgZmFjdG9ycyBsaWtlIHJlcGxheSBhdHRhY2ssIERvUyBhdHRhY2sgKGNsaWVu dCBpbml0aWF0aW5nIGtleSBkZXJpdmF0aW9uIGZvciBlYWNoIHJlcXVlc3QpLCBjbGllbnQgcmVi b290IGNhc2UgZXRjLg0KDQpSZWdhcmRzLA0KQXNob2sNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCltDb21wYW55X2xvZ29dDQoNClJhamEgQXNob2sgViBLDQpIdWF3ZWkgVGVj aG5vbG9naWVzDQpCYW5nYWxvcmUsIEluZGlhDQpodHRwOi8vd3d3Lmh1YXdlaS5jb20NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQqxvtPKvP68sMbkuL28/rqs09C7qs6quavLvrXE saPD3NDFz6KjrL32z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9+w0K1rnI zrrOxuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrahori0 1sahorvyyaK3oqOpsb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6waK8 tLXnu7C78tPKvP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFuZCBpdHMg YXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUks IHdoaWNoDQppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBh ZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRh aW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRv dGFsIG9yIHBhcnRpYWwNCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlv bikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHBy b2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYnkNCnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUg aXQhDQoNCg== --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E22F904DBLREML503MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Goeran Selander,

 

I have gone through the OSCOAP and EDHOC drafts. And= I am having few doubts in it. Please provide your comments on it.

 

This specification makes handshake(EDHOC) for derivi= ng master secret as optional. And also a constraint node can skip handshake= and establish a secure channel if master secret is preconfigured.

 

This may make a constraint node to use same session = keys (sender and receiver key) for longer duration, if sequence number is n= ot exhausted. Only solution for renewing session key is to negotiate new ma= ster secret by using EDHOC. But EDHOC supports only PSK_ECDHE and ECDSA_ECDHE mechanism. Here I feel we are miss= ing PSK without (EC)DHE mechanism for establishing secure channel. I mean w= e are missing TLS_PSK_WITH_AES_128_CCM_8 kind of mechanism.

 

In DTLS, TLS_PSK_WITH_AES_128_CCM_8 uses same PSK ev= ery time for deriving session keys, and it doesn=A1=AFt support PFS. But th= e session key derived is different every time with the help of client and s= erver random.

 

So I feel we can consider of exchanging random numbe= r also along with KID and Partial IV in the 1st Request and Resp= onse. To achieve TLS_PSK_WITH_AES_128_CCM_8 kind of mechanism in OSCoAP wit= hout ECDHE exchange. For this anyway we have to consider multiple factors like replay attack, DoS attack (clien= t initiating key derivation for each request), client reboot case etc.=

 

Regards,

Ashok

 

3D"Company_logo"

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE= =BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD= =F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6= =B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0= =CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF= =BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7= =A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1= =CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA= =BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3= =A1
This e-mail and its attachments contain confide= ntial information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E22F904DBLREML503MBXchi_-- --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E22F904DBLREML503MBXchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Thu, 13 Jul 2017 12:39:30 GMT"; modification-date="Thu, 13 Jul 2017 12:39:30 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E22F904DBLREML503MBXchi_-- From nobody Thu Jul 13 08:01:01 2017 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 9B42F1201F2 for ; Thu, 13 Jul 2017 08:00:55 -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] 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 p3lblORbA6uw for ; Thu, 13 Jul 2017 08:00:54 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2641316C3 for ; Thu, 13 Jul 2017 08:00:51 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id F18874752D for ; Thu, 13 Jul 2017 17:00:49 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 457DF2A for ; Thu, 13 Jul 2017 17:00:49 +0200 (CEST) Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 04A613C3 for ; Thu, 13 Jul 2017 17:00:49 +0200 (CEST) Received: (nullmailer pid 32259 invoked by uid 1000); Thu, 13 Jul 2017 15:00:47 -0000 Date: Thu, 13 Jul 2017 17:00:47 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: "core@ietf.org WG" Message-ID: <20170713150047.zvwivkfv7qgiumbz@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fjmeohunafi7hckg" Content-Disposition: inline User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: [core] Observe and Block1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 15:00:56 -0000 --fjmeohunafi7hckg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello working group, with FETCH, it is now more realistic to get into a situation where an observation is established from a request whose body spans multiple Block1 exchanges. RFC7959 Section 2.6 explains how observe and blockwise interact, but only considers interaction between Block2 and observation. I'd implement it in a way that the Observe option is set on the initial Block1 (and thus the observation results ride on that request's token), but found no text on that, and someone else might send the Observe option on (and request the token of) the last Block1. My earlier implementation would even have sent the Observe option with every block. What do other implementers do there, what are the authors' opinions on this, and where can we write down how to do that? (This came up when refactoring the blockwise implementation of the aiocoap library). Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --fjmeohunafi7hckg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAllnixoACgkQOY0REtOk veFPfRAAuaXdsVU+oqXwS055wwJFX61FksEjeG1uqtbZjpOh0ZIIAFHkb0/6nMEj 4MHX5x1IkRweU5YL1MkZuR8O6NutSnfWW9+yOY3+duskfHV31Fjn9oDNoi9Xmr+i 5x+5rYlbKEHg4xJiaZR6G8iLpTfLODJ/rOzr+6YkHY4n9pHAOaDT4hmU59Dh3Ihn lYkeTqEIyB8B2ZWkgtgtwkT23VrfC7i6VTw1Gy+4yiLB3PVYmmHvL29B4tdHmFzX +6146NPvQwHIyR4GnNbxRBzhN0Sc76S/fG/O8kxJSxoP2pqaCykCpUCiBdVUDvES HNfwQ3UlraURVf4l5fLJnaXQ4hdnZFaJSwQWmwPCpsxGliFIzsLOjxAYDW4Z/Vrw tFcCkM6R36i8ERmVRl0D+p2lN8mUimB2yGNB4vanR3nPtqI27HTTa45AcULWMkWi myA4xXFFrqDSGrpYu2CHQTznCF/xKDVtp5e1hqs0JyY2J8M+qfBtq0RR6JBzqX4U +OzTn3ytHy0IT2NY9FGCuLQyK9mHtE9tacEX2d/bH3fqh65u0nLfYMCOx4rYnAPu pECm8BgtLUTQvGZv5mTAZ6ApBpP80jMm27RzgheEd4Iz4W7fUDHhPwfGZaOsHNRP I9QqdQPsLbNAGhgvhrtlvDsoePexlj3E6FEysrOlp75DPJolZik= =bFAM -----END PGP SIGNATURE----- --fjmeohunafi7hckg-- From nobody Thu Jul 13 10:15:04 2017 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 8DA03129AFF for ; Thu, 13 Jul 2017 10:15:02 -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 KUYZL8sGVbin for ; Thu, 13 Jul 2017 10:15:00 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 3BAEA131747 for ; Thu, 13 Jul 2017 10:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6DHEqlv014024; Thu, 13 Jul 2017 19:14:53 +0200 (CEST) Received: from [192.168.217.113] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3x7j9m5THvzDKXs; Thu, 13 Jul 2017 19:14:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <20170713150047.zvwivkfv7qgiumbz@hephaistos.amsuess.com> Date: Thu, 13 Jul 2017 19:14:52 +0200 Cc: "core@ietf.org WG" X-Mao-Original-Outgoing-Id: 521658892.074859-c57f34473a0e27a43835286fc11af0a2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170713150047.zvwivkfv7qgiumbz@hephaistos.amsuess.com> To: =?utf-8?Q?Christian_Ams=C3=BCss?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Observe and Block1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 17:15:02 -0000 On Jul 13, 2017, at 17:00, Christian Ams=C3=BCss = wrote: >=20 > what are the authors' opinions on > this, The authors of RFC 7959, or those of RFC 8132? :-) I think you have shown that RFC 8132 exposes a weakness in RFC 7959 = (namely that it didn=E2=80=99t define the interaction of Block1 and = Observe, note the curious absence of a section 3.5 =E2=80=9CCombining = Observe and Block1"). Generally, the assumption with Block1 is that all options are sent with = each copy of the request, so I would start out by expecting the Observe = request option to be present on all Block1 requests. Now which token = should be used for the notifications? This question may not really = occur in practice with Block1 as each response is likely to retire the = token, so the next response can use the same token. It is a bit weird = to send an Observe response option on a response that retires the token, = so that would argue for the Observe response option to be present only = on the last exchange in the Block1 sequence. This would fit with the = way Block1 and Block2 are used: The Block2 sequence starts with the last = exchange of the Block1 sequence. Where do we publish the result of the deliberations we need to answer = this question? This is likely to be a bit long for an errata report, so = we could write a short document that updates RFC 7959, or respin RFC = 7959 (which would be most useful if there are also other changes we want = to make). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 13 11:04:45 2017 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 D967B13154E for ; Thu, 13 Jul 2017 11:04:43 -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] 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 kfXl8nRTTx0c for ; Thu, 13 Jul 2017 11:04:42 -0700 (PDT) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17DF5129BA4 for ; Thu, 13 Jul 2017 11:04:41 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 273BD47538; Thu, 13 Jul 2017 20:04:38 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 6FDA22A; Thu, 13 Jul 2017 20:04:37 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [82.202.112.233]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 169EF3C3; Thu, 13 Jul 2017 20:04:37 +0200 (CEST) Received: (nullmailer pid 26828 invoked by uid 1000); Thu, 13 Jul 2017 18:04:34 -0000 Date: Thu, 13 Jul 2017 20:04:34 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Carsten Bormann Cc: "core@ietf.org WG" Message-ID: <20170713180434.meq3pmtdmbwhevsi@hephaistos.amsuess.com> References: <20170713150047.zvwivkfv7qgiumbz@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qmkyplkd32iavvef" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [core] Observe and Block1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 13 Jul 2017 18:04:44 -0000 --qmkyplkd32iavvef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 13, 2017 at 07:14:52PM +0200, Carsten Bormann wrote: > The authors of RFC 7959, or those of RFC 8132? :-) The former, ie. yours :-) > Generally, the assumption with Block1 is that all options are sent > with each copy of the request, so I would start out by expecting the > Observe request option to be present on all Block1 requests. Now > which token should be used for the notifications? This question may > not really occur in practice with Block1 as each response is likely to > retire the token, so the next response can use the same token. It is > a bit weird to send an Observe response option on a response that > retires the token, so that would argue for the Observe response option > to be present only on the last exchange in the Block1 sequence. This > would fit with the way Block1 and Block2 are used: The Block2 sequence > starts with the last exchange of the Block1 sequence. Sounds good to me. The lack of an Observe option in each 2.31 response (what of non-2.31 responses? are they mutually exclusive with observe?) would conveniently inform the client that no notifications will ever arrive on that token, so it is free for reuse before the next block is sent. Thanks for your quick response Christian --=20 This may seem a bit weird, but that's okay, because it is weird. -- perldata(1) about perl variables --qmkyplkd32iavvef Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAllnti4ACgkQOY0REtOk veFogg/9Gsq8zkNIccRu0Ornyr2UBGShRrSSLiVhKJIXG4QZJysRGUJU8n3yy+z4 s4mwcK00j3tFtvH2aNlI20bPymaYBoN367Y3Eb6k9MWp1RvmxBiZXigfkSiNyjR1 sC5IQOa7vSfDKWyivtS4CrPl1nkjNt1rmJPi/G6Q3iqaD5vd/sZ6WyJKKEsKWoHu +mdkxThAdu5yLZ+KbZn0cZ+KI7caCFTBbKmyoCAGWcEsw6elYeE1+poD2hrX+Tkk MrIzEPGdl9+hR/H6SFsqb1eWY+3UsNFqEuT9cRgrzibJUoKSGNQE3OmC+zHa296c jF1vqjDgiIinaaxmC9OLiBV0WyrxkmBwwfpjwv3BCs9lasY7JBrVCm1H2VklL2Hl SRcHs7Somv4lf8Y0pYUHZCiOXwRRdaXnip6xXyZA/zH2Lra65UkznOLvuVdE9clt lRGljCMDYZkus6R76mO0se5vlK1/Tn9Zo0HbI96lgo2I8j8w4xDcv0Y6X5RzYDw3 8zPm2rDC7gS4U84loljhqR6ojFo1jcwmdYBfjou87xdj5KWZ42TwXMD0QtRwR2O4 tIYSul2Y1zA8/1x8IV8rg0PeHwxHpEKmY/1UXzeln/tM5bNUp2sFITSpT38fByJZ aeOvDo3UjF4i7cHnTLCC/6BO+f7aO3CzvkpmfazBxScxKvzB8Ck= =DSr4 -----END PGP SIGNATURE----- --qmkyplkd32iavvef-- From nobody Sat Jul 15 07:46:04 2017 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 93A2212ECC1 for ; Sat, 15 Jul 2017 07:46:02 -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] 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 ibcVmpCLlSCb for ; Sat, 15 Jul 2017 07:46:01 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A90126D85 for ; Sat, 15 Jul 2017 07:46:01 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 4A18647582 for ; Sat, 15 Jul 2017 16:45:59 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 7C6FD2A for ; Sat, 15 Jul 2017 16:45:58 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-886b.meeting.ietf.org [31.133.136.107]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3A4293B4 for ; Sat, 15 Jul 2017 16:45:58 +0200 (CEST) Received: (nullmailer pid 31925 invoked by uid 1000); Sat, 15 Jul 2017 14:45:55 -0000 Date: Sat, 15 Jul 2017 16:45:55 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: core@ietf.org Message-ID: <20170715144555.mr4oz4m7v2bxjmta@hephaistos.amsuess.com> References: <149911257356.22722.5116552878549698625@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ozqi7r2vfiacgu6t" Content-Disposition: inline In-Reply-To: <149911257356.22722.5116552878549698625@ietfa.amsl.com> User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: [core] Short review (was: I-D Action: draft-ietf-core-senml-10.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jul 2017 14:46:02 -0000 --ozqi7r2vfiacgu6t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello CoRE working group, I've gone through the changes since SenML -07, and the concerns I had about the handling of names and base names have been resolved. Personally, I still think that units should be regarded as associated metadata, but that has been discussed before, and the presence of units here does not break anything for me. Nits level remark: There are still some references to "sensml", they were probably just missed in earlier editing steps. Thanks for updating this document, I'd advocate it to go through a WGLC. Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --ozqi7r2vfiacgu6t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAllqKqAACgkQOY0REtOk veEuChAAv4m2JGY/6mnYxbv4Hgabxa1fxzfS2oVn/x6II2Colq0M99ko3sLcOcef dLoplpsIKafpIgaBL2AuUNPM60oUOVEKp0YfHI4i9QVDkgSKHE6vqFd7UnIWGDp/ wWTdaT8Ue5FkTtFAXxMaRRt3I0tZRiUCN3ywO3CHFv7tsFhM8cXB0GgankRphCC4 sfoHniCuF3zRlu7l3lZEjDOWqrGP953iDvonbKIo4KuqY/WirVcprD2yBTbp7nVm 1bacF8Hcg3Kurdu1oH40UuV8DguMis4gQp/WZstcsqkEKgyCwzC2EnVeScdN7+uG Og8Hoi5m9RZSdIBT+lCXckWjIf+xuztQgYTRVak8Xc3xajNHB3mD/zEPnQcA4Xmz oUYNP4oUGvBIVDv/e0FH8JGKlWSzx7+Zqz0vYPm74jFntP3t6N5uLfoQG87lGpwE jtLGhWF+4+WfqHZxsT5UPv48o0rdyEj+rDvOiFwv31mg7BXhmxaTwRVUV68+WvVm UsC0cAF7NWfiFbY/OFZIY/Sqw7tLltBx+j0N4/51+vXHz3bAOUBZQIfdwHVKxs76 QScfv0CIQlpnotYDrTK1f61dUk7rr42RVYwtWSZU0sxmMoAOFyx4NF6M4ulxFR9E pd69UXUdElEwyP+g1lKrlfnQdZ892WvyIZk2GaSPBGVHREsoMkA= =n6Mm -----END PGP SIGNATURE----- --ozqi7r2vfiacgu6t-- From nobody Sat Jul 15 09:40:15 2017 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 3583E13190D for ; Sat, 15 Jul 2017 09:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 fdEu0xpEGy7N for ; Sat, 15 Jul 2017 09:40:12 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 64245131562 for ; Sat, 15 Jul 2017 09:40:12 -0700 (PDT) X-AuditID: c1b4fb2d-bcf0a9c000005faa-3f-596a456a50e1 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 91.14.24490.A654A695; Sat, 15 Jul 2017 18:40:10 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Sat, 15 Jul 2017 18:40:03 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= CC: core Thread-Topic: [core] Short review (was: I-D Action: draft-ietf-core-senml-10.txt) Thread-Index: AQHS/XkYVFoT22o+i0+EUn26tYofyqJU9YeA Date: Sat, 15 Jul 2017 16:40:02 +0000 Message-ID: <5780166F-3044-4C1D-9CE9-2C9513702906@ericsson.com> References: <149911257356.22722.5116552878549698625@ietfa.amsl.com> <20170715144555.mr4oz4m7v2bxjmta@hephaistos.amsuess.com> In-Reply-To: <20170715144555.mr4oz4m7v2bxjmta@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <5A29F66F42AC9D4B86CEFAEB5438F3BE@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7um6Wa1akwffJihbLLzxnsdj3dj2z A5PH1v13mTyWLPnJFMAUxWWTkpqTWZZapG+XwJXxt2UaW8Eu3oqp92YwNzD28HYxcnJICJhI nF9zkLWLkYtDSOAIo8SpJT8ZIZzFjBKvnjSzg1SxCdhKPGndxwpiiwh4SExc+gUsziwgIXF2 5WGwuLBAkMSMGWeZIWqCJab8fc0CYRtJXPzQChZnEVCV6Lu1GMjm4OAVsJfo/iIPEhYSqJPY +KiHDcTmFHCVmDN5Ndh4RgExie+n1jBBrBKXuPVkPhPE0QISS/acZ4awRSVePv7HCmErSaw9 vJ0FZDyzgKbE+l36EK3WEh+vbWCDsBUlpnQ/BBvPKyAocXLmE5YJjGKzkGyYhdA9C0n3LCTd s5B0L2BkXcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGFMHt/zW3cG4+rXjIUYBDkYlHl5V naxIIdbEsuLK3EOMEhzMSiK86+yBQrwpiZVVqUX58UWlOanFhxilOViUxHkd9l2IEBJITyxJ zU5NLUgtgskycXBKNTBa/uXLfnGwslRapzw5duUtL55zS6RMj38/5LRvUmqX9lT1AKU7kqZs hjYHi5dccX3AMYlZyOC8iHScmLTi0t31abOX7pXxrMl0Oc9XMOkmi86b3MSTp551ztJO6hGI 3VW4SXfeztsRV1TzRbk/x2t+TbX+WDLB1342m+/D/oPp4sx37k/sUVdiKc5INNRiLipOBABS pGVgpQIAAA== Archived-At: Subject: Re: [core] Short review (was: I-D Action: draft-ietf-core-senml-10.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jul 2017 16:40:14 -0000 VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IENocmlzdGlhbiENCg0KUmVnYXJkaW5nIHRoZSAic2Vu c21sIiAoYWxsIGxvd2VyIGNhcHMpIHJlZmVyZW5jZXMsIGFsbCBJIGZvdW5kIGZyb20gLTEwIHdl cmUgcmVmZXJlbmNlcyB0byB0aGUgWE1MIHRhZyBuYW1lIG9yIGZpbGVuYW1lIGV4dGVuc2lvbiBm b3IgdGhlIHN0cmVhbWluZyB2ZXJzaW9uLiBUaGV5IHNlZW1lZCBjb3JyZWN0IHRvIG1lLiBXYXMg dGhlcmUgcGFydGljdWxhciBvbmUgeW91IHRoaW5rIGlzIGluY29ycmVjdD8NCg0KDQpDaGVlcnMs DQpBcmkNCg0KPiBPbiAxNSBKdWwgMjAxNywgYXQgMTYuNDUsIENocmlzdGlhbiBBbXPDvHNzIDxj LmFtc3Vlc3NAZW5lcmd5aGFydmVzdGluZy5hdD4gd3JvdGU6DQo+IA0KPiBIZWxsbyBDb1JFIHdv cmtpbmcgZ3JvdXAsDQo+IA0KPiBJJ3ZlIGdvbmUgdGhyb3VnaCB0aGUgY2hhbmdlcyBzaW5jZSBT ZW5NTCAtMDcsIGFuZCB0aGUgY29uY2VybnMgSSBoYWQNCj4gYWJvdXQgdGhlIGhhbmRsaW5nIG9m IG5hbWVzIGFuZCBiYXNlIG5hbWVzIGhhdmUgYmVlbiByZXNvbHZlZC4NCj4gDQo+IA0KPiBQZXJz b25hbGx5LCBJIHN0aWxsIHRoaW5rIHRoYXQgdW5pdHMgc2hvdWxkIGJlIHJlZ2FyZGVkIGFzIGFz c29jaWF0ZWQNCj4gbWV0YWRhdGEsIGJ1dCB0aGF0IGhhcyBiZWVuIGRpc2N1c3NlZCBiZWZvcmUs IGFuZCB0aGUgcHJlc2VuY2Ugb2YgdW5pdHMNCj4gaGVyZSBkb2VzIG5vdCBicmVhayBhbnl0aGlu ZyBmb3IgbWUuDQo+IA0KPiBOaXRzIGxldmVsIHJlbWFyazogVGhlcmUgYXJlIHN0aWxsIHNvbWUg cmVmZXJlbmNlcyB0byAic2Vuc21sIiwgdGhleSB3ZXJlDQo+IHByb2JhYmx5IGp1c3QgbWlzc2Vk IGluIGVhcmxpZXIgZWRpdGluZyBzdGVwcy4NCj4gDQo+IA0KPiBUaGFua3MgZm9yIHVwZGF0aW5n IHRoaXMgZG9jdW1lbnQsIEknZCBhZHZvY2F0ZSBpdCB0byBnbyB0aHJvdWdoIGEgV0dMQy4NCj4g DQo+IEJlc3QgcmVnYXJkcw0KPiBDaHJpc3RpYW4NCj4gDQo+IC0tIA0KPiBUbyB1c2UgcmF3IHBv d2VyIGlzIHRvIG1ha2UgeW91cnNlbGYgaW5maW5pdGVseSB2dWxuZXJhYmxlIHRvIGdyZWF0ZXIg cG93ZXJzLg0KPiAgLS0gQmVuZSBHZXNzZXJpdCBheGlvbQ0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjb3JlIG1haWxpbmcgbGlzdA0KPiBjb3Jl QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29yZQ0K DQo= From nobody Sat Jul 15 10:15:04 2017 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 079EC129B30 for ; Sat, 15 Jul 2017 10:15:03 -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] 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 0WOmLxTgIbpr for ; Sat, 15 Jul 2017 10:15:01 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901EA127078 for ; Sat, 15 Jul 2017 10:15:01 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 1CAB147582; Sat, 15 Jul 2017 19:15:00 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 628C42A; Sat, 15 Jul 2017 19:14:59 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [213.208.157.9]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id CD4A43B4; Sat, 15 Jul 2017 19:14:56 +0200 (CEST) Received: (nullmailer pid 23921 invoked by uid 1000); Sat, 15 Jul 2017 17:14:51 -0000 Date: Sat, 15 Jul 2017 19:14:51 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Ari =?iso-8859-1?Q?Ker=E4nen?= Cc: core Message-ID: <20170715171451.6ni5qs73beb5rkhq@hephaistos.amsuess.com> References: <149911257356.22722.5116552878549698625@ietfa.amsl.com> <20170715144555.mr4oz4m7v2bxjmta@hephaistos.amsuess.com> <5780166F-3044-4C1D-9CE9-2C9513702906@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lwjz2vdws2duhlmx" Content-Disposition: inline In-Reply-To: <5780166F-3044-4C1D-9CE9-2C9513702906@ericsson.com> User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [core] Short review (was: I-D Action: draft-ietf-core-senml-10.txt) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 15 Jul 2017 17:15:03 -0000 --lwjz2vdws2duhlmx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 15, 2017 at 04:40:02PM +0000, Ari Ker=E4nen wrote: > Regarding the "sensml" (all lower caps) references, all I found from > -10 were references to the XML tag name or filename extension for the > streaming version. They seemed correct to me. Was there particular one > you think is incorrect? Oh -- I had forgotten about the "SensML" name introduced in earlier drafts (and didn't read that part again as nothing changed there), and not implementing the XML side of things didn't think of that application justifying the lowercase letters. Sorry for the noise Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --lwjz2vdws2duhlmx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAllqTYcACgkQOY0REtOk veFWORAApQ58KpGypSpWFNkCFFcZR2mC0BwCiEPetwsJ2NOR6fdxRDZ53iNIzapV UkPeBCzMeuK494hykaGVwC8eOIPMeNTo1z7G5XJNNlTVXhGjIl+VW6eube7b91QM Kppq6DI2xKIqRXacqGJFIeTGOUKvjxfFHphWDZKLnpDjHQ/RXrsfRdPbvk4Xpubr coGQPj41su9GJzjSkuYE1J/gWTgDBztPTr/TM9FMTMeC6GLiQIX2AHNMh9qXsZwf Mn3gbBld81IvU+Hu4ZbIC/AyEC20dxGA76v4gCZOPQpd1z9WZC8HHS2ogg54vS6T XeNCc1NT7tDYXBIX3qUJ1UcB16fbTqwTaP3sCkXXVUTwVgW3dpoQo7YXyp79+1qZ tl9QgXm0hQfx+/AncqkGDkMu2zVBLwEk0g14/SNDLul3jd4a9sG2+DV0yZND5/zI x4edIKFPyCQJi6W1fntodUHQpv79cnUDz6aJKAvsJ/Bv0gdlKnzFvnHrTINoKww0 glBSBzh793Ar56pYsNu3R/HOop1CvDU7oFwMCcjmaGJ4NS0m9iMs6NtunZjFLNsO p3J7Ft38lhihBtwUxGGPsYEoq4avm/A7nJEdd6cjrUrqUw1HCpk/xmKwVp1IxKzH msCRQfx/gT8YpJJMHcJGs/XU9nVv7fYUPAJs0MNsTWO/y3RPxds= =U533 -----END PGP SIGNATURE----- --lwjz2vdws2duhlmx-- From nobody Sat Jul 15 20:00:44 2017 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 2098B1316F4 for ; Sat, 15 Jul 2017 20:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=filament-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 I2LpnUq6zEnY for ; Sat, 15 Jul 2017 20:00:41 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 E2C641316F5 for ; Sat, 15 Jul 2017 20:00:40 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id v202so36383884itb.0 for ; Sat, 15 Jul 2017 20:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=wLsqVH78zV1iQXe48uPnfHu5fOIBOP/XsEzNiop+0iY=; b=JPB1s8ay19j+R1AEJ+vymtRJLCUQX3vXlHtoi1PYuYI13PiXEDvaNtvnyBOiZsoDB/ kOsxcb4kw4cAlsxmnhiPW9cmLYswhdJHfnZsdTK5aqurueq1nwnzihGmIkX6075mLu+H wGBwUoapXBLI46pmJdqDxPD6cnL9feNp1c0i+EQ+lIKE9EC0CTmfW3M6c6EFHbc9hxj7 l2enZUVf1kdT/r4Krdmehnk742w652CLjMrtuYmhqppJK/KuVVGMmJ5Qy+FjWHPWuL0B G+auLskgN//WYYUDQn1sdeLyeCJ0WbctM0rucAHrZ3SpZaOQeyknbQOBdcdkwBTNmQv7 30dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wLsqVH78zV1iQXe48uPnfHu5fOIBOP/XsEzNiop+0iY=; b=O0jYFJ8+6s1JBQkchkA+vORB3T/lM4uQdjxRYLJd9jtPhE3RQooJZJpg3v+xQbEKvy 7qlwUfQ715IBzpr1vnd+LcTBsdnQp4TSuO7e6RIzT2DaS+3t6TcmitJ/WHhmmpURQlqc P2e4HIIieBTqkJ/Xx3FDltrlwrxtpzWYWAwb/scldUurDv+VNAP8QiWN1x+buHArYM9S 76aFMXc02AnsMFt9tks3EBLiY8YKaDXyuWqzyW5t92pdyJTWTn0ndwac1OBacb3faGRM NLiIeo1wR8aPfFtebxjyCYpDQjqSFgB0SbiY7Mk21L16Y9jH5LumqQCLNKpxpe+2DS9C PohA== X-Gm-Message-State: AIVw113rdxJPQwyI8QLGSH//K707jWeRNFck/CIQ8iXIDz1VG2dHOTcZ mtnG6lrj4dhRwJa/huY= X-Received: by 10.36.121.145 with SMTP id z139mr46471itc.1.1500174040101; Sat, 15 Jul 2017 20:00:40 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:8466:5ca7:873f:1138]) by smtp.gmail.com with ESMTPSA id e77sm7272313ioi.32.2017.07.15.20.00.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 20:00:39 -0700 (PDT) To: Core References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> From: Peter Saint-Andre - Filament Message-ID: Date: Sat, 15 Jul 2017 21:00:37 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 03:00:43 -0000 On 7/5/17 5:23 AM, Jaime Jimnez wrote: > > Dear CoRE WG, > > The core-senml draft has gotten to a state that the authors feel is in > good shape for WGLC. > We will do a 2 week WGLC before next IETF. > > _https://tools.ietf.org/html/draft-ietf-core-senml-10_ Please consider the following comments. Section 1 Where is the urn:dev namespace defined? I don't see it listed in the registry . If it's being defined in this specification, please refer to RFC 8141 for the most up-to-date guidelines regarding URN namespace registration. If you're just using an arbitrary namespace for examples, please use the urn:example namespace defined in RFC 6963. [See also below.] Section 2 The design goal is to be able to send simple sensor measurements in small packets on mesh networks from large numbers of constrained devices. It's not clear to me why the network topology (e.g., a "mesh" network) is relevant here. I suggest removing "on mesh networks". Keeping the total size of payload under 80 bytes makes this easy to use on a wireless mesh network. Why was 80 bytes chosen instead of, say, 50 bytes or 64 bytes or 100 bytes? (Here again I'd remove the text about mesh networks.) Also, the payload size will vary depending on the encoding (JSON, CBOR, XML, EXI, etc.), and it's not clear which one is being implicitly referenced here. Section 4.3 It is RECOMMENDED that the full names are represented as URIs [RFC3986] or URNs [RFC2141]. Well, URNs *are* URIs. Also, RFC 2141 has been replaced by RFC 8141. Some of the examples in this draft use the device URN type as specified in [I-D.arkko-core-dev-urn]. Aha. But why? That's an expired informational I-D which never actually registered the urn:dev namespace. I suggesting using urn:example URNs instead. (If there's a desire to advance draft-arkko-core-dev-urn, then let's do that - although note that registration is easier now that we've published RFC 8141, and we wouldn't need to advance the I-D in order to register the namespace. In any case, having lots of examples of an unregistered namespace seems like bad form.) The resulting concatenated name MUST consist only of characters out of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", or "_" and it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9". Shall we define this in terms of ABNF, perhaps? Please note that this set is more restricted than the range of characters allowed for URIs in general (RFC 3986) or URNs in particular (RFC 8141). At the least it would be helpful to point this out, because AFAICS it will limit the URI schemes or URN namespaces that can be used. Section 4.4 In addition the records need to be in chronological order. If there are multiple records with the same value of "t", does their order matter? Section 4.6 Up to this point in the document, SenML has been defined as a format for representing sensor measurements. Given that a sensor measures something in the world, what does it mean to *set* the value of a sensor or a sensor measurement? SenML can also be used for configuring parameters and controlling actuators. When a SenML Pack is sent (e.g., using a HTTP/CoAP POST or PUT method) and the semantics of the target are such that SenML is interpreted as configuration/actuation, SenML Records are interpreted as a request to change the values of given (sub)resources (given as names) to given values at the given time(s). This is underspecified. In particular, how does a sender know that "the semantics of the target are such that SenML is interpreted as configuration/actuation"? And aren't configuration and actuation quite different use cases? At the very least, a forward reference to Section 5.1.7 would be helpful. Section 9 To select a single SenML Record, the "rec" scheme followed by a single number is used. It's confusing to use the term "scheme" here - I realize it's the term used in XPointer, but RFC 3986 uses the term "parameter" instead. Section 9.1 The 3rd SenML Record from "coap://example.com/temp" resource can be selected with: coap://example.com/temp#rec=3 But RFC 7252 says: Note: Fragments ([RFC3986], Section 3.5) are not part of the request URI and thus will not be transmitted in a CoAP request. Is there a conflict here? Section 12.1 Units marked with an asterisk are NOT RECOMMENDED to be produced by new implementations, but are in active use and SHOULD be implemented by consumers that can use the related base units. This advice seems unrealistic and likely unnecessary. Section 12.1 Although one could quibble with some of the choices here (lat and lon but no alt?), that's what registration procedures are for. :-) Speaking of which: New entries can be added to the registration by either Expert Review or IESG Approval as defined in [RFC5226]. Why define two policies? That's just introducing the possibility of confusion. Note that RFC 5226 has been replaced by RFC 8126. Section 12.2 See above on having multiple policies. Peter -- Peter Saint-Andre https://filament.com/ From nobody Sun Jul 16 10:31:57 2017 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 3CD4D124D68; Sun, 16 Jul 2017 10:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 PRBj7mepFisW; Sun, 16 Jul 2017 10:31:48 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4751212F4B2; Sun, 16 Jul 2017 10:31:48 -0700 (PDT) Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id B433BA80CE; Sun, 16 Jul 2017 19:31:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id XT68b5C6jsg7; Sun, 16 Jul 2017 19:31:45 +0200 (CEST) X-Originating-IP: 89.176.18.156 Received: from [10.10.22.149] (ip-89-176-18-156.net.upcbroadband.cz [89.176.18.156]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id DE626A80D8; Sun, 16 Jul 2017 19:31:42 +0200 (CEST) From: Alexander Pelov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <1C06C3D6-9C50-4C27-803F-B4BC808A9402@ackl.io> Date: Sun, 16 Jul 2017 19:31:48 +0200 Cc: yot@ietf.org, Benoit Claise To: netmod@ietf.org, Core , t2trg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] Side meeting on Yang of Things X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 17:31:50 -0000 Dear all, As you have probably seen the announcement, a new non-WG mailing list = was created - YoT@ietf.org We=E2=80=99ll have a side meeting on Thursday, 20th, 10h-12h in room = Tyrolka, Mezzanine Level. The description of the mailing list is as follows: YANG is the method of choice in the IETF for describing data models = exposed by manageable items. It is currently being used in the context = of the NETCONF (and, increasingly, RESTCONF) protocols, which generally = target high-function devices. The Coman initiative (RFC 7547, 7548) = investigated requirements and use cases for management of networks with = constrained devices. Building blocks for protocols that make this a = reality (COMI) are emerging in the CoRE working group; however, CoRE as = a WG is not currently focused on network or device management. The "Yang of Things=E2=80=9D (YOT) non-WG mailing list will discuss best = practices for using YANG-based data modeling for the management of = networks with constrained devices and constrained networks. It will also = address how to best make use of properties of the combination of = technologies involved (YANG, CBOR, SID, CoAP, RESTCONF, =E2=80=A6). Of = interest are the ways these same technologies could be applied outside = the COMI focus of interest. The YOT mailing list will also be the proper = forum to discuss new YANG modules targeting constrained devices and = networks. This is the preliminary agenda (subject to change): - Introduction - 10 min: Why YANG for IoT?=20 - The CoMI framework (30 min) - 10 min: The CoMI protocol (and its relation to NETCONF/RESTCONF) - = Michel Veillette, Peter van der Stok - 10 min: YANG-to-CBOR - Michel Veillette - 10 min: The SID registry - Alexander Pelov - Mapping existing tools to YANG (10 min) - 5 min: LWM2M to CoMI - Peter van der Stok, Jaime Jimenez - 5 min: Ressource Directory to CoMI - Alexander Pelov - CoMI for IoT (as of today) (20 min) - 5 min: Firmware update over CoMI - Michel Veillette, Alexander Pelov - 5 min: Event logger and notification control - Michel Veillette - 5 min: 6TiSCH - TBD - 5 min: LPWAN - Laurent Toutain - Yang for IoT (20 min) - 10 min: YANG for embedded systems: Andy Bierman - 10 min: Manufacturer Usage Description (MUD) - Eliot Lear, Thorsten = Dahm - Discussions (30 min) - What other points could YANG address for IoT? - Interaction models for YANG and IoT - Intersection between YANG and IoT communities - Getting YANG out of the routers - Getting efficient technologies to routers (from the constrained = world) - Events, notifications, security, =E2=80=A6 For any questions or comments, please use the mailing list: yot@ietf.org See you on Thursday ! Best, Alexander PS. This is a BYOD event (Bring Your Own Drink) From nobody Sun Jul 16 15:16:57 2017 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 2E12F126CB6 for ; Sun, 16 Jul 2017 15:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kMLB2eNgntrk for ; Sun, 16 Jul 2017 15:16:54 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A22126BF3 for ; Sun, 16 Jul 2017 15:16:54 -0700 (PDT) X-AuditID: c1b4fb3a-803ff70000001b2f-a4-596be5d45851 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 80.D7.06959.4D5EB695; Mon, 17 Jul 2017 00:16:52 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Mon, 17 Jul 2017 00:16:51 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Peter Saint-Andre - Filament CC: core Thread-Topic: =?utf-8?B?W2NvcmVdICDwn5SUIFdHTEMgb24gZHJhZnQtaWV0Zi1jb3JlLWNvYXAtc2Vu?= =?utf-8?Q?ml?= Thread-Index: AQHS9YEpx1mKBvRbS0erW9/y34h5MaJVstyAgAFDCwA= Date: Sun, 16 Jul 2017 22:16:50 +0000 Message-ID: <5559A4D7-0D55-403D-A3C7-527942640A15@ericsson.com> References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <0E112E53BBBD064D947233EF0A712C95@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7qO6Vp9mRBp+Xi1nse7ue2WL2mWAH Jo9Lm2azeyxZ8pMpgCmKyyYlNSezLLVI3y6BK2P6rv1sBZtCKmYum8rSwDgnqIuRk0NCwERi csdVti5GLg4hgSOMEiuvzGeGcBYzSuy/OYcZpIpNwFbiSes+VhBbRMBU4tekfrA4s4CExNmV h8HiwgJpEndu3gWaxAFUky7x61ANRLmVxOMVR1lAbBYBVYmjRy8zgti8AvYS3/bNA2sVEiiV 6FqwHqyGU8BB4knzBbAaRgExie+n1jBBrBKXuPVkPhPE0QISS/acZ4awRSVePv7HCmErSSy6 /ZkJ5ARmAU2J9bv0IVqtJTrfnGGBsBUlpnQ/ZIc4QVDi5MwnLBMYxWYh2TALoXsWku5ZSLpn IelewMi6ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwog5u+W21g/Hgc8dDjAIcjEo8vCdP ZEcKsSaWFVfmHmKU4GBWEuFVPQ0U4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuuw70KEkEB6Yklq dmpqQWoRTJaJg1OqgZHV4tJBpaTna8xKqi/dLr/Bn2+36O0D2elimzrEpMSmehl8qjku8fFu tCX7rdRpu4r23wu1WKe88ToT689+tmV5GluajNt099ztde36H+234tdF/abekmm5rtOlFJcF NScli3M8Z9szdU7u7oQbxkbufux6U2axiSy6UG4s+fZeUoav6CUdPSWW4oxEQy3mouJEAHqD xg2kAgAA Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 22:16:56 -0000 VGhhbmsncyBQZXRlciEgU2VlIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgaW5saW5lLg0KDQo+IE9u IDE2IEp1bCAyMDE3LCBhdCA1LjAwLCBQZXRlciBTYWludC1BbmRyZSAtIEZpbGFtZW50IDxwZXRl ckBmaWxhbWVudC5jb20+IHdyb3RlOg0KPiANCj4gT24gNy81LzE3IDU6MjMgQU0sIEphaW1lIEpp bcOpbmV6IHdyb3RlOg0KPj4gDQo+PiBEZWFyIENvUkUgV0csDQo+PiANCj4+IFRoZSBjb3JlLXNl bm1sIGRyYWZ0IGhhcyBnb3R0ZW4gdG8gYSBzdGF0ZSB0aGF0IHRoZSBhdXRob3JzIGZlZWwgaXMg aW4NCj4+IGdvb2Qgc2hhcGUgZm9yIFdHTEMuIA0KPj4gV2Ugd2lsbCBkbyBhIDIgd2VlayBXR0xD IGJlZm9yZSBuZXh0IElFVEYuIA0KPj4gDQo+PiBfaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtY29yZS1zZW5tbC0xMF8NCj4gDQo+IFBsZWFzZSBjb25zaWRlciB0aGUgZm9s bG93aW5nIGNvbW1lbnRzLg0KPiANCj4gU2VjdGlvbiAxDQo+IA0KPiBXaGVyZSBpcyB0aGUgdXJu OmRldiBuYW1lc3BhY2UgZGVmaW5lZD8gSSBkb24ndCBzZWUgaXQgbGlzdGVkIGluIHRoZQ0KPiBy ZWdpc3RyeSA8aHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdXJuLW5hbWVzcGFjZXMv Pi4gSWYgaXQncw0KPiBiZWluZyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiwgcGxlYXNl IHJlZmVyIHRvIFJGQyA4MTQxIGZvciB0aGUNCj4gbW9zdCB1cC10by1kYXRlIGd1aWRlbGluZXMg cmVnYXJkaW5nIFVSTiBuYW1lc3BhY2UgcmVnaXN0cmF0aW9uLiBJZg0KPiB5b3UncmUganVzdCB1 c2luZyBhbiBhcmJpdHJhcnkgbmFtZXNwYWNlIGZvciBleGFtcGxlcywgcGxlYXNlIHVzZSB0aGUN Cj4gdXJuOmV4YW1wbGUgbmFtZXNwYWNlIGRlZmluZWQgaW4gUkZDIDY5NjMuIFtTZWUgYWxzbyBi ZWxvdy5dDQoNCihhZGRyZXNzZWQgYmVsb3cpDQoNCj4gDQo+IFNlY3Rpb24gMg0KPiANCj4gICBU aGUgZGVzaWduIGdvYWwgaXMgdG8gYmUgYWJsZSB0byBzZW5kIHNpbXBsZSBzZW5zb3IgbWVhc3Vy ZW1lbnRzIGluDQo+ICAgc21hbGwgcGFja2V0cyBvbiBtZXNoIG5ldHdvcmtzIGZyb20gbGFyZ2Ug bnVtYmVycyBvZiBjb25zdHJhaW5lZA0KPiAgIGRldmljZXMuDQo+IA0KPiBJdCdzIG5vdCBjbGVh ciB0byBtZSB3aHkgdGhlIG5ldHdvcmsgdG9wb2xvZ3kgKGUuZy4sIGEgIm1lc2giIG5ldHdvcmsp DQo+IGlzIHJlbGV2YW50IGhlcmUuIEkgc3VnZ2VzdCByZW1vdmluZyAib24gbWVzaCBuZXR3b3Jr cyIuDQo+IA0KPiAgIEtlZXBpbmcgdGhlIHRvdGFsIHNpemUgb2YgcGF5bG9hZCB1bmRlciA4MCBi eXRlcyBtYWtlcyB0aGlzDQo+ICAgZWFzeSB0byB1c2Ugb24gYSB3aXJlbGVzcyBtZXNoIG5ldHdv cmsuDQo+IA0KPiBXaHkgd2FzIDgwIGJ5dGVzIGNob3NlbiBpbnN0ZWFkIG9mLCBzYXksIDUwIGJ5 dGVzIG9yIDY0IGJ5dGVzIG9yIDEwMA0KPiBieXRlcz8gKEhlcmUgYWdhaW4gSSdkIHJlbW92ZSB0 aGUgdGV4dCBhYm91dCBtZXNoIG5ldHdvcmtzLikNCg0KVGhlc2UgdHdvIHBvaW50cywgbWVzaCBh bmQgODAgYnl0ZXMsIGFyZSByZWxhdGVkLiA4MDIuMTUuNCAoNkxvV1BBTikgbWVzaCBuZXR3b3Jr cyByZXN1bHQgaW4gYWJvdXQgODAgYnl0ZXMgb2YgdXNhYmxlIHBheWxvYWQgcGVyIHBhY2tldCB3 aXRob3V0IGZyYWdtZW50YXRpb24uDQoNCkkgZGlkIGZpbmQgaXQgdXNlZnVsIHRvIGhhdmUgc29t ZSBqdXN0aWZpY2F0aW9uIHdoeSB3ZSBjYXJlIGFib3V0IHNoYXZpbmcgYnl0ZXMgaGVyZSAoZS5n LiwsIG5vdCBoYXZpbmcgZXhjZXNzaXZlIGFtb3VudCBvZiBtZXRhZGF0YSBpbmxpbmUpLCBidXQg SSBkb24ndCBoYXZlIHN0cm9uZyBvcGluaW9uIG9uIHdoZXRoZXIgd2Ugc2hvdWxkIGtlZXAgdGhp cyB0ZXh0Lg0KDQo+IEFsc28sIHRoZSBwYXlsb2FkIHNpemUgd2lsbCB2YXJ5IGRlcGVuZGluZyBv biB0aGUgZW5jb2RpbmcgKEpTT04sIENCT1IsDQo+IFhNTCwgRVhJLCBldGMuKSwgYW5kIGl0J3Mg bm90IGNsZWFyIHdoaWNoIG9uZSBpcyBiZWluZyBpbXBsaWNpdGx5DQo+IHJlZmVyZW5jZWQgaGVy ZS4NCg0KVGhpcyBpcyBub3QgYWJvdXQgcGFydGljdWxhciBlbmNvZGluZyBidXQgaW4gZ2VuZXJh bCBqdXN0aWZpY2F0aW9uIHdoeSBzaXplIG1hdHRlcnMuIEFsbCBTZW5NTCBlbmNvZGluZ3MgY2Fu IGdvIGJlbG93IDgwIGJ5dGVzIHdpdGggbW9kZXJhdGUgYW1vdW50IG9mIFJlY29yZHMgYW5kIHNo b3J0LWVub3VnaCBuYW1lcy4NCg0KPiBTZWN0aW9uIDQuMw0KPiANCj4gICBJdCBpcyBSRUNPTU1F TkRFRCB0aGF0IHRoZQ0KPiAgIGZ1bGwgbmFtZXMgYXJlIHJlcHJlc2VudGVkIGFzIFVSSXMgW1JG QzM5ODZdIG9yIFVSTnMgW1JGQzIxNDFdLg0KPiANCj4gV2VsbCwgVVJOcyAqYXJlKiBVUklzLiBB bHNvLCBSRkMgMjE0MSBoYXMgYmVlbiByZXBsYWNlZCBieSBSRkMgODE0MS4NCg0KU2luY2Ugd2Ug c3BlY2lmaWNhbGx5IHVzZSBVUk5zIGluIGV4YW1wbGVzLCBwZXJoYXBzIHRoZSBVUk4gcmVmZXJl bmNlIGlzIHN0aWxsIGp1c3RpZmllZC4gQnV0IHRoaXMgdGV4dCBjb3VsZCBiZSBjaGFuZ2VkIHRv ICJbLi4uXSBhcyBVUklzIFtSRkMzOTg2XSwgc3VjaCBhcyBVUk5zIFtSRkM4MTQxXSIuDQoNCj4g ICBTb21lIG9mIHRoZSBleGFtcGxlcyBpbiB0aGlzIGRyYWZ0IHVzZSB0aGUgZGV2aWNlIFVSTg0K PiAgIHR5cGUgYXMgc3BlY2lmaWVkIGluIFtJLUQuYXJra28tY29yZS1kZXYtdXJuXS4NCj4gDQo+ IEFoYS4gQnV0IHdoeT8gVGhhdCdzIGFuIGV4cGlyZWQgaW5mb3JtYXRpb25hbCBJLUQgd2hpY2gg bmV2ZXIgYWN0dWFsbHkNCj4gcmVnaXN0ZXJlZCB0aGUgdXJuOmRldiBuYW1lc3BhY2UuIEkgc3Vn Z2VzdGluZyB1c2luZyB1cm46ZXhhbXBsZSBVUk5zDQo+IGluc3RlYWQuIChJZiB0aGVyZSdzIGEg ZGVzaXJlIHRvIGFkdmFuY2UgZHJhZnQtYXJra28tY29yZS1kZXYtdXJuLCB0aGVuDQo+IGxldCdz IGRvIHRoYXQgLSBhbHRob3VnaCBub3RlIHRoYXQgcmVnaXN0cmF0aW9uIGlzIGVhc2llciBub3cg dGhhdCB3ZSd2ZQ0KPiBwdWJsaXNoZWQgUkZDIDgxNDEsIGFuZCB3ZSB3b3VsZG4ndCBuZWVkIHRv IGFkdmFuY2UgdGhlIEktRCBpbiBvcmRlciB0bw0KPiByZWdpc3RlciB0aGUgbmFtZXNwYWNlLiBJ biBhbnkgY2FzZSwgaGF2aW5nIGxvdHMgb2YgZXhhbXBsZXMgb2YgYW4NCj4gdW5yZWdpc3RlcmVk IG5hbWVzcGFjZSBzZWVtcyBsaWtlIGJhZCBmb3JtLikNCg0KVGhhdCBkcmFmdCB3YXMganVzdCBy ZWNlbnRseSByZXN1cnJlY3RlZCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFy a2tvLWNvcmUtZGV2LXVybi0wNCksIGJ1dCB1bmZvcnR1bmF0ZWx5IG9ubHkgYWZ0ZXIgd2Ugc3Vi bWl0dGVkIHRoZSBTZW5NTCBkcmFmdC4gR29vZCBjb21tZW50cyBmb3IgdGhhdCBkcmFmdC4NCg0K PiAgIFRoZSByZXN1bHRpbmcgY29uY2F0ZW5hdGVkIG5hbWUgTVVTVCBjb25zaXN0IG9ubHkgb2Yg Y2hhcmFjdGVycyBvdXQNCj4gICBvZiB0aGUgc2V0ICJBIiB0byAiWiIsICJhIiB0byAieiIsICIw IiB0byAiOSIsICItIiwgIjoiLCAiLiIsICIvIiwgb3INCj4gICAiXyIgYW5kIGl0IE1VU1Qgc3Rh cnQgd2l0aCBhIGNoYXJhY3RlciBvdXQgb2YgdGhlIHNldCAiQSIgdG8gIloiLCAiYSINCj4gICB0 byAieiIsIG9yICIwIiB0byAiOSIuDQo+IA0KPiBTaGFsbCB3ZSBkZWZpbmUgdGhpcyBpbiB0ZXJt cyBvZiBBQk5GLCBwZXJoYXBzPw0KDQpNYWtlcyBzZW5zZS4NCg0KPiBQbGVhc2Ugbm90ZSB0aGF0 IHRoaXMgc2V0IGlzIG1vcmUgcmVzdHJpY3RlZCB0aGFuIHRoZSByYW5nZSBvZg0KPiBjaGFyYWN0 ZXJzIGFsbG93ZWQgZm9yIFVSSXMgaW4gZ2VuZXJhbCAoUkZDIDM5ODYpIG9yIFVSTnMgaW4gcGFy dGljdWxhcg0KPiAoUkZDIDgxNDEpLiBBdCB0aGUgbGVhc3QgaXQgd291bGQgYmUgaGVscGZ1bCB0 byBwb2ludCB0aGlzIG91dCwgYmVjYXVzZQ0KPiBBRkFJQ1MgaXQgd2lsbCBsaW1pdCB0aGUgVVJJ IHNjaGVtZXMgb3IgVVJOIG5hbWVzcGFjZXMgdGhhdCBjYW4gYmUgdXNlZC4NCg0KR29vZCBwb2lu dC4gSSdkIHN1Z2dlc3QgdGV4dDogDQoNCiJOb3RlIHRoYXQgdGhlIGNoYXJhY3RlciBzZXQgZm9y IFNlbk1MIG5hbWVzIGlzIGEgc3Vic2V0IG9mIHRoZSBjaGFyYWN0ZXJzIGFsbG93ZWQgaW4gVVJJ cy4gVGhlIHJlc3RyaWN0ZWQgc2V0IHdhcyBjaG9zZW4gdG8gZW5hYmxlIGVmZmljaWVudCBhbmQg c2FmZSB1c2Ugb2YgbmFtZXMgaW4gdmFyaW91cyBzeXN0ZW1zIChlLmcuLCBhcyBkYXRhYmFzZSBr ZXlzKS4iDQoNCj4gU2VjdGlvbiA0LjQNCj4gDQo+ICAgSW4gYWRkaXRpb24gdGhlIHJlY29yZHMg bmVlZCB0byBiZSBpbiBjaHJvbm9sb2dpY2FsIG9yZGVyLg0KPiANCj4gSWYgdGhlcmUgYXJlIG11 bHRpcGxlIHJlY29yZHMgd2l0aCB0aGUgc2FtZSB2YWx1ZSBvZiAidCIsIGRvZXMgdGhlaXINCj4g b3JkZXIgbWF0dGVyPw0KDQpTaG91bGQgbm90IG1hdHRlci4gV2lsbCBjbGFyaWZ5Lg0KDQo+IFNl Y3Rpb24gNC42DQo+IA0KPiBVcCB0byB0aGlzIHBvaW50IGluIHRoZSBkb2N1bWVudCwgU2VuTUwg aGFzIGJlZW4gZGVmaW5lZCBhcyBhIGZvcm1hdCBmb3INCj4gcmVwcmVzZW50aW5nIHNlbnNvciBt ZWFzdXJlbWVudHMuIEdpdmVuIHRoYXQgYSBzZW5zb3IgbWVhc3VyZXMgc29tZXRoaW5nDQo+IGlu IHRoZSB3b3JsZCwgd2hhdCBkb2VzIGl0IG1lYW4gdG8gKnNldCogdGhlIHZhbHVlIG9mIGEgc2Vu c29yIG9yIGENCj4gc2Vuc29yIG1lYXN1cmVtZW50Pw0KDQpJIGd1ZXNzIHRoaXMgbmVlZHMgdG8g YmUgZWxhYm9yYXRlZCBhbHNvIGluIHRoZSBpbnRybyAoaXQncyBoaW50ZWQgaW4gdGhlIGFic3Ry YWN0KS4NCg0KPiAgIFNlbk1MIGNhbiBhbHNvIGJlIHVzZWQgZm9yIGNvbmZpZ3VyaW5nIHBhcmFt ZXRlcnMgYW5kIGNvbnRyb2xsaW5nDQo+ICAgYWN0dWF0b3JzLiAgV2hlbiBhIFNlbk1MIFBhY2sg aXMgc2VudCAoZS5nLiwgdXNpbmcgYSBIVFRQL0NvQVAgUE9TVA0KPiAgIG9yIFBVVCBtZXRob2Qp IGFuZCB0aGUgc2VtYW50aWNzIG9mIHRoZSB0YXJnZXQgYXJlIHN1Y2ggdGhhdCBTZW5NTCBpcw0K PiAgIGludGVycHJldGVkIGFzIGNvbmZpZ3VyYXRpb24vYWN0dWF0aW9uLCBTZW5NTCBSZWNvcmRz IGFyZSBpbnRlcnByZXRlZA0KPiAgIGFzIGEgcmVxdWVzdCB0byBjaGFuZ2UgdGhlIHZhbHVlcyBv ZiBnaXZlbiAoc3ViKXJlc291cmNlcyAoZ2l2ZW4gYXMNCj4gICBuYW1lcykgdG8gZ2l2ZW4gdmFs dWVzIGF0IHRoZSBnaXZlbiB0aW1lKHMpLg0KPiANCj4gVGhpcyBpcyB1bmRlcnNwZWNpZmllZC4N Cj4gDQo+IEluIHBhcnRpY3VsYXIsIGhvdyBkb2VzIGEgc2VuZGVyIGtub3cgdGhhdCAidGhlIHNl bWFudGljcyBvZiB0aGUgdGFyZ2V0DQo+IGFyZSBzdWNoIHRoYXQgU2VuTUwgaXMgaW50ZXJwcmV0 ZWQgYXMgY29uZmlndXJhdGlvbi9hY3R1YXRpb24iPyBBbmQNCj4gYXJlbid0IGNvbmZpZ3VyYXRp b24gYW5kIGFjdHVhdGlvbiBxdWl0ZSBkaWZmZXJlbnQgdXNlIGNhc2VzPw0KDQpUaGVzZSBzZW1h bnRpY3MgbmVlZCB0byBiZSBlc3RhYmxpc2hlZCBvdXQgb2YgYmFuZCBmcm9tIFNlbk1MIHBvaW50 IG9mIHZpZXcuIENvdWxkIGJlIHNvbWV0aGluZyBsaWtlIENvUkUgaW50ZXJmYWNlIHR5cGUgb3Ig THdNMk0gcmVzb3VyY2UgdHlwZSB0aGF0IGFjY2VwdHMgU2VuTUwgZm9yIHRoaXMgcHVycG9zZS4g QnV0IHdlIGRvbid0IHdhbnQgdG8gYmUgcHJlc2NyaXB0aXZlIGhlcmUuIFBlcmhhcHMgZ2l2aW5n IGV4YW1wbGUocykgaXMgZ29vZCBhcHByb2FjaD8NCg0KPiBBdCB0aGUgdmVyeSBsZWFzdCwgYSBm b3J3YXJkIHJlZmVyZW5jZSB0byBTZWN0aW9uIDUuMS43IHdvdWxkIGJlIGhlbHBmdWwuDQoNCkFn cmVlZC4NCg0KPiBTZWN0aW9uIDkNCj4gDQo+ICAgVG8gc2VsZWN0IGEgc2luZ2xlIFNlbk1MIFJl Y29yZCwgdGhlICJyZWMiIHNjaGVtZSBmb2xsb3dlZCBieSBhDQo+ICAgc2luZ2xlIG51bWJlciBp cyB1c2VkLg0KPiANCj4gSXQncyBjb25mdXNpbmcgdG8gdXNlIHRoZSB0ZXJtICJzY2hlbWUiIGhl cmUgLSBJIHJlYWxpemUgaXQncyB0aGUgdGVybQ0KPiB1c2VkIGluIFhQb2ludGVyLCBidXQgUkZD IDM5ODYgdXNlcyB0aGUgdGVybSAicGFyYW1ldGVyIiBpbnN0ZWFkLg0KDQpQYXJhbWV0ZXIgd29y a3MgZm9yIG1lLg0KDQo+IFNlY3Rpb24gOS4xDQo+IA0KPiAgIFRoZSAzcmQgU2VuTUwgUmVjb3Jk IGZyb20gImNvYXA6Ly9leGFtcGxlLmNvbS90ZW1wIiByZXNvdXJjZSBjYW4gYmUNCj4gICBzZWxl Y3RlZCB3aXRoOg0KPiANCj4gICBjb2FwOi8vZXhhbXBsZS5jb20vdGVtcCNyZWM9Mw0KPiANCj4g QnV0IFJGQyA3MjUyIHNheXM6DQo+IA0KPiAgIE5vdGU6IEZyYWdtZW50cyAoW1JGQzM5ODZdLCBT ZWN0aW9uIDMuNSkgYXJlIG5vdCBwYXJ0IG9mIHRoZSByZXF1ZXN0DQo+ICAgVVJJIGFuZCB0aHVz IHdpbGwgbm90IGJlIHRyYW5zbWl0dGVkIGluIGEgQ29BUCByZXF1ZXN0Lg0KPiANCj4gSXMgdGhl cmUgYSBjb25mbGljdCBoZXJlPw0KDQpOb3BlLiBUaGUgInNlbGVjdGlvbiIgaGFwcGVucyBpbiB0 aGUgY2xpZW50LCBqdXN0IGxpa2Ugd2l0aCBDU1YgcmVjb3Jkcy4NCg0KPiBTZWN0aW9uIDEyLjEN Cj4gDQo+ICAgVW5pdHMgbWFya2VkIHdpdGggYW4NCj4gICBhc3RlcmlzayBhcmUgTk9UIFJFQ09N TUVOREVEIHRvIGJlIHByb2R1Y2VkIGJ5IG5ldyBpbXBsZW1lbnRhdGlvbnMsDQo+ICAgYnV0IGFy ZSBpbiBhY3RpdmUgdXNlIGFuZCBTSE9VTEQgYmUgaW1wbGVtZW50ZWQgYnkgY29uc3VtZXJzIHRo YXQgY2FuDQo+ICAgdXNlIHRoZSByZWxhdGVkIGJhc2UgdW5pdHMuDQo+IA0KPiBUaGlzIGFkdmlj ZSBzZWVtcyB1bnJlYWxpc3RpYyBhbmQgbGlrZWx5IHVubmVjZXNzYXJ5Lg0KDQpXaHkgdW5yZWFs aXN0aWM/DQoNCj4gU2VjdGlvbiAxMi4xDQo+IA0KPiBBbHRob3VnaCBvbmUgY291bGQgcXVpYmJs ZSB3aXRoIHNvbWUgb2YgdGhlIGNob2ljZXMgaGVyZSAobGF0IGFuZCBsb24NCj4gYnV0IG5vIGFs dD8pLCB0aGF0J3Mgd2hhdCByZWdpc3RyYXRpb24gcHJvY2VkdXJlcyBhcmUgZm9yLiA6LSkNCg0K QWN0dWFsbHkgImFsdCIgY291bGQgbWFrZSBzZW5zZS4gQnV0IHllcywgaXQncyBieSBkZXNpZ24g ZWFzeSB0byBleHRlbmQgdGhpcy4NCg0KPiBTcGVha2luZyBvZiB3aGljaDoNCj4gDQo+ICAgTmV3 IGVudHJpZXMgY2FuIGJlIGFkZGVkIHRvIHRoZSByZWdpc3RyYXRpb24gYnkgZWl0aGVyIEV4cGVy dCBSZXZpZXcNCj4gICBvciBJRVNHIEFwcHJvdmFsIGFzIGRlZmluZWQgaW4gW1JGQzUyMjZdLg0K PiANCj4gV2h5IGRlZmluZSB0d28gcG9saWNpZXM/IFRoYXQncyBqdXN0IGludHJvZHVjaW5nIHRo ZSBwb3NzaWJpbGl0eSBvZg0KPiBjb25mdXNpb24uDQoNCkkgdGhpbmsgIklFU0cgYXBwcm92YWwi IGlzIHVzdWFsbHkgZ29vZCB0byBoYXZlIGFzIGEgYmFja3VwIGlmIHRoZSBtYWluIHBvbGljeSBj YW4gbm90IGJlIGV4ZXJjaXNlZCBmb3Igc29tZSByZWFzb24uIFBlcmhhcHMgbm90IHRoYXQgaW1w b3J0YW50IHdpdGggdGhlIEV4cGVydCBSZXZpZXcgcG9saWN5IHRob3VnaCwgYnV0IEkgZG9uJ3Qg c2VlIHRvbyBtdWNoIGhhcm0gaGVyZS4gSSdkIGV4cGVjdCBJRVNHIHRvIGNvbnN1bHQgZXhwZXJ0 KHMpIGFueXdheSBpZiB0aGV5IGVuZCB1cCBiZWluZyBhc2tlZCBhYm91dCB0aGlzLg0KDQo+IE5v dGUgdGhhdCBSRkMgNTIyNiBoYXMgYmVlbiByZXBsYWNlZCBieSBSRkMgODEyNi4NCg0KVGhhbmtz IQ0KDQo+IFNlY3Rpb24gMTIuMg0KPiANCj4gU2VlIGFib3ZlIG9uIGhhdmluZyBtdWx0aXBsZSBw b2xpY2llcy4NCg0KQUNLLiBBbmQgdGhhbmtzIG9uY2UgbW9yZSBmb3IgdGhlIHRob3JvdWdoIHJl dmlldyENCg0KDQpDaGVlcnMsDQpBcmkNCg== From nobody Sun Jul 16 15:37:31 2017 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 37A94129BA4 for ; Sun, 16 Jul 2017 15:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=filament-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 VF2uWSKfR5Ob for ; Sun, 16 Jul 2017 15:37:26 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 9CED4127369 for ; Sun, 16 Jul 2017 15:37:26 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id h134so35205899iof.2 for ; Sun, 16 Jul 2017 15:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=I0Ev1gWqjvFPylW3WI56ZjpH+MbahAvcetKmO/BiN04=; b=GcRO4J5rGPOLfzREHZPAhA2rGC7LtE4Uk/WPwkZ5HDpMre5W2AyQFoX/rv52efsbP1 1/+auM5A1doeMgZps0lHMjtZmbDZX053f98JdmoqunAszyKERQ4KTOlJ//FLxikjy2X/ l2CAOCaoWy450Os0MtIJrQjA1rGYIsqf82wskd6g0A+WhhL7lgikmvS6iDPCUfoLQn/B fT9GobUjjPsHlu4fXIf0Gxi/z85dCjp8BgLdTnxY2Wr6emyqgn7cDeQjsFNAD0WKv2t6 sp4kL0qLaBOMQsHZ+MR/9RwRUyOwkSRdAcw/GvmEkQDw8dVPQ6d4zNup/cN9QGeFBrLr UvmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=I0Ev1gWqjvFPylW3WI56ZjpH+MbahAvcetKmO/BiN04=; b=ArQAkojfnGM28FsSkwoIVyvmQgzfcC/6Lt58JQnA80FGvkLJY3at+w3WxyUM7ywyQe +W1S9xgvoM6hQ3/jpZpDijlFPp1Zra7zaUAGV9asNglgDhVSFDDm4xEgBo8Q0Er+36UG ILE+7P9pUTw/WWVnpd7GXaeNu7sPv9Pd7lI9Kh24YJIwcM07GjJ4R9JGkz2ZIlnboIzR /NY8bStqUz+Bl9KE9tx0Er3Fmwn3VQ1KeFjyV451A+8FKVMbxQDPxT9l0W/QXD9foMQT 88nPJgf+J7WgP1lfzYmSgqyqDuz7WogXfmb3deH4fsG7Gm7+mZmjPA6uvOZdl7wE+vAQ B7Sg== X-Gm-Message-State: AIVw111+vPc76uyHHk1kXlMukTB8BajOcm2suuZlpTI5WgOkWg37ebKn HtUdYRUqH89cODFD X-Received: by 10.107.55.68 with SMTP id e65mr17063287ioa.221.1500244645832; Sun, 16 Jul 2017 15:37:25 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:f9ac:8fcb:edd3:a8a0]) by smtp.gmail.com with ESMTPSA id z13sm4981392ita.22.2017.07.16.15.37.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 15:37:24 -0700 (PDT) To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> <5559A4D7-0D55-403D-A3C7-527942640A15@ericsson.com> Cc: core From: Peter Saint-Andre - Filament Message-ID: <1243a4c8-5ce6-642e-faf3-5dda093d13df@filament.com> Date: Sun, 16 Jul 2017 16:37:22 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5559A4D7-0D55-403D-A3C7-527942640A15@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 22:37:29 -0000 On 7/16/17 4:16 PM, Ari Keränen wrote: > Thank's Peter! See comments and questions inline. > >> On 16 Jul 2017, at 5.00, Peter Saint-Andre - Filament >> wrote: >> >> On 7/5/17 5:23 AM, Jaime Jiménez wrote: >>> >>> Dear CoRE WG, >>> >>> The core-senml draft has gotten to a state that the authors feel >>> is in good shape for WGLC. We will do a 2 week WGLC before next >>> IETF. >>> >>> _https://tools.ietf.org/html/draft-ietf-core-senml-10_ >> >> Please consider the following comments. >> >> Section 1 >> >> Where is the urn:dev namespace defined? I don't see it listed in >> the registry . If >> it's being defined in this specification, please refer to RFC 8141 >> for the most up-to-date guidelines regarding URN namespace >> registration. If you're just using an arbitrary namespace for >> examples, please use the urn:example namespace defined in RFC 6963. >> [See also below.] > > (addressed below) > >> >> Section 2 >> >> The design goal is to be able to send simple sensor measurements >> in small packets on mesh networks from large numbers of >> constrained devices. >> >> It's not clear to me why the network topology (e.g., a "mesh" >> network) is relevant here. I suggest removing "on mesh networks". >> >> Keeping the total size of payload under 80 bytes makes this easy to >> use on a wireless mesh network. >> >> Why was 80 bytes chosen instead of, say, 50 bytes or 64 bytes or >> 100 bytes? (Here again I'd remove the text about mesh networks.) > > These two points, mesh and 80 bytes, are related. 802.15.4 (6LoWPAN) > mesh networks result in about 80 bytes of usable payload per packet > without fragmentation. That makes sense. In which case it would be good to mention this, so that readers understand the rationale. > I did find it useful to have some justification why we care about > shaving bytes here (e.g.,, not having excessive amount of metadata > inline), but I don't have strong opinion on whether we should keep > this text. > >> Also, the payload size will vary depending on the encoding (JSON, >> CBOR, XML, EXI, etc.), and it's not clear which one is being >> implicitly referenced here. > > This is not about particular encoding but in general justification > why size matters. All SenML encodings can go below 80 bytes with > moderate amount of Records and short-enough names. > >> Section 4.3 >> >> It is RECOMMENDED that the full names are represented as URIs >> [RFC3986] or URNs [RFC2141]. >> >> Well, URNs *are* URIs. Also, RFC 2141 has been replaced by RFC >> 8141. > > Since we specifically use URNs in examples, perhaps the URN reference > is still justified. But this text could be changed to "[...] as URIs > [RFC3986], such as URNs [RFC8141]". > >> Some of the examples in this draft use the device URN type as >> specified in [I-D.arkko-core-dev-urn]. >> >> Aha. But why? That's an expired informational I-D which never >> actually registered the urn:dev namespace. I suggesting using >> urn:example URNs instead. (If there's a desire to advance >> draft-arkko-core-dev-urn, then let's do that - although note that >> registration is easier now that we've published RFC 8141, and we >> wouldn't need to advance the I-D in order to register the >> namespace. In any case, having lots of examples of an unregistered >> namespace seems like bad form.) > > That draft was just recently resurrected > (https://tools.ietf.org/html/draft-arkko-core-dev-urn-04), but > unfortunately only after we submitted the SenML draft. Good comments > for that draft. Thanks for the pointer. I'm one of the expert reviewers for URN namespace registrations, so I'll provide separate comments about that I-D soon. If that I-D will be a normative reference here or we are depending on registration of the urn:dev namespace before progressing SenML, then the WG might consider using the urn:example namespace for now. >> The resulting concatenated name MUST consist only of characters >> out of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", >> "/", or "_" and it MUST start with a character out of the set "A" >> to "Z", "a" to "z", or "0" to "9". >> >> Shall we define this in terms of ABNF, perhaps? > > Makes sense. > >> Please note that this set is more restricted than the range of >> characters allowed for URIs in general (RFC 3986) or URNs in >> particular (RFC 8141). At the least it would be helpful to point >> this out, because AFAICS it will limit the URI schemes or URN >> namespaces that can be used. > > Good point. I'd suggest text: > > "Note that the character set for SenML names is a subset of the > characters allowed in URIs. The restricted set was chosen to enable > efficient and safe use of names in various systems (e.g., as database > keys)." I suggest that we also say something like "The restrictions imply that care needs to be taken in the choice of URIs or URNs as SenML names." Furthermore, if someone wants to use a URI scheme that allows characters outside that set (e.g., the 'tag' scheme), then do those characters need to be encoded somehow? (Ick.) If not, then we should say so. >> Section 4.4 >> >> In addition the records need to be in chronological order. >> >> If there are multiple records with the same value of "t", does >> their order matter? > > Should not matter. Will clarify. > >> Section 4.6 >> >> Up to this point in the document, SenML has been defined as a >> format for representing sensor measurements. Given that a sensor >> measures something in the world, what does it mean to *set* the >> value of a sensor or a sensor measurement? > > I guess this needs to be elaborated also in the intro (it's hinted in > the abstract). That's the barest of hints. :-) I almost provided a comment about it, but let it go. >> SenML can also be used for configuring parameters and controlling >> actuators. When a SenML Pack is sent (e.g., using a HTTP/CoAP >> POST or PUT method) and the semantics of the target are such that >> SenML is interpreted as configuration/actuation, SenML Records are >> interpreted as a request to change the values of given >> (sub)resources (given as names) to given values at the given >> time(s). >> >> This is underspecified. >> >> In particular, how does a sender know that "the semantics of the >> target are such that SenML is interpreted as >> configuration/actuation"? And aren't configuration and actuation >> quite different use cases? > > These semantics need to be established out of band from SenML point > of view. Could be something like CoRE interface type or LwM2M > resource type that accepts SenML for this purpose. But we don't want > to be prescriptive here. Perhaps giving example(s) is good approach? Examples of such discovery methods would be helpful. >> At the very least, a forward reference to Section 5.1.7 would be >> helpful. > > Agreed. > >> Section 9 >> >> To select a single SenML Record, the "rec" scheme followed by a >> single number is used. >> >> It's confusing to use the term "scheme" here - I realize it's the >> term used in XPointer, but RFC 3986 uses the term "parameter" >> instead. > > Parameter works for me. > >> Section 9.1 >> >> The 3rd SenML Record from "coap://example.com/temp" resource can >> be selected with: >> >> coap://example.com/temp#rec=3 >> >> But RFC 7252 says: >> >> Note: Fragments ([RFC3986], Section 3.5) are not part of the >> request URI and thus will not be transmitted in a CoAP request. >> >> Is there a conflict here? > > Nope. The "selection" happens in the client, just like with CSV > records. OK. >> Section 12.1 >> >> Units marked with an asterisk are NOT RECOMMENDED to be produced by >> new implementations, but are in active use and SHOULD be >> implemented by consumers that can use the related base units. >> >> This advice seems unrealistic and likely unnecessary. > > Why unrealistic? Because we're saying "hey you new implementations, don't do this, but everyone else before you does it". Developers of new implementations won't want to miss out on this feature (if it's important). >> Section 12.1 >> >> Although one could quibble with some of the choices here (lat and >> lon but no alt?), that's what registration procedures are for. :-) > > Actually "alt" could make sense. But yes, it's by design easy to > extend this. > >> Speaking of which: >> >> New entries can be added to the registration by either Expert >> Review or IESG Approval as defined in [RFC5226]. >> >> Why define two policies? That's just introducing the possibility >> of confusion. > > I think "IESG approval" is usually good to have as a backup if the > main policy can not be exercised for some reason. Perhaps not that > important with the Expert Review policy though, but I don't see too > much harm here. I'd expect IESG to consult expert(s) anyway if they > end up being asked about this. Right, so let's simplify it while we have the chance. :-) >> Note that RFC 5226 has been replaced by RFC 8126. > > Thanks! > >> Section 12.2 >> >> See above on having multiple policies. > > ACK. And thanks once more for the thorough review! Thanks for considering the feedback. Peter From nobody Sun Jul 16 15:49:41 2017 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 0054F12441E for ; Sun, 16 Jul 2017 15:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=filament-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 rz1yEbzFNGuw for ; Sun, 16 Jul 2017 15:49:39 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 13C8E12009C for ; Sun, 16 Jul 2017 15:49:39 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id m84so44692297ita.0 for ; Sun, 16 Jul 2017 15:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=7TekL57k2KPLabWYAzDZa4iMR7aGy4DnNcx5VZbd7Ko=; b=RuXa3oHKqf722PXH3iRZrUwxaqATimWLX89xuRe0Qflgj/Ll2P/d4H+0APWuattT5B jK9W7+qQUxTtisg8xVBOW7adfniuDqOXr50HWwlg6wSJFEgERGYcEzgHx3LwifAsbH39 s1GzC0F661RuvE2EjxVrGrZztUg2JScr5yZARgnwPwfRvbWV+k6kf+gewtUqQAUyf3ST P2/uuiEWeDf24SjiKkOHlH1lL3PZhepbRacRwD5L4H9zoEzem43KOlO9F9zDuTDb3wCG ndnrYm1avW0jIujmdIgd4nEnwb1/lkhp88Km12tydUl5cCngKNQ96EKlqUVlsBjqvzib AMag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=7TekL57k2KPLabWYAzDZa4iMR7aGy4DnNcx5VZbd7Ko=; b=X50Ot+798s6G+F14IQshBmHR31ou40ZB619UqDlwE/wD8m8IT4c+2H77qGIwszwoGI O9vjwQ+W/OH6xQbkMCXMrxzMhTFrht5O9C2mNlE032fxwuHrR8rNRTi8lrgIf7yxq8+K 7wlG8YE6hQUepBSDEPE8qFI+yTNf8a9FRkhVHZqyMv1vNC3MM2cWaoQVDmCC2DzJ/ep4 91AXa71yH/DGiqKlSe4ZqgONL5N/2GXOkUrh8gKLrm/oF7vjEoVvW0Xop6er+I9RLtGd 86wHWzprNZPZ0vRnucgRK52W3dmkY5EHBzHVV50uaaE6Ywxlko0Fop00WNGleE4ARMV1 m9RA== X-Gm-Message-State: AIVw111CnHpm+qyuWXPoRgl0/n1Juu+4OGcDNKdKjCVAXni3U/CFsmMm zbbs3QYMsGXgyqHH4Bo= X-Received: by 10.36.184.7 with SMTP id m7mr2914610ite.112.1500245378498; Sun, 16 Jul 2017 15:49:38 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:f9ac:8fcb:edd3:a8a0]) by smtp.gmail.com with ESMTPSA id i133sm8119051ioi.31.2017.07.16.15.49.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 15:49:37 -0700 (PDT) To: Core From: Peter Saint-Andre - Filament Message-ID: Date: Sun, 16 Jul 2017 16:49:36 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [core] comments on draft-arkko-core-dev-urn X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 22:49:41 -0000 As noted in a thread on SenML, I'm one of the expert reviewers for URN namespace registrations. Although this is not an official review, here are some comments. First, RFC 2141 and RFC 3406 were recently replaced by RFC 8141. The registration template has changed, the registration procedure has changed, everything should be simpler than it used to be, etc. Please see RFC 8141 for details. Also, the ISBN and ISSN registrations are great examples of the new template: https://www.iana.org/assignments/urn-formal/isbn https://www.iana.org/assignments/urn-formal/issn Second, we might be able to use URN f-components (preceded by "#" as in other URI schemes) instead of the namespace-specific componentpart (beginning with ";"). Have a look at Section 2.3.3 of RFC 8141. Peter -- Peter Saint-Andre https://filament.com/ From nobody Mon Jul 17 00:33:59 2017 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 84BE1131A7D for ; Mon, 17 Jul 2017 00:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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=googlemail.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 dZehVFjHFwdG for ; Mon, 17 Jul 2017 00:33:52 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 B5B5C131A76 for ; Mon, 17 Jul 2017 00:33:51 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id r36so38777904ioi.1 for ; Mon, 17 Jul 2017 00:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=r/ZsYeqqcK731TSXWk0N1cwggoCH5DA6E1R4kPaPgdo=; b=pBK/ZRhTNrSHSngYQ/3gqjVUmrYF+bonmy6D7tJ3JI1lo8mEtakmE0LKxFWMDSREZ6 JFONshjvz7ZPHYc1YkoHrN9V4UlYgNfBCLcFzEWIWa8cJX/LWIoY3QVZ3xcTAg8mERg3 jIcXq9Odzk9j0G3Dkd/NqrTMzTPzTcvakAQhF9VoX2q8CdQ6Fg58PyI+ihblODP2yf2e kZ5vczKgTTbbHmYo4MYuxpx8NAsCSt9rbyotetNHQbAgwwobDr2ftvOxHITnliyIIYc1 k8XywQ39ya9TM/hJSrUzr3C7uP9QJF2J0MQjKuezT0lWKkDwMtSTE/nDXmIx5t7VbHP6 0nmA== 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:cc; bh=r/ZsYeqqcK731TSXWk0N1cwggoCH5DA6E1R4kPaPgdo=; b=E9TwpZutjBF3khRT7APMfZCzvTyQVmP/90RNyQmL3H61iNvGw+tnPVijTqn7OVeHw0 y3GyYKicBjANa6XAGg0W9KuMm2cnrHRJ37QJJqsDFP6+gORFdMgmUHyzYk1QGvq+xUtN jyhdSmNzQnNitm0yBkNjq/GkabRL7nFYv4Tcu8VmNYWZvBx+zQIvzl7GLrTQzg4D0EpG gkbBWVVIAIfhzOhwTVaeCJZvNkSIs60Xxp1kcUuckA0Fc8GqBfQWqGW+54K/dQPNOrea Rn3hgt1C9wOwQZ3dFPkPvdSG4ichnT9cTMxHGleh2o/khN4BM3qPmNXs6WglhLgPxsBF Z9dg== X-Gm-Message-State: AIVw110wIM1YHbmJVOBAQAA75O91zHR2zgRk1yyWfGDgTuSKLi7HFCI5 9Y4CfdT5IIrehFNnP8h9lagb/A3Ixg== X-Received: by 10.107.152.85 with SMTP id a82mr18537025ioe.105.1500276830831; Mon, 17 Jul 2017 00:33:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.97.195 with HTTP; Mon, 17 Jul 2017 00:33:50 -0700 (PDT) From: Ines Robles Date: Mon, 17 Jul 2017 09:33:50 +0200 Message-ID: To: core@ietf.org, t2trg@irtf.org Cc: mariarita.palattella@list.lu Content-Type: multipart/alternative; boundary="001a11454732911ca005547e6b7e" Archived-At: Subject: [core] Info session on M2MSAT at IETF99 Prague X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 07:33:54 -0000 --001a11454732911ca005547e6b7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI ---------- Message transf=C3=A9r=C3=A9 ---------- De : *Maria Rita Palattella* Date : samedi 15 juillet 2017 Objet : Fw: Info session on M2MSAT at IETF99 Prague I am writing to you because I am organising at IETF99 in Prague a *Info session about an ongoing project I am leading: M2MSAT* ( https://artes.esa.int/projects/m2msat) The project, funded by ESA, aims to analyse (both via simulations and in a real test bed), *the performance of IoT application protocols* (*CoAP* and MQTT) *when communicating over a satellite link*. IoT networks will be soon integrated with terrestrial networks in the 5G scenarios, and it is fundamental to design adaptation/improvement of IoT protocols not originally designed with the satellite network constrains in mind (link disruption, high packet loss, etc). We are currently running performance evaluation using simulators (OpenSAND, Californium CoAP, MQTT Mosquito). And also setting up a testbed, where we we may collect IoT data from OpenMote nodes, running 6TiSCH. I believe the project may be of interest for different IETF folk, such those working on CoAP, IoT, 6TiSCH, LPWAN, 6lo, etc. It will be great if you can join the meeting, planned for *Monday July, 17th at 6pm*, in *Paris Room (Lobby level, L)* in Hilton Hotel in Prague. I will appreciate also if you can spread the info among folks that could find the project of interest, and could provide us some fruitful feedback. We will also announce the Info session during the 6TiSCH WG meeting planned for Monday 17/7/2017, in the first afternoon session. Thank you. Looking forward to hearing from you. See you in Prague Best Regards, Maria Rita Palattella ------------------------------------------------------------ ----------------- Senior R&T Associate Department 'Environmental Research and Innovation' (ERIN) Luxembourg Institute of Science and Technology (LIST) 41, rue du Brill L-4422 Belvaux, Grand-duchy of Luxembourg email: mariarita.palattella@list.lu, tel: +352 275 888-5055 --001a11454732911ca005547e6b7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

FYI

---------- Message transf=C3= =A9r=C3=A9 ----------
De=C2=A0: Maria Rita Palattella <mariarita.palatt= ella@list.lu>
Date=C2=A0: samedi 15 juillet 2017
Objet=C2=A0: = Fw: Info session on M2MSAT at IETF99 Prague



I am writing to you because I am o= rganising at IETF99 in Prague a Info session abo= ut an ongoing project I am leading: M2MSAT=C2= =A0(https://artes.esa.int/projects/m2msat<= font size=3D"2">)
The project, funded by ESA, ai= ms to analyse (both via simulations and in a real test bed), the performance of IoT application protocols=C2=A0(CoAP=C2=A0and MQTT) when communicating over a satel= lite link. IoT networks will be soon integrated= with terrestrial networks in the 5G scenarios, and it is fundamental to de= sign adaptation/improvement of IoT protocols not originally designed with t= he satellite network constrains in mind (link disruption, high packet loss,= etc). We are currently running performance evaluation using simulators (Op= enSAND, Californium CoAP, MQTT Mosquito). And also setting up a testbed, wh= ere we we may collect IoT data from OpenMote nodes, running 6TiSCH.<= br>
I believe the project may be of interest for differ= ent IETF folk, such those working on CoAP, IoT, 6TiSCH, LPWAN, 6lo, etc.

It will be great if you can join the meeting, = planned for Monday July, 17th at 6pm<= font size=3D"2">, in Paris Room (Lobby level, L)= =C2=A0in Hilton Hotel in Prague.
I will appreciate also if you can spread the info=C2=A0 among = folks that could find the project of interest, and could provide us some fr= uitful feedback.
We will also announce the Info = session during the 6TiSCH WG meeting planned for Monday 17/7/2017, in the f= irst afternoon session.

Thank you.Looking forward to hearing from you.
See you in Prague

Best Regards,
Maria Rita Palattella

= -----------------------------------------------------------------= ------------
Senior R&T Associate
Departm= ent 'Environmental Research and Innovation' (ERIN)
Luxembourg In= stitute of Science and Technology (LIST)
41, rue du Brill
L-4422 Belv= aux, Grand-duchy of Luxembourg
email: mariarita.palattella@list.lu, tel: +352 275 888-5055


--001a11454732911ca005547e6b7e-- From nobody Mon Jul 17 07:28:56 2017 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 0EA8B131B5A for ; Mon, 17 Jul 2017 07:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2s-4KcZZBVmb for ; Mon, 17 Jul 2017 07:28:53 -0700 (PDT) Received: from smtp93.ord1c.emailsrvr.com (smtp93.ord1c.emailsrvr.com [108.166.43.93]) (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 A61C7131BE8 for ; Mon, 17 Jul 2017 07:28:53 -0700 (PDT) Received: from smtp28.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp28.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id EBF7040142; Mon, 17 Jul 2017 10:28:52 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp28.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 3160B40201; Mon, 17 Jul 2017 10:28:52 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.61.217.181] ([UNAVAILABLE]. [173.38.220.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Mon, 17 Jul 2017 10:28:52 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D173BF3A-D098-496D-B5C0-81B90DE0BCE2" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <1243a4c8-5ce6-642e-faf3-5dda093d13df@filament.com> Date: Mon, 17 Jul 2017 16:28:49 +0200 Cc: =?utf-8?Q?Ari_Ker=C3=A4nen?= , core Message-Id: <3CFFB9AE-AD69-4AAD-B646-5E348DF53986@iii.ca> References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> <5559A4D7-0D55-403D-A3C7-527942640A15@ericsson.com> <1243a4c8-5ce6-642e-faf3-5dda093d13df@filament.com> To: Peter Saint-Andre - Filament X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 14:28:55 -0000 --Apple-Mail=_D173BF3A-D098-496D-B5C0-81B90DE0BCE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank for the great review... Ari and I working on it but just to add to = this one point.=20 > On Jul 17, 2017, at 12:37 AM, Peter Saint-Andre - Filament = wrote: >=20 >>>=20 >>> Why was 80 bytes chosen instead of, say, 50 bytes or 64 bytes or >>> 100 bytes? (Here again I'd remove the text about mesh networks.) >>=20 >> These two points, mesh and 80 bytes, are related. 802.15.4 (6LoWPAN) >> mesh networks result in about 80 bytes of usable payload per packet >> without fragmentation. >=20 > That makes sense. In which case it would be good to mention this, so >=20 How about we say keeping it small is good and quote examples of 802.15.4 = has about 80 byte payload and that LoRa has 51 byte of applications = payload in long range mode and just remove any reference to "mesh" --Apple-Mail=_D173BF3A-D098-496D-B5C0-81B90DE0BCE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Thank for the great = review... Ari and I working on it but just to add to this one = point. 

On Jul 17, 2017, at 12:37 AM, Peter = Saint-Andre - Filament <peter@filament.com> wrote:


Why was 80 bytes chosen instead = of, say, 50 bytes or 64 bytes or
100 bytes? (Here again = I'd remove the text about mesh networks.)

These two points, mesh and 80 bytes, are related. 802.15.4 = (6LoWPAN)
mesh networks result in about 80 bytes of usable = payload per packet
without fragmentation.

That makes sense. In which case it would be good = to mention this, so


How about we say keeping it small is = good and quote examples of 802.15.4 has about 80 byte payload and =  that LoRa has 51 byte of applications payload in long range mode = and just remove any reference to "mesh"




= --Apple-Mail=_D173BF3A-D098-496D-B5C0-81B90DE0BCE2-- From nobody Mon Jul 17 07:31:12 2017 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 74E6B131C1E for ; Mon, 17 Jul 2017 07:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=filament-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 9AINkLPGy-uk for ; Mon, 17 Jul 2017 07:31:08 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F77131C0F for ; Mon, 17 Jul 2017 07:30:57 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id a62so4705499itd.1 for ; Mon, 17 Jul 2017 07:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=HOWcieI7g71j5wzKxwj2bLx3cobngc0FZcUFB0EWE+Q=; b=mu9zXODhpagF9KXCHgVbEGwiIOfqd8udPhG98qc3VCV2QJ+oZ9vcjlyJIg+eK+64FU AlgfWLYRHIp5lm+AQITpmCFyM1d3RMDnEuISDkVAaZ4Il1jCMxbJrkNnVVyy2I6bL9rX +eT4QMmOrU9UtcxiqKv3/T+tF1se9VqGpdfvgfwCWMb3MUaJcMgPNPmn9Q/qD6jUz6Rr zDgc5ThMzJwUVe/70msx32hxs7EQXLlCP7yAITZ9cOv2Pa0mC+4HN6dkfEUIycRjcxmj 7WpxvvYvJYcHAgcotlqvomKIzGRPq7SSx1KLBuDqABwOMRie06oQvwY58xAyKqws+/ls G0Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HOWcieI7g71j5wzKxwj2bLx3cobngc0FZcUFB0EWE+Q=; b=tEFr+8wQNrNlBVIL2hhkmratruztQzFILDGv4TWBfIuArHuKXuF00lGYbgKvS8DQg9 ZpCwXA7swDAH+p+lI9NHp43Z2HOgHH1iAuXk23Ps56LGgi2X+xebhE6hRVQ/PJI1qgP1 B2aLaRiQLw70VT7RQsbKWJ7KvY6e10NJHsNSV/ZZaFX2cMtwD8oOaepMXgas+ZORa88I 3ILIxcnAfgyPJNFIvdPJ6D9U9yyPk3HTg5I5WSVv43ZIscVRPhgWjIaKD+IOx4kIrwrw 4Xp7R745bFJrWKniXHzlFhaApEKvKTsc9N6N0rAXpjqm6h/wSuO/80XtUdVlDErQ2wxv 8mJw== X-Gm-Message-State: AIVw112wsw9NvwpBzh8nD3yEDDyY3kDBz9ofPXfEm5EQuDRkXLhfL0B5 DPzjoJkrEUICqeMS X-Received: by 10.36.110.149 with SMTP id w143mr5578790itc.21.1500301857247; Mon, 17 Jul 2017 07:30:57 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:e115:fd84:2006:e18c]) by smtp.gmail.com with ESMTPSA id d188sm8903491ioe.52.2017.07.17.07.30.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 07:30:56 -0700 (PDT) To: Cullen Jennings References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> <5559A4D7-0D55-403D-A3C7-527942640A15@ericsson.com> <1243a4c8-5ce6-642e-faf3-5dda093d13df@filament.com> <3CFFB9AE-AD69-4AAD-B646-5E348DF53986@iii.ca> Cc: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , core From: Peter Saint-Andre - Filament Message-ID: Date: Mon, 17 Jul 2017 08:30:55 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3CFFB9AE-AD69-4AAD-B646-5E348DF53986@iii.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 17 Jul 2017 14:31:09 -0000 On 7/17/17 8:28 AM, Cullen Jennings wrote: > > Thank for the great review... Ari and I working on it but just to add to > this one point. > >> On Jul 17, 2017, at 12:37 AM, Peter Saint-Andre - Filament >> > wrote: >> >>>> >>>> Why was 80 bytes chosen instead of, say, 50 bytes or 64 bytes or >>>> 100 bytes? (Here again I'd remove the text about mesh networks.) >>> >>> These two points, mesh and 80 bytes, are related. 802.15.4 (6LoWPAN) >>> mesh networks result in about 80 bytes of usable payload per packet >>> without fragmentation. >> >> That makes sense. In which case it would be good to mention this, so >> > > How about we say keeping it small is good and quote examples of 802.15.4 > has about 80 byte payload and that LoRa has 51 byte of applications > payload in long range mode and just remove any reference to "mesh" +1 Peter From nobody Tue Jul 18 00:53:01 2017 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 2A3B0131D69; Tue, 18 Jul 2017 00:52:59 -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 7-T3YSGb6yf4; Tue, 18 Jul 2017 00:52:58 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 DF3E8131DA6; Tue, 18 Jul 2017 00:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6I7ql2t005715; Tue, 18 Jul 2017 09:52:47 +0200 (CEST) Received: from client-0254.vpn.uni-bremen.de (client-0254.vpn.uni-bremen.de [134.102.107.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xBXSv2CnTz3ZVh; Tue, 18 Jul 2017 09:52:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Tue, 18 Jul 2017 09:52:46 +0200 Cc: Jim Schaad , "draft-amsuess-core-repeat-request-tag@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 522057166.685595-04fcbdf4066a89d0369816a908f8d591 Content-Transfer-Encoding: quoted-printable Message-Id: <4676E9F0-E102-4D18-A10E-BF1210EED4BE@tzi.org> References: <03d901d2f9ba$1164fcf0$342ef6d0$@augustcellars.com> To: =?utf-8?Q?G=C3=B6ran_Selander?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] draft-amsuess-core-repeat-request-tag X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jul 2017 07:52:59 -0000 I agree that the name =E2=80=9CRepeat=E2=80=9D is both confusing and = non-descriptive =E2=80=94 this option is not about repeating anything. Freshness Token is more like it. 2.2: What is an "empty CoAP request=E2=80=9D? (A CoAP message can be empty or can carry a request, but cannot be = both.) I=E2=80=99m not sure that the requirement for a 64-bit or larger value = is justified; it is the application that defines its freshness = requirements, and if the freshness requirement is just about avoiding = unnecessary work, a smaller freshness token may be just fine. There might be other ways to derive/convey a freshness token; maybe = it=E2=80=99s worth thinking about how this option would interact with = that. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 18 01:00:02 2017 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 210AA131A53; Tue, 18 Jul 2017 01:00:01 -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.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150036480108.11397.10886409027756075991@ietfa.amsl.com> Date: Tue, 18 Jul 2017 01:00:01 -0700 Archived-At: Subject: [core] I-D Action: draft-ietf-core-comi-01.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 08:00:01 -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 of the IETF. Title : CoAP Management Interface Authors : Michel Veillette Peter van der Stok Alexander Pelov Andy Bierman Filename : draft-ietf-core-comi-01.txt Pages : 56 Date : 2017-07-18 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. CoMI 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-comi-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 19 00:20:15 2017 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 CB3EF131BF4 for ; Wed, 19 Jul 2017 00:20:13 -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, RP_MATCHES_RCVD=-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 XBrAcT8aERg0 for ; Wed, 19 Jul 2017 00:20:11 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 16F6F13178D for ; Wed, 19 Jul 2017 00:20:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D33D22CD0D; Wed, 19 Jul 2017 10:20:09 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R2gRBFeTcHT; Wed, 19 Jul 2017 10:20:09 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTP id 325182CCBF; Wed, 19 Jul 2017 10:20:09 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_20EFCFB7-81D5-4E94-820D-EB75FAF3F3EC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: Date: Wed, 19 Jul 2017 09:20:10 +0200 Cc: Core Message-Id: <03BBD9AC-BD80-4B24-940C-3980056D4AC3@piuha.net> References: To: Peter Saint-Andre - Filament X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [core] comments on draft-arkko-core-dev-urn X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 07:20:14 -0000 --Apple-Mail=_20EFCFB7-81D5-4E94-820D-EB75FAF3F3EC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Peter, > First, RFC 2141 and RFC 3406 were recently replaced by RFC 8141. The > registration template has changed, the registration procedure has > changed, everything should be simpler than it used to be, etc. Please > see RFC 8141 for details. Also, the ISBN and ISSN registrations are > great examples of the new template: > > https://www.iana.org/assignments/urn-formal/isbn > > https://www.iana.org/assignments/urn-formal/issn > > Second, we might be able to use URN f-components (preceded by "#" as in > other URI schemes) instead of the namespace-specific componentpart > (beginning with ";"). Have a look at Section 2.3.3 of RFC 8141. Thanks for this. I will implement these changes in the next revision. Jari --Apple-Mail=_20EFCFB7-81D5-4E94-820D-EB75FAF3F3EC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZbwgqAAoJEM80gCTQU46q99wP/1pRPqqUkb01wACainORYK8d FpEgFEblcC1L8uCKYyv88o8ykqRSle+eKpMDTcG2vXgQ8znD9Qs6SJ3Pa0kn8gPa cJUenb34MMYAaHVoDvvUsXk8zxSf/Hk6QEURz46gZtVPax1kchMnPdaMieE/8uf5 hqI0aWTf8P1ZJER3dhXcFoiclbnaxZ45ADtW9STJZiP7hB6GbBmKeAl35oxHmY5k H2tARPlAz2NIOjv0cmtTAEN1X240+RJX8Dd+DsvaLAqEYD4WfNhd06rAYmDYcARn LMJPhXpoMe8UdwntkTokKKdiUYWIEeUkXzevdYCr+cQkAgFTW2MPk5kUIP09DwMQ cqgEAditjA/u3Xc30PgdGYqvcO/X1EoptAX48HehhdL9gkVnY5M7xL4MItAebxD7 RmXpagJnfQQjmyQk2YcyywA/yHYLXNgLi4Jfo0o6J96fw0uXMnyUuoTUgkDVlSxY WH1clGa/OlOFky9c1UzxJIPFb5CQZ2dsTnJEiPs8vYj/5ULd9jt0+QLzH9PLdKJz hufwZX6GTk18UGWmI4FllwoveSn+0JBO1YZvWzUfBtElig4QrJV4a8AW3POzDBLS g+7/c4X8CUO5JhUJq2lkxZBfoykWpFu+WPdbq7ZOciB91nLxk98nFB0jnJgYqri9 8BOO35WQIRXN4pwsXuNY =2nSJ -----END PGP SIGNATURE----- --Apple-Mail=_20EFCFB7-81D5-4E94-820D-EB75FAF3F3EC-- From nobody Wed Jul 19 01:21:48 2017 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 21F37131C1E for ; Wed, 19 Jul 2017 01:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 aJDJLTCGsmJl for ; Wed, 19 Jul 2017 01:21:44 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 97661131C13 for ; Wed, 19 Jul 2017 01:21:44 -0700 (PDT) X-AuditID: c1b4fb25-607ff70000001eeb-4b-596f1696bae5 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DE.E4.07915.6961F695; Wed, 19 Jul 2017 10:21:42 +0200 (CEST) Received: from ESESSMB106.ericsson.se ([169.254.6.14]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 10:21:42 +0200 From: =?utf-8?B?SmFpbWUgSmltw6luZXo=?= To: "core@ietf.org WG" Thread-Topic: Temporary Etherpad Thread-Index: AQHTAGgMbDOthJ6uI0uKXGTn9ZJ2cA== Date: Wed, 19 Jul 2017 08:21:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/signed; boundary="Apple-Mail=_32B6F3EE-D1DA-44F1-9D0A-3A3641A00969"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2K7se40sfxIg/4fOhb73q5ndmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtrTW1kLDtlW7P65jaWB8aRVFyMnh4SAiUTvjOnMXYxcHEIC RxgltsxawwbhLGaU+LPhFCNIFZuAs8SnZ43sILaIgJpE66RXbCC2sIC0xJFH+5i6GDmA4goS h9rEIEr0JB7OnsEEYrMIqEpceL4BzOYVsJf48uQjWCujgJjE91NrwOLMAuISt57MZ4I4SETi 4cXTbBC2qMTLx/9YIWwliUW3P0PVT2GUuL9bG2KmoMTJmU9YJjAKzkIyahaSsllIyiDiSRKT 3ixihbC1JZYtfM0MYWtK7O9ezoIpriHR+W0iVL2pxOujHxkhbGuJGb8OskHYihJTuh+yL2Dk XsUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGFsHt/xW3cF4+Y3jIUYBDkYlHt4rgvmRQqyJ ZcWVuYcYVYDmPNqw+gKjFEtefl6qkgjvDnagNG9KYmVValF+fFFpTmrxIUZpDhYlcV7HfRci hATSE0tSs1NTC1KLYLJMHJxSDYz67JcqRdTFTZ6uNDbrEX9yX+fS6z9cs6Kn/BXd2rlJR+fQ 1i6n3COT54fd4hHqLg1afUPkTMN97/Rap5qWp5u5XKU/naladMtbaM6vEmG1l8rChWK7JvFM eH94qu9ejZ+bWvn3a5zovtx0/9jUh4odO6RmWnRm1xdufHatkvME/5xpJ8QeKx5XYinOSDTU Yi4qTgQAVZ5zlrUCAAA= Archived-At: Subject: [core] Temporary Etherpad X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 08:21:46 -0000 --Apple-Mail=_32B6F3EE-D1DA-44F1-9D0A-3A3641A00969 Content-Type: multipart/alternative; boundary="Apple-Mail=_4940197D-7F61-4827-83AF-666C442F4FF6" --Apple-Mail=_4940197D-7F61-4827-83AF-666C442F4FF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As Etherpad seems down, we are using this one temporarily.=20 = https://docs.google.com/document/d/14FAqRl6UooEWY_Iu3s948MVkdk9AYjHAo2YWjz= 0Z8RQ/edit = Thanks! - - Jaime Jim=C3=A9nez --Apple-Mail=_4940197D-7F61-4827-83AF-666C442F4FF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
As Etherpad seems down, we are using this one = temporarily. 

https://docs.google.com/document/d/14FAqRl6UooEWY_Iu3s948MVkdk9= AYjHAo2YWjz0Z8RQ/edit

Thanks!
- - Jaime Jim=C3=A9nez

= --Apple-Mail=_4940197D-7F61-4827-83AF-666C442F4FF6-- --Apple-Mail=_32B6F3EE-D1DA-44F1-9D0A-3A3641A00969 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMrTCCBe8w ggPXoAMCAQICEGjDnK4TEsyfW0+Qr43kvSowDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjA5MTMy MzExWhcNMTcxMjA5MTMyMzEwWjBpMREwDwYDVQQKDAhFcmljc3NvbjEXMBUGA1UEAwwOSmFpbWUg Smltw6luZXoxKTAnBgkqhkiG9w0BCQEWGmphaW1lLmppbWVuZXpAZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdlamFqaW1uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz9DiTCOChb1bYXyr VSnjxfVxZ+NGqajFezGGSWAWycgkTkiVdHu7Ek89luoUCU9D8KukeSlzeIFu+TdcANzelWOUqm53 Dh64KfoutxkI1g1FOk8+o45tjBFqw7xknXyEUhZ9/XLqaXuRdw7sCvO91Z05R37hwGhscO7M0fgv lRtWBxaqbC/Ikvjo+PPqt5zpx+GFaqsJ0+4ZQWjrb6I+8e8EAxCpLqB9HmCAztI+zog/tzaSDQdd gQVjLDAndvnKRziQvOrYc5kvJHkXzLcWITDYmi5pZrgNRBJL2poiwSopQPlF5bGjaRYu2WBytXe2 SDEj1viuqpae1vxy7+AdUwIDAQABo4IBwDCCAbwwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwJQYDVR0RBB4wHIEaamFpbWUuamltZW5lekBlcmljc3Nvbi5jb20wVQYDVR0gBE4w TDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0 LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1Ud DgQWBBQ58oLpEh/5VlA3MqHd3ggGy2cPpzAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9L NzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBABcJc9IVKYtDtvxGDcoFbAFvNeiH +bRaEu1d9BWRhjtb8ZAU586LmsSwblH+2rbFRtisroKUwq7tZyjQtCrL7Rma0yM74p5PNZ7sGfmz yNZT33hfTZEDo7bjKdaUg0ELBzQvttjIIr7tBVf9cpdOAyOkGn3oqGEomPizRDiKrXBD3V8oMibX nQDb90hg8TJmLb9mqyaRnu1ztxV2585qJUXXPAt1v6qUy23V+tmOE7JzMxrQwa5UupoS/muaQSsR 7Evde7pXBg8jERM7o4VZJIA7LI55ogyb37O7W2zhITXzbHgjQzLoS6MonjIPegCv3pLgdLx0zXhp SUT19qg2LmX1sXTxLJBSJp5eev+x8B7H14taM8FpsAVGLccstjPuxOabdmNNaEvfSBL7GPtQ5Sil DTMdbxhtuFPlP+1p4tPC6A/85YQozqTKCgk28emo8UupTt28DZgfP5b7xpBbnrsA/2aRYpmV2Ay8 BOd8g4O+ZP0WZD9/vPddUDBYPpJiSulKe6uj15vsiiBY4D272VS0dMpwXOvmkKKS/ZAmarywk0hy bl2mb+GW456+N8CESWD4JIHABoXxVAaa0GdGEyL1lSEmw7jOU2h5UAhlhHqPudpSoaLJgqateP2C hWYGv/DwkR9bVpuO8k1ohfjJA4n0qgxfOkWU23sZgo6495KjMIIGtjCCBJ6gAwIBAgIRAKAMy8yb mZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNV BAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIx WjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXs MmGSWShc6A5IEyFboXMZW3lFHso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHf Ozlwk7uwojJ34tHLiX/yQoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FA cLiIEeTMPRgXcn+8GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgA mInJ4Ga8S6ME2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenI UwYCKNPq5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP 5XnIcMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLxBiA1 41dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wjNnAA6Mqe aTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIBtDCBigYIKwYB BQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20w SwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxp YXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYB BAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNv bmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYD VR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9 kEKyYZtxJn9cv7S2dUxuUiegmAvUGHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg 36XYkNS7Ot0A1UqdjGFrtnIISI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiX g5HMTdOl6mlDbJaTIEGagdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ 6fEAOLW1j2IjJ0cyDI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+k XDJGbOaK42H2ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5 tTQYQeO7QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6 n5oEGOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz9uHr ZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYICljCCApIC AQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjAJBgUrDgMCGgUAoIIBHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA3MTkwODIxNDFaMCMGCSqGSIb3DQEJBDEWBBRb dgedfZpxDGJ2uIVa4VAF8TE1QTBdBgkrBgEEAYI3EAQxUDBOMDoxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhBow5yuExLMn1tPkK+N5L0q MF8GCyqGSIb3DQEJEAILMVCgTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQaMOcrhMSzJ9bT5CvjeS9KjANBgkqhkiG9w0BAQEFAASC AQAQFpcFLx2G1Oo0Fi67MQf/Vw61qyXPVeIh8BV/tlz6wu/jsZcI3/hc0rFeY36VJFtXcRxpGBY7 m9Q/U6XZvb7daXC6ms/R9z5GeEqLTm/1KN+XnvSYBUM/zZFVbyPdsxV6mIljxv/xb4qVOThzd5Ha Rbp0uMTbEQaC5UXEnWkAdmOAfF4DcrkhqqJl9QNlqBR75qC9vpdat79HbCKxNRipuDZwW5s0PEdY NE4NMUrrTgV2smdbAtb+e6Q2WrwnLvfwRsA78lyhL/Ic2b/PSzgzdphpvTcuGZ4W9ZK2xTDl1iIz path2Qc971GS5ojR7+2NP1v+2G++XoMEapRlKXdMAAAAAAAA --Apple-Mail=_32B6F3EE-D1DA-44F1-9D0A-3A3641A00969-- From nobody Wed Jul 19 02:54:52 2017 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 4489D131C78 for ; Wed, 19 Jul 2017 02:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 FS9XKikyH1ki for ; Wed, 19 Jul 2017 02:54:48 -0700 (PDT) Received: from smtp69.iad3a.emailsrvr.com (smtp69.iad3a.emailsrvr.com [173.203.187.69]) (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 CD31A131C77 for ; Wed, 19 Jul 2017 02:54:47 -0700 (PDT) Received: from smtp25.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F1E1D25892; Wed, 19 Jul 2017 05:54:36 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp25.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 71F0C25890; Wed, 19 Jul 2017 05:54:36 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from ams3-vpn-dhcp2689.cisco.com ([UNAVAILABLE]. [173.38.220.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Wed, 19 Jul 2017 05:54:36 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_55835D87-AEF3-4A28-BE8F-6DAE954F8DEF" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Wed, 19 Jul 2017 11:54:38 +0200 Cc: Core Message-Id: <73869BE3-749F-4D5E-982A-B0ED4DB686D4@iii.ca> References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> To: Peter Saint-Andre - Filament X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 09:54:49 -0000 --Apple-Mail=_55835D87-AEF3-4A28-BE8F-6DAE954F8DEF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Jul 16, 2017, at 5:00 AM, Peter Saint-Andre - Filament = wrote: >=20 > Speaking of which: >=20 > New entries can be added to the registration by either Expert Review > or IESG Approval as defined in [RFC5226]. >=20 > Why define two policies? That's just introducing the possibility of > confusion. There have been times in the past where the Expert was did not respond = in a timely fashion. This allows the IESG to quickly take care of a one = off event. Of course the IESG can always just replace the Expert with = someone new but that tends to be a bit more heavy weight and take = longer.=20 I don't care if we move this to only Expert Review but slightly prefer = both. I would strongly object to making this only IESG Approval as we = need to be able to add new things in a light weight and quick way.=20 --Apple-Mail=_55835D87-AEF3-4A28-BE8F-6DAE954F8DEF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 16, 2017, at 5:00 AM, Peter Saint-Andre - Filament = <peter@filament.com> wrote:

Speaking of which:

  New entries can be added to the = registration by either Expert Review
  or IESG Approval as defined = in [RFC5226].

Why define two = policies? That's just introducing the possibility of
confusion.

There have been times in the past where the = Expert was did not respond in a timely fashion. This allows the IESG to = quickly take care of a one off event. Of course the IESG can always just = replace the Expert with someone new but that tends to be a bit more = heavy weight and take longer. 

I don't care if we move this to only = Expert Review but slightly prefer both. I would strongly object to = making this only IESG Approval as we need to be able to add new things = in a light weight and quick way. 



= --Apple-Mail=_55835D87-AEF3-4A28-BE8F-6DAE954F8DEF-- From nobody Wed Jul 19 05:42:33 2017 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 C4770131CED for ; Wed, 19 Jul 2017 05:42:31 -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] 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 UcbycKsjlyU1 for ; Wed, 19 Jul 2017 05:42:29 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991531288B8 for ; Wed, 19 Jul 2017 05:42:29 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 2C9EA46FDC for ; Wed, 19 Jul 2017 14:42:28 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5D9116F for ; Wed, 19 Jul 2017 14:42:27 +0200 (CEST) Received: from hephaistos.amsuess.com (dhcp-886b.meeting.ietf.org [31.133.136.107]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2D74D389 for ; Wed, 19 Jul 2017 14:42:27 +0200 (CEST) Received: (nullmailer pid 11363 invoked by uid 1000); Wed, 19 Jul 2017 12:42:24 -0000 Date: Wed, 19 Jul 2017 14:42:24 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: Core Message-ID: <20170719124224.kxzusi72sw6m5tqo@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jb6po4v4k2gvb3nl" Content-Disposition: inline User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: [core] coap+at and DNS X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 12:42:32 -0000 --jb6po4v4k2gvb3nl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello working group, going over the notes from the morning session and reading Dave's multi-transport-uris, it didn't become completely clear to me why we can not use DNS-SD for resolution of coap+at URIs, or why Dave's 3.4 is not already the way to go. (For URIs like coap+at://[2001:db8::1]/, this would not do anything). Suppose we specify for coap+at that when the operating system is looking up the reg-name, it needs to go through SRV lookup. The client could then obtain host and port from a direct lookup if it has a or a few particular transport(s) in mind (_coap._tcp.hostname, _coap+ws._tcp.hostname with Hostname and Path being transported in TXT) or ask for all transports using _services._dns-sd._udp.hostname. As said, that'd only be for coap+at lookups of things that are DNS names (in which case the client needs to have DNS anyway, and can probably afford doing that via SRV just as well as using any other mechanism). If a constrained device that can not do DNS lookup is passed a link, it could receive it with target attributes like ;at=3D"udp6:[fd00::1234]:56830 udp4:10.0.12.34:56830" (possibly with some lifetime information as well), and forego that lookup, or a device with a DNS stack could still use that information to save the roundtrips. This sounds like a relatively simple solution to me, so I probably missed something (possibly also Dave already suggesting that with different words) -- but what? Thanks Christian --=20 We are dreamers, shapers, singers, and makers. -- Elric --jb6po4v4k2gvb3nl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAllvU6wACgkQOY0REtOk veHbUQ/+OG+oQIKTrY0culHpw4VUvf6L4jXfAUP3FnfbhzoEVHa7iCIEco64A5Dl 5AoIQ5qq8GgK9qtxCU3Cq+Ec+w7KSZJs+yCcDKijHWRMGA0vJF4GWYhjcBiJT4ws M6JYYYfj/IRhnkNuc0ZmKRoi3Zjh6KQdF72wNWQ8fIuhzCZhJtcEgGT5w4xtyTiG mAI0WqeUaeMi4vAt7Td1cyN2WawUnNxAhrh8Wkbx9MpvpnLrCS5eRCRP3GoNkTbw fKyCS9NeDSv341yRQCdhNnDOMwRObFsg7JlQCeOzN3tG+xb9xoj9G+g8zs4mGI+H eimSpQD91yv+gyGcjLKGUJTt4SczbjMKFmb3pNF1TlIraljxZ0WTWV+KDwkS1AQf dUcOFygdp8gTKTQB+ACSAE2KPVvfQDzcm721QLhyXviP02hX4dfNNhmOAPkBX4Al ih79GhXDGD2RmI5SJ++QWHhj/lbH8+azsNzWHuDdu9DyOediLRuoynJavox5lO0I oco8fzbpSHuiCQ6YVYZjQWEXLHmvdCHx2hAXyHa/vIqQcR0r2yopV6BvgzgAJ2vK ROp3/w2DQicmQqX5VzHeckD2Kkt4J6HY2PEA4RsJ9MVd1Jtn8ebAw9nFqXnnNcVX UBoNgzAVMrUVceL89pBHpfXPUlV8ptU65ZCCqbIYOiC7mh+SIZk= =2WRm -----END PGP SIGNATURE----- --jb6po4v4k2gvb3nl-- From nobody Wed Jul 19 05:45:48 2017 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 85CD9131B1C for ; Wed, 19 Jul 2017 05:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 S1-pOLo6czph for ; Wed, 19 Jul 2017 05:45:45 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.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 2337E1288B8 for ; Wed, 19 Jul 2017 05:45:44 -0700 (PDT) X-AuditID: c1b4fb30-71bff70000001664-df-596f5477710e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8E.E7.05732.7745F695; Wed, 19 Jul 2017 14:45:43 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 14:45:42 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Peter Saint-Andre - Filament CC: core Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dMQyBvbiBkcmFmdC1pZXRmLWNvcmUtY29hcC1zZW5t?= =?utf-8?Q?l?= Thread-Index: AQHS/oQaqDg1pfroaU+/t65FgWCHvaJa+00A Date: Wed, 19 Jul 2017 12:45:42 +0000 Message-ID: <5AA558F8-BD20-4871-806B-251155922C56@ericsson.com> References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> <5559A4D7-0D55-403D-A3C7-527942640A15@ericsson.com> <1243a4c8-5ce6-642e-faf3-5dda093d13df@filament.com> In-Reply-To: <1243a4c8-5ce6-642e-faf3-5dda093d13df@filament.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/signed; boundary="Apple-Mail=_612255DA-328F-4FDF-AEEE-4E6E4FEB7280"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2J7iG55SH6kwYlLshb73q5ntph9JtiB yePSptnsHkuW/GQKYIrisklJzcksSy3St0vgyjh86jFbwWzfipl3uRsYT7t2MXJySAiYSLx+ fICti5GLQ0jgCKPEpe3bWSGcxYwSz66vYQGpYhOwlXjSuo8VxBYRMJX4NamfGcRmFpCQOLvy MFhcWCBVYtGGbmaImjSJSX/+QtlGEje/TwazWQRUJZYcmgtWzytgL3H86CtmiGUPGSWWXtzG 3sXIwcEp4CBx+bwZSA2jgJjE91NrmCB2iUvcejKfCeJqEYmHF0+zQdiiEi8f/2OFsJUkFt3+ zAQyk1lgCqPEr+trmSCWCUqcnPmEZQKjyCwks2Yhq5uFpA6iSFti2cLXzBC2psT+7uVQcVOJ 10c/MkLY1hIzfh1kg7AVJaZ0P2RfwMixilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMw4g5u +W2wg/Hlc8dDjAIcjEo8vDO98yOFWBPLiitzDzGqAM15tGH1BUYplrz8vFQlEd6fQUBp3pTE yqrUovz4otKc1OJDjNIcLErivI77LkQICaQnlqRmp6YWpBbBZJk4OKUaGMtiy/bHvo3XDEs6 yfe2+3w7m6nCus2Vt9oe7NfkKq7hvGC0YaNOrZWDZvUjw0cxelozyt4GF71tFmBu3WhmXizA 91zBYI6Cyj4pDV72+Vwd07qneoa+nbTT3/NEE9PWhyksgupXvGwDm3xL7b/K3S6amHfZdbHZ xfPxG2vr3NL87q9rP+GuxFKckWioxVxUnAgA5JVzBsACAAA= Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 12:45:47 -0000 --Apple-Mail=_612255DA-328F-4FDF-AEEE-4E6E4FEB7280 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Peter, See inline for comments on the remaining issues not discussed in other = parts of this thread. > On 17 Jul 2017, at 0.37, Peter Saint-Andre - Filament = wrote: > On 7/16/17 4:16 PM, Ari Ker=C3=A4nen wrote: [...] >>> Some of the examples in this draft use the device URN type as >>> specified in [I-D.arkko-core-dev-urn]. >>>=20 >>> Aha. But why? That's an expired informational I-D which never >>> actually registered the urn:dev namespace. I suggesting using >>> urn:example URNs instead. (If there's a desire to advance >>> draft-arkko-core-dev-urn, then let's do that - although note that >>> registration is easier now that we've published RFC 8141, and we >>> wouldn't need to advance the I-D in order to register the >>> namespace. In any case, having lots of examples of an unregistered >>> namespace seems like bad form.) >>=20 >> That draft was just recently resurrected >> (https://tools.ietf.org/html/draft-arkko-core-dev-urn-04), but >> unfortunately only after we submitted the SenML draft. Good comments >> for that draft. >=20 > Thanks for the pointer. I'm one of the expert reviewers for URN > namespace registrations, so I'll provide separate comments about that > I-D soon. >=20 > If that I-D will be a normative reference here or we are depending on > registration of the urn:dev namespace before progressing SenML, then = the > WG might consider using the urn:example namespace for now. It's only informative reference and used only as examples. But I don't have strong preference either way (except that not changing = things is always easier ;). [...] >>> Please note that this set is more restricted than the range of=20 >>> characters allowed for URIs in general (RFC 3986) or URNs in >>> particular (RFC 8141). At the least it would be helpful to point >>> this out, because AFAICS it will limit the URI schemes or URN >>> namespaces that can be used. >>=20 >> Good point. I'd suggest text: >>=20 >> "Note that the character set for SenML names is a subset of the >> characters allowed in URIs. The restricted set was chosen to enable >> efficient and safe use of names in various systems (e.g., as database >> keys)." >=20 > I suggest that we also say something like "The restrictions imply that > care needs to be taken in the choice of URIs or URNs as SenML names." > Furthermore, if someone wants to use a URI scheme that allows = characters > outside that set (e.g., the 'tag' scheme), then do those characters = need > to be encoded somehow? (Ick.) If not, then we should say so. One should not try to put "full URIs" into the names. Rather the names = can be used as part of a URI. Perhaps something we should be more clear = about. Now: https://github.com/core-wg/senml-spec/issues/73 >>> Section 4.6 >>>=20 >>> Up to this point in the document, SenML has been defined as a >>> format for representing sensor measurements. Given that a sensor >>> measures something in the world, what does it mean to *set* the >>> value of a sensor or a sensor measurement? >>=20 >> I guess this needs to be elaborated also in the intro (it's hinted in >> the abstract). >=20 > That's the barest of hints. :-) I almost provided a comment about it, > but let it go. Admittedly :) Do you have any proposal how to make it better? [...] >>> Section 12.1 >>>=20 >>> Units marked with an asterisk are NOT RECOMMENDED to be produced by >>> new implementations, but are in active use and SHOULD be >>> implemented by consumers that can use the related base units. >>>=20 >>> This advice seems unrealistic and likely unnecessary. >>=20 >> Why unrealistic? >=20 > Because we're saying "hey you new implementations, don't do this, but > everyone else before you does it". Developers of new implementations > won't want to miss out on this feature (if it's important). You don't really gain anything implementing the "legacy way", so I don't = think that's really a problem.=20 Cheers, Ari= --Apple-Mail=_612255DA-328F-4FDF-AEEE-4E6E4FEB7280 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMqDCCBeow ggPSoAMCAQICEQD6DAOc/5f0WLIscub/Ets/MA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIwMjE0 NTY0MloXDTE3MTIwMjE0NTY0MVowZTERMA8GA1UECgwIRXJpY3Nzb24xFTATBgNVBAMMDEFyaSBL ZXLDpG5lbjEnMCUGCSqGSIb3DQEJARYYYXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tMRAwDgYDVQQF EwdlYXJpa2VyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiQ6/yW4ZyfTOP25xgQsm LuLOe1Dzz6aA5qv8aa+X7zADW1TNPsHlRyEjN25OenU73pSPMM/we06WGetED9lwO6WYSXEW69zN H7shEv7E3oWFkZxLemb/lB6ldVNRc3fmPc8AIvbJmb1O/w1h68pcsMG/zCTDHEp8K9QwyCP2WXBU cBcZ3n67FuSWcxhJLTOScxMiXgbzMy5358ZUVGZwSpo1h6OvjWNMxhP2r9zvVU+rVinsILqwB3Ii 6gSuMheq3n3xNnvpPhj5nDg6HgHU2W/NrE/KoYpRhoxyS/9MgYIXSyHKau4mo0hHAgj0NDwzk45O Yc/pB1keer7g+qT5EwIDAQABo4IBvjCCAbowSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50 cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEE djB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2 Mi5jZXIwIwYDVR0RBBwwGoEYYXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYM KwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxp YXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU Tt7OuiPseKi8/pwwc54KqU7l+uAwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwDgYD VR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBWKYJqheGSHGZGS7Y7pHYHUI9cMUYHmhgI oLqqWcbkeGDqvHsSqYACAOZtxWfonBglWNg2Gp8Mz/ufiCo747KQ+YW9yfn2NXoHVYHKuZLtgwxt kXidHad/VxQJLDRCfGeTv0BxF8uF+05hWpgKx1iRB5HevdF+qb55HcCVw/k5yFK+ZeNnI4FJChD4 NIPtioHadTRnaBWwrbsK1LWaQYLtFRFUH6uaqHSDQF6nIjdwtKn94MLt270IsQj72qvDOHk3XWtw 7p+W0m0Dy6WbSMNysNEah9gp0fPs8hbirK5yqOEp+ug9If2KFZHgKCwJZkhh/3WIFiFZasV2UfN9 Ngx41llsZe28CjA5w97qtnZ86DaTvE5k3NDv5UahBR2bxDznviZFjwhUPSmYXJfanKHW1SopWPmI Z3Ye9zvFSUbYNeTUsxTbjYkuz45BrkzWISv23s7YDNwx/L37QLb0AoNjuq2EoU9dUTIiI5+2giIa ZKiS5bQYl92gG0+hV14u5hLWzfN7QyqdiM5+Nm3KjiXZPW/+ThD/DTDxlyJVTWWP8hb7poSystU+ xqPK0EXtjgfg+jMRFaR0hmdlCMnMjFdlaT8lTKW3DPP78+sQz2svn/JcBY3ETPdJSwSYeEQAjbNG GvJ3DxmGNC5xXoAT6wa80BfNlD7LZEcf4stD9udmrzCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6 cPR8wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVowOjER MA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4Gnl17DJhklko XOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWXhPTdNzrB3zs5cJO7 sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZabrGh9OxQHC4iBHk zD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtVaqitBl0oAJiJyeBm vEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldVJtMwDYXpyFMGAijT 6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDH SBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvw hkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsu REnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3I T7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEB BH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsG AQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25l cmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8C AwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEu Y29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1UdIwQY MBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3PZBCsmGb cSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n65c5oN+l2JDU uzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+xhsfysYiIl4ORzE3T peppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy04/RnoylxSenxADi1 tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEueSRNASLfpFwyRmzm iuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWXI0g6SgdDObU0GEHj u0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBji J/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyG EyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7G eSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGCApkwggKVAgEBME8w OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Eg djICEQD6DAOc/5f0WLIscub/Ets/MAkGBSsOAwIaBQCgggEfMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDcxOTEyNDU0M1owIwYJKoZIhvcNAQkEMRYEFMnHx/yp u3MUN72nkt6Z6wXusbsGMF4GCSsGAQQBgjcQBDFRME8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQD6DAOc/5f0WLIscub/Ets/MGAG CyqGSIb3DQEJEAILMVGgTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIRAPoMA5z/l/RYsixy5v8S2z8wDQYJKoZIhvcNAQEBBQAEggEA JCSz9QP4WDWW0CtjkEAYzpX18UqsxRj3IMpp5hyQLLUxNtBYKFEKMjgiwN4a7rR0C7fkZhJps1Mf +tVRlirIwLbxG37stnwDhzSN1IhuQ26AgxXPpbG9hsecbS728+tRBoVA8QG9vf9i4Hx09TrOFgP4 5UZLM5HdVSoeSmYZEArrP0/HhqGjxKus+41ikY7y2qBYIiyFqquN41k8Iwe2hQyfqdndZbGWeVo9 QhsETWwOsPLDnb15KPR1x+7YW0M+6rC55BGPUKg8jxt5F8TflXCqcrCI73p86ZteclYVka+KinJg bCGao9MWPh9LIPHIxF+W8F4sgAkK4OSwz78/fwAAAAAAAA== --Apple-Mail=_612255DA-328F-4FDF-AEEE-4E6E4FEB7280-- From nobody Wed Jul 19 07:16:01 2017 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 5861A131A7A for ; Wed, 19 Jul 2017 07:16:00 -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, 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=filament-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 EOaEvQLWQjrj for ; Wed, 19 Jul 2017 07:15:59 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 3D32A131891 for ; Wed, 19 Jul 2017 07:15:58 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id h199so1232297ith.1 for ; Wed, 19 Jul 2017 07:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=sMj0Ek2ZZblKb8MlIEYwUpf1fW/LwDPaULMfBJXorzQ=; b=F2GZRMYN1uaQrWdKFaZDCmbZ0D7d7ArW8q/DWWPDOtEjEJn+UCHcuVQWQ6/QVaxCUd Jq7S3aj2epHip4vCZu89S4gA2bWDoID9uY+E0yk1E83Dt36K/wwVn8RvhjzRxmFCOcmu BY3NO6wU86p2Xv4L4guPQD+WmcunYR2PzXjWEuB6fOI+IG9jQVEGgONxJyfBr04P7QZp 22YtVsVSwbca6s40zfUMrOc/27fJLnfBGfUTBjQqge2fa7Dw0tDw2S+8/nWQfK8B1DGr +ZRy+BQP7RbfjyyzBawpkW4ydspwIC7qfLeLFotOIpTRLBGt79ONCh2VxEpULJ9gV3Ex q4pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=sMj0Ek2ZZblKb8MlIEYwUpf1fW/LwDPaULMfBJXorzQ=; b=dUmpJ7L14jiUt0aSKT1/b9yDlS+XDh/SqXBe1h8Auy8ij2NNt9u6LemE44C7VQoYtM zcwc6Lsrx3dk+jt6d2uRqk1wQBhQvYSShu0NEpH5GqB1m1aMdzA8oXOe18S3F6KkIwnt bzbNwK2nh1se9h3LpIMDJXBJqK3QecgMhEjQfOv9LS8BlpEEuy39SB1TmRjE71bK451/ CV6/amEOP/q+OJD8gOHrO9VvIaeSK2wMtFmvS7za93ZeSIbAyK5ZGc0XYIIa4nI+DLiE nmcnZ0UeDy1Ags6R9F2nuUjKPOB3yHXyDy4CUg3ROzaIGiyrbQZLqgQojrsUo0Q3hsas NwCg== X-Gm-Message-State: AIVw110HTc/iSRAUA96G/yRcHudccoKBsMvtWevU4MkP1M1VCC4gVJA2 DsiefIEh8niv2ucL X-Received: by 10.36.17.69 with SMTP id 66mr9066itf.9.1500473757459; Wed, 19 Jul 2017 07:15:57 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:ddf3:d144:6291:35ab]) by smtp.gmail.com with ESMTPSA id d23sm64378ioj.22.2017.07.19.07.15.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 07:15:56 -0700 (PDT) To: Cullen Jennings References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> <73869BE3-749F-4D5E-982A-B0ED4DB686D4@iii.ca> Cc: Core From: Peter Saint-Andre - Filament Message-ID: <904733b3-a5e3-a43a-dd5e-abcf880e4c51@filament.com> Date: Wed, 19 Jul 2017 08:15:53 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <73869BE3-749F-4D5E-982A-B0ED4DB686D4@iii.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 14:16:00 -0000 On 7/19/17 3:54 AM, Cullen Jennings wrote: > >> On Jul 16, 2017, at 5:00 AM, Peter Saint-Andre - Filament >> > wrote: >> >> Speaking of which: >> >> New entries can be added to the registration by either Expert Review >> or IESG Approval as defined in [RFC5226]. >> >> Why define two policies? That's just introducing the possibility of >> confusion. > > There have been times in the past where the Expert was did not respond > in a timely fashion. That's a management problem. Replace or augment the Expert Reviewer team. > This allows the IESG to quickly take care of a one > off event. Of course the IESG can always just replace the Expert with > someone new but that tends to be a bit more heavy weight and take longer. That's a proactive management problem. :-) > I don't care if we move this to only Expert Review but slightly prefer > both. I would strongly object to making this only IESG Approval as we > need to be able to add new things in a light weight and quick way. I have no deep objections to both, but now we have two code paths when one might have been enough. Peter From nobody Wed Jul 19 07:31:57 2017 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 5F9FF131C73 for ; Wed, 19 Jul 2017 07:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=filament-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 mDApK4yZx4Kf for ; Wed, 19 Jul 2017 07:31:53 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0839412F268 for ; Wed, 19 Jul 2017 07:31:53 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id h199so1477771ith.0 for ; Wed, 19 Jul 2017 07:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=k8ChG+jqeUBq2DHhPsHtb4ojkKyI9PD7CFQhjJ2tXe8=; b=cijpGGbiekQ/aQbiJJdYLFMD2htCLEVhpCgKZ1+r/6ta6erXGlK2EgkgJPi7BXYRB/ OkMsgXCy8tX5oI2wNWJhX/uTsWgb3LfArUTUBgtJJi+PvM1U5nPs6JjX73l+z8QQvSnV Tp7EIMv0LML6qLEcVblOUs5peG8hgrAkwbbzApjtXarGGWUk4M2RWLOBb95CrRpKR9F/ /UEQiQSKBkieKG2ILZ8AoAPedJtQe+vWGSL2f+8+3URGcxFiFJ+o/QHTRvpvIRWYSjFK rvxBTkjcnw4qzYVXAgP1aX+z9gClKhAFVjUY/Ah/fvMr1GhxsFG8f7GkubXZPoeaSK7b zgbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=k8ChG+jqeUBq2DHhPsHtb4ojkKyI9PD7CFQhjJ2tXe8=; b=Mt2xw/mhEEhCZRoVC+sMw24AfwrGEpCSYgv74RlxLM25wmdXPSvRS6dAeC+/JGaTKH Von6mnger98gIpEFLJMh2OLymf9YuV4T1oYUH9wJMSsPtQfIu0k0tVqrolJNIMImXJT5 EmsKQaWk55wBVLFopHsjIA/IPTYPTlu9O1yZLznSpVpJKW6ilh8s7I6UrwQzZWt/BwCR ahGXO2ZtxD4XenG82cYp6F1gz+HjN0StHnz1IMHwApkskcYRvggQdjksTNFqM96tCPUD hQaTR0Hwn+r3mZCtDaLoyCy7q6xYohhXbFjHSDr59ePH7FHZnk49IDIrX1G3JZ3RD90s Ecew== X-Gm-Message-State: AIVw113VBMwsxp2hLw8srgl0BHetwG8DaBG7GDxbGqsViS2k4YdPatIr gphuAuOu02+DfDON X-Received: by 10.36.204.131 with SMTP id x125mr95880itf.124.1500474712290; Wed, 19 Jul 2017 07:31:52 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:ddf3:d144:6291:35ab]) by smtp.gmail.com with ESMTPSA id 88sm84344ioi.5.2017.07.19.07.31.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 07:31:51 -0700 (PDT) To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> <5559A4D7-0D55-403D-A3C7-527942640A15@ericsson.com> <1243a4c8-5ce6-642e-faf3-5dda093d13df@filament.com> <5AA558F8-BD20-4871-806B-251155922C56@ericsson.com> Cc: core From: Peter Saint-Andre - Filament Message-ID: <96c526a2-aa7f-5ec3-6e5d-13562b3a8310@filament.com> Date: Wed, 19 Jul 2017 08:31:49 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5AA558F8-BD20-4871-806B-251155922C56@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 14:31:55 -0000 On 7/19/17 6:45 AM, Ari Keränen wrote: > Hi Peter, > > See inline for comments on the remaining issues not discussed in other parts of this thread. > >> On 17 Jul 2017, at 0.37, Peter Saint-Andre - Filament wrote: >> On 7/16/17 4:16 PM, Ari Keränen wrote: > [...] >>>> Some of the examples in this draft use the device URN type as >>>> specified in [I-D.arkko-core-dev-urn]. >>>> >>>> Aha. But why? That's an expired informational I-D which never >>>> actually registered the urn:dev namespace. I suggesting using >>>> urn:example URNs instead. (If there's a desire to advance >>>> draft-arkko-core-dev-urn, then let's do that - although note that >>>> registration is easier now that we've published RFC 8141, and we >>>> wouldn't need to advance the I-D in order to register the >>>> namespace. In any case, having lots of examples of an unregistered >>>> namespace seems like bad form.) >>> >>> That draft was just recently resurrected >>> (https://tools.ietf.org/html/draft-arkko-core-dev-urn-04), but >>> unfortunately only after we submitted the SenML draft. Good comments >>> for that draft. >> >> Thanks for the pointer. I'm one of the expert reviewers for URN >> namespace registrations, so I'll provide separate comments about that >> I-D soon. >> >> If that I-D will be a normative reference here or we are depending on >> registration of the urn:dev namespace before progressing SenML, then the >> WG might consider using the urn:example namespace for now. > > It's only informative reference and used only as examples. We know that sometimes implementers just look at the examples. Copy and paste - it must be right, it's in an RFC! > But I don't have strong preference either way (except that not changing things is always easier ;). My preference would be to progress with the urn:dev namespace because it seems useful and with the new registration procedure in RFC 8141 we don't even need an RFC to register the namespace, so registering it shouldn't hold up the SenML work. If that's not going to happen in a timely fashion, then using the urn:example namespace would be better than using an unregistered namespace (that sets a bad precedent and violates the spirit and letter of how URNs are defined). >>>> Please note that this set is more restricted than the range of >>>> characters allowed for URIs in general (RFC 3986) or URNs in >>>> particular (RFC 8141). At the least it would be helpful to point >>>> this out, because AFAICS it will limit the URI schemes or URN >>>> namespaces that can be used. >>> >>> Good point. I'd suggest text: >>> >>> "Note that the character set for SenML names is a subset of the >>> characters allowed in URIs. The restricted set was chosen to enable >>> efficient and safe use of names in various systems (e.g., as database >>> keys)." >> >> I suggest that we also say something like "The restrictions imply that >> care needs to be taken in the choice of URIs or URNs as SenML names." >> Furthermore, if someone wants to use a URI scheme that allows characters >> outside that set (e.g., the 'tag' scheme), then do those characters need >> to be encoded somehow? (Ick.) If not, then we should say so. > > One should not try to put "full URIs" into the names. Rather the names can be used as part of a URI. I'm confused. What I see in the draft right now is that names (whether "Name" or "Base Name + Name" = concatenated name) are URIs, with URIs from the URN scheme used as examples. Is that a misunderstanding on my part? > Perhaps something we should be more clear about. Yes, clarity would be good. > Now: https://github.com/core-wg/senml-spec/issues/73 > >>>> Section 4.6 >>>> >>>> Up to this point in the document, SenML has been defined as a >>>> format for representing sensor measurements. Given that a sensor >>>> measures something in the world, what does it mean to *set* the >>>> value of a sensor or a sensor measurement? >>> >>> I guess this needs to be elaborated also in the intro (it's hinted in >>> the abstract). >> >> That's the barest of hints. :-) I almost provided a comment about it, >> but let it go. > > Admittedly :) Do you have any proposal how to make it better? One option is to remove the configuration and actuation use cases. They seem to be an afterthought. Perhaps define them more carefully in a separate I-D that re-uses SenML, thus not holding up the core SenML work any further. If people really want to support these use cases now and in the core spec, then I can suggest improvements to the text. > [...] > >>>> Section 12.1 >>>> >>>> Units marked with an asterisk are NOT RECOMMENDED to be produced by >>>> new implementations, but are in active use and SHOULD be >>>> implemented by consumers that can use the related base units. >>>> >>>> This advice seems unrealistic and likely unnecessary. >>> >>> Why unrealistic? >> >> Because we're saying "hey you new implementations, don't do this, but >> everyone else before you does it". Developers of new implementations >> won't want to miss out on this feature (if it's important). > > You don't really gain anything implementing the "legacy way", so I don't think that's really a problem. I just don't think this advice is all that actionable or helpful, and it complicates the registry. But it's not a hill for me to die on. :-) Peter From nobody Wed Jul 19 18:20:59 2017 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 445B112ECC0; Wed, 19 Jul 2017 18:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, WEIRD_PORT=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 tYUXK2eJ1PWY; Wed, 19 Jul 2017 18:20:38 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA14129B4C; Wed, 19 Jul 2017 18:20:38 -0700 (PDT) Received: from mfilter11-d.gandi.net (mfilter11-d.gandi.net [217.70.178.131]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 1BD3D172095; Thu, 20 Jul 2017 03:20:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter11-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter11-d.gandi.net (mfilter11-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 3gdYIX_IMaSV; Thu, 20 Jul 2017 03:20:35 +0200 (CEST) X-Originating-IP: 89.176.18.156 Received: from [10.10.20.70] (ip-89-176-18-156.net.upcbroadband.cz [89.176.18.156]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id F2760172098; Thu, 20 Jul 2017 03:20:34 +0200 (CEST) From: Alexander Pelov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <3E55F10D-EE31-4C9A-B871-5EB8E1A2B583@ackl.io> Date: Thu, 20 Jul 2017 03:20:34 +0200 To: yot@ietf.org, Core , netmod@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [core] Side meeting on YOT X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 01:20:45 -0000 Dear all, This is a reminder for the YANG of THINGS Side meeting, which will take = place *TODAY* (July 20th), 10AM-12PM CEST in room room Tyrolka, = Mezzanine Level. The materials for the meeting are available online at the following = address: https://github.com/Ixau/yot/tree/master/ietf99 Remote presence will be made available thanks to Jitsi - just go to the = address through your browser: https://jitsi.tools.ietf.org/yot=20 We will also try to take notes in the Etherpad: = http://etherpad.tools.ietf.org:9000/p/yot (This is of course an = informal meeting, so don=E2=80=99t expect detailed minutes) Best, Alexander From nobody Thu Jul 20 01:33:29 2017 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 E7EE0131B6A for ; Thu, 20 Jul 2017 01:33:22 -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, RP_MATCHES_RCVD=-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 gENTEvSzwqeE for ; Thu, 20 Jul 2017 01:33:16 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88D2126B72 for ; Thu, 20 Jul 2017 01:33:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id BD3EAF78 for ; Thu, 20 Jul 2017 10:33:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id bqHYNzbgsVzP for ; Thu, 20 Jul 2017 10:33:11 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 20 Jul 2017 10:33:14 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3C19200AA for ; Thu, 20 Jul 2017 10:33:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NJDEgAK8U6dZ; Thu, 20 Jul 2017 10:33:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77D08200A8; Thu, 20 Jul 2017 10:33:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1A62B3FF6E36; Thu, 20 Jul 2017 10:33:13 +0200 (CEST) Date: Thu, 20 Jul 2017 10:33:13 +0200 From: Juergen Schoenwaelder To: core@ietf.org Message-ID: <20170720083313.GA20950@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: core@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [core] comi and NMDA (configuration and operational state datastore) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 08:33:23 -0000 Hi, are there plans to make draft-ietf-core-comi-00 support NMDA (draft-ietf-netmod-revised-datastores-03)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 20 01:42:43 2017 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 91195129B40 for ; Thu, 20 Jul 2017 01:42:41 -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, RP_MATCHES_RCVD=-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 TqsDCsB5bIGf for ; Thu, 20 Jul 2017 01:42:40 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E478126B72 for ; Thu, 20 Jul 2017 01:42:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6DFE88D for ; Thu, 20 Jul 2017 10:42:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id oTUnWK0xqaD8 for ; Thu, 20 Jul 2017 10:42:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 20 Jul 2017 10:42:36 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DB44200AA for ; Thu, 20 Jul 2017 10:42:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zUeZrEyG58IZ; Thu, 20 Jul 2017 10:42:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17FF8200A8; Thu, 20 Jul 2017 10:42:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DE9533FF6E8F; Thu, 20 Jul 2017 10:42:34 +0200 (CEST) Date: Thu, 20 Jul 2017 10:42:34 +0200 From: Juergen Schoenwaelder To: core@ietf.org Message-ID: <20170720084234.GB20950@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: core@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 08:42:41 -0000 Is it possible to define the cbor encoding in such a way that it is not required to use SID? SID may be great for environments that need it, but there are environments where it is not necessary and the complication of dealing with a distributed set of registries may be considered costly. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 20 01:50:57 2017 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 21392127735 for ; Thu, 20 Jul 2017 01:50:56 -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 azA-QJFzdw9o for ; Thu, 20 Jul 2017 01:50:55 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 C54F6126B72 for ; Thu, 20 Jul 2017 01:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6K8oq74022779; Thu, 20 Jul 2017 10:50:52 +0200 (CEST) Received: from [IPv6:2001:638:708:18::19] (unknown [IPv6:2001:638:708:18::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xCnfz6ZqHz3Z4S; Thu, 20 Jul 2017 10:50:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <20170720084234.GB20950@elstar.local> Date: Thu, 20 Jul 2017 10:50:51 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 522233450.971219-46ae4de0b772874b0f04f3b1df968e58 Content-Transfer-Encoding: quoted-printable Message-Id: <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> References: <20170720084234.GB20950@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 08:50:56 -0000 On Jul 20, 2017, at 10:42, Juergen Schoenwaelder = wrote: >=20 > Is it possible to define the cbor encoding in such a way that it is = not > required to use SID? SID may be great for environments that need it, = but > there are environments where it is not necessary and the complication = of > dealing with a distributed set of registries may be considered costly. Yang-cbor also allows the use of string identifiers (search for = =E2=80=9Cmember name=E2=80=9D). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 20 01:57:50 2017 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 D767013147E for ; Thu, 20 Jul 2017 01:57:48 -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, RP_MATCHES_RCVD=-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 nJAr7LYUim2w for ; Thu, 20 Jul 2017 01:57:47 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59549126B72 for ; Thu, 20 Jul 2017 01:57:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 264A9360; Thu, 20 Jul 2017 10:57:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id XURQBs875S8k; Thu, 20 Jul 2017 10:57:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 20 Jul 2017 10:57:44 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 06470200AD; Thu, 20 Jul 2017 10:57:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UySLnuw6_LqK; Thu, 20 Jul 2017 10:57:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4F89200AA; Thu, 20 Jul 2017 10:57:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A397E3FF6F40; Thu, 20 Jul 2017 10:57:43 +0200 (CEST) Date: Thu, 20 Jul 2017 10:57:43 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: core@ietf.org Message-ID: <20170720085743.GC20950@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , core@ietf.org References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 08:57:49 -0000 On Thu, Jul 20, 2017 at 10:50:51AM +0200, Carsten Bormann wrote: > On Jul 20, 2017, at 10:42, Juergen Schoenwaelder wrote: > > > > Is it possible to define the cbor encoding in such a way that it is not > > required to use SID? SID may be great for environments that need it, but > > there are environments where it is not necessary and the complication of > > dealing with a distributed set of registries may be considered costly. > > Yang-cbor also allows the use of string identifiers (search for “member name”). > Thanks, much appreciated. Do I understand correctly that COMI requires that the CBOR encoding uses SID? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 20 02:24:43 2017 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 92946127735 for ; Thu, 20 Jul 2017 02:24:42 -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 SzEqfJL2jRul for ; Thu, 20 Jul 2017 02:24:35 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 671AF13178D for ; Thu, 20 Jul 2017 02:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6K9ONBB021933; Thu, 20 Jul 2017 11:24:23 +0200 (CEST) Received: from [IPv6:2001:638:708:18::19] (unknown [IPv6:2001:638:708:18::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xCpPg403Bz3Z5K; Thu, 20 Jul 2017 11:24:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <20170720085743.GC20950@elstar.local> Date: Thu, 20 Jul 2017 11:24:22 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 522235462.096625-e9af4335a448429c137df9bab19cbb2d Content-Transfer-Encoding: quoted-printable Message-Id: <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 09:24:43 -0000 On Jul 20, 2017, at 10:57, Juergen Schoenwaelder = wrote: >=20 > Thanks, much appreciated. Do I understand correctly that COMI requires > that the CBOR encoding uses SID? A constrained device that wants to support both SID- and string-based = identifiers would need to store all those strings to do identifier = comparisons on incoming requests. It seems to me it is a good tradeoff = for COMI, which is meant to be able to run on constrained devices, to = focus on the use of SIDs for identifiers. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 20 02:40:52 2017 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 E14C112FB9C for ; Thu, 20 Jul 2017 02:40:50 -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, RP_MATCHES_RCVD=-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 rWBpGIUM0QYk for ; Thu, 20 Jul 2017 02:40:49 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997F112ECC3 for ; Thu, 20 Jul 2017 02:40:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id C613F69B; Thu, 20 Jul 2017 11:40:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id l2wxtbwSAssN; Thu, 20 Jul 2017 11:40:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 20 Jul 2017 11:40:47 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5B64200AA; Thu, 20 Jul 2017 11:40:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XCKThGdgtdSJ; Thu, 20 Jul 2017 11:40:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A136200A8; Thu, 20 Jul 2017 11:40:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 364693FF71BA; Thu, 20 Jul 2017 11:40:47 +0200 (CEST) Date: Thu, 20 Jul 2017 11:40:47 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: core@ietf.org Message-ID: <20170720094047.GF20950@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , core@ietf.org References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 09:40:51 -0000 On Thu, Jul 20, 2017 at 11:24:22AM +0200, Carsten Bormann wrote: > On Jul 20, 2017, at 10:57, Juergen Schoenwaelder wrote: > > > > Thanks, much appreciated. Do I understand correctly that COMI requires > > that the CBOR encoding uses SID? > > A constrained device that wants to support both SID- and string-based identifiers would need to store all those strings to do identifier comparisons on incoming requests. It seems to me it is a good tradeoff for COMI, which is meant to be able to run on constrained devices, to focus on the use of SIDs for identifiers. > OK. This limits COMI applicability to constrained devices in the sense of a few 100k of memory or devices living on rather limited links. I am interested in IoT devices that are able to run an embedded Linux inside. So I am then probably more interested in using RESTCONF with CBOR encoding since my devices are not that memory limited and I fear the pain of a global single number managed in a decentralized way will raise development pain. (So I would love to use CBOR without SID.) Well, perhaps even RESTCONF with JSON is just good enough (clearly more attractive for application writers). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 20 02:44:19 2017 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 4B30A131B09 for ; Thu, 20 Jul 2017 02:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTfQbhNX7SFu for ; Thu, 20 Jul 2017 02:44:15 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 8811F131BB0 for ; Thu, 20 Jul 2017 02:44:15 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id l81so5943572wmg.1 for ; Thu, 20 Jul 2017 02:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=yB1ddMzBhME3rFjYfiwTSFPshlEVD7Mew7dYicsiimA=; b=WqyIpaAdtf9pcPt9TIGELIXmKemrEM+uP3q7vLotdOzox0lYrzRUvqExyPhMbodB2s FGowzz0irBf0SFXx6GR7GrF34t70wDo9bUlxlv/J/tstzsbvWq16aKdhDQ2QmqZ3VI3v jrdbO5/CzUKDxbPBwcDPuqtnzgX+r9sKOEp1670EcnTfvzitqGxBzSS1sJZrdcKfjV27 z7hvGv6/YIq8hGSzZOllCdrbmuwEWS0S83VKbWxcSOB6+jWvjsWu75Li2yjry97ZKdkI cTH+fE1z/zG6UiO5JBpDDLm+XvQIbuCIp5Ghtdxrkmp3hUitnPrRqTQsEsytwiiPfz9g zEYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=yB1ddMzBhME3rFjYfiwTSFPshlEVD7Mew7dYicsiimA=; b=DNt9lTbcYJUxmB8h+LbZC4TYnCw0AYz3qqchKf2G+ZpCiK+LGJkPGvFJUkdyVrJJMC E8lH4RyZ4cFiPu0/wCUmQIn53529YV6vcAQlClgOskBzUFxjxbkngi1zls8PirkmpeCo ILCBG2oSZ+jLYhXm7L/c8I8EqW05FmKTKv8D9DQGdFbC8krl5DtQFnGU7MSuXPxGcM+n p3h6hF2rutHAq2sfJTdXh0ADL8m2hr9LH8JfLKcL2qmG429qhxqD1jYWkTpBMM0eZGrb 4SH+I4NXNP4tMCP3SBTRdyDgxfM+K8GuUP84m+CxZFUlbTiqJclEph7siU4XfekrWeO4 uEfQ== X-Gm-Message-State: AIVw111pzeJHKNvRiSXxqyrYbEZSGiRANzCH8iKiGimKKZ3NveVuuUjQ lang13nG/ZTKqMyDfY9suNZsHwCz87fn X-Received: by 10.28.32.81 with SMTP id g78mr1799181wmg.59.1500543854089; Thu, 20 Jul 2017 02:44:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Thu, 20 Jul 2017 02:44:13 -0700 (PDT) In-Reply-To: <20170720083313.GA20950@elstar.local> References: <20170720083313.GA20950@elstar.local> From: Andy Bierman Date: Thu, 20 Jul 2017 02:44:13 -0700 Message-ID: To: Juergen Schoenwaelder , Core Content-Type: multipart/alternative; boundary="001a113c89de64b1230554bc97e2" Archived-At: Subject: Re: [core] comi and NMDA (configuration and operational state datastore) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 09:44:17 -0000 --001a113c89de64b1230554bc97e2 Content-Type: text/plain; charset="UTF-8" Hi, I doubt this will be a primary feature of CoMI. It is similar to RESTCONF, attempting to hide datastores from the client. It also allows access to any RPC (just like RESTCONF operation resources) so protocol operations that support NMDA can be supported. Andy On Thu, Jul 20, 2017 at 1:33 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > are there plans to make draft-ietf-core-comi-00 support NMDA > (draft-ietf-netmod-revised-datastores-03)? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a113c89de64b1230554bc97e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I doubt this will be a primary feat= ure of CoMI.
It is similar to RESTCONF, attempting to hide datast= ores from the client.
It also allows access to any RPC (just like= RESTCONF operation resources)
so protocol operations that suppor= t NMDA can be supported.


Andy
=


On Thu, Jul 20, 2017 at 1:33 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

are there plans to make draft-ietf-core-comi-00 support NMDA
(draft-ietf-netmod-revised-datastores-03)?

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a113c89de64b1230554bc97e2-- From nobody Thu Jul 20 02:47:22 2017 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 80774131A81 for ; Thu, 20 Jul 2017 02:47:21 -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, RP_MATCHES_RCVD=-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 Vz-t4DWaqgR2 for ; Thu, 20 Jul 2017 02:47:20 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A02A12ECCB for ; Thu, 20 Jul 2017 02:47:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2BA248D; Thu, 20 Jul 2017 11:47:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id YrzgtovW2jhm; Thu, 20 Jul 2017 11:47:15 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 20 Jul 2017 11:47:19 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 07BFB200AA; Thu, 20 Jul 2017 11:47:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1Tvwc5ZO2fOk; Thu, 20 Jul 2017 11:47:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9557200A8; Thu, 20 Jul 2017 11:47:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 93A273FF72D7; Thu, 20 Jul 2017 11:47:18 +0200 (CEST) Date: Thu, 20 Jul 2017 11:47:18 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Core Message-ID: <20170720094718.GG20950@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Core References: <20170720083313.GA20950@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [core] comi and NMDA (configuration and operational state datastore) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 09:47:21 -0000 Hi, well, I am trying to understand what the scope of CoMI is. If CoMI is only for ~100k memory devices, you may be right. /js On Thu, Jul 20, 2017 at 02:44:13AM -0700, Andy Bierman wrote: > Hi, > > I doubt this will be a primary feature of CoMI. > It is similar to RESTCONF, attempting to hide datastores from the client. > It also allows access to any RPC (just like RESTCONF operation resources) > so protocol operations that support NMDA can be supported. > > > Andy > > > On Thu, Jul 20, 2017 at 1:33 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > Hi, > > > > are there plans to make draft-ietf-core-comi-00 support NMDA > > (draft-ietf-netmod-revised-datastores-03)? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > core mailing list > > core@ietf.org > > https://www.ietf.org/mailman/listinfo/core > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 20 15:36:47 2017 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 DBA72126B7F for ; Thu, 20 Jul 2017 15:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 XGiX7T1NrdIA for ; Thu, 20 Jul 2017 15:36:43 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.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 0B24F129482 for ; Thu, 20 Jul 2017 15:36:42 -0700 (PDT) X-AuditID: c1b4fb30-aeec49c000001664-48-597130789fec Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1A.B6.05732.87031795; Fri, 21 Jul 2017 00:36:41 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Fri, 21 Jul 2017 00:36:40 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Peter Saint-Andre - Filament CC: core Thread-Topic: =?utf-8?B?W2NvcmVdIPCflJQgV0dMQyBvbiBkcmFmdC1pZXRmLWNvcmUtY29hcC1zZW5t?= =?utf-8?Q?l?= Thread-Index: AQHS/oQaqDg1pfroaU+/t65FgWCHvaJa+00AgAAdpoCAAhnLgA== Date: Thu, 20 Jul 2017 22:36:39 +0000 Message-ID: References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> <5559A4D7-0D55-403D-A3C7-527942640A15@ericsson.com> <1243a4c8-5ce6-642e-faf3-5dda093d13df@filament.com> <5AA558F8-BD20-4871-806B-251155922C56@ericsson.com> <96c526a2-aa7f-5ec3-6e5d-13562b3a8310@filament.com> In-Reply-To: <96c526a2-aa7f-5ec3-6e5d-13562b3a8310@filament.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <37B80F57B1103444A34A169322D91933@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbFdRbfSoDDSoKuXxWLf2/XMFrPPBDsw eVzaNJvdY8mSn0wBTFFcNimpOZllqUX6dglcGRuWrGEr2ORccaattIHximMXIyeHhICJxKpz p9m6GLk4hASOMEosW7qKCcJZzCix9tsXNpAqNgFbiSet+1hBbBEBU4lfk/qZQWxmAQmJsysP g8WFBVIlFm3oZoaoSZOY9OcvkM0BZDtJXPntDmKyCKhKbH/gAFLBK2AvceTmKahVZ5kkLr++ ANbKKeAgceT2E7CRjAJiEt9PrWGCWCUucevJfCaIowUkluw5zwxhi0q8fPyPFcJWklh7eDsL yC5mAU2J9bv0IUxriSMnwyGmKEpM6X7IDnGCoMTJmU9YJjCKzUKyYBZC8yyE5llImmchaV7A yLqKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzCWDm75bbCD8eVzx0OMAhyMSjy8tzYXRAqx JpYVV+YeYpTgYFYS4Z0gXRgpxJuSWFmVWpQfX1Sak1p8iFGag0VJnNdx34UIIYH0xJLU7NTU gtQimCwTB6dUA6OVmPiTo3HMB0uS2z+9cj1xeM39hI2JhVYt34VnFdhWHwuYlTIxeP2SzepO +z1LXsZwSXw4tdjWxDp+cfAD59nhXt/j93xdxCq3823vpS3yn76d2bvA4mDdV5P5K5MU/7wN um658f7pkqtBvfZ6hpOm/JNxcwwTTfs5Pb9qWfw7b6bUAk4L3dVKLMUZiYZazEXFiQDcpTAE oQIAAA== Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 22:36:46 -0000 DQo+IE9uIDE5IEp1bCAyMDE3LCBhdCAxNi4zMSwgUGV0ZXIgU2FpbnQtQW5kcmUgLSBGaWxhbWVu dCA8cGV0ZXJAZmlsYW1lbnQuY29tPiB3cm90ZToNCj4gDQo+IE9uIDcvMTkvMTcgNjo0NSBBTSwg QXJpIEtlcsOkbmVuIHdyb3RlOg0KPj4gSGkgUGV0ZXIsDQo+PiANCj4+IFNlZSBpbmxpbmUgZm9y IGNvbW1lbnRzIG9uIHRoZSByZW1haW5pbmcgaXNzdWVzIG5vdCBkaXNjdXNzZWQgaW4gb3RoZXIg cGFydHMgb2YgdGhpcyB0aHJlYWQuDQo+PiANCj4+PiBPbiAxNyBKdWwgMjAxNywgYXQgMC4zNywg UGV0ZXIgU2FpbnQtQW5kcmUgLSBGaWxhbWVudCA8cGV0ZXJAZmlsYW1lbnQuY29tPiB3cm90ZToN Cj4+PiBPbiA3LzE2LzE3IDQ6MTYgUE0sIEFyaSBLZXLDpG5lbiB3cm90ZToNCj4+IFsuLi5dDQo+ Pj4+PiBTb21lIG9mIHRoZSBleGFtcGxlcyBpbiB0aGlzIGRyYWZ0IHVzZSB0aGUgZGV2aWNlIFVS TiB0eXBlIGFzDQo+Pj4+PiBzcGVjaWZpZWQgaW4gW0ktRC5hcmtrby1jb3JlLWRldi11cm5dLg0K Pj4+Pj4gDQo+Pj4+PiBBaGEuIEJ1dCB3aHk/IFRoYXQncyBhbiBleHBpcmVkIGluZm9ybWF0aW9u YWwgSS1EIHdoaWNoIG5ldmVyDQo+Pj4+PiBhY3R1YWxseSByZWdpc3RlcmVkIHRoZSB1cm46ZGV2 IG5hbWVzcGFjZS4gSSBzdWdnZXN0aW5nIHVzaW5nDQo+Pj4+PiB1cm46ZXhhbXBsZSBVUk5zIGlu c3RlYWQuIChJZiB0aGVyZSdzIGEgZGVzaXJlIHRvIGFkdmFuY2UNCj4+Pj4+IGRyYWZ0LWFya2tv LWNvcmUtZGV2LXVybiwgdGhlbiBsZXQncyBkbyB0aGF0IC0gYWx0aG91Z2ggbm90ZSB0aGF0DQo+ Pj4+PiByZWdpc3RyYXRpb24gaXMgZWFzaWVyIG5vdyB0aGF0IHdlJ3ZlIHB1Ymxpc2hlZCBSRkMg ODE0MSwgYW5kIHdlDQo+Pj4+PiB3b3VsZG4ndCBuZWVkIHRvIGFkdmFuY2UgdGhlIEktRCBpbiBv cmRlciB0byByZWdpc3RlciB0aGUNCj4+Pj4+IG5hbWVzcGFjZS4gSW4gYW55IGNhc2UsIGhhdmlu ZyBsb3RzIG9mIGV4YW1wbGVzIG9mIGFuIHVucmVnaXN0ZXJlZA0KPj4+Pj4gbmFtZXNwYWNlIHNl ZW1zIGxpa2UgYmFkIGZvcm0uKQ0KPj4+PiANCj4+Pj4gVGhhdCBkcmFmdCB3YXMganVzdCByZWNl bnRseSByZXN1cnJlY3RlZA0KPj4+PiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWFya2tvLWNvcmUtZGV2LXVybi0wNCksIGJ1dA0KPj4+PiB1bmZvcnR1bmF0ZWx5IG9ubHkgYWZ0 ZXIgd2Ugc3VibWl0dGVkIHRoZSBTZW5NTCBkcmFmdC4gR29vZCBjb21tZW50cw0KPj4+PiBmb3Ig dGhhdCBkcmFmdC4NCj4+PiANCj4+PiBUaGFua3MgZm9yIHRoZSBwb2ludGVyLiBJJ20gb25lIG9m IHRoZSBleHBlcnQgcmV2aWV3ZXJzIGZvciBVUk4NCj4+PiBuYW1lc3BhY2UgcmVnaXN0cmF0aW9u cywgc28gSSdsbCBwcm92aWRlIHNlcGFyYXRlIGNvbW1lbnRzIGFib3V0IHRoYXQNCj4+PiBJLUQg c29vbi4NCj4+PiANCj4+PiBJZiB0aGF0IEktRCB3aWxsIGJlIGEgbm9ybWF0aXZlIHJlZmVyZW5j ZSBoZXJlIG9yIHdlIGFyZSBkZXBlbmRpbmcgb24NCj4+PiByZWdpc3RyYXRpb24gb2YgdGhlIHVy bjpkZXYgbmFtZXNwYWNlIGJlZm9yZSBwcm9ncmVzc2luZyBTZW5NTCwgdGhlbiB0aGUNCj4+PiBX RyBtaWdodCBjb25zaWRlciB1c2luZyB0aGUgdXJuOmV4YW1wbGUgbmFtZXNwYWNlIGZvciBub3cu DQo+PiANCj4+IEl0J3Mgb25seSBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgYW5kIHVzZWQgb25seSBh cyBleGFtcGxlcy4NCj4gDQo+IFdlIGtub3cgdGhhdCBzb21ldGltZXMgaW1wbGVtZW50ZXJzIGp1 c3QgbG9vayBhdCB0aGUgZXhhbXBsZXMuIENvcHkgYW5kDQo+IHBhc3RlIC0gaXQgbXVzdCBiZSBy aWdodCwgaXQncyBpbiBhbiBSRkMhDQo+IA0KPj4gQnV0IEkgZG9uJ3QgaGF2ZSBzdHJvbmcgcHJl ZmVyZW5jZSBlaXRoZXIgd2F5IChleGNlcHQgdGhhdCBub3QgY2hhbmdpbmcgdGhpbmdzIGlzIGFs d2F5cyBlYXNpZXIgOykuDQo+IA0KPiBNeSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIHByb2dyZXNz IHdpdGggdGhlIHVybjpkZXYgbmFtZXNwYWNlIGJlY2F1c2UgaXQNCj4gc2VlbXMgdXNlZnVsIGFu ZCB3aXRoIHRoZSBuZXcgcmVnaXN0cmF0aW9uIHByb2NlZHVyZSBpbiBSRkMgODE0MSB3ZQ0KPiBk b24ndCBldmVuIG5lZWQgYW4gUkZDIHRvIHJlZ2lzdGVyIHRoZSBuYW1lc3BhY2UsIHNvIHJlZ2lz dGVyaW5nIGl0DQo+IHNob3VsZG4ndCBob2xkIHVwIHRoZSBTZW5NTCB3b3JrLg0KPiANCj4gSWYg dGhhdCdzIG5vdCBnb2luZyB0byBoYXBwZW4gaW4gYSB0aW1lbHkgZmFzaGlvbiwgdGhlbiB1c2lu ZyB0aGUNCj4gdXJuOmV4YW1wbGUgbmFtZXNwYWNlIHdvdWxkIGJlIGJldHRlciB0aGFuIHVzaW5n IGFuIHVucmVnaXN0ZXJlZA0KPiBuYW1lc3BhY2UgKHRoYXQgc2V0cyBhIGJhZCBwcmVjZWRlbnQg YW5kIHZpb2xhdGVzIHRoZSBzcGlyaXQgYW5kIGxldHRlcg0KPiBvZiBob3cgVVJOcyBhcmUgZGVm aW5lZCkuDQoNCk9LLiBUaGUgdXJuOmRldiBpcyBub3cgcHJvZ3Jlc3NpbmcgaW4gQ29SRSBzbyBJ IGd1ZXNzIHdlIGNhbiBkbyB0aGUgYWxsb2NhdGlvbiBmb3IgdGhhdCBhbmQgbW92ZSBmb3J3YXJk IHdpdGggaXQuDQoNCj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBzZXQgaXMgbW9yZSByZXN0 cmljdGVkIHRoYW4gdGhlIHJhbmdlIG9mIA0KPj4+Pj4gY2hhcmFjdGVycyBhbGxvd2VkIGZvciBV UklzIGluIGdlbmVyYWwgKFJGQyAzOTg2KSBvciBVUk5zIGluDQo+Pj4+PiBwYXJ0aWN1bGFyIChS RkMgODE0MSkuIEF0IHRoZSBsZWFzdCBpdCB3b3VsZCBiZSBoZWxwZnVsIHRvIHBvaW50DQo+Pj4+ PiB0aGlzIG91dCwgYmVjYXVzZSBBRkFJQ1MgaXQgd2lsbCBsaW1pdCB0aGUgVVJJIHNjaGVtZXMg b3IgVVJODQo+Pj4+PiBuYW1lc3BhY2VzIHRoYXQgY2FuIGJlIHVzZWQuDQo+Pj4+IA0KPj4+PiBH b29kIHBvaW50LiBJJ2Qgc3VnZ2VzdCB0ZXh0Og0KPj4+PiANCj4+Pj4gIk5vdGUgdGhhdCB0aGUg Y2hhcmFjdGVyIHNldCBmb3IgU2VuTUwgbmFtZXMgaXMgYSBzdWJzZXQgb2YgdGhlDQo+Pj4+IGNo YXJhY3RlcnMgYWxsb3dlZCBpbiBVUklzLiBUaGUgcmVzdHJpY3RlZCBzZXQgd2FzIGNob3NlbiB0 byBlbmFibGUNCj4+Pj4gZWZmaWNpZW50IGFuZCBzYWZlIHVzZSBvZiBuYW1lcyBpbiB2YXJpb3Vz IHN5c3RlbXMgKGUuZy4sIGFzIGRhdGFiYXNlDQo+Pj4+IGtleXMpLiINCj4+PiANCj4+PiBJIHN1 Z2dlc3QgdGhhdCB3ZSBhbHNvIHNheSBzb21ldGhpbmcgbGlrZSAiVGhlIHJlc3RyaWN0aW9ucyBp bXBseSB0aGF0DQo+Pj4gY2FyZSBuZWVkcyB0byBiZSB0YWtlbiBpbiB0aGUgY2hvaWNlIG9mIFVS SXMgb3IgVVJOcyBhcyBTZW5NTCBuYW1lcy4iDQo+Pj4gRnVydGhlcm1vcmUsIGlmIHNvbWVvbmUg d2FudHMgdG8gdXNlIGEgVVJJIHNjaGVtZSB0aGF0IGFsbG93cyBjaGFyYWN0ZXJzDQo+Pj4gb3V0 c2lkZSB0aGF0IHNldCAoZS5nLiwgdGhlICd0YWcnIHNjaGVtZSksIHRoZW4gZG8gdGhvc2UgY2hh cmFjdGVycyBuZWVkDQo+Pj4gdG8gYmUgZW5jb2RlZCBzb21laG93PyAoSWNrLikgSWYgbm90LCB0 aGVuIHdlIHNob3VsZCBzYXkgc28uDQo+PiANCj4+IE9uZSBzaG91bGQgbm90IHRyeSB0byBwdXQg ImZ1bGwgVVJJcyIgaW50byB0aGUgbmFtZXMuIFJhdGhlciB0aGUgbmFtZXMgY2FuIGJlIHVzZWQg YXMgcGFydCBvZiBhIFVSSS4gDQo+IA0KPiBJJ20gY29uZnVzZWQuIFdoYXQgSSBzZWUgaW4gdGhl IGRyYWZ0IHJpZ2h0IG5vdyBpcyB0aGF0IG5hbWVzICh3aGV0aGVyDQo+ICJOYW1lIiBvciAiQmFz ZSBOYW1lICsgTmFtZSIgPSBjb25jYXRlbmF0ZWQgbmFtZSkgYXJlIFVSSXMsIHdpdGggVVJJcw0K PiBmcm9tIHRoZSBVUk4gc2NoZW1lIHVzZWQgYXMgZXhhbXBsZXMuIElzIHRoYXQgYSBtaXN1bmRl cnN0YW5kaW5nIG9uIG15IHBhcnQ/DQoNClVSSXMgdGhhdCBjb25mb3JtIHRvIHRoZSByZXN0cmlj dGVkIGNoYXJhY3RlciBzZXQgKCJBIiB0byAiWiIsICJhIiB0byAieiIsICIwIiB0byAiOSIsICIt IiwgIjoiLCAiLiIsICIvIiwgIl8iKSwgc3VjaCBhcyB1cm46ZGV2LCBhcmUgT0suIEZvciBleGFt cGxlIFVSTCB3aXRoIGJyYWNrZXRzIHdvdWxkIG5vdCBiZSBPSyAoc2VlIHNlY3Rpb24gNS4xLjYg Zm9yIGV4YW1wbGUgd2l0aCBJUHY2IGFkZHJlc3MpLiANCg0KPj4gUGVyaGFwcyBzb21ldGhpbmcg d2Ugc2hvdWxkIGJlIG1vcmUgY2xlYXIgYWJvdXQuDQo+IA0KPiBZZXMsIGNsYXJpdHkgd291bGQg YmUgZ29vZC4NCg0KV2lsbCBhZGQgY2xhcmlmaWNhdGlvbiBhYm91dCB0aGUgVVJJcy4NCg0KPj4g Tm93OiBodHRwczovL2dpdGh1Yi5jb20vY29yZS13Zy9zZW5tbC1zcGVjL2lzc3Vlcy83Mw0KPj4g DQo+Pj4+PiBTZWN0aW9uIDQuNg0KPj4+Pj4gDQo+Pj4+PiBVcCB0byB0aGlzIHBvaW50IGluIHRo ZSBkb2N1bWVudCwgU2VuTUwgaGFzIGJlZW4gZGVmaW5lZCBhcyBhDQo+Pj4+PiBmb3JtYXQgZm9y IHJlcHJlc2VudGluZyBzZW5zb3IgbWVhc3VyZW1lbnRzLiBHaXZlbiB0aGF0IGEgc2Vuc29yDQo+ Pj4+PiBtZWFzdXJlcyBzb21ldGhpbmcgaW4gdGhlIHdvcmxkLCB3aGF0IGRvZXMgaXQgbWVhbiB0 byAqc2V0KiB0aGUNCj4+Pj4+IHZhbHVlIG9mIGEgc2Vuc29yIG9yIGEgc2Vuc29yIG1lYXN1cmVt ZW50Pw0KPj4+PiANCj4+Pj4gSSBndWVzcyB0aGlzIG5lZWRzIHRvIGJlIGVsYWJvcmF0ZWQgYWxz byBpbiB0aGUgaW50cm8gKGl0J3MgaGludGVkIGluDQo+Pj4+IHRoZSBhYnN0cmFjdCkuDQo+Pj4g DQo+Pj4gVGhhdCdzIHRoZSBiYXJlc3Qgb2YgaGludHMuIDotKSBJIGFsbW9zdCBwcm92aWRlZCBh IGNvbW1lbnQgYWJvdXQgaXQsDQo+Pj4gYnV0IGxldCBpdCBnby4NCj4+IA0KPj4gQWRtaXR0ZWRs eSA6KSBEbyB5b3UgaGF2ZSBhbnkgcHJvcG9zYWwgaG93IHRvIG1ha2UgaXQgYmV0dGVyPw0KPiAN Cj4gT25lIG9wdGlvbiBpcyB0byByZW1vdmUgdGhlIGNvbmZpZ3VyYXRpb24gYW5kIGFjdHVhdGlv biB1c2UgY2FzZXMuIFRoZXkNCj4gc2VlbSB0byBiZSBhbiBhZnRlcnRob3VnaHQuIFBlcmhhcHMg ZGVmaW5lIHRoZW0gbW9yZSBjYXJlZnVsbHkgaW4gYQ0KPiBzZXBhcmF0ZSBJLUQgdGhhdCByZS11 c2VzIFNlbk1MLCB0aHVzIG5vdCBob2xkaW5nIHVwIHRoZSBjb3JlIFNlbk1MIHdvcmsNCj4gYW55 IGZ1cnRoZXIuDQo+IA0KPiBJZiBwZW9wbGUgcmVhbGx5IHdhbnQgdG8gc3VwcG9ydCB0aGVzZSB1 c2UgY2FzZXMgbm93IGFuZCBpbiB0aGUgY29yZQ0KPiBzcGVjLCB0aGVuIEkgY2FuIHN1Z2dlc3Qg aW1wcm92ZW1lbnRzIHRvIHRoZSB0ZXh0Lg0KDQpUaGVyZSBpcyBhbHJlYWR5IHVzZSBmb3IgdGhl c2Ugc28gSSB0aGluayB3ZSBzaG91bGQgaW5jbHVkZSB0aGUgZnVuY3Rpb25hbGl0eSBpbiB0aGUg YmFzZSBzcGVjLg0KDQo+PiBbLi4uXQ0KPj4gDQo+Pj4+PiBTZWN0aW9uIDEyLjENCj4+Pj4+IA0K Pj4+Pj4gVW5pdHMgbWFya2VkIHdpdGggYW4gYXN0ZXJpc2sgYXJlIE5PVCBSRUNPTU1FTkRFRCB0 byBiZSBwcm9kdWNlZCBieQ0KPj4+Pj4gbmV3IGltcGxlbWVudGF0aW9ucywgYnV0IGFyZSBpbiBh Y3RpdmUgdXNlIGFuZCBTSE9VTEQgYmUNCj4+Pj4+IGltcGxlbWVudGVkIGJ5IGNvbnN1bWVycyB0 aGF0IGNhbiB1c2UgdGhlIHJlbGF0ZWQgYmFzZSB1bml0cy4NCj4+Pj4+IA0KPj4+Pj4gVGhpcyBh ZHZpY2Ugc2VlbXMgdW5yZWFsaXN0aWMgYW5kIGxpa2VseSB1bm5lY2Vzc2FyeS4NCj4+Pj4gDQo+ Pj4+IFdoeSB1bnJlYWxpc3RpYz8NCj4+PiANCj4+PiBCZWNhdXNlIHdlJ3JlIHNheWluZyAiaGV5 IHlvdSBuZXcgaW1wbGVtZW50YXRpb25zLCBkb24ndCBkbyB0aGlzLCBidXQNCj4+PiBldmVyeW9u ZSBlbHNlIGJlZm9yZSB5b3UgZG9lcyBpdCIuIERldmVsb3BlcnMgb2YgbmV3IGltcGxlbWVudGF0 aW9ucw0KPj4+IHdvbid0IHdhbnQgdG8gbWlzcyBvdXQgb24gdGhpcyBmZWF0dXJlIChpZiBpdCdz IGltcG9ydGFudCkuDQo+PiANCj4+IFlvdSBkb24ndCByZWFsbHkgZ2FpbiBhbnl0aGluZyBpbXBs ZW1lbnRpbmcgdGhlICJsZWdhY3kgd2F5Iiwgc28gSSBkb24ndCB0aGluayB0aGF0J3MgcmVhbGx5 IGEgcHJvYmxlbS4gDQo+IA0KPiBJIGp1c3QgZG9uJ3QgdGhpbmsgdGhpcyBhZHZpY2UgaXMgYWxs IHRoYXQgYWN0aW9uYWJsZSBvciBoZWxwZnVsLCBhbmQgaXQNCj4gY29tcGxpY2F0ZXMgdGhlIHJl Z2lzdHJ5LiBCdXQgaXQncyBub3QgYSBoaWxsIGZvciBtZSB0byBkaWUgb24uIDotKQ0KDQpPSy4g SWYgYW55b25lIGVsc2UgZmVlbHMgbW9yZSBzdHJvbmdseSBhYm91dCB0aGlzLCBwbGVhc2UgbGV0 IHVzIGtub3cgOikNCg0KDQpDaGVlcnMsDQpBcmkNCg0K From nobody Thu Jul 20 16:07:47 2017 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 4DED412EB43 for ; Thu, 20 Jul 2017 16:07:45 -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, HTML_MESSAGE=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=smartthings-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 2_R1ZX8rmkbo for ; Thu, 20 Jul 2017 16:07:42 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 0B43312F28E for ; Thu, 20 Jul 2017 16:07:41 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id v76so91337wmv.1 for ; Thu, 20 Jul 2017 16:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UQWZEpQ5Jnf7vDKqhVLkQ2b6sgOL21oEUvoednRbeaA=; b=kEOePYVyqKfL8nyzxWnP6c0joQpTucQidl/5QEBE3PrwYr6IkhEaMqizTOVr0uwAtO aM8NnxLpYz+Im7hcmbK9kiH2fUx6TeLUPKlePXpV8RMn54V3AtSfrR7OSBfSx2Xq3XwN Mka6bbceDf/NkPBHM+mIR7IoX7LE73973q8L9DQCuRAotPLHJqbFHGTJCUa6JO5irtHp hf+QOPZqoVlmIHGf2i0I3JsF0fqe0uLEmnyGWtjMy6FK9rpQ1IpYQ8lnFa4jsV5OyNlt zVYq/JBL8TkaHlh88n95oe3UYrLiMvFPe7e2EpySMFZhW5gvb7TyZ7hOiyprejAI3Cdy loMA== 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=UQWZEpQ5Jnf7vDKqhVLkQ2b6sgOL21oEUvoednRbeaA=; b=TfI7K++OqHcb59lsG+Tf3So8ntbxN2vP+2r7iwFLy5DVB8IuxnHk4sc732fphHkhXu +jSAkCsX8p1KYZe4d6OiigM3hQyxWraXDMOjX2qX6tGH7T9o0fpAFGKurcCqDWUrJUlW vxGPBmMgTH7aT1f/JUCjm6d80Jjfi+pc3jEreRw5YMt9fD5gimSCWBUuY+R2TwJYDH6k cz0wq+wwAkks1nFZxgGRqJUCkLAOXyu75riHVzrbucFX7IuBkL8S12POvVBnCGNYiAxf ON1FOvowroWs4x0jw69qsDk+oTfX0wDb6U2h0ypmsI7d1MoK04Ke/0WDht9ZV6EXcTzT Inkw== X-Gm-Message-State: AIVw111fr1yfKCqwAh8VbdbOiEuEcKiEKaEleYXlGf0yK5kEnKFlzmme 1L10LFmfa6s5lrMU X-Received: by 10.28.136.147 with SMTP id k141mr3352037wmd.131.1500592060198; Thu, 20 Jul 2017 16:07:40 -0700 (PDT) Received: from dhcp-9839.meeting.ietf.org (dhcp-9839.meeting.ietf.org. [31.133.152.57]) by smtp.gmail.com with ESMTPSA id b25sm4828559wrb.79.2017.07.20.16.07.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 16:07:39 -0700 (PDT) From: Michael Koster Message-Id: <6443250C-79E7-4AF4-AFF3-FFF609FDF2EB@smartthings.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6222E79A-9A7F-46DB-B924-4DB129ADA954" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 20 Jul 2017 16:07:38 -0700 In-Reply-To: <03c301d2f9ae$51878f70$f496ae50$@augustcellars.com> Cc: draft-ietf-core-coap-pubsub@ietf.org, core@ietf.org To: Jim Schaad References: <03c301d2f9ae$51878f70$f496ae50$@augustcellars.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] Review on draft-ietf-core-coap-pubsub-02 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 23:07:45 -0000 --Apple-Mail=_6222E79A-9A7F-46DB-B924-4DB129ADA954 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jim, Thank you for taking the time to evaluate this draft. We have discussed = each point and have included the discussion and resolution inline in = this response. > On Jul 10, 2017, at 11:57 AM, Jim Schaad = wrote: >=20 > Status: This document is not yet ready for a WGLC in my opinion.=20 >=20 > I have copied forward some comments from past reviews where I have not = seem > them addressed or do not believe that they are sufficiently dealt = with. >=20 >=20 >=20 > * Section 3.4 - s/are hosted at the broker and all clients using the = broker > share/are hosted by a broker and all clients using that broker share/ = - a) > you can have multiple brokers and b) the name spaces in that case are = going > to be distinct and potentially overlapping in name w/different values. Yes, updated >=20 > * Section 3.4 - "zero or more stored representations with a = content-format" > I think this is supposed to be "zero or more values - one = content-format". > But the first time I read this, I read this as" zero or more = representations > - each representation has a content format - may be zero or one (?) = value". > I always worry about what is "current" not what is "history" and = assume that > observe is correctly implemented. Note this does go back to the = question of > "is this a queue of values" that Hannes has raised in the past. >=20 We think stored representations is correct, as a broker only stores = representations and is not aware of values. We are restricting it to most recently published representation, and = should take care that this is clear. For queueing and reliable notification, we consider a future extension = based on subscriber-managed queues.=20 See github issues:=20 https://github.com/core-wg/pubsub/issues/5 = > * Section 4.2 - cut and paste error for topic and q as template = variables. > I believe that q should be removed from the template as it makes no = sense. >=20 Yes, corrected. > * Section 4.2 - Is the following legal for payload of a create > ";ct=3D50" - this is a legal link but may not be = legal > for creation of a topic. =20 >=20 Yes, we will clarify what is and is not legal for create. Probably only = one topic tree level at a time. > * Section 4.2 - Is the following legal for the payload of a create > ";ct=3D50" - The text current = says the > target of the link is a "URI formatted string" rather than a fragment. >=20 Same as above.WIll clarify in the next update. > * Section 4.2 - I cannot tell if the requirement for returning 4.04 = (not > found) is new in this document or should be part of RFC 6690 or not. = I > cannot seem to find this requirement in that document. Are you sure = you > want to do this rather than just return an empty content? Should = there be > an errata on RFC 6690? >=20 RFC6690 should not specify how REST APIs are expected to expose links. = It should focus on the format and just provide examples. 4.04 is = returned when the topic has been removed. Subscribe to non-existant = topics may be covered in the subscriber queue extension described above. > * Section 4.2 - There is an implicit statement in section 4.3 that a = single > content type is expected. However, there is no explicit statement = here that > a request with multiple content types is forbidden. Is there really a > requirement that a single content type be required when creating a = topic? > What happens if no 'ct' is specified? >=20 Candidate text: A topic creator includes one or more content format option values in the = create payload. If the broker does not support all of the indicated = formats for both publish and subscribe, it (SHALL) returns an error = response. If a broker allows a topic to be created with more than one = content-format, it SHALL support an arbitrary mix of the supported = content formats in publish and subscribe operations. There is no default content format. If no ct is specified, the broker = SHALL reject the operation with an error code 4.15 "unsupported content = format"=20 > * Section 4.3 - Is a server supposed to accept a publish operation to = a > non-existent location with a POST method?=20 >=20 Create-on-publish must use PUT. The link is constructed from the request = parameters. WIll clarify in the next update. > * Section 4.3 - Is there any reason to accept publish via POST and not = PUT? > Or the other way around? >=20 PUT is required for create-on-publish POST is prefereble when the topic already exists, but PUT may be used = also.=20 Generically, PUT is defined as replace the stored representation with = the supplied representation, may create if the server supports (i.e. a = PUT to a non-existent location may return 2.01 Created or 4.04 Not = Found) > * Section 4.3 - If no Max-Age is on the publish request, should the = default > value be used or should an infinite value (i.e. absent) be used. If a > Max-Age was supplied at the time the subject was created, does that = change > things? If a publish is done with a Max-Age greater than that = provided at > creation, what should happen. Which wins? >=20 More explanatory text is perhaps needed. There are two Max-Age contexts, = one is for the topic and one is for the value. If no Max-Age is supplied, the topic should be permanent, modulo the = server's abiity to store topics. Max-Age on publish should default to permenent also. > * Section 4.3 - Copy and paste error on the topic and q template = variables. > Does 'q' even make sense here? >=20 > * Section 4.3 - Text dealing with propagating publish events up the = tree to > keep nodes alive is missing. >=20 Yes, this is the intended behavior and will be described in the next = update. > * Section 4.4 - Copy and paste error on the topic and q template = variables. > Does 'q' even make sense here? >=20 Yes, corrected in the next update. > * Section 4.4 - Is it permitted that a broker remove a subscription = due to > lack of ACK for a CON w/o sending the "unsubscribed" message? The = document > does not seem to allow that. >=20 If a broker removes a topic, it is allowed to do so without informing = the subscribers. We use a SHOULD statement to indicate that.=20 If a client fails to ACK an observe response when the broker uses CON, = the broker should not try to send a final message. We will clarify this. = RFC7641 section 3.5 doesn't seem to explain this either: An acknowledgement message signals to the server that the client is alive and interested in receiving further notifications; if the server does not receive an acknowledgement in reply to a confirmable notification, it will assume that the client is no longer interested and will eventually remove the associated entry from the list of observers (Section 4.5 = ). > * Section 4.5 - Copy and paste error on the topic and q template = variables. > Does 'q' even make sense here? >=20 Yes, will correct in the next update. > * Section 4.6 - Copy and paste error on the topic and q template = variables. > Does 'q' even make sense here? >=20 Yes. Will correct. > * Section 4.7 - Is remove recursive? =20 >=20 Remove is inclusive of sub-topics, or recursive from the bottom of the = tree. WIll add text to clarify. > * Section 4.7 - What would the correct content be to send an = unsubscribe > notification on a remove operation? '2.07 no content' or '2.02' = deleted or > '4.04' not found? >=20 2.02 Deleted would be the response to the Deleteing client, 4.04 woud be = sent to observing clients, as per standard CoAP Observe. Will make sure = this is clear in the next update. > * Section 8 - If enforcing access policies is of importance, how are = they > set? >=20 The reference is toward an ACL type system that may be out of the scope = of this draft. More could be said about what to do and how to do it. = Will address this after some more discussion. > * Section 8 - It may be that '4.01 Unauthorized' is a better response = than > '4.04 Not Found' in some cases. Doing this does not allow for probing = of > what topics exist when one does not have access to the directory of = topics. >=20 Good point. This may be added to security considerations after = discussion. It would be better to have explicit ACLs that deny access to = the resources and requre returning 4.01 in these cases. >=20 > * Consider the following scenario > - Create node foo - ct=3D40, Max-Age=3D10 > - Create node foo/bar - ct=3D0, Max-Age=3D20 > - Publish to foo/bar @ time=3D5 > When you get to time=3D15, should the node foo be deleted or does the > max-age of foo/bar change that answer? >=20 foo expires and inclusively removes foo/bar at t=3D15 > * Currently an application can use CON to ensure that a server will = get a > message in the long run. The fact that this is no doable here should = be > briefly discussed as an client cannot know that a server has or has = not > received a message. >=20 Yes, end-to-end protocol does not exist in pubsub. We have stayed away = from describing transfer layer operations in this draft, but it seems = like a good idea to point out the considerations in an informative way = here as in the issue above about observe termination.=20 >=20 > Minor: >=20 > * Section 3.4 - s$"EP-33543/sen$"/EP-35543/sen$ - either that or = remove the > leading slash for sensors >=20 Yes, appears to be a typo. >=20 > Philosophy problem: >=20 > I am not happy with the way that 2119 language is sprinkled throughout = this > document. That is not a statement that you need to change it, but it = is a > request that you revisit and look at what is there. =20 > * MUST and SHOULD statements need to be able to have some type of test > written from them. If you cannot write a test, then using the key = words is > probably incorrect. > * SHOULD and MAY statements ought to have some type of language about = when > the action under consideration would not be done. =20 > * MAY statements are almost always a waste of time and should be = written in > a different manner.=20 > * Consider the first sentence in section 4.3. Is there a reason = why > this is not changed to "This section is optional to implement." and = leave it > at that? =20 > * Consider the second sentence in section 4.3. It implies that = there > is a third method that the client can use to publish, what is that = method? > I don't currently know of one. This saying "A client uses the POST or = PUT > method to publish ..." seems to be an adequate statement w/o the MAY. =20= > * Once upon a time, there was a requirement to extract and test all of = the > MUSTs in a document and a strong suggestion to test all of the SHOULDs = in a > document. Too many make things hard to see if you have adequate = coverage. > Too few and you might not have interop working correctly. In many = cases, a > MUST can be expressed w/o the key work. Consider the 2.04 sentence in > section 4.3 paragraph 1 - It can be written as "The broker returns a = "2.04 > Changed" response if the publish request is accepted". This has the = same > information as the current statement but w/o the MUST. The two = following > sentences should probably also be a MUST type statement so that a = client > knows what is going on rather than returning something strange. (That = can > be countered in the case of '4.04 Not Found' to maybe be '4.01 = Unauthorized' > as a reasonable response to prevent knowledge of what topics exist.) >=20 Thanks for this advice. Will discuss and improve the normative language. = Thinking about test cases is indeed a good way to crisp up the normative = stuff, as it makes it painful to try to test things that don't need to = be or shouldn't be prescriptive. --Apple-Mail=_6222E79A-9A7F-46DB-B924-4DB129ADA954 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Jim,

Thank you for taking the time to evaluate this draft. We have = discussed each point and have included the discussion and resolution = inline in this response.

On = Jul 10, 2017, at 11:57 AM, Jim Schaad <ietf@augustcellars.com> wrote:

Status:  This document is not yet ready for a WGLC in my = opinion.

I have copied forward some = comments from past reviews where I have not seem
them = addressed or do not believe that they are sufficiently  dealt = with.



* Section 3.4 = - s/are hosted at the broker and all clients using the broker
share/are hosted by a broker and all clients using that = broker share/ - a)
you can have multiple brokers and b) = the name spaces in that case are going
to be distinct and = potentially overlapping in name w/different values.

Yes, = updated

* Section 3.4 - "zero or more = stored representations with a content-format"
I think this = is supposed to be  "zero or more values - one content-format".
But the first time I read this, I read this as" zero or more = representations
- each representation has a content format = - may be zero or one (?) value".
I always worry about what = is "current" not what is "history" and assume that
observe = is correctly implemented.  Note this does go back to the question = of
"is this a queue of values" that Hannes has raised in = the past.

We think stored representations is correct, as a broker only = stores representations and is not aware of values.
We= are restricting it to most recently published representation, and = should take care that this is clear.

For queueing and reliable notification, = we consider a future extension based on subscriber-managed = queues. 
See github issues: 
https://github.com/core-wg/pubsub/issues/5

* Section 4.2 - cut and paste error for topic = and q as template variables.
I believe that q should be = removed from the template as it makes no sense.

Yes, corrected.

* Section 4.2 - Is the following legal for payload of a = create
"<mainTopic/subTopic>;ct=3D50"  - this = is a legal link but may not be legal
for creation of a = topic.  

Yes, we will clarify what is and is not legal for create. = Probably only one topic tree level at a time.

* Section 4.2 - Is the following legal for the payload of a = create
"<coap://localhost/ps/maintopic/subtopic>;ct=3D50" - The = text current says the
target of the link is a "URI = formatted string" rather than a fragment.

Same as above.WIll clarify in the = next update.

* Section 4.2 - I cannot tell = if the requirement for returning 4.04 (not
found) is new = in this document or should be part of RFC 6690 or not.  I
cannot seem to find this requirement in that document. =  Are you sure you
want to do this rather than just = return an empty content?  Should there be
an errata = on RFC 6690?

RFC6690 should not specify how REST APIs are expected to = expose links. It should focus on the format and just provide examples. = 4.04 is returned when the topic has been removed. Subscribe to = non-existant topics may be covered in the subscriber queue extension = described above.

* Section 4.2 - = There is an implicit statement in section 4.3 that a single
content type is expected.  However, there is no explicit = statement here that
a request with multiple content types = is forbidden.  Is there really a
requirement that a = single content type be required when creating a topic?
What = happens if no 'ct' is specified?

Candidate = text:
A topic creator includes one or more content = format option values in the create payload. If the broker does not = support all of the indicated formats for both publish and subscribe, it = (SHALL) returns an error response.

If a broker allows a topic to be = created with more than one content-format, it SHALL support an arbitrary = mix of the supported content formats in publish and subscribe = operations.

There is no default content format. If no ct is specified, = the broker SHALL reject the operation with an error code 4.15 = "unsupported content format" 

* Section 4.3 - Is a server supposed to accept a publish = operation to a
non-existent location with a POST method? =

Create-on-publish must use PUT. The link is constructed from = the request parameters. WIll clarify in the next update.

* Section 4.3 - Is there any reason to accept = publish via POST and not PUT?
Or the other way around?

PUT = is required for create-on-publish

POST is prefereble when the topic = already exists, but PUT may be used also. 

Generically, PUT is defined as replace = the stored representation with the supplied representation, may create = if the server supports (i.e. a PUT to a non-existent location may return = 2.01 Created or 4.04 Not Found)

* Section 4.3 - If no Max-Age is on the publish request, = should the default
value be used or should an infinite = value (i.e. absent) be used.  If a
Max-Age was = supplied at the time the subject was created, does that change
things?  If a publish is done with a Max-Age greater = than that provided at
creation, what should happen. =  Which wins?

More explanatory = text is perhaps needed. There are two Max-Age contexts, one is for the = topic and one is for the value.

If = no Max-Age is supplied, the topic should be permanent, modulo the = server's abiity to store topics.

Max-Age on publish should default to = permenent also.

* Section 4.3 - = Copy and paste error on the topic and q template variables.
Does 'q' even make sense here?

* = Section 4.3 - Text dealing with propagating publish events up the tree = to
keep nodes alive is missing.

Yes, this is the intended behavior = and will be described in the next update.

* Section 4.4 - Copy and paste error on the topic and q = template variables.
Does 'q' even make sense here?

Yes, corrected in the = next update.

* Section 4.4 - Is it = permitted that a broker remove a subscription due to
lack = of ACK for a CON w/o sending the "unsubscribed" message?  The = document
does not seem to allow that.

If a broker removes a topic, it is = allowed to do so without informing the subscribers. We use a SHOULD = statement to indicate that. 

If = a client fails to ACK an observe response when the broker uses CON, the = broker should not try to send a final message. We will clarify this. = RFC7641 section 3.5 doesn't seem to explain this either:

   An =
acknowledgement message signals to the server that the client is
   alive and interested in receiving further notifications; if the
   server does not receive an acknowledgement in reply to a confirmable
   notification, it will assume that the client is no longer interested
   and will eventually remove the associated entry from the list of
   observers (Section 4.5).

* Section 4.5 - = Copy and paste error on the topic and q template variables.
Does 'q' even make sense here?

Yes, will correct in the next = update.

* Section 4.6 - Copy and paste error on the = topic and q template variables.
Does 'q' even make sense = here?

Yes. Will = correct.

* Section 4.7 - Is remove = recursive?   

Remove is inclusive = of sub-topics, or recursive from the bottom of the tree. WIll add text = to clarify.

* Section 4.7 - = What would the correct content be to send an unsubscribe
notification on a remove operation?  '2.07 no content' = or '2.02' deleted or
'4.04' not found?

2.02 Deleted would be the response = to the Deleteing client, 4.04 woud be sent to observing clients, as per = standard CoAP Observe. Will make sure this is clear in the next = update.

* Section 8 - If enforcing access policies = is of importance, how are they
set?

The reference is toward an ACL = type system that may be out of the scope of this draft. More could be = said about what to do and how to do it. Will address this after some = more discussion.

* Section 8 - = It may be that '4.01 Unauthorized' is a better response than
'4.04 Not Found' in some cases.  Doing this does not = allow for probing of
what topics exist when one does not = have access to the directory of topics.

Good point. This may be added to = security considerations after discussion. It would be better to have = explicit ACLs that deny access to the resources and requre returning = 4.01 in these cases.

* Consider the = following scenario
 - Create node foo - ct=3D40, = Max-Age=3D10
 - Create node foo/bar - ct=3D0, = Max-Age=3D20
 - Publish to foo/bar @ time=3D5
 When you get to time=3D15, should the node foo be = deleted or does the
max-age of foo/bar change that = answer?

foo = expires and inclusively removes foo/bar at t=3D15
* Currently an application can use CON to ensure that a = server will get a
message in the long run.  The fact = that this is no doable here should be
briefly discussed as = an client cannot know that a server has or has not
received = a message.

Yes, = end-to-end protocol does not exist in pubsub. We have stayed away from = describing transfer layer operations in this draft, but it seems like a = good idea to point out the considerations in an informative way here as = in the issue above about observe termination. 

Minor:

* Section 3.4 -  s$"EP-33543/sen$"/EP-35543/sen$ - = either that or remove the
leading slash for sensors

Yes, appears to be a = typo.

Philosophy problem:

I am not happy with the way that 2119 language = is sprinkled throughout this
document.  That is not a = statement that you need to change it, but it is a
request = that you revisit and look at what is there.  
* MUST = and SHOULD statements need to be able to have some type of test
written from them.  If you cannot write a test, then = using the key words is
probably incorrect.
* = SHOULD and MAY statements ought to have some type of language about = when
the action under consideration would not be done. =  
* MAY statements are almost always a waste of time = and should be written in
a different manner.
=    *  Consider the first sentence in section 4.3. =  Is there a reason why
this is not changed to "This = section is optional to implement." and leave it
at that? =  
   *  Consider the second = sentence in section 4.3.  It implies that there
is a = third method that the client can use to publish, what is that method?
I don't currently know of one.  This saying "A client = uses the POST or PUT
method to publish ..." seems to be an = adequate statement w/o the MAY.  
* Once upon a time, = there was a requirement to extract and test all of the
MUSTs= in a document and a strong suggestion to test all of the SHOULDs in = a
document.  Too many make things hard to see if you = have adequate coverage.
Too few and you might not have = interop working correctly.  In many cases, a
MUST can = be expressed w/o the key work.  Consider the 2.04 sentence in
section 4.3 paragraph 1 - It can be written as "The broker = returns a "2.04
Changed" response if the publish request = is accepted".  This has the same
information as the = current statement but w/o the MUST.  The two following
sentences should probably also be a MUST type statement so = that a client
knows what is going on rather than returning = something strange.  (That can
be countered in the = case of '4.04 Not Found' to maybe be '4.01 Unauthorized'
as = a reasonable response to prevent knowledge of what topics exist.)

Thanks for this = advice. Will discuss and improve the normative language. Thinking about = test cases is indeed a good way to crisp up the normative stuff, as it = makes it painful to try to test things that don't need to be or = shouldn't be prescriptive.

= --Apple-Mail=_6222E79A-9A7F-46DB-B924-4DB129ADA954-- From nobody Thu Jul 20 16:12:06 2017 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 BC23A127599 for ; Thu, 20 Jul 2017 16:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=filament-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 xvdx_8xzB5Ni for ; Thu, 20 Jul 2017 16:12:02 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 131571243F3 for ; Thu, 20 Jul 2017 16:12:02 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id h199so155011ith.1 for ; Thu, 20 Jul 2017 16:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=VMDK+Way5gsbURu61dxPQ58c/kFsACJ4OdeIPpJ9x3o=; b=DJ4GuPlcvVNANKYwHkJ4N/bynyB2ctSK0JArrErWTmQZnmlXw05Tvkg79B6q6etsh0 ARe/njtcZ663fheNmfQ3zw0e0KPZr7Hjw2TcUDPVZPvsCZc1FvSJDo9biGi4KXwQuJbO ZcCPuUyW42n5d05SSXIHk2M+57MgY+eyAa12juzbhkzrkb3NpSMSOvelRP8otPrSNez6 lW70WjdPsJ3p135qTry9ESR69HxuzYzuMVxGYICIDQMojtC1tnN+070w+e59zeGrJgKy J+4ql4xH6oS52X48Im3ptcWGdwbOKI8V9Mdk53maLIaoKnirGZS9L946gj56/MHQQVY/ Ywkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=VMDK+Way5gsbURu61dxPQ58c/kFsACJ4OdeIPpJ9x3o=; b=BxdC8q3Lyns8hQIGgHLEcLC3iHIzHB+WoUlqJwDcSznPmfsnmzaiPrk1pry83xvs3U 5B49+ZyYrR55iuYHq8qboTyynK1nFNcBFX8Jw0ikykdIM/Bj6JgudBBUtflbmDA7H40b wp/dYkWseA/MU4o7bSsVhsQds7Z2wyXebi/C0ju+T3vS79xf1ANSQs95UdgfA8lDOFoX Es+Iez14R/u6S9HrcmNg4pmeMT9ZzFXz4grymLql4G1Y/EwF2uFWc3g80SW8Nzf3HBDi 3g8se1EJaTu7mggo1f1PAMslkjiZrZGTQ2QxXKK3VgOTBJv21dPH93bagMMMHifpbwHM 5blA== X-Gm-Message-State: AIVw110V7p6evDPtWFFkNS2uhhPa/USd9tE5fdkgYHgeOyMeCiHvezq9 /eFgAeEiC9i18Gie X-Received: by 10.36.22.17 with SMTP id a17mr5352362ita.40.1500592321303; Thu, 20 Jul 2017 16:12:01 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:dc2d:4b2e:14fc:6687]) by smtp.gmail.com with ESMTPSA id z84sm4181itc.32.2017.07.20.16.11.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 16:12:00 -0700 (PDT) To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= References: <5BAB706B-110D-4711-A62E-5980030F241F@ericsson.com> <5559A4D7-0D55-403D-A3C7-527942640A15@ericsson.com> <1243a4c8-5ce6-642e-faf3-5dda093d13df@filament.com> <5AA558F8-BD20-4871-806B-251155922C56@ericsson.com> <96c526a2-aa7f-5ec3-6e5d-13562b3a8310@filament.com> Cc: core From: Peter Saint-Andre - Filament Message-ID: Date: Thu, 20 Jul 2017 17:11:57 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] =?utf-8?q?=F0=9F=94=94_WGLC_on_draft-ietf-core-coap-senml?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 23:12:04 -0000 On 7/20/17 4:36 PM, Ari Keränen wrote: > >> On 19 Jul 2017, at 16.31, Peter Saint-Andre - Filament >> wrote: >> >> On 7/19/17 6:45 AM, Ari Keränen wrote: > OK. The urn:dev is now progressing in CoRE so I guess we can do the > allocation for that and move forward with it. Excellent! >>>>>> Please note that this set is more restricted than the range >>>>>> of characters allowed for URIs in general (RFC 3986) or >>>>>> URNs in particular (RFC 8141). At the least it would be >>>>>> helpful to point this out, because AFAICS it will limit the >>>>>> URI schemes or URN namespaces that can be used. >>>>> >>>>> Good point. I'd suggest text: >>>>> >>>>> "Note that the character set for SenML names is a subset of >>>>> the characters allowed in URIs. The restricted set was chosen >>>>> to enable efficient and safe use of names in various systems >>>>> (e.g., as database keys)." >>>> >>>> I suggest that we also say something like "The restrictions >>>> imply that care needs to be taken in the choice of URIs or URNs >>>> as SenML names." Furthermore, if someone wants to use a URI >>>> scheme that allows characters outside that set (e.g., the 'tag' >>>> scheme), then do those characters need to be encoded somehow? >>>> (Ick.) If not, then we should say so. >>> >>> One should not try to put "full URIs" into the names. Rather the >>> names can be used as part of a URI. >> >> I'm confused. What I see in the draft right now is that names >> (whether "Name" or "Base Name + Name" = concatenated name) are >> URIs, with URIs from the URN scheme used as examples. Is that a >> misunderstanding on my part? > > URIs that conform to the restricted character set ("A" to "Z", "a" to > "z", "0" to "9", "-", ":", ".", "/", "_"), such as urn:dev, are OK. > For example URL with brackets would not be OK (see section 5.1.6 for > example with IPv6 address). So I'll repeat my concern: How do we handle such URLs? Are they forbidden? If they are not forbidden, do characters like brackets get escaped somehow? (I hope we don't go down that road.) If they are forbidden, then most URI schemes and URN namespaces won't be usable. For example, URIs schemes such as 'tag' (RFC 4151) and 'ni' (RFC 6920) don't conform to the restricted character set, and there are characters allowed in URN syntax (e.g., '@', '%', '?', '[', ']', '#', '~', '+', '=', '&') that don't conform either. Thus it might even be misleading to say that names are URIs because so few URI schemes or URN namespaces can be employed here. We might need to say something like this... OLD The Name value is concatenated to the Base Name value to get the name of the sensor. The resulting name needs to uniquely identify and differentiate the sensor from all others. It is RECOMMENDED that the full names are represented as URIs [RFC3986] or URNs [RFC2141]. One way to create a unique name is to include some bit string that has guaranteed uniqueness (such as a 1-wire address) that is assigned to the device. Some of the examples in this draft use the device URN type as specified in [I-D.arkko-core-dev-urn]. UUIDs [RFC4122] are another way to generate a unique name. Note that long-term stable unique identifiers are problematic for privacy reasons and should be used with care or avoided as described in [RFC7721]. The resulting concatenated name MUST consist only of characters out of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", or "_" and it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9". This restricted character set was chosen so that these names can be directly used as in other types of URI including segments of an HTTP path with no special encoding and can be directly used in many databases and analytic systems. [RFC5952] contains advice on encoding an IPv6 address in a name. NEW The Name value is concatenated to the Base Name value to yield the name of the sensor. The resulting concatenated name needs to uniquely identify and differentiate the sensor from all others. The concatenated name MUST consist only of characters out of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", "/", and "_"; furthermore, it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9". This restricted character set was chosen so that concatenated names can be used directly within various URI schemes (including segments of an HTTP path with no special encoding) and can be used directly in many databases and analytic systems. [RFC5952] contains advice on encoding an IPv6 address in a name. Although it is RECOMMENDED that concatenated names are represented as URIs [RFC3986] or URNs [RFC8141], the restricted character set specified above puts strict limits on the URI schemes and URN namespaces that can be used. As a result, implementers need to take care in choosing the naming scheme for concatenated names, because such names both need to be unique and need to conform to the restricted character set. One approach is to include a bit string that has guaranteed uniqueness (such as a 1-wire address). Another, shown in some of the examples within this document, is to use the device URN namespace as specified in [I-D.arkko-core-dev-urn]. A third approach is to use UUIDs [RFC4122]. Unfortunately, the restricted character set does not allow the use of some URI schemes that might otherwise be attractive, such as the 'tag' scheme [RFC4151] and the 'ni' scheme [RFC6920]. Note also that long-term, stable, unique identifiers are problematic for privacy reasons and should be used with care or avoided entirely as described in [RFC7721]. >>> Perhaps something we should be more clear about. >> >> Yes, clarity would be good. > > Will add clarification about the URIs. See above for proposed text. >>> Now: https://github.com/core-wg/senml-spec/issues/73 >>> >>>>>> Section 4.6 >>>>>> >>>>>> Up to this point in the document, SenML has been defined as >>>>>> a format for representing sensor measurements. Given that a >>>>>> sensor measures something in the world, what does it mean >>>>>> to *set* the value of a sensor or a sensor measurement? >>>>> >>>>> I guess this needs to be elaborated also in the intro (it's >>>>> hinted in the abstract). >>>> >>>> That's the barest of hints. :-) I almost provided a comment >>>> about it, but let it go. >>> >>> Admittedly :) Do you have any proposal how to make it better? >> >> One option is to remove the configuration and actuation use cases. >> They seem to be an afterthought. Perhaps define them more carefully >> in a separate I-D that re-uses SenML, thus not holding up the core >> SenML work any further. >> >> If people really want to support these use cases now and in the >> core spec, then I can suggest improvements to the text. > > There is already use for these so I think we should include the > functionality in the base spec. OK, I will take a closer look at the text and propose some improvements. Peter From nobody Thu Jul 20 18:57:39 2017 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 D076A131CEA for ; Thu, 20 Jul 2017 18:57:37 -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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqQdgvO2WABT for ; Thu, 20 Jul 2017 18:57:35 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C715131CE4 for ; Thu, 20 Jul 2017 18:57:34 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id f21so20535431wrf.5 for ; Thu, 20 Jul 2017 18:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=S8XC0t0wJIgOQ9TOiUR/nujZNXOzoMG0kuvQ5FvF9Is=; b=vh8h4SO0+PliOLE95LNXHRJ8lDf1G2SYJHBcDk9x/znYOvIsCeJKkoxQk9viELRERe OBnWM59n2Aa4MDgS9ow43jeYUks1QkgPLTFBf2Q9X9L+hxCU5scAw3+QMzRB75ibBAVs BxhQiST5YMKTZwb94U4+Ki7wMhFmIcRMQuVEn5kWgchGwJt9Hjry8UY5CyiYgwiCcTeh fQC5ZMbK3a8f4JPlDO3STQg0g3963qR55edlGcUbGnrvbNwxzaCZpnQY4H8N1Cwm9Owv Qpe60TGVRprdWrVmk3f8r0KBuBEnb+kWEfoRtVOQIpSRvuKAh8Ru6XE10G+ZZE8uUqQZ jQYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=S8XC0t0wJIgOQ9TOiUR/nujZNXOzoMG0kuvQ5FvF9Is=; b=FJOqNbJwyM5uYYp1C8N6T7xYErqb1RSqFH/EY9p/LLPMgxpDiKVAC80i08t02RCCSJ y6kkWJJsDGRdA05VY2f+T+1WQ72LNxvbi6IhIguivSgBliodziWRI4Dn+iAXGG/BG0dZ HMEN52xxuL+N18IgPrFwl54sbuCw+juohG5SNmVZrQxj25a09Gm46yHoeZLWevBOMmv9 00t147pD+aXbF5K3AqxX4+X0hmZpSZyQogRIxq88bg5/S4RCtO2HYZmnUcdY6bFgZkTa QU/DzUZJuik5mgLFKGbmhrkPPznLBzHFJhfidEwBBFHRkueij64BYkgqYVq1IkdM+V1+ hkkQ== X-Gm-Message-State: AIVw112GqfdgQnR9hW2p5qsYrXJ5PxJGalCO3Ja97W78pfwYXlmi/FpA PaWELcNJX+zbkZj6KdTrjG0ECHpF84pq X-Received: by 10.223.136.176 with SMTP id f45mr5191373wrf.289.1500602252820; Thu, 20 Jul 2017 18:57:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Thu, 20 Jul 2017 18:57:32 -0700 (PDT) In-Reply-To: <20170720094718.GG20950@elstar.local> References: <20170720083313.GA20950@elstar.local> <20170720094718.GG20950@elstar.local> From: Andy Bierman Date: Thu, 20 Jul 2017 18:57:32 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Core Content-Type: multipart/alternative; boundary="001a11492e6c3a97a80554ca302a" Archived-At: Subject: Re: [core] comi and NMDA (configuration and operational state datastore) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 01:57:38 -0000 --001a11492e6c3a97a80554ca302a Content-Type: text/plain; charset="UTF-8" On Thu, Jul 20, 2017 at 2:47 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > well, I am trying to understand what the scope of CoMI is. If CoMI is > only for ~100k memory devices, you may be right. > IMO the NMDA stuff is only interesting if the device includes some sort of dynamic configuration datastores (extremely unlikely). But in case I am wrong, CoMI provides full access to operation resources, so NETCONF operations such as and can be used if really needed. A few obvious problems with using a multi-step editing process is that it is not REST-full at all, it requires locking, it requires lock recovery when the client goes away with outstanding locks, and it requires that the client support lots of different server transaction models (i.e., just as heavyweight as NETCONF, but much harder without any session-based interaction model). We should be trying to make CoMI as simple as possible, not a binary NETCONF. > /js > Andy > > On Thu, Jul 20, 2017 at 02:44:13AM -0700, Andy Bierman wrote: > > Hi, > > > > I doubt this will be a primary feature of CoMI. > > It is similar to RESTCONF, attempting to hide datastores from the client. > > It also allows access to any RPC (just like RESTCONF operation resources) > > so protocol operations that support NMDA can be supported. > > > > > > Andy > > > > > > On Thu, Jul 20, 2017 at 1:33 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > Hi, > > > > > > are there plans to make draft-ietf-core-comi-00 support NMDA > > > (draft-ietf-netmod-revised-datastores-03)? > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > core mailing list > > > core@ietf.org > > > https://www.ietf.org/mailman/listinfo/core > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11492e6c3a97a80554ca302a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 20, 2017 at 2:47 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

well, I am trying to understand what the scope of CoMI is. If CoMI is
only for ~100k memory devices, you may be right.
=C2= =A0

IMO the NMDA stuff is only interesting if the = device includes some sort of
dynamic configuration datastores (ex= tremely unlikely). But in case I am wrong,
CoMI provides full acc= ess to operation resources, so NETCONF operations
such as <edi= t-config> and <get-data> can be used if really needed.
<= br>
A few obvious problems with using a multi-step editing proces= s is that it
is not REST-full at all, it requires locking, it req= uires lock recovery
when the client goes away with outstanding lo= cks, and it requires that
the client support lots of different se= rver transaction models (i.e.,
just as heavyweight as NETCONF, bu= t much harder without any session-based
interaction model).
=

We should be trying to make CoMI as simple as possible,= not a binary NETCONF.



/js


Andy
=C2= =A0

On Thu, Jul 20, 2017 at 02:44:13AM -0700, Andy Bierman wrote:
> Hi,
>
> I doubt this will be a primary feature of CoMI.
> It is similar to RESTCONF, attempting to hide datastores from the clie= nt.
> It also allows access to any RPC (just like RESTCONF operation resourc= es)
> so protocol operations that support NMDA can be supported.
>
>
> Andy
>
>
> On Thu, Jul 20, 2017 at 1:33 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > Hi,
> >
> > are there plans to make draft-ietf-core-comi-00 support NMDA
> > (draft-ietf-netmod-revised-datastores-03)?
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core<= /a>
> >

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a11492e6c3a97a80554ca302a-- From nobody Thu Jul 20 22:45:31 2017 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 52DAC126D46 for ; Thu, 20 Jul 2017 22:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 uXnnzcHKG3wM for ; Thu, 20 Jul 2017 22:45:27 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0103.outbound.protection.outlook.com [104.47.36.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B299126BF6 for ; Thu, 20 Jul 2017 22:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uGeh5Xgldv8WcRmd39TACKy5OlF9F9MM8jqXJ/c3X4o=; b=AfShR1m5/TclfSjqyy1oJSegtuWS3pu1pYSWTQ5yYkvJRNCsc6cqLA9GuuQ+c9tekLeH1vxKJ5vz67Q9KOL2da0sGbSixbkWrwXmtNHBOYSNXahq7kwCDompvSq1I5kKivaC8cqWUa1MIxJYnZsowu10LRGql/X+1ayvm3ZbzBU= Received: from MWHPR06MB2317.namprd06.prod.outlook.com (10.168.246.147) by MWHPR06MB2320.namprd06.prod.outlook.com (10.168.246.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Fri, 21 Jul 2017 05:45:23 +0000 Received: from MWHPR06MB2317.namprd06.prod.outlook.com ([10.168.246.147]) by MWHPR06MB2317.namprd06.prod.outlook.com ([10.168.246.147]) with mapi id 15.01.1261.024; Fri, 21 Jul 2017 05:45:23 +0000 From: Michel Veillette To: Juergen Schoenwaelder , "core@ietf.org" Thread-Topic: [core] comi and NMDA (configuration and operational state datastore) Thread-Index: AQHTATLhGytpZB5D0UWNWB/cCmKJ+aJdwL/w Date: Fri, 21 Jul 2017 05:45:23 +0000 Message-ID: References: <20170720083313.GA20950@elstar.local> In-Reply-To: <20170720083313.GA20950@elstar.local> 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@trilliantinc.com; x-originating-ip: [193.86.126.99] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR06MB2320; 7:/8mB5EyYz0pWEtXnEIFZkeL8yIH/pV0pCokcht0jZLTzmI/VZPGeuZ/jex7roFr9kOct5RHZt83e7G8M5wWyq9+DFW/PL1/bW7lgIa+4KdnA0v/UyDtd7rFPZeoPJ4DlYF7I/qY4tqSMS+5buf6nDJ/L2guzG99L+PaQUNhHx/q/gsAE93UpfFTJYIYzH6MuwdtCN71+WnztOf+AWM3rxkpp7Ohb5R1IAKPkX3MGTCOGirSgf1jCjyeBDO6s6Bclh8+3ni5q8hjbzTJuidQjjVlgzP9soaVI+IvN2cI0UzVw1uIC4mmk4LL9S/fic9aOndmyZ0z+mD7dS+0rcT0gtVkKRBV3LQ2+mt2j6s7CyKzBSRMu+a3i23WmfeQkkCCRpnuhIjAM2pWu9PxwAdxABXkOz1PO1iSnJj8iVlo3fMUdHuMPLqUF7LVYDf+4hxCmoKPIHKcMGhtFyfN7HRFZnMvATYgx8R5obWfTjX1lMBwMdOVEHKEEvPQVHapDyfNwcL/nLYPmuL/S1kezHYXXIV/XjA4YJpLBT/5pupuwb3CTvuAolvgbEjLAFC2MvxFHR6Trp2nFiWHpXCnDXNRSsNvLMiIk36EBCdpMQ5RHWk9jl7ZYrGHcWXCkE1opXJOvgn/KZbCG5ZAwNPPeVU8SMzJ1WigWPUzP160Yy5rxvAEx6uCbL7jpOfcfbqc2N6OVP3DuaJrgmTT7HB87kODe7nXVs1HDSW4g+MOForkFeP9jMcGO8zZYjwWJhjP1w9Dzrt2P8rnRhdPYpJw4FK9KCNbZztQ7zOSX2dLQz8luC3A= x-ms-office365-filtering-correlation-id: 7139bc11-adbf-4801-682b-08d4cffbae6a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR06MB2320; x-ms-traffictypediagnostic: MWHPR06MB2320: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR06MB2320; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR06MB2320; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39410400002)(39850400002)(39400400002)(13464003)(377454003)(189002)(199003)(229853002)(81166006)(50986999)(54356999)(189998001)(102836003)(6246003)(478600001)(6436002)(99286003)(6506006)(38730400002)(53936002)(966005)(101416001)(68736007)(55016002)(33656002)(6306002)(6116002)(3846002)(77096006)(2950100002)(76176999)(25786009)(9686003)(2900100001)(5660300001)(8936002)(305945005)(106356001)(3280700002)(66066001)(14454004)(72206003)(7736002)(2906002)(7696004)(8676002)(2501003)(86362001)(105586002)(74316002)(53546010)(97736004)(3660700001)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR06MB2320; H:MWHPR06MB2317.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 05:45:23.3845 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB2320 Archived-At: Subject: Re: [core] comi and NMDA (configuration and operational state datastore) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 05:45:29 -0000 Hi Juergen draft-ietf-core-comi-00 won't support NMDA directly but some of these conce= pts might be reused in a complementary draft. I see different use cases of = using multiple datastores in IOT devices. - The ability to support default configuration profiles - The ability to support synchronized (scheduled) update between multiple d= evices - The ability to roolback a configuration If you remember the modem AT command set, this is equivalent to AT&Wn (e.g. AT&W0 Save as user profile 0) ATZn (e.g. ATZ0 Resets the modem and loads stored profile 0) Interactions with these datastores can still be performed using RESTful ope= ration (GET, PUT, POST, DELETE). You are welcome to write such draft for CoMI if this subject is of interest= to you. Regards, Michel -----Original Message----- From: core [mailto:core-bounces@ietf.org] On Behalf Of Juergen Schoenwaelde= r Sent: Thursday, July 20, 2017 10:33 AM To: core@ietf.org Subject: [core] comi and NMDA (configuration and operational state datastor= e) Hi, are there plans to make draft-ietf-core-comi-00 support NMDA (draft-ietf-ne= tmod-revised-datastores-03)? /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From nobody Thu Jul 20 22:58:35 2017 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 DF0E8126BF6 for ; Thu, 20 Jul 2017 22:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBNUXbKDp78f for ; Thu, 20 Jul 2017 22:58:26 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 F1C17127076 for ; Thu, 20 Jul 2017 22:58:25 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id 12so78319493wrb.1 for ; Thu, 20 Jul 2017 22:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=j1Nr/c227o8jjwY2accsjfUEeDv3ThkPP2Z1Xka/cqo=; b=fEgTioFMgPJ+luKqMp1gH6cAhpmIn0QOWD+r//pqYqHiJ0v1agz5JOk4tLAiiP4OUy MNhbbw2f8xZYiRjqcOwX7W8ZgGs9gw5NXMjlb40amhFNMI6rhnohyRoXP2FLGLEafGrm hiWCzf6XGKsn5WhymIc1wigYjDIwqJImpryc+++Xmf+cZXO11txdTaV6qX1NZ/oa/cIZ 2UBS3IfB/BaJ9MjNNjOEgVai0PjcalzpbSMlfBoneRNOvERYRTx3vO4rmKZZ9PoYm1UR YN6kO/tHNZb2hDQa/DFrXXadqWQr1sBoEdxfM6UjCf8IfaQeUxANqilN92Mnm2FoRtbT IHCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=j1Nr/c227o8jjwY2accsjfUEeDv3ThkPP2Z1Xka/cqo=; b=ZZdbMkPUpt1C9wmxegNg/4bONBCsFBaT8fzK4CCWQ+IdfjnuvXsNXIEQqzFirvlrV3 CRZ2pD+Sd6Nltr2znD48OgIaI/Rns8vSfOMjut5JDmLSLRHUU1klE9m/4UcUWjPE1nUs I+5IiDNZj3J5Le5jh4xzSvXjMlC2DYZJL1DqH0wO9VFLX2Q6IyyZycG/+VEV3ZGxtUAY bw8waa3NGMJJmwaAeWAstlapWn1A9H+r4Gb0lpa/cy+OCqq3OtiUyG+0+0iatxc6vyRB ybBBU+aaZzyHoJfj23DVDmxcsGyRlyj4wySHU4L75vWoj6U6SGBHtOMcenYxuq2jEC0J ugqA== X-Gm-Message-State: AIVw112AcAA+ttS6Yt7wbGsmWEkeg4By4qgFqjZn7iOfU6t9cXpSarIl eJ4XT2t40ENXZJJFbkUh5r4Ja5wZvx59 X-Received: by 10.223.171.79 with SMTP id r15mr3598245wrc.57.1500616704454; Thu, 20 Jul 2017 22:58:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Thu, 20 Jul 2017 22:58:23 -0700 (PDT) In-Reply-To: <20170720094047.GF20950@elstar.local> References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> From: Andy Bierman Date: Thu, 20 Jul 2017 22:58:23 -0700 Message-ID: To: Juergen Schoenwaelder , Carsten Bormann , Core Content-Type: multipart/alternative; boundary="94eb2c1cb8189d05bf0554cd8d33" Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 05:58:29 -0000 --94eb2c1cb8189d05bf0554cd8d33 Content-Type: text/plain; charset="UTF-8" Hi, I agree with Juergen that CoMI without SID is a much better solution for network management. The SID approach is brand new, untested, and many network management experts are concerned that perfect registries and perfect implementations are unlikely. The question "why can't I just use CBOR?" keeps coming up in private and WG emails. If SID is so crucial, then why is plain CBOR good enough for CoAP now? Seems to me that if it was so critical to collapse all identifier names down to a single integer, that this requirement would apply to all CoAP servers, not just CoAP using CoMI. IMO CoMI is unusable (experimental at best) because of SID. Perhaps a standards track RFC without SID and an Experimental RFC with SID would be better. Andy On Thu, Jul 20, 2017 at 2:40 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Jul 20, 2017 at 11:24:22AM +0200, Carsten Bormann wrote: > > On Jul 20, 2017, at 10:57, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > Thanks, much appreciated. Do I understand correctly that COMI requires > > > that the CBOR encoding uses SID? > > > > A constrained device that wants to support both SID- and string-based > identifiers would need to store all those strings to do identifier > comparisons on incoming requests. It seems to me it is a good tradeoff for > COMI, which is meant to be able to run on constrained devices, to focus on > the use of SIDs for identifiers. > > > > OK. This limits COMI applicability to constrained devices in the sense > of a few 100k of memory or devices living on rather limited links. > > I am interested in IoT devices that are able to run an embedded Linux > inside. So I am then probably more interested in using RESTCONF with > CBOR encoding since my devices are not that memory limited and I fear > the pain of a global single number managed in a decentralized way will > raise development pain. (So I would love to use CBOR without SID.) > Well, perhaps even RESTCONF with JSON is just good enough (clearly > more attractive for application writers). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --94eb2c1cb8189d05bf0554cd8d33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I agree with Juergen that CoMI with= out SID is a much better solution for network management.
The SID= approach is brand new, untested, and many network management experts are c= oncerned
that perfect registries and perfect implementations are = unlikely.=C2=A0 The question "why can't I just
use CBOR?= " keeps coming up in private and WG emails.

I= f SID is so crucial, then why is plain CBOR good enough for CoAP now?
=
Seems to me that if it was so critical to collapse all identifier name= s down
to a single integer, that this requirement would apply to = all CoAP servers,
not just CoAP using CoMI.

<= div>IMO CoMI is unusable (experimental at best) because of SID.
P= erhaps a standards track RFC without SID and an Experimental RFC with SID
would be better.


Andy



On Thu, Jul 20, 2017 at 2:40 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wro= te:
On Thu, Jul 20, 2017 at 11:24:22AM +0= 200, Carsten Bormann wrote:
> On Jul 20, 2017, at 10:57, Juergen Schoenwaelder <j.schoenwaelder@ja= cobs-university.de> wrote:
> >
> > Thanks, much appreciated. Do I understand correctly that COMI req= uires
> > that the CBOR encoding uses SID?
>
> A constrained device that wants to support both SID- and string-based = identifiers would need to store all those strings to do identifier comparis= ons on incoming requests.=C2=A0 It seems to me it is a good tradeoff for CO= MI, which is meant to be able to run on constrained devices, to focus on th= e use of SIDs for identifiers.
>

OK. This limits COMI applicability to constrained devices in the sense
of a few 100k of memory or devices living on rather limited links.

I am interested in IoT devices that are able to run an embedded Linux
inside. So I am then probably more interested in using RESTCONF with
CBOR encoding since my devices are not that memory limited and I fear
the pain of a global single number managed in a decentralized way will
raise development pain. (So I would love to use CBOR without SID.)
Well, perhaps even RESTCONF with JSON is just good enough (clearly
more attractive for application writers).

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--94eb2c1cb8189d05bf0554cd8d33-- From nobody Thu Jul 20 23:14:46 2017 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 797F7126DFF for ; Thu, 20 Jul 2017 23:14:44 -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 I9EuYWe6E1qW for ; Thu, 20 Jul 2017 23:14:43 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 BF392126D46 for ; Thu, 20 Jul 2017 23:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6L6EdpU016872; Fri, 21 Jul 2017 08:14:39 +0200 (CEST) Received: from surfer-172-30-2-218-hotspot.internet-for-guests.com (107.223.broadband2.iol.cz [83.208.223.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xDL8H2ZXrz3ZKS; Fri, 21 Jul 2017 08:14:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Fri, 21 Jul 2017 08:14:38 +0200 Cc: Juergen Schoenwaelder , Core X-Mao-Original-Outgoing-Id: 522310478.573363-e626d65f999b3fdd52213056a2e8ae31 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 06:14:44 -0000 On Jul 21, 2017, at 07:58, Andy Bierman wrote: >=20 > I agree with Juergen that CoMI without SID is a much better solution = for network management. For class-10+ (*), text string identifiers are fine. Yang-cbor is = neutral on this question. COMI defines a number of media types, and these are right now using = Yang-cbor with SIDs. Maybe we should just define another set of media = types with text string identifiers? After all, COMI is used in the CoRE = environment where we can use media types. Gr=C3=BC=C3=9Fe, Carsten (*) https://tools.ietf.org/html/draft-bormann-lwig-7228bis-01#section-3 From nobody Thu Jul 20 23:56:09 2017 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 5C0FD127076 for ; Thu, 20 Jul 2017 23:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 GnoQI5E_2hcH for ; Thu, 20 Jul 2017 23:56:06 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0104.outbound.protection.outlook.com [104.47.42.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13776124D85 for ; Thu, 20 Jul 2017 23:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0OWDsjKdVskLFknma5VlXfD0OnJkwSbsmJ836iel8SU=; b=HtHzjGKf6p3m5AC7wx8xiPGQYZ+UmJhljDpBCQWUbiYTJGr8DOofA9qdZ59AUY+bVbRjLx9OlkWoOqKCe85mzYrt0zgFi+ieA0uNV3tBQNSki1LCdhJH763O1CKaJHjukIoULeU8aPhqI5OI6VGL1Bbq/V4XKqsMsUzNV65lP1k= Received: from MWHPR06MB2317.namprd06.prod.outlook.com (10.168.246.147) by MWHPR06MB2318.namprd06.prod.outlook.com (10.168.246.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Fri, 21 Jul 2017 06:56:03 +0000 Received: from MWHPR06MB2317.namprd06.prod.outlook.com ([10.168.246.147]) by MWHPR06MB2317.namprd06.prod.outlook.com ([10.168.246.147]) with mapi id 15.01.1261.024; Fri, 21 Jul 2017 06:56:03 +0000 From: Michel Veillette To: Carsten Bormann , Andy Bierman CC: Core Thread-Topic: [core] yang cbor encoding without SID Thread-Index: AQHTATQrCEiVptWX80+aOopWb5cOWaJcaCuAgAAB64CAAAdyAIAABJeAgAFUMYCAAASKAIAABsVg Date: Fri, 21 Jul 2017 06:56:03 +0000 Message-ID: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> In-Reply-To: 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@trilliantinc.com; x-originating-ip: [31.133.142.211] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR06MB2318; 7:pzz34iMx60dTRqUdL2uAtNVx5I9L00zD02v/RM4rVG5l4Ze4z8y2ONzPVYizxgVCVaaRFPd3/NoTMW3JfgRGiCk02RzIo1PELHdZDMQ6aw0xIs53cO9bZld64so6/4m4/YrVYcwMqkSU4uLO5jXY5vO0Bc9gCXjYyFKjYJHI59iipMzydIeXN+QQW0YEQxvZGojNo/v2InuEZMBqvSgI6Ht8U3oEmMTZ3EoDwFKstMF97dp7yE0b4KEvMONMUkUnR4mtrX+IByFuUa3Q4AiPq2jGbuffsevHVhdwTlrM5Q2mb4ImN6nlBesrNPt45Mw2e0SpLGHLHW00QXgiEwQhwzBJPu2X5nS1MjF1Jrdc342il8ACQuHAimbtV/VONszZOngG4T2KHNP5bjQ6uCEN6TwyIaGzQ7rNamTFke3HOcQJuASSpmxSuHTI5kSUXPNfqVaDdNAAeHe1NzvQU401XBw+JSiljju/RgzcytQARvy15pH1EydiL0atjC8jFd2Rn8lBG+vi17l3YbuiqsW4txgovbHvLhOi/66bxOzmC6iARzeeZ4aJ0TMV21FDuY8B7k3G369k2XYDQvCFBrTDP35/YK7GNrwRgLy6bsnwbZqvYTaGr7uuoK2RL+6728ITw7tMnlIaL8LH9/MQthe9NtOc8AgMAqtP39aH84FANKmUB0l5EYg7V2XXteIVWdW5ae9PIvSiwfV5ArEIXSjM9MgsXbGe0RguaJlZLT7DM3kwCILtF2IrV5VGt8UZ8b8mDXqaKhAxvGr+xCgpR2hxrfsJzUTgGHmct7YNSnQM9Ns= x-ms-office365-filtering-correlation-id: 278d1e20-0b47-4c69-a49a-08d4d0058d93 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR06MB2318; x-ms-traffictypediagnostic: MWHPR06MB2318: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR06MB2318; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR06MB2318; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39840400002)(39850400002)(39450400003)(189002)(377454003)(24454002)(199003)(13464003)(72206003)(966005)(33656002)(102836003)(101416001)(305945005)(25786009)(3660700001)(105586002)(14454004)(68736007)(229853002)(106356001)(8936002)(76176999)(3846002)(53936002)(77096006)(6246003)(93886004)(74316002)(38730400002)(189998001)(5660300001)(50986999)(478600001)(97736004)(54356999)(6306002)(6436002)(2950100002)(7736002)(99286003)(7696004)(66066001)(2906002)(81156014)(81166006)(53546010)(86362001)(3280700002)(6506006)(55016002)(4326008)(9686003)(8676002)(2900100001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR06MB2318; H:MWHPR06MB2317.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 06:56:03.3509 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB2318 Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 06:56:08 -0000 SGkgQW5keQ0KDQpJIHdvbid0IG9iamVjdCB0byB0aGUgaW50cm9kdWN0aW9uIG9mIG5hbWVzIHdp dGhpbiBDb01JIGlmIHNvbWVvbmUgdGFrZXMgdGhlIGxlYWQgdG8gaW50cm9kdWNlIGl0Lg0KDQpI b3dldmVyLCBJIHdhbnQgdG8gc2F5IHRoYXQgbmFtZXMgY2FuIGJlIGVycm9yLXByb25lIGFsc28u DQpTaW1pbGFyIGFzIFNJRCwgbmFtZXMgcmVseSBvbiBhIHJlZ2lzdHJ5IG9mIGZpbGVzIChpLmUu IHlhbmcgZmlsZXMpIHRvIGVuYWJsZSBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIHRvIHNoYXJl IHRoZSBzYW1lIHNldCBvZiBpZGVudGlmaWVycy4NCkNvbnNpZGVyaW5nIHRoYXQgU0lEIHJlZ2lz dHJpZXMgY2FuIGF1dG9tYXRpY2FsbHkgZGV0ZWN0IGFueSBtaXN1c2Ugb3IgZHVwbGljYXRlIHVz ZSBvZiBTSURzLCBJIGRvbid0IHNlZSB0aGUgaW5jcmVtZW50YWwgcmlzay4NCg0KSSBhbHNvIHdh bnQgdG8gbWVudGlvbiB0aGF0IHRoZSB1c2Ugb2YgYmluYXJ5IGlkZW50aWZpZXIgaXMgbm90IGEg bmV3IG9yIGV4cGVyaW1lbnRhbCBjb25jZXB0LiBJdCBoYXZlIGJlZW4gdXNlZCBpbiBkaWZmZXJl bnQgcHJvdG9jb2xzIHdpdGggc3VjY2VzcyBmb3IgZGVjYWRlcy4NCg0KUmVnYXJkcywNCk1pY2hl bA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY29yZSBbbWFpbHRvOmNvcmUt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubg0KU2VudDogRnJp ZGF5LCBKdWx5IDIxLCAyMDE3IDg6MTUgQU0NClRvOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdv cmtzLmNvbT4NCkNjOiBDb3JlIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSB5 YW5nIGNib3IgZW5jb2Rpbmcgd2l0aG91dCBTSUQNCg0KT24gSnVsIDIxLCAyMDE3LCBhdCAwNzo1 OCwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiANCj4gSSBhZ3Jl ZSB3aXRoIEp1ZXJnZW4gdGhhdCBDb01JIHdpdGhvdXQgU0lEIGlzIGEgbXVjaCBiZXR0ZXIgc29s dXRpb24gZm9yIG5ldHdvcmsgbWFuYWdlbWVudC4NCg0KRm9yIGNsYXNzLTEwKyAoKiksIHRleHQg c3RyaW5nIGlkZW50aWZpZXJzIGFyZSBmaW5lLiAgWWFuZy1jYm9yIGlzIG5ldXRyYWwgb24gdGhp cyBxdWVzdGlvbi4NCg0KQ09NSSBkZWZpbmVzIGEgbnVtYmVyIG9mIG1lZGlhIHR5cGVzLCBhbmQg dGhlc2UgYXJlIHJpZ2h0IG5vdyB1c2luZyBZYW5nLWNib3Igd2l0aCBTSURzLiAgTWF5YmUgd2Ug c2hvdWxkIGp1c3QgZGVmaW5lIGFub3RoZXIgc2V0IG9mIG1lZGlhIHR5cGVzIHdpdGggdGV4dCBz dHJpbmcgaWRlbnRpZmllcnM/ICBBZnRlciBhbGwsIENPTUkgaXMgdXNlZCBpbiB0aGUgQ29SRSBl bnZpcm9ubWVudCB3aGVyZSB3ZSBjYW4gdXNlIG1lZGlhIHR5cGVzLg0KDQpHcsO8w59lLCBDYXJz dGVuDQoNCigqKSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm9ybWFubi1sd2ln LTcyMjhiaXMtMDEjc2VjdGlvbi0zDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From nobody Fri Jul 21 00:45:48 2017 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 A28E512783A for ; Fri, 21 Jul 2017 00:45:46 -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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWZmwIdhUbwQ for ; Fri, 21 Jul 2017 00:45:44 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8661012714F for ; Fri, 21 Jul 2017 00:45:44 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id 12so79186198wrb.1 for ; Fri, 21 Jul 2017 00:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wuFRMBc1NkmKEuWxdIrHHIXYEWCwUfwPvNV8XNCnR2A=; b=IbMFqrJrd6Ow2PBhJmONaO8B8/sIU9OrewX1o8WKik/TRu2M98qyH8g3CkkivkKovG 2NC7ySCc6VpWxIDW59khP1fToR4LebRGC5WlAIDhk4rEU9yNPGKcJayU6Dzgxm96VPKL MpePWO7A9qKxeCHaiXCBDVvUut7fxBS0r6qDkMTrajgG4X2c3XkRg8KCDRQU0ZHnGiJj +QuRl1l1AN038oW59XRUgX2BTKKdc4IWGZjm9E8L6rtWTACe6CAXMeHXO5ZvEcOkP4X5 WT29JVQhmeByypqCBNzxccXhaDE1+Ba1ATe/LEnW2/1lnwFo1ySlBc2RkMP+47ZBpTJ9 ghIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wuFRMBc1NkmKEuWxdIrHHIXYEWCwUfwPvNV8XNCnR2A=; b=m2KME3x9KV6bIy7WdCAn0x6uL49CWgcw8c/CBblyza7yBUhXTZjJJwv+OxUhOHb+p+ +P/0kUJp+bD0hMYy5k+eE3svl8eXiKkYXCA8wSySxOYMG7T22CyVvUM749ffiu6u8D9j 1xTdvqgkm8VuIa5AsKKe6KfdJsPOv8mDqL+J/oCIMwLk0JIH4Z4bNRpBUjNFZjZ59zPn bfEZRY+a1wppjJAYDL9MVYmsPPZ7IslTAWcRa8dRdjEA3P8cEqSFoTjYqwlIdmSTngcG LwhH3yAyNBhCFV00j7+GEjh+1/rsBbojFrUoCFQZ3Qqzijkqtc/msxXr/rqEjYoZ+Y9k hEGA== X-Gm-Message-State: AIVw111pwJtPC0dhN6GHCCITdcOkdBgYGkZs2KRLfNsr0qJY8DlkWCQL C9cMv5X26kvAGuX7Ht7t5aR68/K/eDZE X-Received: by 10.223.171.79 with SMTP id r15mr3823930wrc.57.1500623143118; Fri, 21 Jul 2017 00:45:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Fri, 21 Jul 2017 00:45:42 -0700 (PDT) In-Reply-To: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> From: Andy Bierman Date: Fri, 21 Jul 2017 00:45:42 -0700 Message-ID: To: Carsten Bormann Cc: Juergen Schoenwaelder , Core Content-Type: multipart/alternative; boundary="94eb2c1cb818633ce90554cf0d78" Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 07:45:47 -0000 --94eb2c1cb818633ce90554cf0d78 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 20, 2017 at 11:14 PM, Carsten Bormann wrote: > On Jul 21, 2017, at 07:58, Andy Bierman wrote: > > > > I agree with Juergen that CoMI without SID is a much better solution fo= r > network management. > > For class-10+ (*), text string identifiers are fine. Yang-cbor is neutra= l > on this question. > But ALL CoAP devices using CBOR now use string identifiers right? There is no alternative now, even for Class 1 devices, right? So why is CBOR appropriate at all now, since identifiers are strings? > > COMI defines a number of media types, and these are right now using > Yang-cbor with SIDs. Maybe we should just define another set of media > types with text string identifiers? After all, COMI is used in the CoRE > environment where we can use media types. > > Gr=C3=BC=C3=9Fe, Carsten > > (*) https://tools.ietf.org/html/draft-bormann-lwig-7228bis-01#section-3 > > Andy --94eb2c1cb818633ce90554cf0d78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 20, 2017 at 11:14 PM, Carsten Bormann <= ;cabo@tzi.org> wrote:
On Jul 21, 2017, at 07:58, And= y Bierman <andy@yumaworks.com&= gt; wrote:
>
> I agree with Juergen that CoMI without SID is a much better solution f= or network management.

For class-10+ (*), text string identifiers are fine.=C2=A0 Yang-cbor is neu= tral on this question.

But ALL CoAP dev= ices using CBOR now use string identifiers right?
There is no alt= ernative now, even for Class 1 devices, right?
So why is CBOR app= ropriate at all now, since identifiers are strings?

=C2=A0

COMI defines a number of media types, and these are right now using Yang-cb= or with SIDs.=C2=A0 Maybe we should just define another set of media types = with text string identifiers?=C2=A0 After all, COMI is used in the CoRE env= ironment where we can use media types.

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

(*) https://tools.ietf.org/html/<= wbr>draft-bormann-lwig-7228bis-01#section-3


Andy
--94eb2c1cb818633ce90554cf0d78-- From nobody Fri Jul 21 00:57:27 2017 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 B12CA131BC3 for ; Fri, 21 Jul 2017 00:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7, 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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG9dNcWlil6f for ; Fri, 21 Jul 2017 00:56:14 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7500B1316E2 for ; Fri, 21 Jul 2017 00:56:14 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id w191so1907214wmw.1 for ; Fri, 21 Jul 2017 00:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2HF/KChZrDiL6lpDm2W6jUMD49d0YfFaEu1U0fF522g=; b=kTAiZ0+17PuOQAD567pvOfk/PdzV3ZgRQmhaY/HOOc9QswDvConY6tKluuaNffV5Ua YoH6TwDUFZEfo6afmOC6cQPNDZzwxzr9srRed+3UuWTC39eVbZCzeGJI1e7s4mFv3hVr s0AwXg/cUUTHM0WWNdX+CtDVAotRYEeTVvmbrvn0okS+Pt8tya/lLPt6QemlJ3RhD5WA zQ+hIJWslQyyoNbdehJLAm7fjjyiqApJJqr+YJQkSPxGJ0WGhbuPVNY0qkAi44Vy5T/r qmE7faaKaADNDnh+kPuJcwGpUxFVqN0JbAPDCG13etA9W3O1PZTUyHohiYl81Cy6a7Su kPFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2HF/KChZrDiL6lpDm2W6jUMD49d0YfFaEu1U0fF522g=; b=EutJHFKAktv73cfRe16W0pYRvRRMYiK+zGP7Jr7EEsoF4i03okYoerbq/9UxnV84or B98Xhpz/7qLuidDmvGFpMgf1Sua9hdEOB/eVShynaRiekEOOxpUJZlhmorrvFRNEG9Ax UGl/4Beib6GIe/LTaGgnmAmLqoyK6py4BCtQxszlt/BTwqVJqdOwt/vO6Ymyh8/dTXyb Dm5EY9HjHmFo9KpdLsXAxHoAVwJ+Z1itmGVpLtqtzAYB2sb9VhijMBlPTwlWE0kcPjla 8r/y4fjRzfLgQfJyBrBdIIPWq6oqQEcGXa5IcsQsUfwb40sqq/qwFEFNh9udicjkDshp 6hiQ== X-Gm-Message-State: AIVw112ZtorG0GioF5506x0FYkc1ckxexmWNhqAtCn2Zw423lVi095sz 98agJIfNqBSKrPdHVv/WBjbbFGiU+iu6 X-Received: by 10.28.32.81 with SMTP id g78mr4015879wmg.59.1500623773010; Fri, 21 Jul 2017 00:56:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Fri, 21 Jul 2017 00:56:12 -0700 (PDT) In-Reply-To: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> From: Andy Bierman Date: Fri, 21 Jul 2017 00:56:12 -0700 Message-ID: To: Michel Veillette Cc: Carsten Bormann , Core Content-Type: multipart/alternative; boundary="001a113c89deee9f9e0554cf32b9" Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 07:56:18 -0000 --001a113c89deee9f9e0554cf32b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 20, 2017 at 11:56 PM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi Andy > > I won't object to the introduction of names within CoMI if someone takes > the lead to introduce it. > > However, I want to say that names can be error-prone also. > Similar as SID, names rely on a registry of files (i.e. yang files) to > enable different implementations to share the same set of identifiers. > Considering that SID registries can automatically detect any misuse or > duplicate use of SIDs, I don't see the incremental risk. > > I do not agree. Currently, it is IMPOSSIBLE to create a YANG module for which an instance document cannot be 100% correctly encoded and decoded using XML or JSON. This is not the case with YANG to CBOR at all. Developers need special tools to check the YANG module to make sure it does not contain certain union types. If it does, the YANG module must be changed or not used at all. Also, YANG updates allow statements to be moved and altered in many ways. None of these changes impact the XML or JSON encoding at all, but they do affect CBOR. It is critical to maintain previous SID assignments. YANG identifiers do not have to be long. They can be 1 byte if you want. YANG modules for constrained devices can use short identifiers. Since XML and JSON are hierarchical, the identifier length is actually the node name length (e.g., 'name') not the full path string from root (e.g. /interfaces/interface/name). Andy > I also want to mention that the use of binary identifier is not a new or > experimental concept. It have been used in different protocols with succe= ss > for decades. > > Regards, > Michel > > -----Original Message----- > From: core [mailto:core-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Friday, July 21, 2017 8:15 AM > To: Andy Bierman > Cc: Core > Subject: Re: [core] yang cbor encoding without SID > > On Jul 21, 2017, at 07:58, Andy Bierman wrote: > > > > I agree with Juergen that CoMI without SID is a much better solution fo= r > network management. > > For class-10+ (*), text string identifiers are fine. Yang-cbor is neutra= l > on this question. > > COMI defines a number of media types, and these are right now using > Yang-cbor with SIDs. Maybe we should just define another set of media > types with text string identifiers? After all, COMI is used in the CoRE > environment where we can use media types. > > Gr=C3=BC=C3=9Fe, Carsten > > (*) https://tools.ietf.org/html/draft-bormann-lwig-7228bis-01#section-3 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a113c89deee9f9e0554cf32b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 20, 2017 at 11:56 PM, Michel Veillette &l= t;Mi= chel.Veillette@trilliantinc.com> wrote:
Hi Andy

I won't object to the introduction of names within CoMI if someone take= s the lead to introduce it.

However, I want to say that names can be error-prone also.
Similar as SID, names rely on a registry of files (i.e. yang files) to enab= le different implementations to share the same set of identifiers.
Considering that SID registries can automatically detect any misuse or dupl= icate use of SIDs, I don't see the incremental risk.



I do not agree.
Currently, it is IMPOSSIBLE to create a YANG module for which an
instance document cannot be 100% correctly encoded and decoded using XML= or JSON.
This is not the case with YANG to CBOR at all.=C2=A0 De= velopers need special tools to
check the YANG module to make sure= it does not contain certain union types.
If it does, the YANG mo= dule must be changed or not used at all.

Also, YAN= G updates allow statements to be moved and altered in many ways.
= None of these changes impact the XML or JSON encoding at all, but they do
affect CBOR.=C2=A0 It is critical to maintain previous SID assignm= ents.
YANG identifiers do not have to be long. They can be 1 byte= if you want.
YANG modules for constrained devices can use short = identifiers.
Since XML and JSON are hierarchical, the identifier = length is actually
the node name length (e.g., 'name') no= t the full path string from root
(e.g. /interfaces/interface/name= ).


Andy

= =C2=A0
I also want to mention that the use of binary identifier is not a new or ex= perimental concept. It have been used in different protocols with success f= or decades.

Regards,
Michel

-----Original Message-----
From: core [mailto:core-bounces@ie= tf.org] On Behalf Of Carsten Bormann
Sent: Friday, July 21, 2017 8:15 AM
To: Andy Bierman <andy@yumaworks.c= om>
Cc: Core <core@ietf.org>
Subject: Re: [core] yang cbor encoding without SID

On Jul 21, 2017, at 07:58, Andy Bierman <andy@yumaworks.com> wrote:
>
> I agree with Juergen that CoMI without SID is a much better solution f= or network management.

For class-10+ (*), text string identifiers are fine.=C2=A0 Yang-cbor is neu= tral on this question.

COMI defines a number of media types, and these are right now using Yang-cb= or with SIDs.=C2=A0 Maybe we should just define another set of media types = with text string identifiers?=C2=A0 After all, COMI is used in the CoRE env= ironment where we can use media types.

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

(*) https://tools.ietf.org/html/<= wbr>draft-bormann-lwig-7228bis-01#section-3

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

--001a113c89deee9f9e0554cf32b9-- From nobody Fri Jul 21 01:13:06 2017 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 00D66131748 for ; Fri, 21 Jul 2017 01:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTxKSoc64R8v for ; Fri, 21 Jul 2017 01:13:02 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) (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 196BD12EB2B for ; Fri, 21 Jul 2017 01:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6L8CwGk022840; Fri, 21 Jul 2017 10:12:58 +0200 (CEST) Received: from dhcp-808c.meeting.ietf.org (dhcp-808c.meeting.ietf.org [31.133.128.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xDNmp502zz3ZMB; Fri, 21 Jul 2017 10:12:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <20170720094047.GF20950@elstar.local> Date: Fri, 21 Jul 2017 10:12:56 +0200 Cc: core@ietf.org X-Mao-Original-Outgoing-Id: 522317576.507728-7c78c11a44c5cc1e1b08b3518597c3a3 Content-Transfer-Encoding: quoted-printable Message-Id: <7A58CD49-AC30-45DF-8C91-1ADFC9422C0D@tzi.org> References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 08:13:05 -0000 On Jul 20, 2017, at 11:40, Juergen Schoenwaelder = wrote: >=20 > OK. This limits COMI applicability to constrained devices in the sense > of a few 100k of memory or devices living on rather limited links. Not being affluent in memory may be one reason to use a constrained = management solution; another reason may be not being affluent in = bandwidth (or in total energy). The third reason may be wanting to stay = compatible with nodes that are in one of these two situations. In other = words: I don=E2=80=99t think the above mentioned limit in applicability = really exists; you don=E2=80=99t have to abandon COMI as soon as you add = some memory. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 21 01:17:40 2017 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 8F369131A54 for ; Fri, 21 Jul 2017 01: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 KuwDQfmFObSU for ; Fri, 21 Jul 2017 01:17:37 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0135.outbound.protection.outlook.com [104.47.42.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081C012EC51 for ; Fri, 21 Jul 2017 01:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y4pRT58W9HLB0CrMBCAEvm8kHEEo5K4oijvEs+mRSAI=; b=Icr1KPQd4hHGOiOvTR/czEH8ldjNEXvnYeVmyge7Sxb05KhzKnLQtZjuX0Qpm9Rlieqa4/1Zc37VyaClEyk8/MJdbtQ2vLqNiDQMfsLdwfMqWIYOjpWyw1z+fqo1Aqlz8BEksowmXkpDAjBuc62DHm2ZqmZ1Nl/8Bh2k6DWJ49c= Received: from MWHPR06MB2317.namprd06.prod.outlook.com (10.168.246.147) by MWHPR06MB2320.namprd06.prod.outlook.com (10.168.246.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Fri, 21 Jul 2017 08:17:34 +0000 Received: from MWHPR06MB2317.namprd06.prod.outlook.com ([10.168.246.147]) by MWHPR06MB2317.namprd06.prod.outlook.com ([10.168.246.147]) with mapi id 15.01.1261.024; Fri, 21 Jul 2017 08:17:34 +0000 From: Michel Veillette To: Andy Bierman CC: Carsten Bormann , Core Thread-Topic: [core] yang cbor encoding without SID Thread-Index: AQHTATQrCEiVptWX80+aOopWb5cOWaJcaCuAgAAB64CAAAdyAIAABJeAgAFUMYCAAASKAIAABsVggAAVnACAAANLIA== Date: Fri, 21 Jul 2017 08:17:34 +0000 Message-ID: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> In-Reply-To: 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@trilliantinc.com; x-originating-ip: [31.133.142.211] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR06MB2320; 7:5TnC01UdvGvDfiNJbUhxa8LO/Mxcs1HtUtzIeRY/hKGc42ylN2U57SF7rl4Yf4sj/a8kYuh6T4emKjXDMfi2YljpJAv0TflvL7Fzp1usKWT9X6yguDk31t5CijFN0C53HLQnwhdTzv65SHJowrzK1h0XJgWc7kiUMNQ7voJpKcg/6T42y7qZ27enhMu6tCjpdkFsnD2OX9zLQxgfKx/FUdMjANZxG38hE1+vuv5kj+XADRHa5InYu+AxYpvr3FAaR8D8mM7yWfUseX+sJMArbuB+Nn5idwUESy8Atik3k8qwbSAXS4fn6iFKBPYIDKldxW5rxs/uXybrRwZM6EqHJ97sNLHgFyaUWkt5pNR7KnV2mfvXwnr7ehCIWZxrCqa7DPDoHt6NZ7hAzimjVlAWtd1HsbRjXENbT8t46BLhxZdmVVTtqGE95DzwxUZN5mSAcICcPt77yXsMNPXeLO6kn3Qswobfg1OD1fIF5gv40rkHqiwiV4KXflHd1r6azfq76I4orbpCOG4bSI8CZNR1RkbESDkz9F84pmLAJV1DXYQiLJPr8stefgLMVYGfM5bY2b0WBRGmIWbJ5fGO/+/ehTJXk2xWQQw+nWOoMVLV2xFJZKQBuejsAudV1ciAdD70pMRHDMdipZjPpEtauGjKuB3bui5JpREClz7/szwvgjMe6+kqHCkaZmyj1l7BAGbWPAKm4esg0B0XkxHfbe/lLpCZ43h9Aw8YNRfZ/5j4JnCyX0lTrSLiaU/vLQn6gDPvBe89KI7CTOSB6Jl0vnQslOgXiiwyrJOEXOOfCTALUYM= x-ms-office365-filtering-correlation-id: a6f5b2a6-b283-4054-1024-08d4d010f0e1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR06MB2320; x-ms-traffictypediagnostic: MWHPR06MB2320: x-exchange-antispam-report-test: UriScan:(26388249023172)(21748063052155)(151999592597050); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR06MB2320; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR06MB2320; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39410400002)(39850400002)(39840400002)(39450400003)(199003)(24454002)(189002)(13464003)(377454003)(14454004)(6916009)(54896002)(66066001)(106356001)(5660300001)(8936002)(3280700002)(93886004)(53546010)(19609705001)(74316002)(97736004)(81156014)(3660700001)(86362001)(2906002)(7736002)(7696004)(72206003)(105586002)(8676002)(4326008)(38730400002)(99286003)(6436002)(6506006)(55016002)(54906002)(33656002)(68736007)(101416001)(966005)(53936002)(606006)(54356999)(229853002)(81166006)(50986999)(6246003)(478600001)(110136004)(102836003)(189998001)(9686003)(2900100001)(790700001)(25786009)(236005)(77096006)(6306002)(3846002)(6116002)(76176999)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR06MB2320; H:MWHPR06MB2317.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR06MB2317092747A52FB815570C7DFEA40MWHPR06MB2317namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 08:17:34.4324 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB2320 Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 08:17:39 -0000 --_000_MWHPR06MB2317092747A52FB815570C7DFEA40MWHPR06MB2317namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keQ0KDQpBYm91dCB0aGUgdW5pb24sIHRoZSBDQk9SIGVuY29kaW5nIGF2b2lkIGFueSBh bWJpZ3VpdGllcyBiZXR3ZWVuIGRhdGF0eXBlcywgc29tZXRoaW5nIG5vdCBhcmNoaXZlZCBieSB0 aGUgeG1sIG1hcHBpbmcgYW5kIHBhcnRpYWxseSBhcmNoaXZlZCBieSBKU09OLiBGb3IgZXhhbXBs ZSwgaW4geG1sLCBpdCBpcyBpbXBvc3NpYmxlIHRvIGRpZmZlcmVudGlhdGUgdGhlIHN0cmluZyAi MSIgZnJvbSB0aGUgaW50ZWdlciAxLiBUaGUgb25seSBhbWJpZ3VpdGllcyBub3QgcmVzb2x2ZWQg YnkgdGhlIENCT1IgZW5jb2RpbmcgaXMgYW4gdW5pb24gY29tcG9zZWQgb2YgdHdvIGVudW1lcmF0 aW9ucyBkZWZpbmluZyB0aGUgc2FtZSB2YWx1ZSBhc3NvY2lhdGVkIHRvIGRpZmZlcmVudCBtZWFu aW5ncy4gSSB3aWxsIGFyZ3VlIHRoYXQgc3VjaCBkZWZpbml0aW9uIGlzIGluY29ycmVjdC4NCg0K QWJvdXQgeW91ciBzZWNvbmQgcG9pbnQsIGlmIHRoZSBKU09OIGVuY29kaW5nIGlzIG5vdCBpbXBh Y3RlZCwgSSBkb24ndCBzZWUgd2h5IFNJRCB3aWxsIGJlIGltcGFjdGVkLiBBcyB5b3Ugc2FpZCB5 ZXN0ZXJkYXksIFNJRHMgaXMgYSBzaW1wbGUgbWFwcGluZyBiZXR3ZWVuIEpTT04gcGF0aHMgYW5k IG51bWVyaWMgSURzLg0KDQpSZWdhcmRzLA0KTWljaGVsDQoNCkZyb206IEFuZHkgQmllcm1hbiBb bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IEZyaWRheSwgSnVseSAyMSwgMjAxNyA5 OjU2IEFNDQpUbzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRp bmMuY29tPg0KQ2M6IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPjsgQ29yZSA8Y29yZUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbY29yZV0geWFuZyBjYm9yIGVuY29kaW5nIHdpdGhvdXQg U0lEDQoNCg0KDQpPbiBUaHUsIEp1bCAyMCwgMjAxNyBhdCAxMTo1NiBQTSwgTWljaGVsIFZlaWxs ZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPG1haWx0bzpNaWNoZWwuVmVp bGxldHRlQHRyaWxsaWFudGluYy5jb20+PiB3cm90ZToNCkhpIEFuZHkNCg0KSSB3b24ndCBvYmpl Y3QgdG8gdGhlIGludHJvZHVjdGlvbiBvZiBuYW1lcyB3aXRoaW4gQ29NSSBpZiBzb21lb25lIHRh a2VzIHRoZSBsZWFkIHRvIGludHJvZHVjZSBpdC4NCg0KSG93ZXZlciwgSSB3YW50IHRvIHNheSB0 aGF0IG5hbWVzIGNhbiBiZSBlcnJvci1wcm9uZSBhbHNvLg0KU2ltaWxhciBhcyBTSUQsIG5hbWVz IHJlbHkgb24gYSByZWdpc3RyeSBvZiBmaWxlcyAoaS5lLiB5YW5nIGZpbGVzKSB0byBlbmFibGUg ZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyB0byBzaGFyZSB0aGUgc2FtZSBzZXQgb2YgaWRlbnRp ZmllcnMuDQpDb25zaWRlcmluZyB0aGF0IFNJRCByZWdpc3RyaWVzIGNhbiBhdXRvbWF0aWNhbGx5 IGRldGVjdCBhbnkgbWlzdXNlIG9yIGR1cGxpY2F0ZSB1c2Ugb2YgU0lEcywgSSBkb24ndCBzZWUg dGhlIGluY3JlbWVudGFsIHJpc2suDQoNCg0KSSBkbyBub3QgYWdyZWUuDQpDdXJyZW50bHksIGl0 IGlzIElNUE9TU0lCTEUgdG8gY3JlYXRlIGEgWUFORyBtb2R1bGUgZm9yIHdoaWNoIGFuDQppbnN0 YW5jZSBkb2N1bWVudCBjYW5ub3QgYmUgMTAwJSBjb3JyZWN0bHkgZW5jb2RlZCBhbmQgZGVjb2Rl ZCB1c2luZyBYTUwgb3IgSlNPTi4NClRoaXMgaXMgbm90IHRoZSBjYXNlIHdpdGggWUFORyB0byBD Qk9SIGF0IGFsbC4gIERldmVsb3BlcnMgbmVlZCBzcGVjaWFsIHRvb2xzIHRvDQpjaGVjayB0aGUg WUFORyBtb2R1bGUgdG8gbWFrZSBzdXJlIGl0IGRvZXMgbm90IGNvbnRhaW4gY2VydGFpbiB1bmlv biB0eXBlcy4NCklmIGl0IGRvZXMsIHRoZSBZQU5HIG1vZHVsZSBtdXN0IGJlIGNoYW5nZWQgb3Ig bm90IHVzZWQgYXQgYWxsLg0KDQpBbHNvLCBZQU5HIHVwZGF0ZXMgYWxsb3cgc3RhdGVtZW50cyB0 byBiZSBtb3ZlZCBhbmQgYWx0ZXJlZCBpbiBtYW55IHdheXMuDQpOb25lIG9mIHRoZXNlIGNoYW5n ZXMgaW1wYWN0IHRoZSBYTUwgb3IgSlNPTiBlbmNvZGluZyBhdCBhbGwsIGJ1dCB0aGV5IGRvDQph ZmZlY3QgQ0JPUi4gIEl0IGlzIGNyaXRpY2FsIHRvIG1haW50YWluIHByZXZpb3VzIFNJRCBhc3Np Z25tZW50cy4NCllBTkcgaWRlbnRpZmllcnMgZG8gbm90IGhhdmUgdG8gYmUgbG9uZy4gVGhleSBj YW4gYmUgMSBieXRlIGlmIHlvdSB3YW50Lg0KWUFORyBtb2R1bGVzIGZvciBjb25zdHJhaW5lZCBk ZXZpY2VzIGNhbiB1c2Ugc2hvcnQgaWRlbnRpZmllcnMuDQpTaW5jZSBYTUwgYW5kIEpTT04gYXJl IGhpZXJhcmNoaWNhbCwgdGhlIGlkZW50aWZpZXIgbGVuZ3RoIGlzIGFjdHVhbGx5DQp0aGUgbm9k ZSBuYW1lIGxlbmd0aCAoZS5nLiwgJ25hbWUnKSBub3QgdGhlIGZ1bGwgcGF0aCBzdHJpbmcgZnJv bSByb290DQooZS5nLiAvaW50ZXJmYWNlcy9pbnRlcmZhY2UvbmFtZSkuDQoNCg0KQW5keQ0KDQoN CkkgYWxzbyB3YW50IHRvIG1lbnRpb24gdGhhdCB0aGUgdXNlIG9mIGJpbmFyeSBpZGVudGlmaWVy IGlzIG5vdCBhIG5ldyBvciBleHBlcmltZW50YWwgY29uY2VwdC4gSXQgaGF2ZSBiZWVuIHVzZWQg aW4gZGlmZmVyZW50IHByb3RvY29scyB3aXRoIHN1Y2Nlc3MgZm9yIGRlY2FkZXMuDQoNClJlZ2Fy ZHMsDQpNaWNoZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNvcmUgW21h aWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNvcmUtYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBDYXJzdGVuIEJvcm1hbm4NClNlbnQ6IEZyaWRheSwgSnVseSAyMSwgMjAx NyA4OjE1IEFNDQpUbzogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFu ZHlAeXVtYXdvcmtzLmNvbT4+DQpDYzogQ29yZSA8Y29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2NvcmVdIHlhbmcgY2JvciBlbmNvZGluZyB3aXRob3V0 IFNJRA0KDQpPbiBKdWwgMjEsIDIwMTcsIGF0IDA3OjU4LCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVt YXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4gd3JvdGU6DQo+DQo+IEkgYWdy ZWUgd2l0aCBKdWVyZ2VuIHRoYXQgQ29NSSB3aXRob3V0IFNJRCBpcyBhIG11Y2ggYmV0dGVyIHNv bHV0aW9uIGZvciBuZXR3b3JrIG1hbmFnZW1lbnQuDQoNCkZvciBjbGFzcy0xMCsgKCopLCB0ZXh0 IHN0cmluZyBpZGVudGlmaWVycyBhcmUgZmluZS4gIFlhbmctY2JvciBpcyBuZXV0cmFsIG9uIHRo aXMgcXVlc3Rpb24uDQoNCkNPTUkgZGVmaW5lcyBhIG51bWJlciBvZiBtZWRpYSB0eXBlcywgYW5k IHRoZXNlIGFyZSByaWdodCBub3cgdXNpbmcgWWFuZy1jYm9yIHdpdGggU0lEcy4gIE1heWJlIHdl IHNob3VsZCBqdXN0IGRlZmluZSBhbm90aGVyIHNldCBvZiBtZWRpYSB0eXBlcyB3aXRoIHRleHQg c3RyaW5nIGlkZW50aWZpZXJzPyAgQWZ0ZXIgYWxsLCBDT01JIGlzIHVzZWQgaW4gdGhlIENvUkUg ZW52aXJvbm1lbnQgd2hlcmUgd2UgY2FuIHVzZSBtZWRpYSB0eXBlcy4NCg0KR3LDvMOfZSwgQ2Fy c3Rlbg0KDQooKikgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvcm1hbm4tbHdp Zy03MjI4YmlzLTAxI3NlY3Rpb24tMw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KY29yZSBtYWlsaW5nIGxpc3QNCmNvcmVAaWV0Zi5vcmc8bWFpbHRv OmNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv cmUNCg0K --_000_MWHPR06MB2317092747A52FB815570C7DFEA40MWHPR06MB2317namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBBbmR5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QWJvdXQgdGhlIHVuaW9uLCB0aGUgQ0JPUiBlbmNv ZGluZyBhdm9pZCBhbnkgYW1iaWd1aXRpZXMgYmV0d2VlbiBkYXRhdHlwZXMsIHNvbWV0aGluZyBu b3QgYXJjaGl2ZWQgYnkgdGhlIHhtbCBtYXBwaW5nIGFuZCBwYXJ0aWFsbHkgYXJjaGl2ZWQgYnkg SlNPTi4gRm9yIGV4YW1wbGUsDQogaW4geG1sLCBpdCBpcyBpbXBvc3NpYmxlIHRvIGRpZmZlcmVu dGlhdGUgdGhlIHN0cmluZyAmcXVvdDsxJnF1b3Q7IGZyb20gdGhlIGludGVnZXIgMS4gVGhlIG9u bHkgYW1iaWd1aXRpZXMgbm90IHJlc29sdmVkIGJ5IHRoZSBDQk9SIGVuY29kaW5nIGlzIGFuIHVu aW9uIGNvbXBvc2VkIG9mIHR3byBlbnVtZXJhdGlvbnMgZGVmaW5pbmcgdGhlIHNhbWUgdmFsdWUg YXNzb2NpYXRlZCB0byBkaWZmZXJlbnQgbWVhbmluZ3MuIEkgd2lsbCBhcmd1ZSB0aGF0IHN1Y2gg ZGVmaW5pdGlvbg0KIGlzIGluY29ycmVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5BYm91dCB5b3VyIHNlY29uZCBwb2ludCwgaWYgdGhlIEpTT04gZW5jb2Rpbmcg aXMgbm90IGltcGFjdGVkLCBJIGRvbid0IHNlZSB3aHkgU0lEIHdpbGwgYmUgaW1wYWN0ZWQuIEFz IHlvdSBzYWlkIHllc3RlcmRheSwgU0lEcyBpcyBhIHNpbXBsZSBtYXBwaW5nIGJldHdlZW4gSlNP Tg0KIHBhdGhzIGFuZCBudW1lcmljIElEcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1pY2hlbDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFuZHkg Qmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBG cmlkYXksIEp1bHkgMjEsIDIwMTcgOTo1NiBBTTxicj4NCjxiPlRvOjwvYj4gTWljaGVsIFZlaWxs ZXR0ZSAmbHQ7TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gQ2Fyc3RlbiBCb3JtYW5uICZsdDtjYWJvQHR6aS5vcmcmZ3Q7OyBDb3JlICZsdDtjb3Jl QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2NvcmVdIHlhbmcgY2JvciBl bmNvZGluZyB3aXRob3V0IFNJRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSnVs IDIwLCAyMDE3IGF0IDExOjU2IFBNLCBNaWNoZWwgVmVpbGxldHRlICZsdDs8YSBocmVmPSJtYWls dG86TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWlj aGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5IaSBBbmR5PGJyPg0KPGJyPg0KSSB3b24ndCBvYmplY3QgdG8gdGhlIGludHJv ZHVjdGlvbiBvZiBuYW1lcyB3aXRoaW4gQ29NSSBpZiBzb21lb25lIHRha2VzIHRoZSBsZWFkIHRv IGludHJvZHVjZSBpdC48YnI+DQo8YnI+DQpIb3dldmVyLCBJIHdhbnQgdG8gc2F5IHRoYXQgbmFt ZXMgY2FuIGJlIGVycm9yLXByb25lIGFsc28uPGJyPg0KU2ltaWxhciBhcyBTSUQsIG5hbWVzIHJl bHkgb24gYSByZWdpc3RyeSBvZiBmaWxlcyAoaS5lLiB5YW5nIGZpbGVzKSB0byBlbmFibGUgZGlm ZmVyZW50IGltcGxlbWVudGF0aW9ucyB0byBzaGFyZSB0aGUgc2FtZSBzZXQgb2YgaWRlbnRpZmll cnMuPGJyPg0KQ29uc2lkZXJpbmcgdGhhdCBTSUQgcmVnaXN0cmllcyBjYW4gYXV0b21hdGljYWxs eSBkZXRlY3QgYW55IG1pc3VzZSBvciBkdXBsaWNhdGUgdXNlIG9mIFNJRHMsIEkgZG9uJ3Qgc2Vl IHRoZSBpbmNyZW1lbnRhbCByaXNrLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCBhZ3JlZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkN1cnJlbnRseSwgaXQgaXMg SU1QT1NTSUJMRSB0byBjcmVhdGUgYSBZQU5HIG1vZHVsZSBmb3Igd2hpY2ggYW48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluc3RhbmNlIGRvY3Vt ZW50IGNhbm5vdCBiZSAxMDAlIGNvcnJlY3RseSBlbmNvZGVkIGFuZCBkZWNvZGVkIHVzaW5nIFhN TCBvciBKU09OLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhpcyBpcyBub3QgdGhlIGNhc2Ugd2l0aCBZQU5HIHRvIENCT1IgYXQgYWxsLiZuYnNw OyBEZXZlbG9wZXJzIG5lZWQgc3BlY2lhbCB0b29scyB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2hlY2sgdGhlIFlBTkcgbW9kdWxlIHRvIG1h a2Ugc3VyZSBpdCBkb2VzIG5vdCBjb250YWluIGNlcnRhaW4gdW5pb24gdHlwZXMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBpdCBkb2VzLCB0 aGUgWUFORyBtb2R1bGUgbXVzdCBiZSBjaGFuZ2VkIG9yIG5vdCB1c2VkIGF0IGFsbC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgWUFO RyB1cGRhdGVzIGFsbG93IHN0YXRlbWVudHMgdG8gYmUgbW92ZWQgYW5kIGFsdGVyZWQgaW4gbWFu eSB3YXlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Tm9uZSBvZiB0aGVzZSBjaGFuZ2VzIGltcGFjdCB0aGUgWE1MIG9yIEpTT04gZW5jb2Rpbmcg YXQgYWxsLCBidXQgdGhleSBkbzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+YWZmZWN0IENCT1IuJm5ic3A7IEl0IGlzIGNyaXRpY2FsIHRvIG1haW50 YWluIHByZXZpb3VzIFNJRCBhc3NpZ25tZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllBTkcgaWRlbnRpZmllcnMgZG8gbm90IGhhdmUgdG8g YmUgbG9uZy4gVGhleSBjYW4gYmUgMSBieXRlIGlmIHlvdSB3YW50LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WUFORyBtb2R1bGVzIGZvciBjb25z dHJhaW5lZCBkZXZpY2VzIGNhbiB1c2Ugc2hvcnQgaWRlbnRpZmllcnMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZSBYTUwgYW5kIEpTT04g YXJlIGhpZXJhcmNoaWNhbCwgdGhlIGlkZW50aWZpZXIgbGVuZ3RoIGlzIGFjdHVhbGx5PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgbm9kZSBu YW1lIGxlbmd0aCAoZS5nLiwgJ25hbWUnKSBub3QgdGhlIGZ1bGwgcGF0aCBzdHJpbmcgZnJvbSBy b290PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4o ZS5nLiAvaW50ZXJmYWNlcy9pbnRlcmZhY2UvbmFtZSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyB3YW50IHRv IG1lbnRpb24gdGhhdCB0aGUgdXNlIG9mIGJpbmFyeSBpZGVudGlmaWVyIGlzIG5vdCBhIG5ldyBv ciBleHBlcmltZW50YWwgY29uY2VwdC4gSXQgaGF2ZSBiZWVuIHVzZWQgaW4gZGlmZmVyZW50IHBy b3RvY29scyB3aXRoIHN1Y2Nlc3MgZm9yIGRlY2FkZXMuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+ DQpNaWNoZWw8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IGNvcmUgW21haWx0bzo8YSBocmVmPSJtYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnIj5jb3Jl LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uPGJyPg0K U2VudDogRnJpZGF5LCBKdWx5IDIxLCAyMDE3IDg6MTUgQU08YnI+DQpUbzogQW5keSBCaWVybWFu ICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5j b208L2E+Jmd0Ozxicj4NCkNjOiBDb3JlICZsdDs8YSBocmVmPSJtYWlsdG86Y29yZUBpZXRmLm9y ZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KU3ViamVjdDogUmU6IFtjb3JlXSB5YW5nIGNi b3IgZW5jb2Rpbmcgd2l0aG91dCBTSUQ8YnI+DQo8YnI+DQpPbiBKdWwgMjEsIDIwMTcsIGF0IDA3 OjU4LCBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20i PmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IEkg YWdyZWUgd2l0aCBKdWVyZ2VuIHRoYXQgQ29NSSB3aXRob3V0IFNJRCBpcyBhIG11Y2ggYmV0dGVy IHNvbHV0aW9uIGZvciBuZXR3b3JrIG1hbmFnZW1lbnQuPGJyPg0KPGJyPg0KRm9yIGNsYXNzLTEw JiM0MzsgKCopLCB0ZXh0IHN0cmluZyBpZGVudGlmaWVycyBhcmUgZmluZS4mbmJzcDsgWWFuZy1j Ym9yIGlzIG5ldXRyYWwgb24gdGhpcyBxdWVzdGlvbi48YnI+DQo8YnI+DQpDT01JIGRlZmluZXMg YSBudW1iZXIgb2YgbWVkaWEgdHlwZXMsIGFuZCB0aGVzZSBhcmUgcmlnaHQgbm93IHVzaW5nIFlh bmctY2JvciB3aXRoIFNJRHMuJm5ic3A7IE1heWJlIHdlIHNob3VsZCBqdXN0IGRlZmluZSBhbm90 aGVyIHNldCBvZiBtZWRpYSB0eXBlcyB3aXRoIHRleHQgc3RyaW5nIGlkZW50aWZpZXJzPyZuYnNw OyBBZnRlciBhbGwsIENPTUkgaXMgdXNlZCBpbiB0aGUgQ29SRSBlbnZpcm9ubWVudCB3aGVyZSB3 ZSBjYW4gdXNlIG1lZGlhIHR5cGVzLjxicj4NCjxicj4NCkdyw7zDn2UsIENhcnN0ZW48YnI+DQo8 YnI+DQooKikgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvcm1h bm4tbHdpZy03MjI4YmlzLTAxI3NlY3Rpb24tMyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvcm1hbm4tbHdpZy03MjI4YmlzLTAxI3NlY3Rpb24t MzwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCmNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmNvcmVA aWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR06MB2317092747A52FB815570C7DFEA40MWHPR06MB2317namp_-- From nobody Fri Jul 21 01:27:05 2017 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 873F112EC51 for ; Fri, 21 Jul 2017 01:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7, 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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAQLTpNz8NVM for ; Fri, 21 Jul 2017 01:27:03 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 D4FCE12778D for ; Fri, 21 Jul 2017 01:27:02 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id l81so1948324wmg.1 for ; Fri, 21 Jul 2017 01:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OKM1ckNalGyALcvBtaEBarJyZz1ZZJiLbcLBC/tG7eU=; b=dszuFOml0My3NQymLFKI+anqCyNoTmZajdBgW0RQjgjSM6UtrjS7TSS8Zwj/fm+2kW JvVRorGowGLVZbGVqmHaseUhmjk6RlCgY7t8ar5fSyfrZMOwqX+d9x+dZZSfW0RoPzXS qc91rxrFgAptS1DNd6BRQx5hU/JIMgcgD+Ls7/HqXRxq2ubxdnjzSmkj5XTdb905Ypc8 mHqGs2wdfR8Wvbr36Dw90D57Uv4beIsQqaB/Yy0y0BHSdTJtFHmGvSdftR8aMDN0QsoD vR636X47yk6OktOB3VF/dsGVFd5sl0nFkRgETkmkapfKDk1M7CxhmAh214VRZboiR361 Hztg== 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=OKM1ckNalGyALcvBtaEBarJyZz1ZZJiLbcLBC/tG7eU=; b=JkTuZlC2Y6AoZsJrb2IVVZPsmE8t+3U10U6vuTW1zjsyXGIRIEfzeho9w+k+pNxIen +RStB1W1lGjv0yHjbmzjFE608mpllgN2e5CkOhtiB4hih4n1rGtN+vkvvcUHeNwFCb4/ N/30jqpizgRIwGFLqrTkbo6g1rRq0LFv2Rf46dlw7L3PyZLl1RgMfqVLNQkBggbYZLC7 btgzPM5b09Z2HqDiOBSGW6XrZQRbqSFDHivykMFmjyx8d1GYpKuAK7FGDUT3O41p0Gvb mUYeNgyeDvX7x0jQz2zoyYpO6YrX6Qh/zL/zoNU/8KART0BMfPP1/S+HiX66EUrPQPlx trqA== X-Gm-Message-State: AIVw113nKM0nOj8Q7vO/8bZkKlzOjvvlfFXPS81uLxu9o7bGQsoziZYJ VPLUCrK+FS992c/5VLQ0utexU0IhoNAg X-Received: by 10.28.13.138 with SMTP id 132mr4205766wmn.23.1500625621419; Fri, 21 Jul 2017 01:27:01 -0700 (PDT) MIME-Version: 1.0 References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <7A58CD49-AC30-45DF-8C91-1ADFC9422C0D@tzi.org> In-Reply-To: <7A58CD49-AC30-45DF-8C91-1ADFC9422C0D@tzi.org> From: Andy Bierman Date: Fri, 21 Jul 2017 08:26:50 +0000 Message-ID: To: Carsten Bormann , Juergen Schoenwaelder Cc: core@ietf.org Content-Type: multipart/alternative; boundary="001a11444c121b28690554cfa111" Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 08:27:04 -0000 --001a11444c121b28690554cfa111 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think a good compromise would be to: 1) continue CoMI with SID as planned 2) create 2 different YANG to CBOR media types 3) RESTCONF can use the unoptimized media type 4) CoMI can use the optimized media type Andy On Fri, Jul 21, 2017 at 10:13 Carsten Bormann wrote: > On Jul 20, 2017, at 11:40, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > OK. This limits COMI applicability to constrained devices in the sense > > of a few 100k of memory or devices living on rather limited links. > > Not being affluent in memory may be one reason to use a constrained > management solution; another reason may be not being affluent in bandwidt= h > (or in total energy). The third reason may be wanting to stay compatible > with nodes that are in one of these two situations. In other words: I > don=E2=80=99t think the above mentioned limit in applicability really exi= sts; you > don=E2=80=99t have to abandon COMI as soon as you add some memory. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --001a11444c121b28690554cfa111 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think a good compromise would be to:
1) =C2=A0continue CoMI with SID as planned
2) create 2 different YANG to CBOR media types
3) R= ESTCONF can use the unoptimized media type
4) CoMI c= an use the optimized media type

Andy


On Fri, Jul 21, 2017 at 10:13 Carsten Bormann <cabo@tzi.org> wrote:
On Jul 20, 2017, at 11:40, Juergen Schoenwaelder <j.schoenwaelde= r@jacobs-university.de> wrote:
>
> OK. This limits COMI applicability to constrained devices in the sense=
> of a few 100k of memory or devices living on rather limited links.

Not being affluent in memory may be one reason to use a constrained managem= ent solution; another reason may be not being affluent in bandwidth (or in = total energy).=C2=A0 The third reason may be wanting to stay compatible wit= h nodes that are in one of these two situations.=C2=A0 In other words: I do= n=E2=80=99t think the above mentioned limit in applicability really exists;= you don=E2=80=99t have to abandon COMI as soon as you add some memory.

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

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core
--001a11444c121b28690554cfa111-- From nobody Fri Jul 21 01:40:31 2017 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 327C112EC51 for ; Fri, 21 Jul 2017 01:40:29 -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 i9xyIdKS1V18 for ; Fri, 21 Jul 2017 01:40:28 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 1CDC8129B55 for ; Fri, 21 Jul 2017 01:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6L8eP3b016834; Fri, 21 Jul 2017 10:40:25 +0200 (CEST) Received: from dhcp-808c.meeting.ietf.org (dhcp-808c.meeting.ietf.org [31.133.128.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xDPNT2tr5z3ZMZ; Fri, 21 Jul 2017 10:40:25 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Fri, 21 Jul 2017 10:40:24 +0200 Cc: Juergen Schoenwaelder , core@ietf.org X-Mao-Original-Outgoing-Id: 522319224.64699-9782aab666786f4eaf0f43b5d48671b2 Content-Transfer-Encoding: quoted-printable Message-Id: <76A63D9C-5BA5-41CF-B209-16D78927569F@tzi.org> References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <7A58CD49-AC30-45DF-8C91-1ADFC9422C0D@tzi.org> To: Andy Bierman X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 08:40:29 -0000 On Jul 21, 2017, at 10:26, Andy Bierman wrote: >=20 > I think a good compromise would be to: Let me try to rephrase this (I don=E2=80=99t even think this would be a = =E2=80=9Ccompromise=E2=80=9D): > 1) continue CoMI with SID as planned +1 > 2) create 2 different YANG to CBOR media types This would be two sets of media types, one expecting SID support and one = expecting the string identifiers to be known. (Is there a need for mixing? Not sure.) > 3) RESTCONF can use the unoptimized media type > 4) CoMI can use the optimized media type This would be what we would expect to be supported (MTI). =20 Since this is REST, either could also support the other set of media = types. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 21 02:02:09 2017 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 E231912F274 for ; Fri, 21 Jul 2017 02:02:06 -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 3_LsSNF8kyFl for ; Fri, 21 Jul 2017 02:02:05 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 97455131456 for ; Fri, 21 Jul 2017 02:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6L91u7D004208; Fri, 21 Jul 2017 11:01:56 +0200 (CEST) Received: from dhcp-808c.meeting.ietf.org (dhcp-808c.meeting.ietf.org [31.133.128.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xDPsJ5wWPz3ZMw; Fri, 21 Jul 2017 11:01:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Fri, 21 Jul 2017 11:01:56 +0200 Cc: Andy Bierman , Core X-Mao-Original-Outgoing-Id: 522320516.295486-cc94a616f5fa9c2c07da2301d167988e Content-Transfer-Encoding: quoted-printable Message-Id: <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> To: Michel Veillette X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 09:02:07 -0000 > On Jul 21, 2017, at 10:17, Michel Veillette = wrote: >=20 > Hi Andy > =20 > About the union, the CBOR encoding avoid any ambiguities between = datatypes, something not archived by the xml mapping and partially = archived by JSON. For example, in xml, it is impossible to differentiate = the string "1" from the integer 1. I think Andy=E2=80=99s point is that the serialization idiosyncrasies = that leak into YANG are at this point well-known if it is the = idiosyncrasies from the XML serialization (which have been maintained = quite well in the JSON serialization, too) but not so for the CBOR = serialization. With some effort, it is possible to write YANG that = exposes these idiosyncrasies: > The only ambiguities not resolved by the CBOR encoding is an union = composed of two enumerations defining the same value associated to = different meanings. I will argue that such definition is incorrect. Not sure that is the only case, but it still is a case. Right now, the = YANG tools don=E2=80=99t know about these cases yet. So having, say, a = pyang extension that tests for this might be a useful thing to have. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 21 02:36:09 2017 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 542B212ECB4 for ; Fri, 21 Jul 2017 02:36:07 -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, RP_MATCHES_RCVD=-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 5r2xrkZkrMfY for ; Fri, 21 Jul 2017 02:36:05 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BDF127869 for ; Fri, 21 Jul 2017 02:36:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8D08D8D; Fri, 21 Jul 2017 11:36:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ilkXWTcNWoeS; Fri, 21 Jul 2017 11:35:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 21 Jul 2017 11:36:01 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C00A200AD; Fri, 21 Jul 2017 11:36:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hADwZzjsM-D8; Fri, 21 Jul 2017 11:36:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E663B200AA; Fri, 21 Jul 2017 11:36:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D87E93FF872C; Fri, 21 Jul 2017 11:35:59 +0200 (CEST) Date: Fri, 21 Jul 2017 11:35:59 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Core Message-ID: <20170721093559.GA22027@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Core References: <20170720083313.GA20950@elstar.local> <20170720094718.GG20950@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [core] comi and NMDA (configuration and operational state datastore) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 09:36:07 -0000 On Thu, Jul 20, 2017 at 06:57:32PM -0700, Andy Bierman wrote: > On Thu, Jul 20, 2017 at 2:47 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > Hi, > > > > well, I am trying to understand what the scope of CoMI is. If CoMI is > > only for ~100k memory devices, you may be right. > > > > > IMO the NMDA stuff is only interesting if the device includes some sort of > dynamic configuration datastores (extremely unlikely). But in case I am > wrong, > CoMI provides full access to operation resources, so NETCONF operations > such as and can be used if really needed. > > A few obvious problems with using a multi-step editing process is that it > is not REST-full at all, it requires locking, it requires lock recovery > when the client goes away with outstanding locks, and it requires that > the client support lots of different server transaction models (i.e., > just as heavyweight as NETCONF, but much harder without any session-based > interaction model). > > We should be trying to make CoMI as simple as possible, not a binary > NETCONF. Exactly. You do not want to use NETCONF operations and hence be able to expose multiple datastores as different resources, as proposed for RESTCONF. My point is that YANG data models move towards NMDA and hence having and exposed become an issue. Well, if CoMI is only for 100k devices, then probably not. The question for me really is whether CoMI targets a very narrow target market (these ~100k memory constrained devices) while embedded devices capable to run embedded Unix flavours will simply do RESTCONF. (I personally believe this is the most likely scenario; and I personally believe many of the 100k devices will likely do something like mud, i.e., pulling a config from a server, and not expose a real management interface.) If so, what is the market for CoMI? Perhaps CoMI has a market if application data is communicated with it, i.e., a device pulls its config etc from a server and afterwards ships application data that is defined in YANG via CoMI (in which case CoMI is kind of a misnomer). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jul 21 02:51:33 2017 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 A3DD312EB2B for ; Fri, 21 Jul 2017 02:51:31 -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, RP_MATCHES_RCVD=-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 kci-AH8R14sD for ; Fri, 21 Jul 2017 02:51:30 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450CD127869 for ; Fri, 21 Jul 2017 02:51:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 140396C5; Fri, 21 Jul 2017 11:51:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 1VYysVK2sNdB; Fri, 21 Jul 2017 11:51:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 21 Jul 2017 11:51:28 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C52DA200A8; Fri, 21 Jul 2017 11:51:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ECsfPDCGDa4b; Fri, 21 Jul 2017 11:51:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 915B4200AD; Fri, 21 Jul 2017 11:51:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 64A303FF89B6; Fri, 21 Jul 2017 11:51:27 +0200 (CEST) Date: Fri, 21 Jul 2017 11:51:27 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: Andy Bierman , Core Message-ID: <20170721095127.GC22027@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , Andy Bierman , Core References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 09:51:31 -0000 On Fri, Jul 21, 2017 at 08:14:38AM +0200, Carsten Bormann wrote: > > COMI defines a number of media types, and these are right now using Yang-cbor with SIDs. Maybe we should just define another set of media types with text string identifiers? After all, COMI is used in the CoRE environment where we can use media types. > Having separate media types would clearly help. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jul 21 02:55:30 2017 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 1CD99131456 for ; Fri, 21 Jul 2017 02:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 q7LHo3uGG6ph for ; Fri, 21 Jul 2017 02:55:27 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A27127869 for ; Fri, 21 Jul 2017 02:55:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9241AF71; Fri, 21 Jul 2017 11:55:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ykEBVaBjfJaP; Fri, 21 Jul 2017 11:55:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 21 Jul 2017 11:55:25 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 70740200AD; Fri, 21 Jul 2017 11:55:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OfPcrCoAjHWF; Fri, 21 Jul 2017 11:55:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 191E3200AA; Fri, 21 Jul 2017 11:55:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E509A3FF89F9; Fri, 21 Jul 2017 11:55:24 +0200 (CEST) Date: Fri, 21 Jul 2017 11:55:24 +0200 From: Juergen Schoenwaelder To: Michel Veillette Cc: Carsten Bormann , Andy Bierman , Core Message-ID: <20170721095524.GD22027@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michel Veillette , Carsten Bormann , Andy Bierman , Core References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 09:55:28 -0000 On Fri, Jul 21, 2017 at 06:56:03AM +0000, Michel Veillette wrote: > > However, I want to say that names can be error-prone also. > Similar as SID, names rely on a registry of files (i.e. yang files) to enable different implementations to share the same set of identifiers. > Considering that SID registries can automatically detect any misuse or duplicate use of SIDs, I don't see the incremental risk. > Michel, Andy and I have many years of MIB doctor and YANG doctor experience and getting people to write reasonably correct modules is already hard. Getting multiple organizations to maintain a global unique number space for all YANG identifiers where everybody fully understands the rules (a number once assigned is never allowed to change) is from my own experience a non-starter. But, if people believe this is doable, go for it - as long as there are ways to fall back to an encoding that does not require this global number space to work I am fine to let people run the experiement and collect their own experience. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jul 21 03:08:17 2017 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 90E58127869 for ; Fri, 21 Jul 2017 03:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.262 X-Spam-Level: X-Spam-Status: No, score=0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telecom-bretagne.eu 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 jBByQkCdRqQ5 for ; Fri, 21 Jul 2017 03:08:13 -0700 (PDT) Received: from smtp1.enst.fr (smtp1.enst.fr [137.194.2.138]) by ietfa.amsl.com (Postfix) with ESMTP id 87BA91277BB for ; Fri, 21 Jul 2017 03:08:13 -0700 (PDT) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.2.193]) by smtp1.enst.fr (Postfix) with ESMTP id 7715C215E7 for ; Fri, 21 Jul 2017 12:08:09 +0200 (CEST) Authentication-Results: smtp1.enst.fr; dkim=pass reason="1024-bit key; unprotected key" header.d=telecom-bretagne.eu header.i=@telecom-bretagne.eu header.b=UYR166mh; dkim-adsp=pass; dkim-atps=neutral Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 711B210097E for ; Fri, 21 Jul 2017 12:08:09 +0200 (CEST) Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id mBF4GEKHMpvz for ; Fri, 21 Jul 2017 12:08:09 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id EA677100A01 for ; Fri, 21 Jul 2017 12:08:08 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 zproxy120.enst.fr EA677100A01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecom-bretagne.eu; s=CFDC2CFA-4654-11E5-AACD-7BCC68B6580D; t=1500631688; bh=PZq5/cjQ2jcSgQLXLWX/KAiODuegmTXwsA72YlMo6LQ=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=UYR166mhsF6/0rYTMK7Fr6jiz6TOMFMkr1/UUyZM5Yyp7VLlxHibhQ8v2rTWBVpqa dfIWIOYoUwdS+SdNURDAc54eb1rxTWPMwwncfDHFNmlciZifR9g7Uu0yvS853xjnKS xBIA/AK43IvqjPWkAI5dXNc0v7kJq1qxltzb9Czk= X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id 9O5YvSJg9cvz for ; Fri, 21 Jul 2017 12:08:08 +0200 (CEST) Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com [209.85.217.175]) by zproxy120.enst.fr (Postfix) with ESMTPSA id 9ED1010097E for ; Fri, 21 Jul 2017 12:08:08 +0200 (CEST) Received: by mail-ua0-f175.google.com with SMTP id 80so42015055uas.0 for ; Fri, 21 Jul 2017 03:08:08 -0700 (PDT) X-Gm-Message-State: AIVw113uPBzAcz3smNuhjoD3mvg8+qpoBpjVCM16Se5XWoz8tuCrScEq xzh9h1/VKL7MXikb8aYKRilHVJzgpg== X-Received: by 10.31.84.130 with SMTP id i124mr3500518vkb.41.1500631687302; Fri, 21 Jul 2017 03:08:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.33.183 with HTTP; Fri, 21 Jul 2017 03:07:26 -0700 (PDT) In-Reply-To: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <7A58CD49-AC30-45DF-8C91-1ADFC9422C0D@tzi.org> From: Laurent Toutain Date: Fri, 21 Jul 2017 12:07:26 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Andy Bierman Cc: Carsten Bormann , Juergen Schoenwaelder , "core@ietf.org WG" Content-Type: multipart/alternative; boundary="001a114e5bfca916f40554d10a7d" Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 10:08:15 -0000 --001a114e5bfca916f40554d10a7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 21, 2017 at 10:26 AM, Andy Bierman wrote: > I think a good compromise would be to: > 1) continue CoMI with SID as planned > +1 there is not only constrained device, there is also constrained network where names can be too long to be sent. > 2) create 2 different YANG to CBOR media types > may be a problem for interoperability > 3) RESTCONF can use the unoptimized media type > 4) CoMI can use the optimized media type > > Andy > > > On Fri, Jul 21, 2017 at 10:13 Carsten Bormann wrote: > >> On Jul 20, 2017, at 11:40, Juergen Schoenwaelder > university.de> wrote: >> > >> > OK. This limits COMI applicability to constrained devices in the sense >> > of a few 100k of memory or devices living on rather limited links. >> >> Not being affluent in memory may be one reason to use a constrained >> management solution; another reason may be not being affluent in bandwid= th >> (or in total energy). The third reason may be wanting to stay compatibl= e >> with nodes that are in one of these two situations. In other words: I >> don=E2=80=99t think the above mentioned limit in applicability really ex= ists; you >> don=E2=80=99t have to abandon COMI as soon as you add some memory. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> _______________________________________________ >> 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 > > --=20 Laurent Toutain +--- VoIP (recommended) ---+----------- T=C3=A9l=C3=A9com Bretagne --------= ---+ | Tel: +33 2 22 06 8156 | Tel: + 33 2 99 12 7026 | Visit : | Mob: +33 6 800 75 900 | | | Fax: +33 2 22 06 8445 | Fax: +33 2 99 12 7030 | http://class.touta.in | Laurent@Touta.in | Laurent.Toutain@Telecom-Bretagne.eu | +--------------------------+----------------------------------------+ --001a114e5bfca916f40554d10a7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 21, 2017 at 10:26 AM, Andy Bierman <andy@yumaworks.com> wrote:
I think a good compromise would be to:
1) =C2=A0co= ntinue CoMI with SID as planned

+1 there is not only constrained device, there is also constrained network= where names can be too long to be sent.
=C2=A0
2) create 2 different YANG to= CBOR media types

may be a prob= lem for interoperability
=C2=A0
3) RESTCONF can use the unoptimized media type
<= /blockquote>
4) CoMI c= an use the optimized media type

Andy


On Fri, Jul 21, 2017 at 10:13 Carsten Bormann <cabo@tzi.org> wrote:
<= /div>
On Jul 20, 2017, at 11:40, Juergen Scho= enwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>
> OK. This limits COMI applicability to constrained devices in the sense=
> of a few 100k of memory or devices living on rather limited links.

Not being affluent in memory may be one reason to use a constrained managem= ent solution; another reason may be not being affluent in bandwidth (or in = total energy).=C2=A0 The third reason may be wanting to stay compatible wit= h nodes that are in one of these two situations.=C2=A0 In other words: I do= n=E2=80=99t think the above mentioned limit in applicability really exists;= you don=E2=80=99t have to abandon COMI as soon as you add some memory.

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

_______________________________________________
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




--
Lau= rent Toutain=C2=A0
+--- VoIP (recommended) ---+-----= ------ T=C3=A9l=C3=A9com Bretagne -----------+
| Tel: +33 2 22 06 8156 = =C2=A0 =C2=A0| Tel: + 33 2 99 12 7026 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | Visit :
| Mob: +33 6 800 75 900 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Fax: +33 2 22 06 8445 =C2=A0 =C2=A0= | Fax: +33 2 99 12 7030 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0ht= tp://class.touta.in
| Laurent@Touta.in =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= Laurent.Toutain@Telecom-Bretagne.eu =C2=A0 =C2=A0|
+-------------------= -------+----------------------------------------+
<= /div>
--001a114e5bfca916f40554d10a7d-- From nobody Fri Jul 21 03:16:01 2017 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 06B311277BB for ; Fri, 21 Jul 2017 03:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkDe0331wMGG for ; Fri, 21 Jul 2017 03:15:57 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D395127337 for ; Fri, 21 Jul 2017 03:15:57 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:517a:b55:84e2:6264] (unknown [IPv6:2001:67c:370:128:517a:b55:84e2:6264]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 63460C5A70; Fri, 21 Jul 2017 12:15:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Alexander Pelov In-Reply-To: <20170721095524.GD22027@elstar.local> Date: Fri, 21 Jul 2017 12:15:52 +0200 Cc: Michel Veillette , Core Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <20170721095524.GD22027@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 10:16:00 -0000 Dear Juergen, all, We=E2=80=99ve had these discussions for some time now and I am very glad = that fresh eyeballs are looking at the problem.=20 At some point we=E2=80=99ve had both the =C2=AB name =C2=BB and SID in = the YANG-CBOR draft. The choice depends on the problem space you are = trying to address. We chose to have a pragmatic approach - solve at = least the problems of constrained devices and constrained networks. If you are having a NETCONF/RESTCONF server anyway, and just want an = efficient CBOR representation, then you could do it more simply than = following the YANG-CBOR draft. Get your JSON, convert to CBOR, then on = the receiver side convert back to JSON and process it.=20 The issue is when you want to address constrained devices, where you = DON=E2=80=99T want to keep string identifiers lying around in case = someone sends you a name. This is where things get more challenging - = and this is the question we=E2=80=99re solving here.=20 Yes, it is trivial to add item names as identifiers. I think that=E2=80=99= s exactly why we should not add them today. (we are not blocking any = future development - and all will remain perfectly compatible). Alexander =20 > Le 21 juil. 2017 =C3=A0 11:55, Juergen Schoenwaelder = a =C3=A9crit : >=20 > On Fri, Jul 21, 2017 at 06:56:03AM +0000, Michel Veillette wrote: >>=20 >> However, I want to say that names can be error-prone also. >> Similar as SID, names rely on a registry of files (i.e. yang files) = to enable different implementations to share the same set of = identifiers. >> Considering that SID registries can automatically detect any misuse = or duplicate use of SIDs, I don't see the incremental risk. >>=20 >=20 > Michel, >=20 > Andy and I have many years of MIB doctor and YANG doctor experience > and getting people to write reasonably correct modules is already > hard. Getting multiple organizations to maintain a global unique > number space for all YANG identifiers where everybody fully > understands the rules (a number once assigned is never allowed to > change) is from my own experience a non-starter. >=20 > But, if people believe this is doable, go for it - as long as there > are ways to fall back to an encoding that does not require this global > number space to work I am fine to let people run the experiement and > collect their own experience. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Fri Jul 21 03:18:42 2017 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 96ECF129B7F for ; Fri, 21 Jul 2017 03:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 g8Lfo2oNKgxe for ; Fri, 21 Jul 2017 03:18:38 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0091.outbound.protection.outlook.com [104.47.40.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82977129B40 for ; Fri, 21 Jul 2017 03:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zKaCXNaDdF4pFpsIgOw7t1By2hvcD9FkdgRnXCV0cTA=; b=awkIF4EQAVSLUseDczgWf12h/83jV3QV5guYubXCYXjMyLQSKWiEsky5EDeY3twx0wLSBgH/fSVfkVHMoEpOZuVRKA8irtkoSpqvijsqlD11K5foQ0b/FnhvN5kd0emEbESvL4S+HPxvYb2Wh4NWgm6weRa+doZKoAXDr73TEVA= Received: from MWHPR21MB0125.namprd21.prod.outlook.com (10.173.52.7) by MWHPR21MB0287.namprd21.prod.outlook.com (10.173.53.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.2; Fri, 21 Jul 2017 10:18:37 +0000 Received: from MWHPR21MB0125.namprd21.prod.outlook.com ([10.173.52.7]) by MWHPR21MB0125.namprd21.prod.outlook.com ([10.173.52.7]) with mapi id 15.01.1282.008; Fri, 21 Jul 2017 10:18:37 +0000 From: Dave Thaler To: "core@ietf.org" Thread-Topic: SenML units Thread-Index: AdMCClG7XNRJsTBaTJWRWMS4NICMqA== Date: Fri, 21 Jul 2017 10:18:36 +0000 Message-ID: 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=dthaler@microsoft.com; x-originating-ip: [2001:67c:370:128:1196:a030:bd86:d04e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0287; 7:iUx8vu+peI19GJ5nEXbZWN3qWz1lOO6RJ4gNgIF/aO+M/D4gMghlnM3netK19pNb6EiwbSzQodPPdF9bktQcN6CPPXEV32/VvOUHUmV++umCXWMDGpgZaAxCG1cZJleCkSXqPyoFIsHKW4SpSyd93QY+Aei+UxMAfN2MwaA5PvMKBZMUnH3/Nq2Il4mEp0nPHqvFyZzhfwYIMGKuHEY4o2QYL41gAyiuX/WaaJL5lc30VZQvPaDy+ay6M94BrLZdP0MQv7VJZ7b7SUxAzBVLgjlEm2DBCu4inunzQdgvqqtOQEQpkRK4OaeJpDa3e6q7sYFBTgISodMU1BSllzUdZibv0OA6uLg+msq7B01e5apB4iB9gU5ZQxrFfYbXJ53MIXREVpK243Es39mp4Ig/ZIeXoWEYHvMZa1XRKqresFtJMaX5S+RJo40DVBjdry7cBr2N8J1G5qDD3b+UFY9zb8QRLqeWjOZjljnndby9LE/ObA/Ahl4l34/IRDWKFd6WAyLy1cHJIpGghdREgyNT6+YxpZtzjqpQQZqnZgSJBhPHNOhJOPdWJ5zpOUbk4B7xsHiuwIXotfi8sl31Mf97oI+yha4nK7l7TutwvELmlztIUJmBB9iR5ntf3FcKE8oOfdWkqOuvBRNwDJtYL4eEQC1mHKDuZuFRIGL5DDd+V8gzZ7gQb27gcxPazkiL8AK1Asl1OlM9mkbM+ME30YFGnKkKfjV2XmXZsyPDjN/yx3nsdI2E1SYH4E4Vj0vx3hb+W7j700UYcrAT+mp8PlG9ATTDX1FpDYzhjs+gNd8cY9TSS2otqSCBD03rM66BqA3h x-ms-office365-filtering-correlation-id: db019593-56b7-4210-f86a-08d4d021d9c1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0287; x-ms-traffictypediagnostic: MWHPR21MB0287: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0287; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0287; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39850400002)(39410400002)(39400400002)(39860400002)(39450400003)(47760400005)(199003)(189002)(77096006)(2906002)(2501003)(7736002)(3480700004)(221733001)(97736004)(10090500001)(74316002)(236005)(6116002)(99286003)(6916009)(6506006)(14454004)(790700001)(606006)(6436002)(8936002)(55016002)(9686003)(6306002)(110136004)(8676002)(81166006)(81156014)(1730700003)(3660700001)(3280700002)(102836003)(5640700003)(38730400002)(966005)(53936002)(54896002)(478600001)(7696004)(8990500004)(5005710100001)(86362001)(7116003)(86612001)(50986999)(2351001)(10290500003)(54356999)(25786009)(106356001)(68736007)(105586002)(101416001)(5630700001)(189998001)(5660300001)(33656002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0287; H:MWHPR21MB0125.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0125705BF92F4807B0CCC977A3A40MWHPR21MB0125namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 10:18:37.1167 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0287 Archived-At: Subject: [core] SenML units X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 10:18:41 -0000 --_000_MWHPR21MB0125705BF92F4807B0CCC977A3A40MWHPR21MB0125namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to put on the list what I mentioned at the mic... https://tools.ietf.org/html/draft-ietf-core-senml-10#section-12.1 has: | K | kelvin | float | RFC-AAAA | | Cel | degrees Celsius | float | RFC-AAAA | The issue is that neither of the above have an asterisk by them, so both ar= e recommended and per Carsten's definition of "units" during the meeting (i.e., where the reference point i= s separate from the units), then Kelvin and Celsius have the same units as they only vary by what the refere= nce point is. During the meeting, Carsten and Ari agreed that one of them should have an = asterisk. Dave --_000_MWHPR21MB0125705BF92F4807B0CCC977A3A40MWHPR21MB0125namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just to put on the list what I mentioned at the mic&= #8230;

 

https://tools.ietf.org/html/draft-ietf-core-senml= -10#section-12.1 has:

|    &nb= sp;   K | kelvin        &= nbsp;           &nbs= p;        | float | RFC-AAAA  |

|      Cel | degrees Celsius  =
            &nb=
sp;     | float | RFC-AAAA  |

 


The issue is that neither of the above have an aster=
isk by them, so both are recommended and per Carsten’s


definition of “units” during the meeting=
 (i.e., where the reference point is separate from the units), then


Kelvin and Celsius have the same units as they only =
vary by what the reference point is.


 


During the meeting, Carsten and Ari agreed that one =
of them should have an asterisk.


 


Dave
--_000_MWHPR21MB0125705BF92F4807B0CCC977A3A40MWHPR21MB0125namp_-- From nobody Fri Jul 21 03:29:35 2017 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 37112127337 for ; Fri, 21 Jul 2017 03:29:25 -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, RP_MATCHES_RCVD=-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 P9Cn3ybfjZET for ; Fri, 21 Jul 2017 03:29:23 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20994129B40 for ; Fri, 21 Jul 2017 03:29:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DAC654C6; Fri, 21 Jul 2017 12:29:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id yq6o66jKrTFh; Fri, 21 Jul 2017 12:29:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 21 Jul 2017 12:29:21 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95527200AD; Fri, 21 Jul 2017 12:29:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JrtiKrzHsZnp; Fri, 21 Jul 2017 12:29:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DF24200A8; Fri, 21 Jul 2017 12:29:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9643F3FF8B47; Fri, 21 Jul 2017 12:29:19 +0200 (CEST) Date: Fri, 21 Jul 2017 12:29:19 +0200 From: Juergen Schoenwaelder To: Alexander Pelov Cc: Michel Veillette , Core Message-ID: <20170721102919.GA22212@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Alexander Pelov , Michel Veillette , Core References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <20170721095524.GD22027@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 10:29:25 -0000 On Fri, Jul 21, 2017 at 12:15:52PM +0200, Alexander Pelov wrote: > > If you are having a NETCONF/RESTCONF server anyway, and just want an efficient CBOR representation, then you could do it more simply than following the YANG-CBOR draft. Get your JSON, convert to CBOR, then on the receiver side convert back to JSON and process it. > So does the YANG-CBOR draft exist only so that we have SID? Or are there any other differences between [1] YANG->JSON->CBOR (RFC 7951 + RFC 7049 section 4) and [2] YANG->CBOR (draft-ietf-core-yang-cbor-04)? I understand that I can implement [1] without having to generate JSON first. Perhaps a discussion of this would be a nice addition to draft-ietf-core-yang-cbor-04. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jul 21 03:35:46 2017 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 98A5A129B7F for ; Fri, 21 Jul 2017 03:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 E16dn57ya6vF for ; Fri, 21 Jul 2017 03:35:43 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02FAB127337 for ; Fri, 21 Jul 2017 03:35:43 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:517a:b55:84e2:6264] (unknown [IPv6:2001:67c:370:128:517a:b55:84e2:6264]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 194ABA8112; Fri, 21 Jul 2017 12:35:39 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Alexander Pelov In-Reply-To: <20170721102919.GA22212@elstar.local> Date: Fri, 21 Jul 2017 12:35:38 +0200 Cc: Michel Veillette , Core Content-Transfer-Encoding: quoted-printable Message-Id: <8B8E067B-9572-4ACC-A0EB-2BAC32B8B4AD@ackl.io> References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <20170721095524.GD22027@elstar.local> <20170721102919.GA22212@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 10:35:45 -0000 See inline. > Le 21 juil. 2017 =C3=A0 12:29, Juergen Schoenwaelder = a =C3=A9crit : >=20 > On Fri, Jul 21, 2017 at 12:15:52PM +0200, Alexander Pelov wrote: >>=20 >> If you are having a NETCONF/RESTCONF server anyway, and just want an = efficient CBOR representation, then you could do it more simply than = following the YANG-CBOR draft. Get your JSON, convert to CBOR, then on = the receiver side convert back to JSON and process it.=20 >>=20 >=20 > So does the YANG-CBOR draft exist only so that we have SID? Or are > there any other differences between [1] YANG->JSON->CBOR (RFC 7951 + > RFC 7049 section 4) and [2] YANG->CBOR (draft-ietf-core-yang-cbor-04)? Differences exist. YANG-CBOR is more efficient than YANG->JSON->CBOR, = but definitely not on a scale that would be important for a 16 MB device = and a 200kbps+ network. What I=E2=80=99m saying is: if you don=E2=80=99t care that much for the = amount of data and the impact on the code on the end-device, then = YANG->JSON->CBOR is good enough. If you do care a lot for these things, then you will be willing to go an = extra mile. If you are doing YANG->JSON->CBOR you are not doing YANG->CBOR. You are = doing JSON->CBOR and it=E2=80=99s already in the CBOR RFC. Maybe = you=E2=80=99re right that we should add a paragraph for people that = don=E2=80=99t want to use SIDs. Alexander >=20 > I understand that I can implement [1] without having to generate JSON > first. Perhaps a discussion of this would be a nice addition to > draft-ietf-core-yang-cbor-04. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Jul 21 03:39:08 2017 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 9F979129B7F for ; Fri, 21 Jul 2017 03:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 uC2xZ1mJSHMG for ; Fri, 21 Jul 2017 03:39:04 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0099.outbound.protection.outlook.com [104.47.40.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68956127337 for ; Fri, 21 Jul 2017 03:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DXTW/fYUul3eDCFKSbPhwcwgtvUHXD6fiMG7gTMLOQQ=; b=smPDWbfJm+jLEiVzrCfvFNhGdsZFnUVtZJ86Kx28HGq4OncKB7EjYjzEKpni2uMScOUcqjXQGwoGdv16wDZ9y1Bcjauh/aclJ3GDw+jJkufViXPu2O9Xl7rpeyXz9BLTb8SRdxUfqPuv9DX4pZ6c5u//WYidaxKGea75fH52Gy4= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2306.namprd06.prod.outlook.com (10.173.19.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Fri, 21 Jul 2017 10:38:55 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.1282.016; Fri, 21 Jul 2017 10:38:55 +0000 From: Michel Veillette To: Juergen Schoenwaelder , "Alexander Pelov" CC: Core Thread-Topic: [core] yang cbor encoding without SID Thread-Index: AQHTATQrCEiVptWX80+aOopWb5cOWaJcaCuAgAAB64CAAAdyAIAABJeAgAFUMYCAAASKAIAABsVggAA26gCAAAW4AIAAA8KAgAABVnA= Date: Fri, 21 Jul 2017 10:38:55 +0000 Message-ID: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <20170721095524.GD22027@elstar.local> <20170721102919.GA22212@elstar.local> In-Reply-To: <20170721102919.GA22212@elstar.local> 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@trilliantinc.com; x-originating-ip: [31.133.142.211] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR06MB2306; 7:bhjyeG2asyjuIgngRekMNq/JlR2TYG+5BOhXvk4ynf6fEwjleGz/KeGFO/XGK1VbDYYtVgVrMCeoAKT6AM157gG7a1RI6rdRQn32VdlLZRY80euCFue3naYzuBNo39DjXC3NgwSmG7aAEdaH8OgmJ9PjazjuqJC2t8/fAO++6JZ6/u5f8mgIBDz+VTMgPNveHhPW86gp4HEPaBR5Xa4+PHfXVA5vanJ66Hhq5eNcG2FoFdd8CFIAPhwAKdbb5KbpnN4jwN88dwJt5ygn7fasTq4KR50Wbt3f4H30qOtdhzZS1AkI/POhuNigL0ZJNH45ZdTqANjKx9AYDC+lI6GoktOUytZTfvYem6RWu6NLacqAcRUUB59yHmlCUaH5ivTuyMe2NxMehfiZi5mFESdvSf70CPoKdvFX/agsIjpOtss/sVkWp8CoCV696WeeObK0GtD0fWkQq3gdHMiOurScIGWC8KQukUu5YsXRyd8J83UndA6btCJxpf89/aWF3h+smzRddnxLtOcHvOsYCEDleXct105CJqOrmvAPpHmW56YjPoreelozKJLE7VRvyjGvPe5AgvmiBHdv8Lr7/nclMLL56FGigbOEK+6QI7nXBeHivm7gUuxR+Spc+5gr1qsoVRXB0+kv4h3Go590kHndBwNwbyWSe+u+8vWIF81CW0rSPCa9Kr1S2acHY4wnOHasvfOlDD5P7UwBi94m7qu1Khp2QE+QvTTe+1tZE6g8QOXzH7MV3Szc/yEtgK1rpAO22vWhoHYPGKL34cpQpiRYy4Y1YygAxF2u+caJsI+sJQ4= x-ms-office365-filtering-correlation-id: 35e91ec9-d5a2-4791-b301-08d4d024afd5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR06MB2306; x-ms-traffictypediagnostic: BN6PR06MB2306: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR06MB2306; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR06MB2306; x-forefront-prvs: 0375972289 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39850400002)(39840400002)(39450400003)(199003)(189002)(377454003)(52314003)(13464003)(24454002)(2900100001)(6246003)(6306002)(7696004)(101416001)(3280700002)(93886004)(54356999)(3660700001)(76176999)(50986999)(97736004)(99286003)(6436002)(53936002)(68736007)(33656002)(14454004)(9686003)(53546010)(55016002)(2906002)(66066001)(38730400002)(25786009)(81166006)(6506006)(81156014)(478600001)(966005)(86362001)(2950100002)(8676002)(106356001)(5660300001)(102836003)(6116002)(3846002)(305945005)(105586002)(74316002)(8936002)(189998001)(72206003)(77096006)(7736002)(229853002)(4326008)(781001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2306; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2017 10:38:55.2809 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2306 Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 10:39:07 -0000 Hi Juergen, Hi Alexander I just want to mention that the following text relative to this topic is already present In the YANG to CBOR draft. https://tools.ietf.org/html/draft-ietf-core-yang-cbor-04#section-3 This specification supports two type of CBOR keys; YANG Schema Item iDentifier (SID) as defined in Section 2.1 and member names as defined in [RFC7951]. Each of these key types is encoded using a specific CBOR type which allows their interpretation during the deserialization process. The end user of this mapping specification (e.g. RESTCONF [RFC8040], CoMI [I-D.ietf-core-comi]) can mandate the use of a specific key type. Regards, Michel -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, July 21, 2017 12:29 PM To: Alexander Pelov Cc: Michel Veillette ; Core Subject: Re: [core] yang cbor encoding without SID On Fri, Jul 21, 2017 at 12:15:52PM +0200, Alexander Pelov wrote: >=20 > If you are having a NETCONF/RESTCONF server anyway, and just want an effi= cient CBOR representation, then you could do it more simply than following = the YANG-CBOR draft. Get your JSON, convert to CBOR, then on the receiver s= ide convert back to JSON and process it.=20 > So does the YANG-CBOR draft exist only so that we have SID? Or are there an= y other differences between [1] YANG->JSON->CBOR (RFC 7951 + RFC 7049 secti= on 4) and [2] YANG->CBOR (draft-ietf-core-yang-cbor-04)? I understand that I can implement [1] without having to generate JSON first= . Perhaps a discussion of this would be a nice addition to draft-ietf-core-= yang-cbor-04. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jul 21 03:48:35 2017 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 4622C12EB5D for ; Fri, 21 Jul 2017 03:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 9Vk5ectMxrQN for ; Fri, 21 Jul 2017 03:48:32 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8C2127337 for ; Fri, 21 Jul 2017 03:48:32 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:517a:b55:84e2:6264] (unknown [IPv6:2001:67c:370:128:517a:b55:84e2:6264]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id EC621C5A76; Fri, 21 Jul 2017 12:48:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Alexander Pelov In-Reply-To: Date: Fri, 21 Jul 2017 12:48:28 +0200 Cc: Juergen Schoenwaelder , Core Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <20170721095524.GD22027@elstar.local> <20170721102919.GA22212@elstar.local> To: Michel Veillette X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 10:48:34 -0000 Oh, thanks for the reminder, Michel ! I remember having long discussions on removing the member names from the = spec.. and then we had the decision to keep them and leave to the = implementers.=20 So, it=E2=80=99s solved then? Alexander > Le 21 juil. 2017 =C3=A0 12:38, Michel Veillette = a =C3=A9crit : >=20 > Hi Juergen, Hi Alexander >=20 > I just want to mention that the following text relative to this topic > is already present In the YANG to CBOR draft. >=20 > https://tools.ietf.org/html/draft-ietf-core-yang-cbor-04#section-3 >=20 > This specification supports two type of CBOR keys; YANG > Schema Item iDentifier (SID) as defined in Section 2.1 and member > names as defined in [RFC7951]. Each of these key types is encoded > using a specific CBOR type which allows their interpretation during > the deserialization process. The end user of this mapping > specification (e.g. RESTCONF [RFC8040], CoMI [I-D.ietf-core-comi]) > can mandate the use of a specific key type. >=20 > Regards, > Michel >=20 > -----Original Message----- > From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Friday, July 21, 2017 12:29 PM > To: Alexander Pelov > Cc: Michel Veillette ; Core = > Subject: Re: [core] yang cbor encoding without SID >=20 > On Fri, Jul 21, 2017 at 12:15:52PM +0200, Alexander Pelov wrote: >>=20 >> If you are having a NETCONF/RESTCONF server anyway, and just want an = efficient CBOR representation, then you could do it more simply than = following the YANG-CBOR draft. Get your JSON, convert to CBOR, then on = the receiver side convert back to JSON and process it.=20 >>=20 >=20 > So does the YANG-CBOR draft exist only so that we have SID? Or are = there any other differences between [1] YANG->JSON->CBOR (RFC 7951 + RFC = 7049 section 4) and [2] YANG->CBOR (draft-ietf-core-yang-cbor-04)? >=20 > I understand that I can implement [1] without having to generate JSON = first. Perhaps a discussion of this would be a nice addition to = draft-ietf-core-yang-cbor-04. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Jul 21 15:57:16 2017 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 7A1A6127B57 for ; Fri, 21 Jul 2017 15:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7, 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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhVwXdMHbLlz for ; Fri, 21 Jul 2017 15:57:12 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 ABEEA120721 for ; Fri, 21 Jul 2017 15:57:12 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id l81so6504926wmg.1 for ; Fri, 21 Jul 2017 15:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+Ej2nVHM9OE3/79jRgZuC7j3sPW+Bj7JfrcKmp34RII=; b=tnJU9u5lwzYDqC+dWro2+LyLIB+uhNyx4pqLu3BsWZVxRtc4oI/bmlTcBilcMkAvjM glrOeaozx6xRqW6I1PYrdbPEYjb3VvjZthSyOi2pDtb05XNg6hFMQRCEsY1IdN91D8NP hAtCK84gNkF3LRXeEXWQD4h1oZ4tVtO1AUv2G6uBLpfE4cSopdM+SjNlNZC9n+PEl4Ab CR8ZubiYl+NbEehXVZjSGYWI1aPjjqmgEGkoYYMfuJsKpag+yDQzxfNNnjmsa78OCJFo 5xfGCbleUDhrB3CU6uzE3U/9Xdke3wP0GtHW2gCJRzNfh+P3f5ijTbbUlFb/DiPGbm9b WXdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+Ej2nVHM9OE3/79jRgZuC7j3sPW+Bj7JfrcKmp34RII=; b=I7iqn2TxHX1DqyHWF65kSRV0oEqiK6iZo6WlFuA72nbmEebn+dSbZfY3t/q3003AtN Tp6Nnb7ECf5naQtGTw8UHPbAsuKqvHe1MMjrmWXNg6h56OtxhFbcTar8/LcHRGFHHKzm m/kpgokS5bJrGDWS4ZMdmbd5wqxizuUxL+Zyd/gp3beBNUqUJcKCm5z0FGhf6qCX17Y7 oh8Ql/KMkgpHAv3P9lASRev6w7yZiQoZ5sqiISREe+l/GPj05Hkv6DnI8sofVxdsj4K3 0TU6e6l9O5HazA6oIR1K1b9Wv+CUjrkFaN7dY963WdNH+I9LJAaF+bJC2e7tLSt1gBbm Kvog== X-Gm-Message-State: AIVw112yFFoHspK0aPFPjf6hwkfhss3nPf2h4OHWUC20ADvGVvYkGKCz +77TiqtNtz4r2Wm9pYtAC9xYXbV8qd5r X-Received: by 10.28.7.19 with SMTP id 19mr343330wmh.23.1500677831149; Fri, 21 Jul 2017 15:57:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Fri, 21 Jul 2017 15:57:10 -0700 (PDT) In-Reply-To: <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> From: Andy Bierman Date: Fri, 21 Jul 2017 15:57:10 -0700 Message-ID: To: Carsten Bormann Cc: Michel Veillette , Core Content-Type: multipart/alternative; boundary="001a114432ac0c64480554dbc905" Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 21 Jul 2017 22:57:14 -0000 --001a114432ac0c64480554dbc905 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 21, 2017 at 2:01 AM, Carsten Bormann wrote: > > > On Jul 21, 2017, at 10:17, Michel Veillette < > Michel.Veillette@trilliantinc.com> wrote: > > > > Hi Andy > > > > About the union, the CBOR encoding avoid any ambiguities between > datatypes, something not archived by the xml mapping and partially archiv= ed > by JSON. For example, in xml, it is impossible to differentiate the strin= g > "1" from the integer 1. > > I think Andy=E2=80=99s point is that the serialization idiosyncrasies tha= t leak > into YANG are at this point well-known if it is the idiosyncrasies from t= he > XML serialization (which have been maintained quite well in the JSON > serialization, too) but not so for the CBOR serialization. With some > effort, it is possible to write YANG that exposes these idiosyncrasies: > > What I mean is that XML and JSON encodings align with YANG by design. The YANG identifiers are strings. The value spaces are specified such that any collision is invalid YANG. The XML/JSON encoding formats are "protected" by the rules of YANG. It is not possible for identifier or value space errors to occur if the YANG module is valid. This protection is built into the data modeling language by design for numbered identifiers as well (e.g., SMIv2, Zigbee, etc.) But SID is completely unprotected from these errors because the SID identifier and data type encoding can change even though no YANG rules have been violated. Statement position carries (almost) no semantic or identifier value at all in YANG. Rely on it at your own risk. > The only ambiguities not resolved by the CBOR encoding is an union > composed of two enumerations defining the same value associated to > different meanings. I will argue that such definition is incorrect. > > Not sure that is the only case, but it still is a case. Right now, the > YANG tools don=E2=80=99t know about these cases yet. So having, say, a p= yang > extension that tests for this might be a useful thing to have. > > Gr=C3=BC=C3=9Fe, Carsten > > Andy --001a114432ac0c64480554dbc905 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 21, 2017 at 2:01 AM, Carsten Bormann <= cabo@tzi.org> wrote:

> On Jul 21, 2017, at 10:17, Michel Veillette <Michel.Veillette@trilliant= inc.com> wrote:
>
> Hi Andy
>
> About the union, the CBOR encoding avoid any ambiguities between datat= ypes, something not archived by the xml mapping and partially archived by J= SON. For example, in xml, it is impossible to differentiate the string &quo= t;1" from the integer 1.

I think Andy=E2=80=99s point is that the serialization idiosyncrasies that = leak into YANG are at this point well-known if it is the idiosyncrasies fro= m the XML serialization (which have been maintained quite well in the JSON = serialization, too) but not so for the CBOR serialization.=C2=A0 With some = effort, it is possible to write YANG that exposes these idiosyncrasies:



What I mean is that XML= and JSON encodings align with YANG by design.
The YANG identifie= rs are strings. The value spaces are specified such that any
coll= ision is invalid YANG.

The =C2=A0XML/JSON encoding= formats are "protected" by the rules of YANG.
It is no= t possible for identifier or value space errors to occur if the YANG module= is valid.
This protection is built into the data modeling langua= ge by design for numbered
identifiers as well (e.g., SMIv2, Z= igbee, etc.)

But SID is completely unprotected fro= m these errors because the SID identifier and
data type encoding = can change even though no YANG rules have been violated.
Statemen= t position carries (almost) no semantic or identifier value at all in YANG.=
Rely on it at your own risk.


=
> The only ambiguities not resolved by the CBOR encoding is an union com= posed of two enumerations defining the same value associated to different m= eanings. I will argue that such definition is incorrect.

Not sure that is the only case, but it still is a case.=C2=A0 Right now, th= e YANG tools don=E2=80=99t know about these cases yet.=C2=A0 So having, say= , a pyang extension that tests for this might be a useful thing to have.
Gr=C3=BC=C3=9Fe, Carsten


Andy

--001a114432ac0c64480554dbc905-- From nobody Fri Jul 21 19:46:09 2017 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 08F5B1270A3 for ; Fri, 21 Jul 2017 19:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=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 dMdjZXvAD67V for ; Fri, 21 Jul 2017 19:46:04 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0128.outbound.protection.outlook.com [104.47.40.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC39128B8F for ; Fri, 21 Jul 2017 19:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wg02JfuK1BXN8knmzPkRSO938o/WdxaI0MQzpYjkdeI=; b=vSTQoGO7dpuaxH8BKUsDV3C4m4VCHa/TyTjre3U9Givi16sX3seVL6LoT2AB8H1xFsPH24fMZGez5MnlTV8j29zmjOgpEidxhA1zCVassAbPYi9yV8bArvB55ESzvxpcKIyZVrVkCQ6H3RdkmmKZNv6KzRJ2lN5s8LQNx4j+xZY= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2305.namprd06.prod.outlook.com (10.173.19.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Sat, 22 Jul 2017 02:45:54 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.1282.016; Sat, 22 Jul 2017 02:45:54 +0000 From: Michel Veillette To: Andy Bierman , Carsten Bormann CC: Core Thread-Topic: [core] yang cbor encoding without SID Thread-Index: AQHTATQrCEiVptWX80+aOopWb5cOWaJcaCuAgAAB64CAAAdyAIAABJeAgAFUMYCAAASKAIAABsVggAAVnACAAANLIIAADxMAgADpXACAAD4CkA== Date: Sat, 22 Jul 2017 02:45:54 +0000 Message-ID: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> In-Reply-To: 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@trilliantinc.com; x-originating-ip: [193.86.126.99] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR06MB2305; 7:Chep70qCYCILjL6CkLxqvV77QPPomNM/5LQo6g5Sm83+X5J+BK4by7xcdCaZ0AdEy6QbTA7TjyapfspmLyonIIehq85cC/K0AhnmcrIVSCINS+cNpaSrCpNrtD/EzFYddivWJLu+1D5cP9Hlnn38CTu9KazlbgZ7xcwfWOJYi5DTEjxaw4OHQyK8WSKmMZsmEipfGUCuS0E/NsIbELrD+73CA+p3vuaMzMm8+RaiUILUVPJRwCiD3j0oV5qPDRkwskXqrb7Ko3kJpJL288ah5YbycInUMKU2GBfZSU1iqQHxLkJNLI9QWbQHZwQVdM9v2vwkJ4OoUtVJeSec1XrToBGbJK4nT9KmkJaTTG6rieJWT37cAS/tJp22M0Jcsk7dvAZT/kPkhye3N8rF6IO7iCNttH/oOehuBRC7jI1wlNvS86JJ+LRUu5CoxfOYK6KLcDR8aTzbCu30OQKsMaEIRybOBNgeqWnOrC8IGYHzBsXO7cWtmtyS45FGXjpDwmlSSWFz9xfThCvKOhOo+oYgo9mqzjmoJjjEq1PdI2EubQw4Bo8GdwaOyOZTtA8M44gVSaMdv0PQ3tAq8odK6gYKypxqBRsP59KChxqKVhihsHqSpH+x2QXBz7/I1hkt8Qg8Cc7RpDvTsniufAIZXAS6DQ/YNmrUCjsBlGbiRCtjOlekO6EB3ggJFBz1rYqpELiPbkJVUC2Gczm7fePao62mf3qoZOjaFC0h255AT76XoNYT3pXwoRwh//lrRCYeMf9fu6Ef9J5b1509vSB1CduhwInShPf3iIsdcllwZebpv3E= x-ms-office365-filtering-correlation-id: 86b0f70e-0a71-4797-7378-08d4d0abc5f5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR06MB2305; x-ms-traffictypediagnostic: BN6PR06MB2305: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR06MB2305; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR06MB2305; x-forefront-prvs: 0376ECF4DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39840400002)(39400400002)(39450400003)(39410400002)(377454003)(24454002)(199003)(189002)(66066001)(93886004)(6246003)(38730400002)(25786009)(4326008)(33656002)(7696004)(19609705001)(8936002)(229853002)(97736004)(77096006)(8676002)(81166006)(81156014)(3660700001)(7736002)(3280700002)(6506006)(106356001)(189998001)(68736007)(105586002)(236005)(6306002)(86362001)(14454004)(9686003)(478600001)(2906002)(6436002)(53936002)(99286003)(50986999)(2900100001)(53546010)(72206003)(74316002)(102836003)(6116002)(3846002)(2950100002)(790700001)(55016002)(101416001)(5660300001)(54896002)(54356999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2305; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR06MB2308B8B1F80F42C24FED4D77FEA50BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2017 02:45:54.3393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2305 Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 02:46:08 -0000 --_000_BN6PR06MB2308B8B1F80F42C24FED4D77FEA50BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keQ0KDQpJIHdpbGwgYWdyZWUgd2l0aCB5b3Ugb24gb25lIHBvaW50LCBzb21lIGltcGxl bWVudGVycyBtaWdodCBoYXZlIGRlZmluZWQgY2FyZWxlc3NseSAndmFsdWUnIGFuZCAncG9zaXRp b24nIGJlY2F1c2UgdGhlc2Ugc3RhdGVtZW50cyB3YXMgbm90IHVzZWZ1bCBmb3IgdGhlaXIgTkVU Q09ORiBvciBSRVNUQ09ORiBpbXBsZW1lbnRhdGlvbnMuIFRoaXMgaXMgbm90IGFuIGlzc3VlIHdp dGggWUFORyBidXQgd2l0aCB0aG9zZSBkZXZlbG9wZXJzLiBJIGRvbid0IGFncmVlIHRoYXQgdGhl IGRlc2lnbmVycyBvZiB0aGUgWUFORyBtb2RlbGluZyBsYW5ndWFnZSBwdXQgdGhlc2Ugc3RhdGVt ZW50cyBpbiB0aGUgc2NoZW1hIGRlZmluaXRpb24ganVzdCBmb3IgZnVuLiBUaGV5IGNlcnRhaW5s eSBmb3Jlc2F3IHRoZSB0aW1lIFlBTkcgd2lsbCBiZSBpbXBsZW1lbnRlZCBpbiBiaW5hcnkuDQoN ClRoZSBpbXBhY3RzIG9uIHRoZSB5YW5nIHRvIGNib3IgbWFwcGluZyBpcyBob3dldmVyIGxpbWl0 ZWQuIFRoZSBZQU5HIHNwZWNpZmljYXRpb24gYW5kIFlBTkcgdmFsaWRhdG9ycyBndWFyYW50ZWUg dGhlIHVuaXF1ZW5lc3Mgb2YgZW51bWVyYXRpb24gdmFsdWVzIGFuZCBiaXRzIHBvc2l0aW9ucy4g V2hlbiB1c2VkIGluIGEgdW5pb24sIHRoZSBjb25jbHVzaW9uIG9mIHRoZSBkZXNpZ24gdGVhbSB3 YXMgdG8gYWRkIGEgY2hlY2sgaW4gdmFsaWRhdGlvbiB0b29scyB0byBnZW5lcmF0ZSBhIHdhcm5p bmcgd2hlbiBkdXBsaWNhdGUgdmFsdWVzIG9yIHBvc2l0aW9ucyBhcmUgZGV0ZWN0ZWQuIFN1Y2gg Y2hlY2sgY2FuIGJlIHBhcnQgb2YgYSB2YWxpZGF0aW9uIHBlcmZvcm1lZCB3aGVuIHJlZ2lzdGVy aW5nIFNJRHMuIFNpbmNlIHRob3NlIHZhbHVlcyBvciBwb3NpdGlvbiBhcmUgbm90IGxpa2VseSB0 byBoYXZlIGJlZW4gdXNlZCwgZml4aW5nIHRoZW0gd29uJ3QgaGF2ZSBhbnkgaW1wYWN0cyBvbiBw cmlvciBpbXBsZW1lbnRhdGlvbnMuIE5vYm9keSBob3dldmVyIGhhdmUgcmVwb3J0ZWQgc28gZmFy IGFueSBpbnN0YW5jZXMgb2YgdGhpcyBpc3N1ZS4NCg0KSSBkb24ndCBzZWUgYW55IHJlYXNvbnMg d2h5IFlBTkcgd29uJ3QgYmUgc3VpdGFibGUgZm9yIGJpbmFyeSBpbXBsZW1lbnRhdGlvbnMgYW5k IGRlc2lnbmVycyBvZiB0aGlzIG1vZGVsaW5nIGxhbmd1YWdlIHNob3VsZCBiZSBwcm91ZCBvZiB0 aGlzIGFjY29tcGxpc2htZW50Lg0KDQpSZWdhcmRzLA0KTWljaGVsDQoNCg0KRnJvbTogQW5keSBC aWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KU2VudDogU2F0dXJkYXksIEp1bHkg MjIsIDIwMTcgMTI6NTcgQU0NClRvOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4NCkNj OiBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20+OyBD b3JlIDxjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjb3JlXSB5YW5nIGNib3IgZW5jb2Rp bmcgd2l0aG91dCBTSUQNCg0KDQoNCk9uIEZyaSwgSnVsIDIxLCAyMDE3IGF0IDI6MDEgQU0sIENh cnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPG1haWx0bzpjYWJvQHR6aS5vcmc+PiB3cm90ZToN Cg0KPiBPbiBKdWwgMjEsIDIwMTcsIGF0IDEwOjE3LCBNaWNoZWwgVmVpbGxldHRlIDxNaWNoZWwu VmVpbGxldHRlQHRyaWxsaWFudGluYy5jb208bWFpbHRvOk1pY2hlbC5WZWlsbGV0dGVAdHJpbGxp YW50aW5jLmNvbT4+IHdyb3RlOg0KPg0KPiBIaSBBbmR5DQo+DQo+IEFib3V0IHRoZSB1bmlvbiwg dGhlIENCT1IgZW5jb2RpbmcgYXZvaWQgYW55IGFtYmlndWl0aWVzIGJldHdlZW4gZGF0YXR5cGVz LCBzb21ldGhpbmcgbm90IGFyY2hpdmVkIGJ5IHRoZSB4bWwgbWFwcGluZyBhbmQgcGFydGlhbGx5 IGFyY2hpdmVkIGJ5IEpTT04uIEZvciBleGFtcGxlLCBpbiB4bWwsIGl0IGlzIGltcG9zc2libGUg dG8gZGlmZmVyZW50aWF0ZSB0aGUgc3RyaW5nICIxIiBmcm9tIHRoZSBpbnRlZ2VyIDEuDQoNCkkg dGhpbmsgQW5keeKAmXMgcG9pbnQgaXMgdGhhdCB0aGUgc2VyaWFsaXphdGlvbiBpZGlvc3luY3Jh c2llcyB0aGF0IGxlYWsgaW50byBZQU5HIGFyZSBhdCB0aGlzIHBvaW50IHdlbGwta25vd24gaWYg aXQgaXMgdGhlIGlkaW9zeW5jcmFzaWVzIGZyb20gdGhlIFhNTCBzZXJpYWxpemF0aW9uICh3aGlj aCBoYXZlIGJlZW4gbWFpbnRhaW5lZCBxdWl0ZSB3ZWxsIGluIHRoZSBKU09OIHNlcmlhbGl6YXRp b24sIHRvbykgYnV0IG5vdCBzbyBmb3IgdGhlIENCT1Igc2VyaWFsaXphdGlvbi4gIFdpdGggc29t ZSBlZmZvcnQsIGl0IGlzIHBvc3NpYmxlIHRvIHdyaXRlIFlBTkcgdGhhdCBleHBvc2VzIHRoZXNl IGlkaW9zeW5jcmFzaWVzOg0KDQoNCldoYXQgSSBtZWFuIGlzIHRoYXQgWE1MIGFuZCBKU09OIGVu Y29kaW5ncyBhbGlnbiB3aXRoIFlBTkcgYnkgZGVzaWduLg0KVGhlIFlBTkcgaWRlbnRpZmllcnMg YXJlIHN0cmluZ3MuIFRoZSB2YWx1ZSBzcGFjZXMgYXJlIHNwZWNpZmllZCBzdWNoIHRoYXQgYW55 DQpjb2xsaXNpb24gaXMgaW52YWxpZCBZQU5HLg0KDQpUaGUgIFhNTC9KU09OIGVuY29kaW5nIGZv cm1hdHMgYXJlICJwcm90ZWN0ZWQiIGJ5IHRoZSBydWxlcyBvZiBZQU5HLg0KSXQgaXMgbm90IHBv c3NpYmxlIGZvciBpZGVudGlmaWVyIG9yIHZhbHVlIHNwYWNlIGVycm9ycyB0byBvY2N1ciBpZiB0 aGUgWUFORyBtb2R1bGUgaXMgdmFsaWQuDQpUaGlzIHByb3RlY3Rpb24gaXMgYnVpbHQgaW50byB0 aGUgZGF0YSBtb2RlbGluZyBsYW5ndWFnZSBieSBkZXNpZ24gZm9yIG51bWJlcmVkDQppZGVudGlm aWVycyBhcyB3ZWxsIChlLmcuLCBTTUl2MiwgWmlnYmVlLCBldGMuKQ0KDQpCdXQgU0lEIGlzIGNv bXBsZXRlbHkgdW5wcm90ZWN0ZWQgZnJvbSB0aGVzZSBlcnJvcnMgYmVjYXVzZSB0aGUgU0lEIGlk ZW50aWZpZXIgYW5kDQpkYXRhIHR5cGUgZW5jb2RpbmcgY2FuIGNoYW5nZSBldmVuIHRob3VnaCBu byBZQU5HIHJ1bGVzIGhhdmUgYmVlbiB2aW9sYXRlZC4NClN0YXRlbWVudCBwb3NpdGlvbiBjYXJy aWVzIChhbG1vc3QpIG5vIHNlbWFudGljIG9yIGlkZW50aWZpZXIgdmFsdWUgYXQgYWxsIGluIFlB TkcuDQpSZWx5IG9uIGl0IGF0IHlvdXIgb3duIHJpc2suDQoNCg0KPiBUaGUgb25seSBhbWJpZ3Vp dGllcyBub3QgcmVzb2x2ZWQgYnkgdGhlIENCT1IgZW5jb2RpbmcgaXMgYW4gdW5pb24gY29tcG9z ZWQgb2YgdHdvIGVudW1lcmF0aW9ucyBkZWZpbmluZyB0aGUgc2FtZSB2YWx1ZSBhc3NvY2lhdGVk IHRvIGRpZmZlcmVudCBtZWFuaW5ncy4gSSB3aWxsIGFyZ3VlIHRoYXQgc3VjaCBkZWZpbml0aW9u IGlzIGluY29ycmVjdC4NCg0KTm90IHN1cmUgdGhhdCBpcyB0aGUgb25seSBjYXNlLCBidXQgaXQg c3RpbGwgaXMgYSBjYXNlLiAgUmlnaHQgbm93LCB0aGUgWUFORyB0b29scyBkb27igJl0IGtub3cg YWJvdXQgdGhlc2UgY2FzZXMgeWV0LiAgU28gaGF2aW5nLCBzYXksIGEgcHlhbmcgZXh0ZW5zaW9u IHRoYXQgdGVzdHMgZm9yIHRoaXMgbWlnaHQgYmUgYSB1c2VmdWwgdGhpbmcgdG8gaGF2ZS4NCg0K R3LDvMOfZSwgQ2Fyc3Rlbg0KDQpBbmR5DQoNCg== --_000_BN6PR06MB2308B8B1F80F42C24FED4D77FEA50BN6PR06MB2308namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkg QW5keTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdpbGwgYWdyZWUgd2l0aCB5b3Ugb24gb25l IHBvaW50LCBzb21lIGltcGxlbWVudGVycyBtaWdodCBoYXZlIGRlZmluZWQgY2FyZWxlc3NseSAn dmFsdWUnIGFuZCAncG9zaXRpb24nIGJlY2F1c2UgdGhlc2Ugc3RhdGVtZW50cyB3YXMgbm90IHVz ZWZ1bCBmb3IgdGhlaXIgTkVUQ09ORiBvciBSRVNUQ09ORiBpbXBsZW1lbnRhdGlvbnMuIFRoaXMg aXMgbm90IGFuIGlzc3VlIHdpdGggWUFORyBidXQgd2l0aCB0aG9zZQ0KIGRldmVsb3BlcnMuIEkg ZG9uJ3QgYWdyZWUgdGhhdCB0aGUgZGVzaWduZXJzIG9mIHRoZSBZQU5HIG1vZGVsaW5nIGxhbmd1 YWdlIHB1dCB0aGVzZSBzdGF0ZW1lbnRzIGluIHRoZSBzY2hlbWEgZGVmaW5pdGlvbiBqdXN0IGZv ciBmdW4uIFRoZXkgY2VydGFpbmx5IGZvcmVzYXcgdGhlIHRpbWUgWUFORyB3aWxsIGJlIGltcGxl bWVudGVkIGluIGJpbmFyeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGltcGFjdHMgb24g dGhlIHlhbmcgdG8gY2JvciBtYXBwaW5nIGlzIGhvd2V2ZXIgbGltaXRlZC4gVGhlIFlBTkcgc3Bl Y2lmaWNhdGlvbiBhbmQgWUFORyB2YWxpZGF0b3JzIGd1YXJhbnRlZSB0aGUgdW5pcXVlbmVzcyBv ZiBlbnVtZXJhdGlvbiB2YWx1ZXMgYW5kIGJpdHMgcG9zaXRpb25zLiBXaGVuIHVzZWQgaW4gYSB1 bmlvbiwgdGhlIGNvbmNsdXNpb24gb2YgdGhlIGRlc2lnbiB0ZWFtIHdhcyB0byBhZGQNCiBhIGNo ZWNrIGluIHZhbGlkYXRpb24gdG9vbHMgdG8gZ2VuZXJhdGUgYSB3YXJuaW5nIHdoZW4gZHVwbGlj YXRlIHZhbHVlcyBvciBwb3NpdGlvbnMgYXJlIGRldGVjdGVkLiBTdWNoIGNoZWNrIGNhbiBiZSBw YXJ0IG9mIGEgdmFsaWRhdGlvbiBwZXJmb3JtZWQgd2hlbiByZWdpc3RlcmluZyBTSURzLiBTaW5j ZSB0aG9zZSB2YWx1ZXMgb3IgcG9zaXRpb24gYXJlIG5vdCBsaWtlbHkgdG8gaGF2ZSBiZWVuIHVz ZWQsIGZpeGluZyB0aGVtIHdvbid0IGhhdmUNCiBhbnkgaW1wYWN0cyBvbiBwcmlvciBpbXBsZW1l bnRhdGlvbnMuIE5vYm9keSBob3dldmVyIGhhdmUgcmVwb3J0ZWQgc28gZmFyIGFueSBpbnN0YW5j ZXMgb2YgdGhpcyBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCBzZWUgYW55 IHJlYXNvbnMgd2h5IFlBTkcgd29uJ3QgYmUgc3VpdGFibGUgZm9yIGJpbmFyeSBpbXBsZW1lbnRh dGlvbnMgYW5kIGRlc2lnbmVycyBvZiB0aGlzIG1vZGVsaW5nIGxhbmd1YWdlIHNob3VsZCBiZSBw cm91ZCBvZiB0aGlzIGFjY29tcGxpc2htZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJGUi1DQSI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUi1DQSI+TWljaGVsPC9zcGFuPjxzcGFuIGxhbmc9IkZS LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFuZHkgQmll cm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1 cmRheSwgSnVseSAyMiwgMjAxNyAxMjo1NyBBTTxicj4NCjxiPlRvOjwvYj4gQ2Fyc3RlbiBCb3Jt YW5uICZsdDtjYWJvQHR6aS5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWNoZWwgVmVpbGxldHRl ICZsdDtNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20mZ3Q7OyBDb3JlICZsdDtjb3Jl QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2NvcmVdIHlhbmcgY2JvciBl bmNvZGluZyB3aXRob3V0IFNJRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVs IDIxLCAyMDE3IGF0IDI6MDEgQU0sIENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmNhYm9AdHppLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNhYm9AdHppLm9yZzwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KJmd0OyBPbiBKdWwgMjEsIDIwMTcsIGF0IDEw OjE3LCBNaWNoZWwgVmVpbGxldHRlICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGVsLlZlaWxsZXR0 ZUB0cmlsbGlhbnRpbmMuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGVsLlZlaWxsZXR0ZUB0cmls bGlhbnRpbmMuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgQW5keTxi cj4NCiZndDs8YnI+DQomZ3Q7IEFib3V0IHRoZSB1bmlvbiwgdGhlIENCT1IgZW5jb2RpbmcgYXZv aWQgYW55IGFtYmlndWl0aWVzIGJldHdlZW4gZGF0YXR5cGVzLCBzb21ldGhpbmcgbm90IGFyY2hp dmVkIGJ5IHRoZSB4bWwgbWFwcGluZyBhbmQgcGFydGlhbGx5IGFyY2hpdmVkIGJ5IEpTT04uIEZv ciBleGFtcGxlLCBpbiB4bWwsIGl0IGlzIGltcG9zc2libGUgdG8gZGlmZmVyZW50aWF0ZSB0aGUg c3RyaW5nICZxdW90OzEmcXVvdDsgZnJvbSB0aGUgaW50ZWdlciAxLjxicj4NCjxicj4NCkkgdGhp bmsgQW5keeKAmXMgcG9pbnQgaXMgdGhhdCB0aGUgc2VyaWFsaXphdGlvbiBpZGlvc3luY3Jhc2ll cyB0aGF0IGxlYWsgaW50byBZQU5HIGFyZSBhdCB0aGlzIHBvaW50IHdlbGwta25vd24gaWYgaXQg aXMgdGhlIGlkaW9zeW5jcmFzaWVzIGZyb20gdGhlIFhNTCBzZXJpYWxpemF0aW9uICh3aGljaCBo YXZlIGJlZW4gbWFpbnRhaW5lZCBxdWl0ZSB3ZWxsIGluIHRoZSBKU09OIHNlcmlhbGl6YXRpb24s IHRvbykgYnV0IG5vdCBzbyBmb3IgdGhlIENCT1INCiBzZXJpYWxpemF0aW9uLiZuYnNwOyBXaXRo IHNvbWUgZWZmb3J0LCBpdCBpcyBwb3NzaWJsZSB0byB3cml0ZSBZQU5HIHRoYXQgZXhwb3NlcyB0 aGVzZSBpZGlvc3luY3Jhc2llczo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBJIG1lYW4gaXMgdGhhdCBYTUwgYW5kIEpT T04gZW5jb2RpbmdzIGFsaWduIHdpdGggWUFORyBieSBkZXNpZ24uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgWUFORyBpZGVudGlmaWVycyBh cmUgc3RyaW5ncy4gVGhlIHZhbHVlIHNwYWNlcyBhcmUgc3BlY2lmaWVkIHN1Y2ggdGhhdCBhbnk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNvbGxp c2lvbiBpcyBpbnZhbGlkIFlBTkcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSAmbmJzcDtYTUwvSlNPTiBlbmNvZGluZyBmb3JtYXRzIGFy ZSAmcXVvdDtwcm90ZWN0ZWQmcXVvdDsgYnkgdGhlIHJ1bGVzIG9mIFlBTkcuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBub3QgcG9zc2li bGUgZm9yIGlkZW50aWZpZXIgb3IgdmFsdWUgc3BhY2UgZXJyb3JzIHRvIG9jY3VyIGlmIHRoZSBZ QU5HIG1vZHVsZSBpcyB2YWxpZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoaXMgcHJvdGVjdGlvbiBpcyBidWlsdCBpbnRvIHRoZSBkYXRhIG1v ZGVsaW5nIGxhbmd1YWdlIGJ5IGRlc2lnbiBmb3IgbnVtYmVyZWQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlkZW50aWZpZXJzIGFzIHdlbGwgKGUu Zy4sIFNNSXYyLCBaaWdiZWUsIGV0Yy4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBTSUQgaXMgY29tcGxldGVseSB1bnByb3RlY3RlZCBm cm9tIHRoZXNlIGVycm9ycyBiZWNhdXNlIHRoZSBTSUQgaWRlbnRpZmllciBhbmQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRhdGEgdHlwZSBlbmNv ZGluZyBjYW4gY2hhbmdlIGV2ZW4gdGhvdWdoIG5vIFlBTkcgcnVsZXMgaGF2ZSBiZWVuIHZpb2xh dGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U3RhdGVtZW50IHBvc2l0aW9uIGNhcnJpZXMgKGFsbW9zdCkgbm8gc2VtYW50aWMgb3IgaWRlbnRp ZmllciB2YWx1ZSBhdCBhbGwgaW4gWUFORy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlbHkgb24gaXQgYXQgeW91ciBvd24gcmlzay48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsgVGhlIG9ubHkgYW1iaWd1aXRpZXMgbm90 IHJlc29sdmVkIGJ5IHRoZSBDQk9SIGVuY29kaW5nIGlzIGFuIHVuaW9uIGNvbXBvc2VkIG9mIHR3 byBlbnVtZXJhdGlvbnMgZGVmaW5pbmcgdGhlIHNhbWUgdmFsdWUgYXNzb2NpYXRlZCB0byBkaWZm ZXJlbnQgbWVhbmluZ3MuIEkgd2lsbCBhcmd1ZSB0aGF0IHN1Y2ggZGVmaW5pdGlvbiBpcyBpbmNv cnJlY3QuPGJyPg0KPGJyPg0KTm90IHN1cmUgdGhhdCBpcyB0aGUgb25seSBjYXNlLCBidXQgaXQg c3RpbGwgaXMgYSBjYXNlLiZuYnNwOyBSaWdodCBub3csIHRoZSBZQU5HIHRvb2xzIGRvbuKAmXQg a25vdyBhYm91dCB0aGVzZSBjYXNlcyB5ZXQuJm5ic3A7IFNvIGhhdmluZywgc2F5LCBhIHB5YW5n IGV4dGVuc2lvbiB0aGF0IHRlc3RzIGZvciB0aGlzIG1pZ2h0IGJlIGEgdXNlZnVsIHRoaW5nIHRv IGhhdmUuPGJyPg0KPGJyPg0KR3LDvMOfZSwgQ2Fyc3RlbjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR06MB2308B8B1F80F42C24FED4D77FEA50BN6PR06MB2308namp_-- From nobody Fri Jul 21 21:53:22 2017 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 1C2D6127444 for ; Fri, 21 Jul 2017 21:53: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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdPRdGpYtXuC for ; Fri, 21 Jul 2017 21:53:18 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 58BB112741D for ; Fri, 21 Jul 2017 21:53:18 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id f21so32147438wrf.5 for ; Fri, 21 Jul 2017 21:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z8FTSilz3KJW7aUj8gz2prS8qzyWUnJeHWdT4GFf/DU=; b=dq9tSP6yVmY1FJsufWzj/yXN6HXtY7T7c0NEoEh9cH7cRuPSPYMmS8iVjnYtGM2/6t jV9nwrrL4W4efqtdlSj8df6pKfNDd6NprDEHUdTDtmJw2iO2iYkzW8anbFFZw2K3Bck+ +IVfhlQBBvZKvEAoqZWXbUmt3fW9MBLFJvC/gc2JwgboMAqeATxeTaPa2FmT99ghBU3R PcfX6LLKsfjWk86YuZJsDORJ3PPHbCEefCHQEnHpAvDMiG63c5V4ZRX6ZOODqN+qs9kc Up2kmtRtISu99IITZCawJbG2LP//bHgGd5yA5eob2iVBJbGlfm92duS3gQPJeTj9gm6O lE4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z8FTSilz3KJW7aUj8gz2prS8qzyWUnJeHWdT4GFf/DU=; b=ENXntHqAUXzBBtMEFgdi3wNZZ2NnpKdUJDfo7IegZrtvFIV25r39V2bd0tUGagq+Jg q3b8eL+pLtiCfZKkViJnQa4q0ZzXIP5z0zctN9yMAyz2cmh7VHWp9SFvmcyTHWxZ+hwy hlEBnWspi0rMp4Nf4MBLQRKybKmTAfbeKHCypz/dQyG1ilsiYd5goIKsJOR+aay+FwDo n3FOxN9vYOCIgf0xoMVbIe6lUsVnWTqWgkMsMyBfRnW35K/bO0BGK79ljdRGHbQQhFd9 qcqGqxjZCQyqCB2JxuQo7lEb50/O7INTztjyA5/CvwhQ5iNWXOPKdrVQzY4/EcCojIRU vWcQ== X-Gm-Message-State: AIVw113kPTpVNwe1yRdvL/GuF2/Hs14ulyVRta24JlirynI8kPhCvp1R 9cGemeuoYdRzpxlISYCNi9mg+gp71yCU X-Received: by 10.223.171.79 with SMTP id r15mr6101834wrc.57.1500699196687; Fri, 21 Jul 2017 21:53:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Fri, 21 Jul 2017 21:53:15 -0700 (PDT) In-Reply-To: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> From: Andy Bierman Date: Fri, 21 Jul 2017 21:53:15 -0700 Message-ID: To: Michel Veillette Cc: Carsten Bormann , Core Content-Type: multipart/alternative; boundary="94eb2c1cb818889e280554e0c26f" Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 04:53:21 -0000 --94eb2c1cb818889e280554e0c26f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I am not going to explain it anymore. The order most statements appear in a YANG file is irrelevant to the semantics of the YANG module except (1) auto-numbering of position or value and (2) evaluation order of union member types. Keeping the SID files perfectly aligned with the YANG fie is a challenge. There is no way for a module to get out of synch with itself wrt/ schema node naming or instance value evaluation. So of course the tools will be perfect and the developers will be perfect and never let the registries and implementations get out of synch. Otherwise SID will produce incorrect results. If you cannot recognize the additional risks introduced by SID, you probably need to study RFC 7950 a bit more. Andy On Fri, Jul 21, 2017 at 7:45 PM, Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi Andy > > > > I will agree with you on one point, some implementers might have defined > carelessly 'value' and 'position' because these statements was not useful > for their NETCONF or RESTCONF implementations. This is not an issue with > YANG but with those developers. I don't agree that the designers of the > YANG modeling language put these statements in the schema definition just > for fun. They certainly foresaw the time YANG will be implemented in bina= ry. > > > > The impacts on the yang to cbor mapping is however limited. The YANG > specification and YANG validators guarantee the uniqueness of enumeration > values and bits positions. When used in a union, the conclusion of the > design team was to add a check in validation tools to generate a warning > when duplicate values or positions are detected. Such check can be part o= f > a validation performed when registering SIDs. Since those values or > position are not likely to have been used, fixing them won't have any > impacts on prior implementations. Nobody however have reported so far any > instances of this issue. > > > > I don't see any reasons why YANG won't be suitable for binary > implementations and designers of this modeling language should be proud o= f > this accomplishment. > > > > Regards, > > Michel > > > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Saturday, July 22, 2017 12:57 AM > *To:* Carsten Bormann > *Cc:* Michel Veillette ; Core < > core@ietf.org> > *Subject:* Re: [core] yang cbor encoding without SID > > > > > > > > On Fri, Jul 21, 2017 at 2:01 AM, Carsten Bormann wrote: > > > > On Jul 21, 2017, at 10:17, Michel Veillette trilliantinc.com> wrote: > > > > Hi Andy > > > > About the union, the CBOR encoding avoid any ambiguities between > datatypes, something not archived by the xml mapping and partially archiv= ed > by JSON. For example, in xml, it is impossible to differentiate the strin= g > "1" from the integer 1. > > I think Andy=E2=80=99s point is that the serialization idiosyncrasies tha= t leak > into YANG are at this point well-known if it is the idiosyncrasies from t= he > XML serialization (which have been maintained quite well in the JSON > serialization, too) but not so for the CBOR serialization. With some > effort, it is possible to write YANG that exposes these idiosyncrasies: > > > > > > What I mean is that XML and JSON encodings align with YANG by design. > > The YANG identifiers are strings. The value spaces are specified such tha= t > any > > collision is invalid YANG. > > > > The XML/JSON encoding formats are "protected" by the rules of YANG. > > It is not possible for identifier or value space errors to occur if the > YANG module is valid. > > This protection is built into the data modeling language by design for > numbered > > identifiers as well (e.g., SMIv2, Zigbee, etc.) > > > > But SID is completely unprotected from these errors because the SID > identifier and > > data type encoding can change even though no YANG rules have been violate= d. > > Statement position carries (almost) no semantic or identifier value at al= l > in YANG. > > Rely on it at your own risk. > > > > > > > The only ambiguities not resolved by the CBOR encoding is an union > composed of two enumerations defining the same value associated to > different meanings. I will argue that such definition is incorrect. > > Not sure that is the only case, but it still is a case. Right now, the > YANG tools don=E2=80=99t know about these cases yet. So having, say, a p= yang > extension that tests for this might be a useful thing to have. > > Gr=C3=BC=C3=9Fe, Carsten > > > > Andy > > > --94eb2c1cb818889e280554e0c26f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am not going to explain it anymor= e.
The order most statements appear in a YANG file is irrelevant = to the semantics of the YANG module
except (1) auto-numbering of = position or value and (2) evaluation order of union member types.
Keeping the SID files perfectly aligned with the YANG fie is a challenge. = There is no way for
a module to get out of synch with itself wrt/= schema node naming or instance value evaluation.

= So of course the tools will be perfect and the developers will be perfect
and never let the registries and implementations get out of synch.=
Otherwise SID will produce incorrect results. =C2=A0
I= f you cannot recognize the additional risks introduced by SID,
you probably need to study RFC 7950 a bit more.

=
Andy



On Fri, Jul 21, 2017 at 7:45 PM, Mich= el Veillette <Michel.Veillette@trilliantinc.com> wrote:

Hi Andy

=C2=A0

I will agree with you on one point, some implementer= s might have defined carelessly 'value' and 'position' beca= use these statements was not useful for their NETCONF or RESTCONF implement= ations. This is not an issue with YANG but with those developers. I don't agree that the designers of the YANG modeling lang= uage put these statements in the schema definition just for fun. They certa= inly foresaw the time YANG will be implemented in binary.

=C2=A0

The impacts on the yang to cbor mapping is however l= imited. The YANG specification and YANG validators guarantee the uniqueness= of enumeration values and bits positions. When used in a union, the conclu= sion of the design team was to add a check in validation tools to generate a warning when duplicate values or= positions are detected. Such check can be part of a validation performed w= hen registering SIDs. Since those values or position are not likely to have= been used, fixing them won't have any impacts on prior implementations. Nobody however have reported so far = any instances of this issue.

=C2=A0

I don't see any reasons why YANG won't be su= itable for binary implementations and designers of this modeling language s= hould be proud of this accomplishment.

=C2=A0

Regards,

Michel

=C2=A0

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Saturday, July 22, 2017 12:57 AM
To: Carsten Bormann <cabo@tzi.org>
Cc: Michel Veillette <Michel.Veillette@trilliantinc.com>;= Core <core@ietf.org<= /a>>
Subject: Re: [core] yang cbor encoding without SID

=C2=A0

=C2=A0

=C2=A0

On Fri, Jul 21, 2017 at 2:01 AM, Carsten Bormann <= ;cabo@tzi.org> wro= te:


> On Jul 21, 2017, at 10:17, Michel Veillette <Michel.Veillette@tril= liantinc.com> wrote:
>
> Hi Andy
>
> About the union, the CBOR encoding avoid any ambiguities between datat= ypes, something not archived by the xml mapping and partially archived by J= SON. For example, in xml, it is impossible to differentiate the string &quo= t;1" from the integer 1.

I think Andy=E2=80=99s point is that the serialization idiosyncrasies that = leak into YANG are at this point well-known if it is the idiosyncrasies fro= m the XML serialization (which have been maintained quite well in the JSON = serialization, too) but not so for the CBOR serialization.=C2=A0 With some effort, it is possible to write YANG that e= xposes these idiosyncrasies:

=C2=A0

=C2=A0

What I mean is that XML and JSON encodings align wit= h YANG by design.

The YANG identifiers are strings. The value spaces a= re specified such that any

collision is invalid YANG.

=C2=A0

The =C2=A0XML/JSON encoding formats are "protec= ted" by the rules of YANG.

It is not possible for identifier or value space err= ors to occur if the YANG module is valid.

This protection is built into the data modeling lang= uage by design for numbered

identifiers as well (e.g., SMIv2, Zigbee, etc.)

=C2=A0

But SID is completely unprotected from these errors = because the SID identifier and

data type encoding can change even though no YANG ru= les have been violated.

Statement position carries (almost) no semantic or i= dentifier value at all in YANG.

Rely on it at your own risk.

=C2=A0

=C2=A0

> The only ambigui= ties not resolved by the CBOR encoding is an union composed of two enumerat= ions defining the same value associated to different meanings. I will argue= that such definition is incorrect.

Not sure that is the only case, but it still is a case.=C2=A0 Right now, th= e YANG tools don=E2=80=99t know about these cases yet.=C2=A0 So having, say= , a pyang extension that tests for this might be a useful thing to have.
Gr=C3=BC=C3=9Fe, Carsten

=C2=A0

Andy

=C2=A0


--94eb2c1cb818889e280554e0c26f-- From nobody Fri Jul 21 23:43:00 2017 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 BDF1A126BF6; Fri, 21 Jul 2017 23:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 djiw5UWqdwSh; Fri, 21 Jul 2017 23:42:56 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 AFF8D129ABE; Fri, 21 Jul 2017 23:42:52 -0700 (PDT) X-AuditID: c1b4fb25-5efff70000001eeb-bd-5972f3ea0101 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1B.65.07915.AE3F2795; Sat, 22 Jul 2017 08:42:50 +0200 (CEST) Received: from ESESSMB110.ericsson.se ([169.254.10.145]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Sat, 22 Jul 2017 08:42:50 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Raja ashok CC: "core@ietf.org" , "draft-ietf-core-object-security@ietf.org" Thread-Topic: Doubts in draft-ietf-core-object-security Thread-Index: AdL71RHIJFGFQkrRQUCixg0rsoEXNAG4KoyA Date: Sat, 22 Jul 2017 06:42:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [153.88.183.149] Content-Type: multipart/mixed; boundary="_004_D59897E7848E1goranselanderericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42KZGbFdUffV56JIg0nftSz2vV3PbDHt3xkW i1VPpB2YPVqOvGX1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxoa9N9kKZj9hrHjxs4G9gfHdXcYu Rk4OCQETiU+LV7N1MXJxCAkcYZT49msqE0hCSGApo8SF1gIQm03AReJBwyOwuIiAmsTzx6/A bGaBOommvRvZQGxhATOJpgVzmbsYOYBqzCW+LMyHKDeSOLF6JTOIzSKgKrHl6x4WEJtXwEKi b8c6NohVoRKfv80Eu4dTIExi+/U1YPWMAmIS30+tgVolLnHryXwmiJtFJB5ePM0GYYtKvHz8 jxXEFhXQk9jb0w4VV5JYe3g7C8g5zALhEnv/eUKsFZQ4OfMJywRG0VlIps5CqJqFpAqiJFbi 9uSXrBAlmhLrd+lDhBUlpnQ/ZIewNSRa58yFsq0lfhw4woipRldi+oQjTDDx2ctfAdVwAdkr GSXOXf7NCpHQkXi34QE7suYFjHyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQKTw8Etv1V3 MF5+43iIUYCDUYmH1/BDUaQQa2JZcWXuIUYVoDmPNqy+wCjFkpefl6okwjvnLVCaNyWxsiq1 KD++qDQntfgQozQHi5I4r+O+CxFCAumJJanZqakFqUUwWSYOTqkGxogzKxQqfjyfmOOhX9Uj /0341vfQ72EbkkLMZpxM6Urd3JSm1jw38NKuE1mF641mzry2kG9Dyw4XnroTTqfOmHex+TS7 h7UyT+usS7b+pjs7qbog+8D1G7v2H2o92+2v+SsrqPdnyryW+WfUlR9rCHdrBp152dAuoibz 7OqJukXKV29+4T7/SImlOCPRUIu5qDgRAFVq1jQWAwAA Archived-At: Subject: Re: [core] Doubts in draft-ietf-core-object-security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 06:42:59 -0000 --_004_D59897E7848E1goranselanderericssoncom_ Content-Type: multipart/alternative; boundary="_000_D59897E7848E1goranselanderericssoncom_" --_000_D59897E7848E1goranselanderericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQXNob2ssDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4NCg0KV2hhdCBhbW91bnQgb2Yg bWVzc2FnZSBkYXRhIGRvIHlvdSBlbnZpc2lvbiBkdXJpbmcgdGhlIGxpZmV0aW1lIG9mIHRoZSBk ZXZpY2U/IFRoZSBzYW1lIGtleSBjYW4gYmUgdXNlZCBmb3IgYSBsYXJnZSBudW1iZXIgb2YgbWVz c2FnZXMgKHRoZSBudW1iZXIgZGVwZW5kaW5nIG9uIHRoZSBBRUFEIGFsZ29yaXRobSkgYW5kIHRo ZXJlIGlzIGluIHByaW5jaXBsZSBubyByZWFzb24gdG8gY2hhbmdlIGtleSBiZWZvcmUgdGhhdC4g QW5kIGFmdGVyIHRoYXQgeW91IHdvdWxkIHByb2JhYmx5IHdhbnQgdG8gYW55d2F5IG1ha2UgYSBE aWZmaWUtSGVsbG1hbiBrZXkgZXhjaGFuZ2Ugc2luY2UgdGhlIGVudHJvcHkgb2YgdGhlIG1hc3Rl ciBzZWNyZXQgaXMgd29ybiBvdXQuDQoNCkluIHByaW5jaXBsZSBpdCBpcyBwb3NzaWJsZSB0byBo YXZlIGEgbmV3IG1hc3RlciBzYWx0IHNlZWRlZCBieSAoc29tZXRoaW5nIHJhbmRvbSBrbm93biB0 bykgY2xpZW50IGFuZCBzZXJ2ZXIgYW5kIGRlcml2ZSBhIG5ldyBzZXNzaW9uIGtleSwgYnV0IGZv ciB0aGUgcmVhc29ucyBhYm92ZSB3ZSBkaWQgbm90IHNwZWNpZnkgdGhhdC4gQW5vdGhlciBvcHRp b24gaXMgdG8gdXNlIE9TQ09BUCB3aXRoIHNvbWUgb3RoZXIga2V5IGV4Y2hhbmdlIHByb3RvY29s IHdoaWNoIHN1cHBvcnRzIGtleSByb2xsb3Zlci4NCg0KUGxlYXNlIGxldCBtZSBrbm93IG1vcmUg YWJvdXQgdGhlIHVzZSBjYXNlIGlmIHRoaXMgZG9lc27igJl0IGFuc3dlciB0aGUgcXVlc3Rpb24u DQoNClRoYW5rcw0KR8O2cmFuDQoNCkZyb206IFJhamEgYXNob2sgPHJhamEuYXNob2tAaHVhd2Vp LmNvbTxtYWlsdG86cmFqYS5hc2hva0BodWF3ZWkuY29tPj4NCkRhdGU6IFRodXJzZGF5IDEzIEp1 bHkgMjAxNyBhdCAxNDozOQ0KVG86IEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJp Y3Nzb24uY29tPG1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20+PiwgImRyYWZ0LWll dGYtY29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY29yZS1v YmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0 eUBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9y Zz4+DQpDYzogImNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+IiA8Y29yZUBpZXRm Lm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBEb3VidHMgaW4gZHJhZnQtaWV0 Zi1jb3JlLW9iamVjdC1zZWN1cml0eQ0KDQpIaSBHb2VyYW4gU2VsYW5kZXIsDQoNCkkgaGF2ZSBn b25lIHRocm91Z2ggdGhlIE9TQ09BUCBhbmQgRURIT0MgZHJhZnRzLiBBbmQgSSBhbSBoYXZpbmcg ZmV3IGRvdWJ0cyBpbiBpdC4gUGxlYXNlIHByb3ZpZGUgeW91ciBjb21tZW50cyBvbiBpdC4NCg0K VGhpcyBzcGVjaWZpY2F0aW9uIG1ha2VzIGhhbmRzaGFrZShFREhPQykgZm9yIGRlcml2aW5nIG1h c3RlciBzZWNyZXQgYXMgb3B0aW9uYWwuIEFuZCBhbHNvIGEgY29uc3RyYWludCBub2RlIGNhbiBz a2lwIGhhbmRzaGFrZSBhbmQgZXN0YWJsaXNoIGEgc2VjdXJlIGNoYW5uZWwgaWYgbWFzdGVyIHNl Y3JldCBpcyBwcmVjb25maWd1cmVkLg0KDQpUaGlzIG1heSBtYWtlIGEgY29uc3RyYWludCBub2Rl IHRvIHVzZSBzYW1lIHNlc3Npb24ga2V5cyAoc2VuZGVyIGFuZCByZWNlaXZlciBrZXkpIGZvciBs b25nZXIgZHVyYXRpb24sIGlmIHNlcXVlbmNlIG51bWJlciBpcyBub3QgZXhoYXVzdGVkLiBPbmx5 IHNvbHV0aW9uIGZvciByZW5ld2luZyBzZXNzaW9uIGtleSBpcyB0byBuZWdvdGlhdGUgbmV3IG1h c3RlciBzZWNyZXQgYnkgdXNpbmcgRURIT0MuIEJ1dCBFREhPQyBzdXBwb3J0cyBvbmx5IFBTS19F Q0RIRSBhbmQgRUNEU0FfRUNESEUgbWVjaGFuaXNtLiBIZXJlIEkgZmVlbCB3ZSBhcmUgbWlzc2lu ZyBQU0sgd2l0aG91dCAoRUMpREhFIG1lY2hhbmlzbSBmb3IgZXN0YWJsaXNoaW5nIHNlY3VyZSBj aGFubmVsLiBJIG1lYW4gd2UgYXJlIG1pc3NpbmcgVExTX1BTS19XSVRIX0FFU18xMjhfQ0NNXzgg a2luZCBvZiBtZWNoYW5pc20uDQoNCkluIERUTFMsIFRMU19QU0tfV0lUSF9BRVNfMTI4X0NDTV84 IHVzZXMgc2FtZSBQU0sgZXZlcnkgdGltZSBmb3IgZGVyaXZpbmcgc2Vzc2lvbiBrZXlzLCBhbmQg aXQgZG9lc27igJl0IHN1cHBvcnQgUEZTLiBCdXQgdGhlIHNlc3Npb24ga2V5IGRlcml2ZWQgaXMg ZGlmZmVyZW50IGV2ZXJ5IHRpbWUgd2l0aCB0aGUgaGVscCBvZiBjbGllbnQgYW5kIHNlcnZlciBy YW5kb20uDQoNClNvIEkgZmVlbCB3ZSBjYW4gY29uc2lkZXIgb2YgZXhjaGFuZ2luZyByYW5kb20g bnVtYmVyIGFsc28gYWxvbmcgd2l0aCBLSUQgYW5kIFBhcnRpYWwgSVYgaW4gdGhlIDFzdCBSZXF1 ZXN0IGFuZCBSZXNwb25zZS4gVG8gYWNoaWV2ZSBUTFNfUFNLX1dJVEhfQUVTXzEyOF9DQ01fOCBr aW5kIG9mIG1lY2hhbmlzbSBpbiBPU0NvQVAgd2l0aG91dCBFQ0RIRSBleGNoYW5nZS4gRm9yIHRo aXMgYW55d2F5IHdlIGhhdmUgdG8gY29uc2lkZXIgbXVsdGlwbGUgZmFjdG9ycyBsaWtlIHJlcGxh eSBhdHRhY2ssIERvUyBhdHRhY2sgKGNsaWVudCBpbml0aWF0aW5nIGtleSBkZXJpdmF0aW9uIGZv ciBlYWNoIHJlcXVlc3QpLCBjbGllbnQgcmVib290IGNhc2UgZXRjLg0KDQpSZWdhcmRzLA0KQXNo b2sNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCltDb21wYW55X2xvZ29dDQoN ClJhamEgQXNob2sgViBLDQpIdWF3ZWkgVGVjaG5vbG9naWVzDQpCYW5nYWxvcmUsIEluZGlhDQpo dHRwOi8vd3d3Lmh1YXdlaS5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrm nKzpgq7ku7blj4rlhbbpmYTku7blkKvmnInljY7kuLrlhazlj7jnmoTkv53lr4bkv6Hmga/vvIzk u4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrkurrmiJbnvqTnu4Tj gILnpoENCuatouS7u+S9leWFtuS7luS6uuS7peS7u+S9leW9ouW8j+S9v+eUqO+8iOWMheaLrOS9 huS4jemZkOS6juWFqOmDqOaIlumDqOWIhuWcsOazhOmcsuOAgeWkjeWItuOAgeaIluaVo+WPke+8 ieacrOmCruS7tuS4rQ0K55qE5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM 6K+35oKo56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu 5Lu277yBDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50 aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaA0KaXMgaW50ZW5kZWQgb25seSBmb3Ig dGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1 c2Ugb2YgdGhlDQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1 ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQpkaXNjbG9zdXJlLCBy ZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUg aW50ZW5kZWQNCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlz IGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5DQpwaG9uZSBvciBl bWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KDQo= --_000_D59897E7848E1goranselanderericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBBc2hvayw8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyBmb3IgeW91ciBjb21tZW50cy48 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldoYXQgYW1vdW50IG9mIG1lc3NhZ2UgZGF0 YSBkbyB5b3UgZW52aXNpb24gZHVyaW5nIHRoZSBsaWZldGltZSBvZiB0aGUgZGV2aWNlPyBUaGUg c2FtZSBrZXkgY2FuIGJlIHVzZWQgZm9yIGEgbGFyZ2UgbnVtYmVyIG9mIG1lc3NhZ2VzICh0aGUg bnVtYmVyIGRlcGVuZGluZyBvbiB0aGUgQUVBRCBhbGdvcml0aG0pIGFuZCB0aGVyZSBpcyBpbiBw cmluY2lwbGUgbm8gcmVhc29uIHRvIGNoYW5nZSBrZXkgYmVmb3JlIHRoYXQuIEFuZCBhZnRlcg0K IHRoYXQgeW91IHdvdWxkIHByb2JhYmx5IHdhbnQgdG8gYW55d2F5IG1ha2UgYSBEaWZmaWUtSGVs bG1hbiBrZXkgZXhjaGFuZ2Ugc2luY2UgdGhlIGVudHJvcHkgb2YgdGhlIG1hc3RlciBzZWNyZXQg aXMgd29ybiBvdXQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JbiBwcmluY2lwbGUg aXQgaXMgcG9zc2libGUgdG8gaGF2ZSBhIG5ldyBtYXN0ZXIgc2FsdCBzZWVkZWQgYnkgKHNvbWV0 aGluZyByYW5kb20ga25vd24gdG8pIGNsaWVudCBhbmQgc2VydmVyIGFuZCBkZXJpdmUgYSBuZXcg c2Vzc2lvbiBrZXksIGJ1dCBmb3IgdGhlIHJlYXNvbnMgYWJvdmUgd2UgZGlkIG5vdCBzcGVjaWZ5 IHRoYXQuIEFub3RoZXIgb3B0aW9uIGlzIHRvIHVzZSBPU0NPQVAgd2l0aCBzb21lIG90aGVyIGtl eSBleGNoYW5nZQ0KIHByb3RvY29sIHdoaWNoIHN1cHBvcnRzIGtleSByb2xsb3Zlci48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBsZWFzZSBsZXQgbWUga25vdyBtb3JlIGFib3V0IHRo ZSB1c2UgY2FzZSBpZiB0aGlzIGRvZXNu4oCZdCBhbnN3ZXIgdGhlIHF1ZXN0aW9uLjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzPC9kaXY+DQo8ZGl2PkfDtnJhbjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5SYWphIGFzaG9rICZsdDs8YSBocmVmPSJtYWlsdG86 cmFqYS5hc2hva0BodWF3ZWkuY29tIj5yYWphLmFzaG9rQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXkgMTMg SnVseSAyMDE3IGF0IDE0OjM5PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRv OiA8L3NwYW4+R8O2cmFuIFNlbGFuZGVyICZsdDs8YSBocmVmPSJtYWlsdG86Z29yYW4uc2VsYW5k ZXJAZXJpY3Nzb24uY29tIj5nb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb208L2E+Jmd0OywgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5v cmciPmRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9y ZyI+ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86Y29yZUBpZXRmLm9yZyI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5Eb3VidHMgaW4gZHJhZnQt aWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHls ZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46 MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIg eG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3 PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8v c2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8v d3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT48 c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6 dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K LnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0t PjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQg NiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrljY7mlofn u4bpu5E7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3 Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjIwNTAiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgR29lcmFuIFNlbGFu ZGVyLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgZ29uZSB0aHJvdWdoIHRoZSBPU0NP QVAgYW5kIEVESE9DIGRyYWZ0cy4gQW5kIEkgYW0gaGF2aW5nIGZldyBkb3VidHMgaW4gaXQuIFBs ZWFzZSBwcm92aWRlIHlvdXIgY29tbWVudHMgb24gaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoaXMgc3BlY2lmaWNhdGlvbiBtYWtlcyBoYW5kc2hha2UoRURIT0MpIGZvciBkZXJpdmluZyBt YXN0ZXIgc2VjcmV0IGFzIG9wdGlvbmFsLiBBbmQgYWxzbyBhIGNvbnN0cmFpbnQgbm9kZSBjYW4g c2tpcCBoYW5kc2hha2UgYW5kIGVzdGFibGlzaCBhIHNlY3VyZSBjaGFubmVsIGlmIG1hc3RlciBz ZWNyZXQgaXMgcHJlY29uZmlndXJlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBtYXkg bWFrZSBhIGNvbnN0cmFpbnQgbm9kZSB0byB1c2Ugc2FtZSBzZXNzaW9uIGtleXMgKHNlbmRlciBh bmQgcmVjZWl2ZXIga2V5KSBmb3IgbG9uZ2VyIGR1cmF0aW9uLCBpZiBzZXF1ZW5jZSBudW1iZXIg aXMgbm90IGV4aGF1c3RlZC4gT25seSBzb2x1dGlvbiBmb3IgcmVuZXdpbmcgc2Vzc2lvbiBrZXkg aXMgdG8gbmVnb3RpYXRlIG5ldyBtYXN0ZXIgc2VjcmV0IGJ5IHVzaW5nIEVESE9DLiBCdXQgRURI T0MNCiBzdXBwb3J0cyBvbmx5IFBTS19FQ0RIRSBhbmQgRUNEU0FfRUNESEUgbWVjaGFuaXNtLiBI ZXJlIEkgZmVlbCB3ZSBhcmUgbWlzc2luZyBQU0sgd2l0aG91dCAoRUMpREhFIG1lY2hhbmlzbSBm b3IgZXN0YWJsaXNoaW5nIHNlY3VyZSBjaGFubmVsLiBJIG1lYW4gd2UgYXJlIG1pc3NpbmcgVExT X1BTS19XSVRIX0FFU18xMjhfQ0NNXzgga2luZCBvZiBtZWNoYW5pc20uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkluIERUTFMsIFRMU19QU0tfV0lUSF9BRVNfMTI4X0NDTV84IHVzZXMgc2FtZSBQ U0sgZXZlcnkgdGltZSBmb3IgZGVyaXZpbmcgc2Vzc2lvbiBrZXlzLCBhbmQgaXQgZG9lc27igJl0 IHN1cHBvcnQgUEZTLiBCdXQgdGhlIHNlc3Npb24ga2V5IGRlcml2ZWQgaXMgZGlmZmVyZW50IGV2 ZXJ5IHRpbWUgd2l0aCB0aGUgaGVscCBvZiBjbGllbnQgYW5kIHNlcnZlciByYW5kb20uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNvIEkgZmVlbCB3ZSBjYW4gY29uc2lkZXIgb2YgZXhjaGFuZ2lu ZyByYW5kb20gbnVtYmVyIGFsc28gYWxvbmcgd2l0aCBLSUQgYW5kIFBhcnRpYWwgSVYgaW4gdGhl IDE8c3VwPnN0PC9zdXA+IFJlcXVlc3QgYW5kIFJlc3BvbnNlLiBUbyBhY2hpZXZlIFRMU19QU0tf V0lUSF9BRVNfMTI4X0NDTV84IGtpbmQgb2YgbWVjaGFuaXNtIGluIE9TQ29BUCB3aXRob3V0IEVD REhFIGV4Y2hhbmdlLiBGb3IgdGhpcyBhbnl3YXkNCiB3ZSBoYXZlIHRvIGNvbnNpZGVyIG11bHRp cGxlIGZhY3RvcnMgbGlrZSByZXBsYXkgYXR0YWNrLCBEb1MgYXR0YWNrIChjbGllbnQgaW5pdGlh dGluZyBrZXkgZGVyaXZhdGlvbiBmb3IgZWFjaCByZXF1ZXN0KSwgY2xpZW50IHJlYm9vdCBjYXNl IGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFzaG9rPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0i MTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjwhLS1b aWYgZ3RlIHZtbCAxXT48djpzaGFwZXR5cGUgaWQ9Il94MDAwMF90NzUiIGNvb3Jkc2l6ZT0iMjE2 MDAsMjE2MDAiIG86c3B0PSI3NSIgbzpwcmVmZXJyZWxhdGl2ZT0idCIgcGF0aD0ibUA0QDVsQDRA MTFAOUAxMUA5QDV4ZSIgZmlsbGVkPSJmIiBzdHJva2VkPSJmIj4NCjx2OnN0cm9rZSBqb2luc3R5 bGU9Im1pdGVyIiAvPg0KPHY6Zm9ybXVsYXM+DQo8djpmIGVxbj0iaWYgbGluZURyYXduIHBpeGVs TGluZVdpZHRoIDAiIC8+DQo8djpmIGVxbj0ic3VtIEAwIDEgMCIgLz4NCjx2OmYgZXFuPSJzdW0g MCAwIEAxIiAvPg0KPHY6ZiBlcW49InByb2QgQDIgMSAyIiAvPg0KPHY6ZiBlcW49InByb2QgQDMg MjE2MDAgcGl4ZWxXaWR0aCIgLz4NCjx2OmYgZXFuPSJwcm9kIEAzIDIxNjAwIHBpeGVsSGVpZ2h0 IiAvPg0KPHY6ZiBlcW49InN1bSBAMCAwIDEiIC8+DQo8djpmIGVxbj0icHJvZCBANiAxIDIiIC8+ DQo8djpmIGVxbj0icHJvZCBANyAyMTYwMCBwaXhlbFdpZHRoIiAvPg0KPHY6ZiBlcW49InN1bSBA OCAyMTYwMCAwIiAvPg0KPHY6ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4ZWxIZWlnaHQiIC8+DQo8 djpmIGVxbj0ic3VtIEAxMCAyMTYwMCAwIiAvPg0KPC92OmZvcm11bGFzPg0KPHY6cGF0aCBvOmV4 dHJ1c2lvbm9rPSJmIiBncmFkaWVudHNoYXBlb2s9InQiIG86Y29ubmVjdHR5cGU9InJlY3QiIC8+ DQo8bzpsb2NrIHY6ZXh0PSJlZGl0IiBhc3BlY3RyYXRpbz0idCIgLz4NCjwvdjpzaGFwZXR5cGU+ PHY6c2hhcGUgaWQ9InJpZEltZyIgbzpzcGlkPSJfeDAwMDBfczEwMjYiIHR5cGU9IiNfeDAwMDBf dDc1IiBhbHQ9IkNvbXBhbnlfbG9nbyIgc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO21hcmdpbi1s ZWZ0OjA7bWFyZ2luLXRvcDowO3dpZHRoOjc2LjVwdDtoZWlnaHQ6MjRwdDt6LWluZGV4OjE7dmlz aWJpbGl0eTp2aXNpYmxlO21zby13cmFwLXN0eWxlOnNxdWFyZTttc28td3JhcC1kaXN0YW5jZS1s ZWZ0OjA7bXNvLXdyYXAtZGlzdGFuY2UtdG9wOjA7bXNvLXdyYXAtZGlzdGFuY2UtcmlnaHQ6MDtt c28td3JhcC1kaXN0YW5jZS1ib3R0b206MDttc28tcG9zaXRpb24taG9yaXpvbnRhbDpsZWZ0O21z by1wb3NpdGlvbi1ob3Jpem9udGFsLXJlbGF0aXZlOnRleHQ7bXNvLXBvc2l0aW9uLXZlcnRpY2Fs OmFic29sdXRlO21zby1wb3NpdGlvbi12ZXJ0aWNhbC1yZWxhdGl2ZTpsaW5lJyBvOmFsbG93b3Zl cmxhcD0iZiI+DQo8djppbWFnZWRhdGEgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxRDJGQzAzLjJC N0JBMkIwIiBvOmhyZWY9ImZpbGU6Ly8vQzpcVXNlcnNccjAwOTAyNzM2XEFwcGxpY2F0aW9uJTIw RGF0YVxNaWNyb3NvZnRcU2lnbmF0dXJlc1xjb21wYW55X2xvZ28uanBnIiAvPg0KPHc6d3JhcCB0 eXBlPSJzcXVhcmUiIGFuY2hvcnk9ImxpbmUiLz4NCjwvdjpzaGFwZT48IVtlbmRpZl0tLT48IS0t W2lmICF2bWxdLS0+PGltZyB3aWR0aD0iMTAyIiBoZWlnaHQ9IjMyIiBzcmM9ImNpZDppbWFnZTAw MS5qcGdAMDFEMkZDMDMuMkI3QkEyQjAiIGFsaWduPSJsZWZ0IiBhbHQ9IkNvbXBhbnlfbG9nbyIg djpzaGFwZXM9InJpZEltZyI+PCEtLVtlbmRpZl0tLT48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6IzU5NTk1OSI+UmFqYSBBc2hvayBWIEs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6IzU5NTk1OSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj NTk1OTU5Ij5IdWF3ZWkgVGVjaG5vbG9naWVzPGJyPg0KQmFuZ2Fsb3JlLCBJbmRpYTxicj4NCjxh IGhyZWY9Imh0dHA6Ly93d3cuaHVhd2VpLmNvbSI+aHR0cDovL3d3dy5odWF3ZWkuY29tPC9hPiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50 ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk65a6L5L2TIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249 ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6 Z3JheSI+5pys6YKu5Lu25Y+K5YW26ZmE5Lu25ZCr5pyJ5Y2O5Li65YWs5Y+455qE5L+d5a+G5L+h 5oGv77yM5LuF6ZmQ5LqO5Y+R6YCB57uZ5LiK6Z2i5Zyw5Z2A5Lit5YiX5Ye655qE5Liq5Lq65oiW 576k57uE44CC56aBPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p bHk65Y2O5paH57uG6buRO2NvbG9yOmdyYXkiPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1D TiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6Z3JheSI+ 5q2i5Lu75L2V5YW25LuW5Lq65Lul5Lu75L2V5b2i5byP5L2/55So77yI5YyF5ous5L2G5LiN6ZmQ 5LqO5YWo6YOo5oiW6YOo5YiG5Zyw5rOE6Zyy44CB5aSN5Yi244CB5oiW5pWj5Y+R77yJ5pys6YKu 5Lu25LitPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk65Y2O 5paH57uG6buRO2NvbG9yOmdyYXkiPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6Z3JheSI+55qE5L+h 5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW 6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu5Lu277yBPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk65Y2O5paH57uG6buRO2NvbG9yOmdyYXki Pjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA3LjVwdDsgZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogZ3JheTsiPlRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0 YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdo aWNoDQo8YnI+DQppcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9z ZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCjxicj4NCmluZm9ybWF0 aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0 ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCjxicj4NCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwg b3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCA8YnI+ DQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KPGJyPg0KcGhvbmUgb3IgZW1h aWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCE8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv c3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D59897E7848E1goranselanderericssoncom_-- --_004_D59897E7848E1goranselanderericssoncom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: attachment; filename="image001.jpg"; size=6737; creation-date="Sat, 22 Jul 2017 06:42:49 GMT"; modification-date="Sat, 22 Jul 2017 06:42:49 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_D59897E7848E1goranselanderericssoncom_-- From nobody Fri Jul 21 23:47:38 2017 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 E6029129ABE for ; Fri, 21 Jul 2017 23:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=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 laXL5SQBRpKU for ; Fri, 21 Jul 2017 23:47:31 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0093.outbound.protection.outlook.com [104.47.41.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC68126BF6 for ; Fri, 21 Jul 2017 23:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6zqY6+GT/9NJwh6svtq3+1kwo81WqDxwFR3k4DWxDGQ=; b=kmmLVuN/AKT/4sxHAiGJkBXDT8ruHekUhPO7kV8e37GUhbseLdFl8kae9Nv6kaoxo1jD+RKBDCbscrh3+3osky7+NyO7Ydmj08nR86mwvG7zO1PyBY4EKoPSBVz64xiw3AxDpio++cvp3RCciEzkO2bDyZY7/YRfMN5LWBt3oNs= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Sat, 22 Jul 2017 06:47:27 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.1282.016; Sat, 22 Jul 2017 06:47:27 +0000 From: Michel Veillette To: Andy Bierman CC: Carsten Bormann , Core Thread-Topic: [core] yang cbor encoding without SID Thread-Index: AQHTATQrCEiVptWX80+aOopWb5cOWaJcaCuAgAAB64CAAAdyAIAABJeAgAFUMYCAAASKAIAABsVggAAVnACAAANLIIAADxMAgADpXACAAD4CkIAAJXuAgAAezQA= Date: Sat, 22 Jul 2017 06:47:27 +0000 Message-ID: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> In-Reply-To: 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@trilliantinc.com; x-originating-ip: [80.188.89.22] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR06MB2308; 7:G92keKmFMpiEGzW4RZvieP7QXL4ao72m7M/TSDX/+HZUqGPxoOO/MEBVdWWfM/jKfFv6X+vP/Pn48WjcXQxzx0IK1lR+0NK7p7GCMqfv3wTYZ1sCw4AoY4DmVJ/glI7Y3WJ94i/1RwoQR1XnYglcsLd1ST8uxzdOHVMMP0HC8JG3ooIaa/ZCwmxJr2F8AQAKHWfXRIfb1P5vbiqfUgT2AuFCR59Ph7qg/Dd0pLdgpjmupr91Bn8yyyDacdkfdjnkEZr272kwdJmeOMATLIWGF3OuT655PRJnXIVt0bQLcFv2EP1JsitxSCE1LLATqsoV/VaDr6pMl87NL2kxVNx4xt6yHtviMLbFzRZB6QQdKc3y7Xq8PGhFDKQfvXNn4qHY50D55AlzLD/ksuw7Fp7h9B8ljzl7VMBad+pwOCrGhFLDE9pKEnIOQ/Q660tCV/FzU/ZVJBB0Q6j92q0PuaKZ31IVYOeDsGuQBmQyZs6/nxxm3uOE3nf6/tyf7/wrmFHQ/z01BSN4EhjHUOgmdzsakwsxbgOY2SkNJW53WPqVFEiNZTW241TB+dAx7pwlY5DdhebVXtxIhUuHLRUIXPgiY6cVBOtyKyAmQrQ+Z7pUDKCHPVFX2Smu6Zbxcsgc7tjcSpPc6tdIjVihaYyo1M0blQHjT1wmsjFv9nidDof8m6K8oYQM/4nuN1dArjB5dZLE1BX4Zy4ykW/qpWsB1TOoBG54SsfjXjW8jNWS6Dt8zybCer4Jzn2bM/q+QfN0ylfsJgBQEXFQjU9qf86i89O3CYfXhdeouU3G690jbmHckpI= x-ms-office365-filtering-correlation-id: b7e63719-5878-49e1-39fd-08d4d0cd8469 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR06MB2308; x-ms-traffictypediagnostic: BN6PR06MB2308: x-exchange-antispam-report-test: UriScan:(209352067349851)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR06MB2308; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR06MB2308; x-forefront-prvs: 0376ECF4DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39850400002)(39410400002)(39400400002)(199003)(189002)(377454003)(24454002)(54356999)(2900100001)(55016002)(7736002)(4326008)(66066001)(99286003)(54896002)(8936002)(105586002)(6436002)(236005)(81156014)(53936002)(93886004)(3280700002)(6246003)(33656002)(54906002)(8676002)(81166006)(38730400002)(6506006)(25786009)(2906002)(50986999)(76176999)(6306002)(110136004)(9686003)(101416001)(106356001)(86362001)(2950100002)(5660300001)(6916009)(6116002)(102836003)(3846002)(7696004)(790700001)(97736004)(19609705001)(77096006)(68736007)(72206003)(229853002)(53546010)(74316002)(189998001)(478600001)(3660700001)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2308; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR06MB23088C017D8B90385667998FFEA50BN6PR06MB2308namp_" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2017 06:47:27.3983 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2308 Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 06:47:35 -0000 --_000_BN6PR06MB23088C017D8B90385667998FFEA50BN6PR06MB2308namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keQ0KDQpXZSBkbyByZWNvZ25pemUgdGhlIGFkZGl0aW9uYWwgcmlza3MgaWYgU0lEcyBh cmUgdW5tYW5hZ2VkLg0KVGhpcyBpcyB3aHkgd2Ugd29yayBhY3RpdmVseSBvbiB0aGUgZGV2ZWxv cG1lbnQgb2YgdGhlIHJlZ2lzdHJhdGlvbiBXRUIgc2l0ZS4NCkFzIHNvb24gYSBiZXRhIHZlcnNp b24gaXMgb25saW5lLCBJIGxldCB5b3UgdHJ5IGl0IHRvIHNlZSBpZiBpdCBhZGRyZXNzIHlvdXIg Y29uY2VybnMuDQoNClJlZ2FyZHMsDQpNaWNoZWwNCg0KRnJvbTogQW5keSBCaWVybWFuIFttYWls dG86YW5keUB5dW1hd29ya3MuY29tXQ0KU2VudDogU2F0dXJkYXksIEp1bHkgMjIsIDIwMTcgNjo1 MyBBTQ0KVG86IE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50aW5j LmNvbT4NCkNjOiBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz47IENvcmUgPGNvcmVAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2NvcmVdIHlhbmcgY2JvciBlbmNvZGluZyB3aXRob3V0IFNJ RA0KDQpIaSwNCg0KSSBhbSBub3QgZ29pbmcgdG8gZXhwbGFpbiBpdCBhbnltb3JlLg0KVGhlIG9y ZGVyIG1vc3Qgc3RhdGVtZW50cyBhcHBlYXIgaW4gYSBZQU5HIGZpbGUgaXMgaXJyZWxldmFudCB0 byB0aGUgc2VtYW50aWNzIG9mIHRoZSBZQU5HIG1vZHVsZQ0KZXhjZXB0ICgxKSBhdXRvLW51bWJl cmluZyBvZiBwb3NpdGlvbiBvciB2YWx1ZSBhbmQgKDIpIGV2YWx1YXRpb24gb3JkZXIgb2YgdW5p b24gbWVtYmVyIHR5cGVzLg0KS2VlcGluZyB0aGUgU0lEIGZpbGVzIHBlcmZlY3RseSBhbGlnbmVk IHdpdGggdGhlIFlBTkcgZmllIGlzIGEgY2hhbGxlbmdlLiBUaGVyZSBpcyBubyB3YXkgZm9yDQph IG1vZHVsZSB0byBnZXQgb3V0IG9mIHN5bmNoIHdpdGggaXRzZWxmIHdydC8gc2NoZW1hIG5vZGUg bmFtaW5nIG9yIGluc3RhbmNlIHZhbHVlIGV2YWx1YXRpb24uDQoNClNvIG9mIGNvdXJzZSB0aGUg dG9vbHMgd2lsbCBiZSBwZXJmZWN0IGFuZCB0aGUgZGV2ZWxvcGVycyB3aWxsIGJlIHBlcmZlY3QN CmFuZCBuZXZlciBsZXQgdGhlIHJlZ2lzdHJpZXMgYW5kIGltcGxlbWVudGF0aW9ucyBnZXQgb3V0 IG9mIHN5bmNoLg0KT3RoZXJ3aXNlIFNJRCB3aWxsIHByb2R1Y2UgaW5jb3JyZWN0IHJlc3VsdHMu DQpJZiB5b3UgY2Fubm90IHJlY29nbml6ZSB0aGUgYWRkaXRpb25hbCByaXNrcyBpbnRyb2R1Y2Vk IGJ5IFNJRCwNCnlvdSBwcm9iYWJseSBuZWVkIHRvIHN0dWR5IFJGQyA3OTUwIGEgYml0IG1vcmUu DQoNCg0KQW5keQ0KDQoNCg0KT24gRnJpLCBKdWwgMjEsIDIwMTcgYXQgNzo0NSBQTSwgTWljaGVs IFZlaWxsZXR0ZSA8TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPG1haWx0bzpNaWNo ZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20+PiB3cm90ZToNCkhpIEFuZHkNCg0KSSB3aWxs IGFncmVlIHdpdGggeW91IG9uIG9uZSBwb2ludCwgc29tZSBpbXBsZW1lbnRlcnMgbWlnaHQgaGF2 ZSBkZWZpbmVkIGNhcmVsZXNzbHkgJ3ZhbHVlJyBhbmQgJ3Bvc2l0aW9uJyBiZWNhdXNlIHRoZXNl IHN0YXRlbWVudHMgd2FzIG5vdCB1c2VmdWwgZm9yIHRoZWlyIE5FVENPTkYgb3IgUkVTVENPTkYg aW1wbGVtZW50YXRpb25zLiBUaGlzIGlzIG5vdCBhbiBpc3N1ZSB3aXRoIFlBTkcgYnV0IHdpdGgg dGhvc2UgZGV2ZWxvcGVycy4gSSBkb24ndCBhZ3JlZSB0aGF0IHRoZSBkZXNpZ25lcnMgb2YgdGhl IFlBTkcgbW9kZWxpbmcgbGFuZ3VhZ2UgcHV0IHRoZXNlIHN0YXRlbWVudHMgaW4gdGhlIHNjaGVt YSBkZWZpbml0aW9uIGp1c3QgZm9yIGZ1bi4gVGhleSBjZXJ0YWlubHkgZm9yZXNhdyB0aGUgdGlt ZSBZQU5HIHdpbGwgYmUgaW1wbGVtZW50ZWQgaW4gYmluYXJ5Lg0KDQpUaGUgaW1wYWN0cyBvbiB0 aGUgeWFuZyB0byBjYm9yIG1hcHBpbmcgaXMgaG93ZXZlciBsaW1pdGVkLiBUaGUgWUFORyBzcGVj aWZpY2F0aW9uIGFuZCBZQU5HIHZhbGlkYXRvcnMgZ3VhcmFudGVlIHRoZSB1bmlxdWVuZXNzIG9m IGVudW1lcmF0aW9uIHZhbHVlcyBhbmQgYml0cyBwb3NpdGlvbnMuIFdoZW4gdXNlZCBpbiBhIHVu aW9uLCB0aGUgY29uY2x1c2lvbiBvZiB0aGUgZGVzaWduIHRlYW0gd2FzIHRvIGFkZCBhIGNoZWNr IGluIHZhbGlkYXRpb24gdG9vbHMgdG8gZ2VuZXJhdGUgYSB3YXJuaW5nIHdoZW4gZHVwbGljYXRl IHZhbHVlcyBvciBwb3NpdGlvbnMgYXJlIGRldGVjdGVkLiBTdWNoIGNoZWNrIGNhbiBiZSBwYXJ0 IG9mIGEgdmFsaWRhdGlvbiBwZXJmb3JtZWQgd2hlbiByZWdpc3RlcmluZyBTSURzLiBTaW5jZSB0 aG9zZSB2YWx1ZXMgb3IgcG9zaXRpb24gYXJlIG5vdCBsaWtlbHkgdG8gaGF2ZSBiZWVuIHVzZWQs IGZpeGluZyB0aGVtIHdvbid0IGhhdmUgYW55IGltcGFjdHMgb24gcHJpb3IgaW1wbGVtZW50YXRp b25zLiBOb2JvZHkgaG93ZXZlciBoYXZlIHJlcG9ydGVkIHNvIGZhciBhbnkgaW5zdGFuY2VzIG9m IHRoaXMgaXNzdWUuDQoNCkkgZG9uJ3Qgc2VlIGFueSByZWFzb25zIHdoeSBZQU5HIHdvbid0IGJl IHN1aXRhYmxlIGZvciBiaW5hcnkgaW1wbGVtZW50YXRpb25zIGFuZCBkZXNpZ25lcnMgb2YgdGhp cyBtb2RlbGluZyBsYW5ndWFnZSBzaG91bGQgYmUgcHJvdWQgb2YgdGhpcyBhY2NvbXBsaXNobWVu dC4NCg0KUmVnYXJkcywNCk1pY2hlbA0KDQoNCkZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFu ZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPl0NClNlbnQ6IFNhdHVy ZGF5LCBKdWx5IDIyLCAyMDE3IDEyOjU3IEFNDQpUbzogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6 aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9yZz4+DQpDYzogTWljaGVsIFZlaWxsZXR0ZSA8TWljaGVs LlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPG1haWx0bzpNaWNoZWwuVmVpbGxldHRlQHRyaWxs aWFudGluYy5jb20+PjsgQ29yZSA8Y29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSZTogW2NvcmVdIHlhbmcgY2JvciBlbmNvZGluZyB3aXRob3V0IFNJRA0KDQoN Cg0KT24gRnJpLCBKdWwgMjEsIDIwMTcgYXQgMjowMSBBTSwgQ2Fyc3RlbiBCb3JtYW5uIDxjYWJv QHR6aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9yZz4+IHdyb3RlOg0KDQo+IE9uIEp1bCAyMSwgMjAx NywgYXQgMTA6MTcsIE1pY2hlbCBWZWlsbGV0dGUgPE1pY2hlbC5WZWlsbGV0dGVAdHJpbGxpYW50 aW5jLmNvbTxtYWlsdG86TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRpbmMuY29tPj4gd3JvdGU6 DQo+DQo+IEhpIEFuZHkNCj4NCj4gQWJvdXQgdGhlIHVuaW9uLCB0aGUgQ0JPUiBlbmNvZGluZyBh dm9pZCBhbnkgYW1iaWd1aXRpZXMgYmV0d2VlbiBkYXRhdHlwZXMsIHNvbWV0aGluZyBub3QgYXJj aGl2ZWQgYnkgdGhlIHhtbCBtYXBwaW5nIGFuZCBwYXJ0aWFsbHkgYXJjaGl2ZWQgYnkgSlNPTi4g Rm9yIGV4YW1wbGUsIGluIHhtbCwgaXQgaXMgaW1wb3NzaWJsZSB0byBkaWZmZXJlbnRpYXRlIHRo ZSBzdHJpbmcgIjEiIGZyb20gdGhlIGludGVnZXIgMS4NCg0KSSB0aGluayBBbmR54oCZcyBwb2lu dCBpcyB0aGF0IHRoZSBzZXJpYWxpemF0aW9uIGlkaW9zeW5jcmFzaWVzIHRoYXQgbGVhayBpbnRv IFlBTkcgYXJlIGF0IHRoaXMgcG9pbnQgd2VsbC1rbm93biBpZiBpdCBpcyB0aGUgaWRpb3N5bmNy YXNpZXMgZnJvbSB0aGUgWE1MIHNlcmlhbGl6YXRpb24gKHdoaWNoIGhhdmUgYmVlbiBtYWludGFp bmVkIHF1aXRlIHdlbGwgaW4gdGhlIEpTT04gc2VyaWFsaXphdGlvbiwgdG9vKSBidXQgbm90IHNv IGZvciB0aGUgQ0JPUiBzZXJpYWxpemF0aW9uLiAgV2l0aCBzb21lIGVmZm9ydCwgaXQgaXMgcG9z c2libGUgdG8gd3JpdGUgWUFORyB0aGF0IGV4cG9zZXMgdGhlc2UgaWRpb3N5bmNyYXNpZXM6DQoN Cg0KV2hhdCBJIG1lYW4gaXMgdGhhdCBYTUwgYW5kIEpTT04gZW5jb2RpbmdzIGFsaWduIHdpdGgg WUFORyBieSBkZXNpZ24uDQpUaGUgWUFORyBpZGVudGlmaWVycyBhcmUgc3RyaW5ncy4gVGhlIHZh bHVlIHNwYWNlcyBhcmUgc3BlY2lmaWVkIHN1Y2ggdGhhdCBhbnkNCmNvbGxpc2lvbiBpcyBpbnZh bGlkIFlBTkcuDQoNClRoZSAgWE1ML0pTT04gZW5jb2RpbmcgZm9ybWF0cyBhcmUgInByb3RlY3Rl ZCIgYnkgdGhlIHJ1bGVzIG9mIFlBTkcuDQpJdCBpcyBub3QgcG9zc2libGUgZm9yIGlkZW50aWZp ZXIgb3IgdmFsdWUgc3BhY2UgZXJyb3JzIHRvIG9jY3VyIGlmIHRoZSBZQU5HIG1vZHVsZSBpcyB2 YWxpZC4NClRoaXMgcHJvdGVjdGlvbiBpcyBidWlsdCBpbnRvIHRoZSBkYXRhIG1vZGVsaW5nIGxh bmd1YWdlIGJ5IGRlc2lnbiBmb3IgbnVtYmVyZWQNCmlkZW50aWZpZXJzIGFzIHdlbGwgKGUuZy4s IFNNSXYyLCBaaWdiZWUsIGV0Yy4pDQoNCkJ1dCBTSUQgaXMgY29tcGxldGVseSB1bnByb3RlY3Rl ZCBmcm9tIHRoZXNlIGVycm9ycyBiZWNhdXNlIHRoZSBTSUQgaWRlbnRpZmllciBhbmQNCmRhdGEg dHlwZSBlbmNvZGluZyBjYW4gY2hhbmdlIGV2ZW4gdGhvdWdoIG5vIFlBTkcgcnVsZXMgaGF2ZSBi ZWVuIHZpb2xhdGVkLg0KU3RhdGVtZW50IHBvc2l0aW9uIGNhcnJpZXMgKGFsbW9zdCkgbm8gc2Vt YW50aWMgb3IgaWRlbnRpZmllciB2YWx1ZSBhdCBhbGwgaW4gWUFORy4NClJlbHkgb24gaXQgYXQg eW91ciBvd24gcmlzay4NCg0KDQo+IFRoZSBvbmx5IGFtYmlndWl0aWVzIG5vdCByZXNvbHZlZCBi eSB0aGUgQ0JPUiBlbmNvZGluZyBpcyBhbiB1bmlvbiBjb21wb3NlZCBvZiB0d28gZW51bWVyYXRp b25zIGRlZmluaW5nIHRoZSBzYW1lIHZhbHVlIGFzc29jaWF0ZWQgdG8gZGlmZmVyZW50IG1lYW5p bmdzLiBJIHdpbGwgYXJndWUgdGhhdCBzdWNoIGRlZmluaXRpb24gaXMgaW5jb3JyZWN0Lg0KDQpO b3Qgc3VyZSB0aGF0IGlzIHRoZSBvbmx5IGNhc2UsIGJ1dCBpdCBzdGlsbCBpcyBhIGNhc2UuICBS aWdodCBub3csIHRoZSBZQU5HIHRvb2xzIGRvbuKAmXQga25vdyBhYm91dCB0aGVzZSBjYXNlcyB5 ZXQuICBTbyBoYXZpbmcsIHNheSwgYSBweWFuZyBleHRlbnNpb24gdGhhdCB0ZXN0cyBmb3IgdGhp cyBtaWdodCBiZSBhIHVzZWZ1bCB0aGluZyB0byBoYXZlLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoN CkFuZHkNCg0KDQo= --_000_BN6PR06MB23088C017D8B90385667998FFEA50BN6PR06MB2308namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBBbmR5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2UgZG8gcmVjb2duaXplIHRoZSBhZGRpdGlvbmFs IHJpc2tzIGlmIFNJRHMgYXJlIHVubWFuYWdlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIHdo eSB3ZSB3b3JrIGFjdGl2ZWx5IG9uIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgcmVnaXN0cmF0aW9u IFdFQiBzaXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFzIHNvb24gYSBiZXRhIHZlcnNpb24gaXMgb25s aW5lLCBJIGxldCB5b3UgdHJ5IGl0IHRvIHNlZSBpZiBpdCBhZGRyZXNzIHlvdXIgY29uY2VybnMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5NaWNoZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3 b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEp1bHkgMjIsIDIwMTcgNjo1 MyBBTTxicj4NCjxiPlRvOjwvYj4gTWljaGVsIFZlaWxsZXR0ZSAmbHQ7TWljaGVsLlZlaWxsZXR0 ZUB0cmlsbGlhbnRpbmMuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQ2Fyc3RlbiBCb3JtYW5uICZs dDtjYWJvQHR6aS5vcmcmZ3Q7OyBDb3JlICZsdDtjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW2NvcmVdIHlhbmcgY2JvciBlbmNvZGluZyB3aXRob3V0IFNJRDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3QgZ29pbmcgdG8gZXhwbGFpbiBpdCBh bnltb3JlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIG9yZGVyIG1vc3Qgc3RhdGVtZW50cyBhcHBlYXIgaW4gYSBZQU5HIGZpbGUgaXMgaXJy ZWxldmFudCB0byB0aGUgc2VtYW50aWNzIG9mIHRoZSBZQU5HIG1vZHVsZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZXhjZXB0ICgxKSBhdXRvLW51 bWJlcmluZyBvZiBwb3NpdGlvbiBvciB2YWx1ZSBhbmQgKDIpIGV2YWx1YXRpb24gb3JkZXIgb2Yg dW5pb24gbWVtYmVyIHR5cGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+S2VlcGluZyB0aGUgU0lEIGZpbGVzIHBlcmZlY3RseSBhbGlnbmVkIHdp dGggdGhlIFlBTkcgZmllIGlzIGEgY2hhbGxlbmdlLiBUaGVyZSBpcyBubyB3YXkgZm9yPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hIG1vZHVsZSB0 byBnZXQgb3V0IG9mIHN5bmNoIHdpdGggaXRzZWxmIHdydC8gc2NoZW1hIG5vZGUgbmFtaW5nIG9y IGluc3RhbmNlIHZhbHVlIGV2YWx1YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIG9mIGNvdXJzZSB0aGUgdG9vbHMgd2lsbCBiZSBw ZXJmZWN0IGFuZCB0aGUgZGV2ZWxvcGVycyB3aWxsIGJlIHBlcmZlY3Q8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCBuZXZlciBsZXQgdGhlIHJl Z2lzdHJpZXMgYW5kIGltcGxlbWVudGF0aW9ucyBnZXQgb3V0IG9mIHN5bmNoLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3RoZXJ3aXNlIFNJRCB3 aWxsIHByb2R1Y2UgaW5jb3JyZWN0IHJlc3VsdHMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IGNhbm5vdCByZWNvZ25pemUg dGhlIGFkZGl0aW9uYWwgcmlza3MgaW50cm9kdWNlZCBieSBTSUQsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj55b3UgcHJvYmFibHkgbmVlZCB0byBz dHVkeSBSRkMgNzk1MCBhIGJpdCBtb3JlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEp1bCAyMSwgMjAxNyBhdCA3OjQ1IFBNLCBN aWNoZWwgVmVpbGxldHRlICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGVsLlZlaWxsZXR0ZUB0cmls bGlhbnRpbmMuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRp bmMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEFuZHk8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkkgd2lsbCBhZ3JlZSB3aXRoIHlvdSBvbiBvbmUgcG9pbnQsIHNvbWUgaW1wbGVt ZW50ZXJzIG1pZ2h0IGhhdmUgZGVmaW5lZCBjYXJlbGVzc2x5ICd2YWx1ZScgYW5kICdwb3NpdGlv bicgYmVjYXVzZSB0aGVzZSBzdGF0ZW1lbnRzIHdhcyBub3QgdXNlZnVsIGZvciB0aGVpciBORVRD T05GIG9yIFJFU1RDT05GDQogaW1wbGVtZW50YXRpb25zLiBUaGlzIGlzIG5vdCBhbiBpc3N1ZSB3 aXRoIFlBTkcgYnV0IHdpdGggdGhvc2UgZGV2ZWxvcGVycy4gSSBkb24ndCBhZ3JlZSB0aGF0IHRo ZSBkZXNpZ25lcnMgb2YgdGhlIFlBTkcgbW9kZWxpbmcgbGFuZ3VhZ2UgcHV0IHRoZXNlIHN0YXRl bWVudHMgaW4gdGhlIHNjaGVtYSBkZWZpbml0aW9uIGp1c3QgZm9yIGZ1bi4gVGhleSBjZXJ0YWlu bHkgZm9yZXNhdyB0aGUgdGltZSBZQU5HIHdpbGwgYmUgaW1wbGVtZW50ZWQgaW4NCiBiaW5hcnku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgaW1wYWN0cyBvbiB0aGUgeWFuZyB0byBj Ym9yIG1hcHBpbmcgaXMgaG93ZXZlciBsaW1pdGVkLiBUaGUgWUFORyBzcGVjaWZpY2F0aW9uIGFu ZCBZQU5HIHZhbGlkYXRvcnMgZ3VhcmFudGVlIHRoZSB1bmlxdWVuZXNzIG9mIGVudW1lcmF0aW9u IHZhbHVlcyBhbmQgYml0cyBwb3NpdGlvbnMuIFdoZW4gdXNlZA0KIGluIGEgdW5pb24sIHRoZSBj b25jbHVzaW9uIG9mIHRoZSBkZXNpZ24gdGVhbSB3YXMgdG8gYWRkIGEgY2hlY2sgaW4gdmFsaWRh dGlvbiB0b29scyB0byBnZW5lcmF0ZSBhIHdhcm5pbmcgd2hlbiBkdXBsaWNhdGUgdmFsdWVzIG9y IHBvc2l0aW9ucyBhcmUgZGV0ZWN0ZWQuIFN1Y2ggY2hlY2sgY2FuIGJlIHBhcnQgb2YgYSB2YWxp ZGF0aW9uIHBlcmZvcm1lZCB3aGVuIHJlZ2lzdGVyaW5nIFNJRHMuIFNpbmNlIHRob3NlIHZhbHVl cyBvciBwb3NpdGlvbg0KIGFyZSBub3QgbGlrZWx5IHRvIGhhdmUgYmVlbiB1c2VkLCBmaXhpbmcg dGhlbSB3b24ndCBoYXZlIGFueSBpbXBhY3RzIG9uIHByaW9yIGltcGxlbWVudGF0aW9ucy4gTm9i b2R5IGhvd2V2ZXIgaGF2ZSByZXBvcnRlZCBzbyBmYXIgYW55IGluc3RhbmNlcyBvZiB0aGlzIGlz c3VlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkb24ndCBzZWUgYW55IHJlYXNvbnMg d2h5IFlBTkcgd29uJ3QgYmUgc3VpdGFibGUgZm9yIGJpbmFyeSBpbXBsZW1lbnRhdGlvbnMgYW5k IGRlc2lnbmVycyBvZiB0aGlzIG1vZGVsaW5nIGxhbmd1YWdlIHNob3VsZCBiZSBwcm91ZCBvZiB0 aGlzIGFjY29tcGxpc2htZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRlItQ0EiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJGUi1DQSI+TWljaGVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkZSLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gQW5keSBCaWVybWFuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFuZHlA eXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEp1bHkgMjIsIDIwMTcgMTI6NTcgQU08YnI+DQo8 Yj5Ubzo8L2I+IENhcnN0ZW4gQm9ybWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmNhYm9AdHppLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBN aWNoZWwgVmVpbGxldHRlICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGVsLlZlaWxsZXR0ZUB0cmls bGlhbnRpbmMuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGVsLlZlaWxsZXR0ZUB0cmlsbGlhbnRp bmMuY29tPC9hPiZndDs7IENvcmUgJmx0OzxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+Y29yZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbY29yZV0geWFuZyBjYm9yIGVuY29kaW5nIHdpdGhvdXQgU0lEPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIEp1bCAyMSwgMjAxNyBhdCAyOjAxIEFNLCBDYXJz dGVuIEJvcm1hbm4gJmx0OzxhIGhyZWY9Im1haWx0bzpjYWJvQHR6aS5vcmciIHRhcmdldD0iX2Js YW5rIj5jYWJvQHR6aS5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQomZ3Q7IE9uIEp1bCAyMSwgMjAxNywgYXQgMTA6MTcsIE1pY2hlbCBWZWlsbGV0dGUg Jmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb20iIHRh cmdldD0iX2JsYW5rIj5NaWNoZWwuVmVpbGxldHRlQHRyaWxsaWFudGluYy5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBBbmR5PGJyPg0KJmd0Ozxicj4NCiZndDsgQWJv dXQgdGhlIHVuaW9uLCB0aGUgQ0JPUiBlbmNvZGluZyBhdm9pZCBhbnkgYW1iaWd1aXRpZXMgYmV0 d2VlbiBkYXRhdHlwZXMsIHNvbWV0aGluZyBub3QgYXJjaGl2ZWQgYnkgdGhlIHhtbCBtYXBwaW5n IGFuZCBwYXJ0aWFsbHkgYXJjaGl2ZWQgYnkgSlNPTi4gRm9yIGV4YW1wbGUsIGluIHhtbCwgaXQg aXMgaW1wb3NzaWJsZSB0byBkaWZmZXJlbnRpYXRlIHRoZSBzdHJpbmcgJnF1b3Q7MSZxdW90OyBm cm9tIHRoZSBpbnRlZ2VyIDEuPGJyPg0KPGJyPg0KSSB0aGluayBBbmR54oCZcyBwb2ludCBpcyB0 aGF0IHRoZSBzZXJpYWxpemF0aW9uIGlkaW9zeW5jcmFzaWVzIHRoYXQgbGVhayBpbnRvIFlBTkcg YXJlIGF0IHRoaXMgcG9pbnQgd2VsbC1rbm93biBpZiBpdCBpcyB0aGUgaWRpb3N5bmNyYXNpZXMg ZnJvbSB0aGUgWE1MIHNlcmlhbGl6YXRpb24gKHdoaWNoIGhhdmUgYmVlbiBtYWludGFpbmVkIHF1 aXRlIHdlbGwgaW4gdGhlIEpTT04gc2VyaWFsaXphdGlvbiwgdG9vKSBidXQgbm90IHNvIGZvciB0 aGUgQ0JPUg0KIHNlcmlhbGl6YXRpb24uJm5ic3A7IFdpdGggc29tZSBlZmZvcnQsIGl0IGlzIHBv c3NpYmxlIHRvIHdyaXRlIFlBTkcgdGhhdCBleHBvc2VzIHRoZXNlIGlkaW9zeW5jcmFzaWVzOjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5XaGF0IEkgbWVhbiBpcyB0aGF0IFhNTCBhbmQgSlNPTiBlbmNvZGluZ3MgYWxp Z24gd2l0aCBZQU5HIGJ5IGRlc2lnbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIFlBTkcgaWRlbnRpZmllcnMgYXJlIHN0cmluZ3MuIFRo ZSB2YWx1ZSBzcGFjZXMgYXJlIHNwZWNpZmllZCBzdWNoIHRoYXQgYW55PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmNvbGxpc2lvbiBpcyBpbnZh bGlkIFlBTkcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGUgJm5ic3A7WE1ML0pTT04gZW5jb2RpbmcgZm9ybWF0cyBhcmUgJnF1b3Q7 cHJvdGVjdGVkJnF1b3Q7IGJ5IHRoZSBydWxlcyBvZiBZQU5HLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBpcyBub3QgcG9zc2libGUgZm9y IGlkZW50aWZpZXIgb3IgdmFsdWUgc3BhY2UgZXJyb3JzIHRvIG9jY3VyIGlmIHRoZSBZQU5HIG1v ZHVsZSBpcyB2YWxpZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhpcyBwcm90ZWN0aW9uIGlzIGJ1aWx0IGludG8gdGhlIGRhdGEgbW9kZWxp bmcgbGFuZ3VhZ2UgYnkgZGVzaWduIGZvciBudW1iZXJlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5pZGVudGlmaWVycyBhcyB3ZWxsIChlLmcu LCBTTUl2MiwgWmlnYmVlLCBldGMuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QnV0IFNJRCBpcyBjb21wbGV0ZWx5IHVucHJvdGVjdGVk IGZyb20gdGhlc2UgZXJyb3JzIGJlY2F1c2UgdGhlIFNJRCBpZGVudGlmaWVyIGFuZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5kYXRhIHR5cGUg ZW5jb2RpbmcgY2FuIGNoYW5nZSBldmVuIHRob3VnaCBubyBZQU5HIHJ1bGVzIGhhdmUgYmVlbiB2 aW9sYXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+U3RhdGVtZW50IHBvc2l0aW9uIGNhcnJpZXMgKGFsbW9zdCkgbm8gc2VtYW50aWMgb3Ig aWRlbnRpZmllciB2YWx1ZSBhdCBhbGwgaW4gWUFORy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVseSBvbiBpdCBhdCB5b3VyIG93biByaXNr LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7IFRoZSBvbmx5 IGFtYmlndWl0aWVzIG5vdCByZXNvbHZlZCBieSB0aGUgQ0JPUiBlbmNvZGluZyBpcyBhbiB1bmlv biBjb21wb3NlZCBvZiB0d28gZW51bWVyYXRpb25zIGRlZmluaW5nIHRoZSBzYW1lIHZhbHVlIGFz c29jaWF0ZWQgdG8gZGlmZmVyZW50IG1lYW5pbmdzLiBJIHdpbGwgYXJndWUgdGhhdCBzdWNoIGRl ZmluaXRpb24NCiBpcyBpbmNvcnJlY3QuPGJyPg0KPGJyPg0KTm90IHN1cmUgdGhhdCBpcyB0aGUg b25seSBjYXNlLCBidXQgaXQgc3RpbGwgaXMgYSBjYXNlLiZuYnNwOyBSaWdodCBub3csIHRoZSBZ QU5HIHRvb2xzIGRvbuKAmXQga25vdyBhYm91dCB0aGVzZSBjYXNlcyB5ZXQuJm5ic3A7IFNvIGhh dmluZywgc2F5LCBhIHB5YW5nIGV4dGVuc2lvbiB0aGF0IHRlc3RzIGZvciB0aGlzIG1pZ2h0IGJl IGEgdXNlZnVsIHRoaW5nIHRvIGhhdmUuPGJyPg0KPGJyPg0KR3LDvMOfZSwgQ2Fyc3RlbjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR06MB23088C017D8B90385667998FFEA50BN6PR06MB2308namp_-- From nobody Sat Jul 22 00:43:37 2017 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 B2DA1131BFF for ; Sat, 22 Jul 2017 00:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYVcsKLoUwhr for ; Sat, 22 Jul 2017 00:43:33 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 09D6C126B6E for ; Sat, 22 Jul 2017 00:43:32 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id v139so1094542wmv.0 for ; Sat, 22 Jul 2017 00:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ufXKMp92LphkXcbfD+7xGnyj8+qGpuEz4A1igDHErWQ=; b=0F4Uw3a4wvsWCUv/bYuVGrPhd6IwUsM5TvGLccklD85BvFzkh8GyMzxVQDsDp8pYv8 TayMKaApT2brt5g92S8ZZUm8Hvbn07gz8clzEZyAs3mEM0Z9e+WZXu/Lxyl2ZKxztD8p InXUQz1Jx0vPzsH0qFf1s2q8y0T43PkKHpv6Ukve0xDzR71DZaGL7vpkCfFrs6mauVXO 7QRudS2UkQVjcDk5obnUM8NB4LwKiZXf1PhBFJF8PgCuqkIFCLSqQ7qnOILCivNiQunX ua/sfwO0szYiido2XFR7bgV9+f0XfHn5BY0iKcRHaVyGFw9bYAyhTUXPvBg0sglHXV3n 3Rtg== 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=ufXKMp92LphkXcbfD+7xGnyj8+qGpuEz4A1igDHErWQ=; b=PzHtUbZbNF7Ize0fqYObfyfFQRuMpuwUGwG/XP8GmtvX2W8cbODcQnDPhaUKwGgzo1 vBJcorjMpvPLMtkZxEppX16t64ovUGl5Stz1kgDAX7Q/MEAEHlBeuViEG6BGeX8JwOS8 OrlZN2OX+Blh4S3dFvDApxT9RAkiVlexsuH7imHoQVCOFdnhVpwU0W3d/cm4ywbV9ztG 4v5sLIa13AzbsRGgl0xBGZGf0dCIqTHuKblMz5h5sI9rZx2u88isgqjWyGJNXBCV0N0L xTUKei8TDc6yAPG19oMZpaYjQctEwz3z57Z2BBDA+vuqa4Iv3ljdFrA6FW9FqY5vHu61 zmjQ== X-Gm-Message-State: AIVw110Kgwk9izbDJ+Sxg+dEgYPWPhoiqezsk7mlIWtq9VbtrhkYtyfV QqfsNakMKGkXHmOetK4JXKVSN6SczDAd X-Received: by 10.28.7.19 with SMTP id 19mr904883wmh.23.1500709411193; Sat, 22 Jul 2017 00:43:31 -0700 (PDT) MIME-Version: 1.0 References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> In-Reply-To: From: Andy Bierman Date: Sat, 22 Jul 2017 07:43:20 +0000 Message-ID: To: Michel Veillette Cc: Carsten Bormann , Core Content-Type: multipart/alternative; boundary="001a114432ac5d9ac80554e3233e" Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 07:43:36 -0000 --001a114432ac5d9ac80554e3233e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 22, 2017 at 08:47 Michel Veillette < Michel.Veillette@trilliantinc.com> wrote: > Hi Andy > > I think 2 sets of media types addresses all my concerns. It is very simple to define a YANG to CBOR encoding that aligns with the standard data naming and instance value encoding. It is very easy to use the Accept header to insure interoperability. This "plain" encoding can be quite useful for RESTCONF. We have already implemented RESTCONF over CoAP and plan to use it for that as well. Andy > We do recognize the additional risks if SIDs are unmanaged. > > This is why we work actively on the development of the registration WEB > site. > > As soon a beta version is online, I let you try it to see if it address > your concerns. > > > > Regards, > > Michel > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Saturday, July 22, 2017 6:53 AM > *To:* Michel Veillette > *Cc:* Carsten Bormann ; Core > > > *Subject:* Re: [core] yang cbor encoding without SID > > > > Hi, > > > > I am not going to explain it anymore. > > The order most statements appear in a YANG file is irrelevant to the > semantics of the YANG module > > except (1) auto-numbering of position or value and (2) evaluation order o= f > union member types. > > Keeping the SID files perfectly aligned with the YANG fie is a challenge. > There is no way for > > a module to get out of synch with itself wrt/ schema node naming or > instance value evaluation. > > > > So of course the tools will be perfect and the developers will be perfect > > and never let the registries and implementations get out of synch. > > Otherwise SID will produce incorrect results. > > If you cannot recognize the additional risks introduced by SID, > > you probably need to study RFC 7950 a bit more. > > > > > > Andy > > > > > > > > On Fri, Jul 21, 2017 at 7:45 PM, Michel Veillette < > Michel.Veillette@trilliantinc.com> wrote: > > Hi Andy > > > > I will agree with you on one point, some implementers might have defined > carelessly 'value' and 'position' because these statements was not useful > for their NETCONF or RESTCONF implementations. This is not an issue with > YANG but with those developers. I don't agree that the designers of the > YANG modeling language put these statements in the schema definition just > for fun. They certainly foresaw the time YANG will be implemented in bina= ry. > > > > The impacts on the yang to cbor mapping is however limited. The YANG > specification and YANG validators guarantee the uniqueness of enumeration > values and bits positions. When used in a union, the conclusion of the > design team was to add a check in validation tools to generate a warning > when duplicate values or positions are detected. Such check can be part o= f > a validation performed when registering SIDs. Since those values or > position are not likely to have been used, fixing them won't have any > impacts on prior implementations. Nobody however have reported so far any > instances of this issue. > > > > I don't see any reasons why YANG won't be suitable for binary > implementations and designers of this modeling language should be proud o= f > this accomplishment. > > > > Regards, > > Michel > > > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Saturday, July 22, 2017 12:57 AM > *To:* Carsten Bormann > *Cc:* Michel Veillette ; Core < > core@ietf.org> > *Subject:* Re: [core] yang cbor encoding without SID > > > > > > > > On Fri, Jul 21, 2017 at 2:01 AM, Carsten Bormann wrote: > > > > On Jul 21, 2017, at 10:17, Michel Veillette < > Michel.Veillette@trilliantinc.com> wrote: > > > > Hi Andy > > > > About the union, the CBOR encoding avoid any ambiguities between > datatypes, something not archived by the xml mapping and partially archiv= ed > by JSON. For example, in xml, it is impossible to differentiate the strin= g > "1" from the integer 1. > > I think Andy=E2=80=99s point is that the serialization idiosyncrasies tha= t leak > into YANG are at this point well-known if it is the idiosyncrasies from t= he > XML serialization (which have been maintained quite well in the JSON > serialization, too) but not so for the CBOR serialization. With some > effort, it is possible to write YANG that exposes these idiosyncrasies: > > > > > > What I mean is that XML and JSON encodings align with YANG by design. > > The YANG identifiers are strings. The value spaces are specified such tha= t > any > > collision is invalid YANG. > > > > The XML/JSON encoding formats are "protected" by the rules of YANG. > > It is not possible for identifier or value space errors to occur if the > YANG module is valid. > > This protection is built into the data modeling language by design for > numbered > > identifiers as well (e.g., SMIv2, Zigbee, etc.) > > > > But SID is completely unprotected from these errors because the SID > identifier and > > data type encoding can change even though no YANG rules have been violate= d. > > Statement position carries (almost) no semantic or identifier value at al= l > in YANG. > > Rely on it at your own risk. > > > > > > > The only ambiguities not resolved by the CBOR encoding is an union > composed of two enumerations defining the same value associated to > different meanings. I will argue that such definition is incorrect. > > Not sure that is the only case, but it still is a case. Right now, the > YANG tools don=E2=80=99t know about these cases yet. So having, say, a p= yang > extension that tests for this might be a useful thing to have. > > Gr=C3=BC=C3=9Fe, Carsten > > > > Andy > > > > > --001a114432ac5d9ac80554e3233e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Jul 22, 2017 = at 08:47 Michel Veillette <Michel.Veillette@trilliantinc.com> wrote:

Hi Andy


<= /div>
I think 2 sets of media types addresses all my conce= rns. It is very simple to define a YANG to CBOR encoding that aligns with t= he standard data naming and instance value encoding. It is very easy to use= the Accept header to insure interoperability. This "plain" encod= ing can be quite useful for RESTCONF. We have already implemented RESTCONF = over CoAP and plan to use it for that as well.

<= /div>
Andy


We do recognize the additional risks= if SIDs are unmanaged.

This is why we work actively on the = development of the registration WEB site.

As soon a beta version is online, I = let you try it to see if it address your concerns.

=C2=A0

Regards,

Michel

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Saturday, July 22, 2017 6:53 AM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: Carsten Bormann <cabo@tzi.org>; Core <core@ietf.org>


Subject: Re: [core] yang cbor encoding without SID

=C2=A0

Hi,

=C2=A0

I am not going to explain it anymore.<= /p>

The order most statements appear in a YANG file is i= rrelevant to the semantics of the YANG module

except (1) auto-numbering of position or value and (= 2) evaluation order of union member types.

Keeping the SID files perfectly aligned with the YAN= G fie is a challenge. There is no way for

a module to get out of synch with itself wrt/ schema= node naming or instance value evaluation.

=C2=A0

So of course the tools will be perfect and the devel= opers will be perfect

and never let the registries and implementations get= out of synch.

Otherwise SID will produce incorrect results. =C2=A0=

If you cannot recognize the additional risks introdu= ced by SID,

you probably need to study RFC 7950 a bit more.

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

On Fri, Jul 21, 2017 at 7:45 PM, Michel Veillette &l= t;Mi= chel.Veillette@trilliantinc.com> wrote:

Hi Andy

=C2=A0

I will agree with you on one point, some implementer= s might have defined carelessly 'value' and 'position' beca= use these statements was not useful for their NETCONF or RESTCONF implementations. This is not an issue with YANG but with those developers.= I don't agree that the designers of the YANG modeling language put the= se statements in the schema definition just for fun. They certainly foresaw= the time YANG will be implemented in binary.

=C2=A0

The impacts on the yang to cbor mapping is however l= imited. The YANG specification and YANG validators guarantee the uniqueness= of enumeration values and bits positions. When used in a union, the conclusion of the design team was to add a check in valida= tion tools to generate a warning when duplicate values or positions are det= ected. Such check can be part of a validation performed when registering SI= Ds. Since those values or position are not likely to have been used, fixing them won't have any impacts o= n prior implementations. Nobody however have reported so far any instances = of this issue.

=C2=A0

I don't see any reasons why YANG won't be su= itable for binary implementations and designers of this modeling language s= hould be proud of this accomplishment.

=C2=A0

Regards,

Michel

=C2=A0

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Saturday, July 22, 2017 12:57 AM
To: Carsten Bormann <cabo@tzi.org>
Cc: Michel Veillette <Michel.Veillette@trilliantinc.com>; Core= <core@ietf.org&g= t;
Subject: Re: [core] yang cbor encoding without SID<= /u>

=C2=A0

=C2=A0

=C2=A0

On Fri, Jul 21, 2017 at 2:01 AM, Carsten Bormann <= ;cabo@tzi.org> wro= te:


> On Jul 21, 2017, at 10:17, Michel Veillette <Michel.Veillette@trilliant= inc.com> wrote:
>
> Hi Andy
>
> About the union, the CBOR encoding avoid any ambiguities between datat= ypes, something not archived by the xml mapping and partially archived by J= SON. For example, in xml, it is impossible to differentiate the string &quo= t;1" from the integer 1.

I think Andy=E2=80=99s point is that the serialization idiosyncrasies that = leak into YANG are at this point well-known if it is the idiosyncrasies fro= m the XML serialization (which have been maintained quite well in the JSON = serialization, too) but not so for the CBOR serialization.=C2=A0 With some effort, it is possible to write YANG that e= xposes these idiosyncrasies:

=C2=A0

=C2=A0

What I mean is that XML and JSON encodings align wit= h YANG by design.

The YANG identifiers are strings. The value spaces a= re specified such that any

collision is invalid YANG.

=C2=A0

The =C2=A0XML/JSON encoding formats are "protec= ted" by the rules of YANG.

It is not possible for identifier or value space err= ors to occur if the YANG module is valid.

This protection is built into the data modeling lang= uage by design for numbered

identifiers as well (e.g., SMIv2, Zigbee, etc.)

=C2=A0

But SID is completely unprotected from these errors = because the SID identifier and

data type encoding can change even though no YANG ru= les have been violated.

Statement position carries (almost) no semantic or i= dentifier value at all in YANG.

Rely on it at your own risk.

=C2=A0

=C2=A0

> The only ambigui= ties not resolved by the CBOR encoding is an union composed of two enumerat= ions defining the same value associated to different meanings. I will argue= that such definition is incorrect.

Not sure that is the only case, but it still is a case.=C2=A0 Right now, th= e YANG tools don=E2=80=99t know about these cases yet.=C2=A0 So having, say= , a pyang extension that tests for this might be a useful thing to have.
Gr=C3=BC=C3=9Fe, Carsten

=C2=A0

Andy

=C2=A0

=C2=A0

--001a114432ac5d9ac80554e3233e-- From nobody Sat Jul 22 03:35:10 2017 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 27653131DAA for ; Sat, 22 Jul 2017 03:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.022 X-Spam-Level: X-Spam-Status: No, score=-14.022 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 hZbei3PVHfiF for ; Sat, 22 Jul 2017 03:35:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8420E129A96 for ; Sat, 22 Jul 2017 03:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22732; q=dns/txt; s=iport; t=1500719706; x=1501929306; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2+x0A9JvhpX+4gk1HKVafRo49Atg1sw701xBg2mua1w=; b=ExBs/oRZntiVYx8YNb5fIKUhZAm9YNUixFbhQ5SOT06hJbtsa/rVSozy G1F3lskXT4DUuFKoy8V1qq1KDpCqduJCTfx3WgCqTp5aLED3G/5nW+SR+ NWsPVLKfIg8mSRa4mAdZ3nnAaBonX8Gga3ZpoiH3Tf5o0ePZjyl26CGW6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAAARKnNZ/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEUjgyRZZYFghIhAQqFGwKDfj8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECAQEBKzoHCwULAgEIEQQBAQEgBwcnCxQJCAIEDgWJS1wIELAKiy4BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYMog02BYSuCeYRHMiiDDYIxBZdMiAECixSJBpI?= =?us-ascii?q?3lWMBHzg/S3UVSRIBhQAcgWd2hyACJAeCEwEBAQ?= X-IronPort-AV: E=Sophos; i="5.40,395,1496102400"; d="scan'208,217"; a="55209403" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2017 10:35:05 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v6MAZ52E005635 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 22 Jul 2017 10:35:05 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 22 Jul 2017 05:35:04 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Sat, 22 Jul 2017 05:35:04 -0500 From: "Pascal Thubert (pthubert)" To: Michel Veillette CC: Andy Bierman , Core Thread-Topic: [core] yang cbor encoding without SID Thread-Index: AQHTAnS2WnX4jXok2UCoR2sHaFZjPKJfeC4AgAAjlYCAAB/ogP//68gK Date: Sat, 22 Jul 2017 10:35:04 +0000 Message-ID: References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_BDFAF884B9B84F82858B3FE576443271ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 10:35:09 -0000 --_000_BDFAF884B9B84F82858B3FE576443271ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Michel Maybe some thoughts should be given on how this ledger is implemented befor= e we start. Looks to me that the problem fits the domain of block chains qu= ite well but I may be wrong. Regards, Pascal Le 22 juil. 2017 =E0 08:47, Michel Veillette > a =E9crit : Hi Andy We do recognize the additional risks if SIDs are unmanaged. This is why we work actively on the development of the registration WEB sit= e. As soon a beta version is online, I let you try it to see if it address you= r concerns. Regards, Michel From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Saturday, July 22, 2017 6:53 AM To: Michel Veillette > Cc: Carsten Bormann >; Core > Subject: Re: [core] yang cbor encoding without SID Hi, I am not going to explain it anymore. The order most statements appear in a YANG file is irrelevant to the semant= ics of the YANG module except (1) auto-numbering of position or value and (2) evaluation order of = union member types. Keeping the SID files perfectly aligned with the YANG fie is a challenge. T= here is no way for a module to get out of synch with itself wrt/ schema node naming or instanc= e value evaluation. So of course the tools will be perfect and the developers will be perfect and never let the registries and implementations get out of synch. Otherwise SID will produce incorrect results. If you cannot recognize the additional risks introduced by SID, you probably need to study RFC 7950 a bit more. Andy On Fri, Jul 21, 2017 at 7:45 PM, Michel Veillette > wrote: Hi Andy I will agree with you on one point, some implementers might have defined ca= relessly 'value' and 'position' because these statements was not useful for= their NETCONF or RESTCONF implementations. This is not an issue with YANG = but with those developers. I don't agree that the designers of the YANG mod= eling language put these statements in the schema definition just for fun. = They certainly foresaw the time YANG will be implemented in binary. The impacts on the yang to cbor mapping is however limited. The YANG specif= ication and YANG validators guarantee the uniqueness of enumeration values = and bits positions. When used in a union, the conclusion of the design team= was to add a check in validation tools to generate a warning when duplicat= e values or positions are detected. Such check can be part of a validation = performed when registering SIDs. Since those values or position are not lik= ely to have been used, fixing them won't have any impacts on prior implemen= tations. Nobody however have reported so far any instances of this issue. I don't see any reasons why YANG won't be suitable for binary implementatio= ns and designers of this modeling language should be proud of this accompli= shment. Regards, Michel From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Saturday, July 22, 2017 12:57 AM To: Carsten Bormann > Cc: Michel Veillette >; Core > Subject: Re: [core] yang cbor encoding without SID On Fri, Jul 21, 2017 at 2:01 AM, Carsten Bormann > wrote: > On Jul 21, 2017, at 10:17, Michel Veillette > wrote: > > Hi Andy > > About the union, the CBOR encoding avoid any ambiguities between datatype= s, something not archived by the xml mapping and partially archived by JSON= . For example, in xml, it is impossible to differentiate the string "1" fro= m the integer 1. I think Andy=92s point is that the serialization idiosyncrasies that leak i= nto YANG are at this point well-known if it is the idiosyncrasies from the = XML serialization (which have been maintained quite well in the JSON serial= ization, too) but not so for the CBOR serialization. With some effort, it = is possible to write YANG that exposes these idiosyncrasies: What I mean is that XML and JSON encodings align with YANG by design. The YANG identifiers are strings. The value spaces are specified such that = any collision is invalid YANG. The XML/JSON encoding formats are "protected" by the rules of YANG. It is not possible for identifier or value space errors to occur if the YAN= G module is valid. This protection is built into the data modeling language by design for numb= ered identifiers as well (e.g., SMIv2, Zigbee, etc.) But SID is completely unprotected from these errors because the SID identif= ier and data type encoding can change even though no YANG rules have been violated. Statement position carries (almost) no semantic or identifier value at all = in YANG. Rely on it at your own risk. > The only ambiguities not resolved by the CBOR encoding is an union compos= ed of two enumerations defining the same value associated to different mean= ings. I will argue that such definition is incorrect. Not sure that is the only case, but it still is a case. Right now, the YAN= G tools don=92t know about these cases yet. So having, say, a pyang extens= ion that tests for this might be a useful thing to have. Gr=FC=DFe, Carsten Andy _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core --_000_BDFAF884B9B84F82858B3FE576443271ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Michel 

Maybe some thoughts should be given on how t= his ledger is implemented before we start. Looks to me that the problem fit= s the domain of block chains quite well but I may be wrong.

Regards,

Pascal

Le 22 juil. 2017 =E0 08:47, Michel Veillette <Michel.Veillette@trilliantinc.com> a =E9c= rit :

Hi Andy

 

We do recognize the additional risks= if SIDs are unmanaged.

This is why we work actively on the = development of the registration WEB site.

As soon a beta version is online, I = let you try it to see if it address your concerns.

 

Regards,

Michel

 

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Saturday, July 22, 2017 6:53 AM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: Carsten Bormann <cabo@tzi.org= >; Core <core@ietf.org> Subject: Re: [core] yang cbor encoding without SID=

 

Hi,

 

I am not going to explain it anymore.

The order most statements appear in a YANG file is i= rrelevant to the semantics of the YANG module

except (1) auto-numbering of position or value and (= 2) evaluation order of union member types.

Keeping the SID files perfectly aligned with the YAN= G fie is a challenge. There is no way for

a module to get out of synch with itself wrt/ schema= node naming or instance value evaluation.

 

So of course the tools will be perfect and the devel= opers will be perfect

and never let the registries and implementations get= out of synch.

Otherwise SID will produce incorrect results.  =

If you cannot recognize the additional risks introdu= ced by SID,

you probably need to study RFC 7950 a bit more.=

 

 

Andy

 

 

 

On Fri, Jul 21, 2017 at 7:45 PM, Michel Veillette &l= t;Mi= chel.Veillette@trilliantinc.com> wrote:

Hi Andy

 

I will agree with you on one point, some implementers might have d= efined carelessly 'value' and 'position' because these statements was not u= seful for their NETCONF or RESTCONF implementations. This is not an issue with YANG but with those developers.= I don't agree that the designers of the YANG modeling language put these s= tatements in the schema definition just for fun. They certainly foresaw the= time YANG will be implemented in binary.

 

The impacts on the yang to cbor mapping is however limited. The YA= NG specification and YANG validators guarantee the uniqueness of enumeratio= n values and bits positions. When used in a union, the conclusion of the design team was to add a check in valida= tion tools to generate a warning when duplicate values or positions are det= ected. Such check can be part of a validation performed when registering SI= Ds. Since those values or position are not likely to have been used, fixing them won't have any impacts on pr= ior implementations. Nobody however have reported so far any instances of t= his issue.

 

I don't see any reasons why YANG won't be suitable for binary impl= ementations and designers of this modeling language should be proud of this= accomplishment.

 

Regards,

Michel

 

 

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Saturday, July 22, 2017 12:57 AM
To: Carsten Bormann <cabo@tzi.org>
Cc: Michel Veillette <Michel.Veillette@trilliantinc.com>; Core= <core@ietf.org&g= t;
Subject: Re: [core] yang cbor encoding without SID=

 

 

 

On Fri, Jul 21, 2017 at 2:01 AM, Carsten Bormann <cabo@tzi.org> wrote:=


> On Jul 21, 2017, at 10:17, Michel Veillette <Michel.Veillette@trilliant= inc.com> wrote:
>
> Hi Andy
>
> About the union, the CBOR encoding avoid any ambiguities between datat= ypes, something not archived by the xml mapping and partially archived by J= SON. For example, in xml, it is impossible to differentiate the string &quo= t;1" from the integer 1.

I think Andy=92s point is that the serialization idiosyncrasies that leak i= nto YANG are at this point well-known if it is the idiosyncrasies from the = XML serialization (which have been maintained quite well in the JSON serial= ization, too) but not so for the CBOR serialization.  With some effort, it is possible to write YANG that e= xposes these idiosyncrasies:

 

 

What I mean is that XML and JSON encodings align with YANG by desi= gn.

The YANG identifiers are strings. The value spaces are specified s= uch that any

collision is invalid YANG.

 

The  XML/JSON encoding formats are "protected" by t= he rules of YANG.

It is not possible for identifier or value space errors to occur i= f the YANG module is valid.

This protection is built into the data modeling language by design= for numbered

identifiers as well (e.g., SMIv2, Zigbee, etc.)

 

But SID is completely unprotected from these errors because the SI= D identifier and

data type encoding can change even though no YANG rules have been = violated.

Statement position carries (almost) no semantic or identifier valu= e at all in YANG.

Rely on it at your own risk.

 

 

> The only ambiguities not resolved by the CBOR encoding is an union = composed of two enumerations defining the same value associated to differen= t meanings. I will argue that such definition is incorrect.

Not sure that is the only case, but it still is a case.  Right now, th= e YANG tools don=92t know about these cases yet.  So having, say, a py= ang extension that tests for this might be a useful thing to have.

Gr=FC=DFe, Carsten

 

Andy

 

 

_______________________________________________
core mailing list
core@ietf.org
https://www.ie= tf.org/mailman/listinfo/core
--_000_BDFAF884B9B84F82858B3FE576443271ciscocom_-- From nobody Sat Jul 22 04:39:49 2017 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 6D525129B3A for ; Sat, 22 Jul 2017 04:39:48 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 MBf-6GtVARz5 for ; Sat, 22 Jul 2017 04:39:45 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 1EE3C129432 for ; Sat, 22 Jul 2017 04:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6MBdXbo011957; Sat, 22 Jul 2017 13:39:33 +0200 (CEST) Received: from [100.118.63.230] (ip-109-45-1-198.web.vodafone.de [109.45.1.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xF5Jj0Q3Yz3Zkp; Sat, 22 Jul 2017 13:39:33 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-A79D8B8E-33E4-486A-890F-B7BD416ADBA9 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Sat, 22 Jul 2017 13:39:31 +0200 Cc: Michel Veillette , Core Content-Transfer-Encoding: 7bit Message-Id: <69F4F942-993D-4B53-A76D-70C69FF205A6@tzi.org> References: <20170720084234.GB20950@elstar.local> <9835E0B2-4B7F-4266-AD05-292B388B41AB@tzi.org> <20170720085743.GC20950@elstar.local> <26C20912-6896-4240-B7E9-79F5579F1686@tzi.org> <20170720094047.GF20950@elstar.local> <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> To: "Pascal Thubert (pthubert)" Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 11:39:48 -0000 --Apple-Mail-A79D8B8E-33E4-486A-890F-B7BD416ADBA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, Alex had actually proposed this a couple of years ago in the first DIN s= ide meeting. The beauty of the range application approach is that we can do t= he block chain thing later for a range once we have figured out a good way t= o run this ledger while starting out today with the approach shown by Alex.=20= Sent from mobile > On 22. Jul 2017, at 12:35, Pascal Thubert (pthubert) w= rote: >=20 > Hello Michel=20 >=20 > Maybe some thoughts should be given on how this ledger is implemented befo= re we start. Looks to me that the problem fits the domain of block chains qu= ite well but I may be wrong. >=20 > Regards, >=20 > Pascal >=20 > Le 22 juil. 2017 =C3=A0 08:47, Michel Veillette a =C3=A9crit : >=20 >> Hi Andy >> =20 >> We do recognize the additional risks if SIDs are unmanaged. >> This is why we work actively on the development of the registration WEB s= ite. >> As soon a beta version is online, I let you try it to see if it address y= our concerns. >> =20 >> Regards, >> Michel >> =20 >> From: Andy Bierman [mailto:andy@yumaworks.com]=20 >> Sent: Saturday, July 22, 2017 6:53 AM >> To: Michel Veillette >> Cc: Carsten Bormann ; Core >> Subject: Re: [core] yang cbor encoding without SID >> =20 >> Hi, >> =20 >> I am not going to explain it anymore. >> The order most statements appear in a YANG file is irrelevant to the sema= ntics of the YANG module >> except (1) auto-numbering of position or value and (2) evaluation order o= f union member types. >> Keeping the SID files perfectly aligned with the YANG fie is a challenge.= There is no way for >> a module to get out of synch with itself wrt/ schema node naming or insta= nce value evaluation. >> =20 >> So of course the tools will be perfect and the developers will be perfect= >> and never let the registries and implementations get out of synch. >> Otherwise SID will produce incorrect results. =20 >> If you cannot recognize the additional risks introduced by SID, >> you probably need to study RFC 7950 a bit more. >> =20 >> =20 >> Andy >> =20 >> =20 >> =20 >> On Fri, Jul 21, 2017 at 7:45 PM, Michel Veillette wrote: >> Hi Andy >> =20 >> I will agree with you on one point, some implementers might have defined c= arelessly 'value' and 'position' because these statements was not useful for= their NETCONF or RESTCONF implementations. This is not an issue with YANG b= ut with those developers. I don't agree that the designers of the YANG model= ing language put these statements in the schema definition just for fun. The= y certainly foresaw the time YANG will be implemented in binary. >> =20 >> The impacts on the yang to cbor mapping is however limited. The YANG spec= ification and YANG validators guarantee the uniqueness of enumeration values= and bits positions. When used in a union, the conclusion of the design team= was to add a check in validation tools to generate a warning when duplicate= values or positions are detected. Such check can be part of a validation pe= rformed when registering SIDs. Since those values or position are not likely= to have been used, fixing them won't have any impacts on prior implementati= ons. Nobody however have reported so far any instances of this issue. >> =20 >> I don't see any reasons why YANG won't be suitable for binary implementat= ions and designers of this modeling language should be proud of this accompl= ishment. >> =20 >> Regards, >> Michel >> =20 >> =20 >> From: Andy Bierman [mailto:andy@yumaworks.com]=20 >> Sent: Saturday, July 22, 2017 12:57 AM >> To: Carsten Bormann >> Cc: Michel Veillette ; Core >> Subject: Re: [core] yang cbor encoding without SID >> =20 >> =20 >> =20 >> On Fri, Jul 21, 2017 at 2:01 AM, Carsten Bormann wrote: >>=20 >> > On Jul 21, 2017, at 10:17, Michel Veillette wrote: >> > >> > Hi Andy >> > >> > About the union, the CBOR encoding avoid any ambiguities between dataty= pes, something not archived by the xml mapping and partially archived by JSO= N. For example, in xml, it is impossible to differentiate the string "1" fro= m the integer 1. >>=20 >> I think Andy=E2=80=99s point is that the serialization idiosyncrasies tha= t leak into YANG are at this point well-known if it is the idiosyncrasies fr= om the XML serialization (which have been maintained quite well in the JSON s= erialization, too) but not so for the CBOR serialization. With some effort,= it is possible to write YANG that exposes these idiosyncrasies: >>=20 >> =20 >> =20 >> What I mean is that XML and JSON encodings align with YANG by design. >> The YANG identifiers are strings. The value spaces are specified such tha= t any >> collision is invalid YANG. >> =20 >> The XML/JSON encoding formats are "protected" by the rules of YANG. >> It is not possible for identifier or value space errors to occur if the Y= ANG module is valid. >> This protection is built into the data modeling language by design for nu= mbered >> identifiers as well (e.g., SMIv2, Zigbee, etc.) >> =20 >> But SID is completely unprotected from these errors because the SID ident= ifier and >> data type encoding can change even though no YANG rules have been violate= d. >> Statement position carries (almost) no semantic or identifier value at al= l in YANG. >> Rely on it at your own risk. >> =20 >> =20 >> > The only ambiguities not resolved by the CBOR encoding is an union comp= osed of two enumerations defining the same value associated to different mea= nings. I will argue that such definition is incorrect. >>=20 >> Not sure that is the only case, but it still is a case. Right now, the Y= ANG tools don=E2=80=99t know about these cases yet. So having, say, a pyang= extension that tests for this might be a useful thing to have. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >> =20 >> Andy >> =20 >> =20 >> _______________________________________________ >> 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 --Apple-Mail-A79D8B8E-33E4-486A-890F-B7BD416ADBA9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes, Alex had actually proposed this a= couple of years ago in the first DIN side meeting. The beauty of the range a= pplication approach is that we can do the block chain thing later for a rang= e once we have figured out a good way to run this ledger while starting out t= oday with the approach shown by Alex. 

Sent from mobile

On 22. Jul 2017, at 12:35= , Pascal Thubert (pthubert) <pthube= rt@cisco.com> wrote:

Hello Michel 

Maybe some thoughts should be given on how th= is ledger is implemented before we start. Looks to me that the problem fits t= he domain of block chains quite well but I may be wrong.

Regards,

Pascal

Le 22 juil. 2017 =C3=A0 08:47, Michel Veillette <Michel.Veillette@trilliantinc.com> a =C3= =A9crit :

Hi Andy

 

We do recognize the additional risks i= f SIDs are unmanaged.

This is why we work actively on the de= velopment of the registration WEB site.

As soon a beta version is online, I le= t you try it to see if it address your concerns.

 

Regards,

Michel

 

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Saturday, July 22, 2017 6:53 AM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>
Cc: Carsten Bormann <cabo@tzi.org<= /a>>; Core <core@ietf.org>
= Subject: Re: [core] yang cbor encoding without SID<= /p>

 

Hi,

 

I am not going to explain it anymore.

The order most statements appear in a YANG file is ir= relevant to the semantics of the YANG module

except (1) auto-numbering of position or value and (2= ) evaluation order of union member types.

Keeping the SID files perfectly aligned with the YANG= fie is a challenge. There is no way for

a module to get out of synch with itself wrt/ schema n= ode naming or instance value evaluation.

 

So of course the tools will be perfect and the develo= pers will be perfect

and never let the registries and implementations get o= ut of synch.

Otherwise SID will produce incorrect results.  <= o:p>

If you cannot recognize the additional risks introduc= ed by SID,

you probably need to study RFC 7950 a bit more.<= /o:p>

 

 

Andy

 

 

 

On Fri, Jul 21, 2017 at 7:45 PM, Michel Veillette <= ;Mich= el.Veillette@trilliantinc.com> wrote:

Hi Andy

 

I will agree with you on one point, some implementers might have def= ined carelessly 'value' and 'position' because these statements was not usef= ul for their NETCONF or RESTCONF implementations. This is not an issue with YANG but with those developers. I= don't agree that the designers of the YANG modeling language put these stat= ements in the schema definition just for fun. They certainly foresaw the tim= e YANG will be implemented in binary.

 

The impacts on the yang to cbor mapping is however limited. The YANG= specification and YANG validators guarantee the uniqueness of enumeration v= alues and bits positions. When used in a union, the conclusion of the design team was to add a check in validat= ion tools to generate a warning when duplicate values or positions are detec= ted. Such check can be part of a validation performed when registering SIDs.= Since those values or position are not likely to have been used, fixing them won't have any impacts on pri= or implementations. Nobody however have reported so far any instances of thi= s issue.

 

I don't see any reasons why YANG won't be suitable for binary implem= entations and designers of this modeling language should be proud of this ac= complishment.

 

Regards,

Michel

 

 

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Saturday, July 22, 2017 12:57 AM
To: Carsten Bormann <cabo@tzi.org>
Cc: Michel Veillette <Michel.Veillette@trilliantinc.com>; Core &= lt;core@ietf.org><= br> Subject: Re: [core] yang cbor encoding without SID<= /p>

 

 

 

On Fri, Jul 21, 2017 at 2:01 AM, Carsten Bormann <cabo@tzi.org> wrote:


> On Jul 21, 2017, at 10:17, Michel Veillette <Michel.Veillette@trilliantin= c.com> wrote:
>
> Hi Andy
>
> About the union, the CBOR encoding avoid any ambiguities between dataty= pes, something not archived by the xml mapping and partially archived by JSO= N. For example, in xml, it is impossible to differentiate the string "1" fro= m the integer 1.

I think Andy=E2=80=99s point is that the serialization idiosyncrasies that l= eak into YANG are at this point well-known if it is the idiosyncrasies from t= he XML serialization (which have been maintained quite well in the JSON seri= alization, too) but not so for the CBOR serialization.  With some effort, it is possible to write YANG that ex= poses these idiosyncrasies:

 

 

What I mean is that XML and JSON encodings align with YANG by design= .

The YANG identifiers are strings. The value spaces are specified suc= h that any

collision is invalid YANG.

 

The  XML/JSON encoding formats are "protected" by the rules of Y= ANG.

It is not possible for identifier or value space errors to occur if t= he YANG module is valid.

This protection is built into the data modeling language by design f= or numbered

identifiers as well (e.g., SMIv2, Zigbee, etc.)

 

But SID is completely unprotected from these errors because the SID i= dentifier and

data type encoding can change even though no YANG rules have been vi= olated.

Statement position carries (almost) no semantic or identifier value a= t all in YANG.

Rely on it at your own risk.

 

 

> The only ambiguities not resolved by the CBOR encoding is an union co= mposed of two enumerations defining the same value associated to different m= eanings. I will argue that such definition is incorrect.

Not sure that is the only case, but it still is a case.  Right now, the= YANG tools don=E2=80=99t know about these cases yet.  So having, say, a= pyang extension that tests for this might be a useful thing to have.

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

 

Andy

 

 

_______________________________________________
core mailing list
core@ietf.org
https://www.iet= f.org/mailman/listinfo/core
____________________= ___________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman= /listinfo/core
= --Apple-Mail-A79D8B8E-33E4-486A-890F-B7BD416ADBA9-- From nobody Sat Jul 22 05:03:07 2017 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 A8D2F12EB2B for ; Sat, 22 Jul 2017 05:03:05 -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, RP_MATCHES_RCVD=-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 1Rlb4tM6dFcG for ; Sat, 22 Jul 2017 05:03:03 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E3F129432 for ; Sat, 22 Jul 2017 05:03:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 47BE26E2; Sat, 22 Jul 2017 14:03:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id m954hAFoeMw1; Sat, 22 Jul 2017 14:02:55 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 22 Jul 2017 14:03:01 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26FFC200AA; Sat, 22 Jul 2017 14:03:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id skaC7s6ba73O; Sat, 22 Jul 2017 14:03:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0303200A8; Sat, 22 Jul 2017 14:02:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 669B43FF96FA; Sat, 22 Jul 2017 14:02:59 +0200 (CEST) Date: Sat, 22 Jul 2017 14:02:59 +0200 From: Juergen Schoenwaelder To: Michel Veillette Cc: Andy Bierman , Core Message-ID: <20170722120258.GA22600@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Michel Veillette , Andy Bierman , Core References: <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 12:03:06 -0000 On Sat, Jul 22, 2017 at 06:47:27AM +0000, Michel Veillette wrote: > This is why we work actively on the development of the registration WEB site. > As soon a beta version is online, I let you try it to see if it address your concerns. Michel, do you really believe that well managed registries will for example survive company mergers or acquisitions? What about modules under development where people build prototypes and then later identifiers get changed? Do you expect _all_ developers will go and update the number schemes embedded in their code correctly? Anyway, I do not want to prevent people from getting experience with this as long as there is a way to use YANG-CBOR without SID. Make SID an additional optimization. If you want to require SID for CoMI, fine. Then in the worst case CoMI goes with the fate of SIDs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Jul 22 06:34:14 2017 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 AA79E129AD1 for ; Sat, 22 Jul 2017 06:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 GZpcNO76W2Il for ; Sat, 22 Jul 2017 06:34:10 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 6E55E12EBF7 for ; Sat, 22 Jul 2017 06:34:10 -0700 (PDT) X-AuditID: c1b4fb2d-857ff70000005f66-7a-59735450ab9a Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6C.89.24422.05453795; Sat, 22 Jul 2017 15:34:08 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Sat, 22 Jul 2017 15:34:07 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: core Thread-Topic: "ni" URIs in SenML names (and no ";" in allowed characters) Thread-Index: AQHTAu8xdeRk7vlQb0W808f+1LOnPQ== Date: Sat, 22 Jul 2017 13:34:07 +0000 Message-ID: <988B5CDC-8709-4BF1-AB6F-C5B16D45E563@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7F14FD953395F1419EDCAA3CA8E629BB@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM2K7h25ASHGkwcYL8hb73q5ndmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr1Fs5kLXnBWPFvRyNrA+Iq9i5GTQ0LAROJP03XGLkYuDiGB I4wS7ybsYIFwFjNK/Lp7mBWkik3AXmLymo+MILaIgIRE59f9YN3CAi4SF2bPZYaIe0o8v3wW qkZP4vXlbrAaFgFViZ9tbSwgNi/QnHl/WsBsRgExie+n1jCB2MwC4hK3nsxngrhIQGLJnvPM ELaoxMvH/1ghbCWJtYe3s0DU60ncmDqFDcK2lpj1cAkrhK0tsWzha2aIXYISJ2c+YZnAKDwL yYpZSNpnIWmfhaR9FpL2BYysqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECg//glt+6OxhX v3Y8xCjAwajEw/vJpThSiDWxrLgy9xCjBAezkgjvJW+gEG9KYmVValF+fFFpTmrxIUZpDhYl cV6HfRcihATSE0tSs1NTC1KLYLJMHJxSDYzdF5cd7KzYZLF1HUefYO+k9Zfs3OYyzpi5WJCv uut91+Z/OpZVlawqiXeefsh+uilSLv9k+Be+9/l9lvUeNt9mFsb/X+75W9lPMsZCtGmTZAT/ /BTGNTeuPUiXltB/kFWen9Onus5T7V+w1PKJ/56derqdc9EKFpfMucc2Tvuqt7P9x9n5yyWU WIozEg21mIuKEwHefW12egIAAA== Archived-At: Subject: [core] "ni" URIs in SenML names (and no "; " in allowed characters) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 13:34:13 -0000 Hi all, In the Friday CoRE session we discussed that adding ";" to the allowed char= acters of SenML names could be useful for accommodating for certain kinds o= f URIs, like "ni". However, as I mentioned during the meeting, whether the = ";" character is safe for names needs to be checked with experts on the top= ic. We got now feedback that it is *not* safe to use that character and sho= uld not be included in the character set. Therefore, instead of allowing ";" in names, we could consider documenting = simple translation rule for "ni" URIs: just switch the ";" into ":". In the= ni-URIs the ";" character is used just once: between base64 encoded hash a= nd the algorithm used to generate the hash value [1]. And to avoid issues w= ith encoding the authority part, we could use just the alg-val part of the = URI as name. This could be done in the SenML base spec, or we could leave all such trans= lation / name-mapping rules for future spec(s) since they are just a specia= l case for name generation and not a requirement for SenML as such. I'm per= haps leaning towards the latter option to get SenML shipped now. Comments / opinions on this? Cheers, Ari [1] https://tools.ietf.org/html/rfc6920#section-3= From nobody Sat Jul 22 06:37:43 2017 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 E1981127058 for ; Sat, 22 Jul 2017 06:37:40 -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 yvaBtRGht372 for ; Sat, 22 Jul 2017 06:37:39 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 52CEE129AD1 for ; Sat, 22 Jul 2017 06:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6MDbZEW018675; Sat, 22 Jul 2017 15:37:35 +0200 (CEST) Received: from [172.20.10.11] (ip-109-45-1-198.web.vodafone.de [109.45.1.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xF7wv04Kmz3ZnK; Sat, 22 Jul 2017 15:37:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <20170722120258.GA22600@elstar.local> Date: Sat, 22 Jul 2017 15:37:33 +0200 Cc: Michel Veillette , Core X-Mao-Original-Outgoing-Id: 522423453.665162-4e122620017ab71e332b945b2c17ab32 Content-Transfer-Encoding: quoted-printable Message-Id: <9BC4E6D5-EB85-474F-A52B-BC170A962FC5@tzi.org> References: <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> <20170722120258.GA22600@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 13:37:41 -0000 > On Jul 22, 2017, at 14:02, Juergen Schoenwaelder = wrote: >=20 > On Sat, Jul 22, 2017 at 06:47:27AM +0000, Michel Veillette wrote: >=20 >> This is why we work actively on the development of the registration = WEB site. >> As soon a beta version is online, I let you try it to see if it = address your concerns. >=20 > Michel, >=20 > do you really believe that well managed registries will for example > survive company mergers or acquisitions? They mostly seem to manage that for their financial information :-) > What about modules under > development where people build prototypes and then later identifiers > get changed? Do you expect _all_ developers will go and update the > number schemes embedded in their code correctly? I think that the situation in 2017 is really different from that even a = decade ago. Developers have been getting used to version control, which does require = a bit of a protocol to use it right. We also have web applications that help with that (bitbucket, github, = gitlab, =E2=80=A6). So I=E2=80=99m more optimistic that the same can be done for SID = control. The SID tool in pyang can be the basis of one way to do it, and we = probably should evolve an informational document explaining a best = practice way to handle SIDs. > Anyway, I do not want to prevent people from getting experience with > this as long as there is a way to use YANG-CBOR without SID. Make SID > an additional optimization. If you want to require SID for CoMI, fine. > Then in the worst case CoMI goes with the fate of SIDs. Sounds good to me. So we would have the following levels of optimization: 1 RESTCONF with JSON-YANG 2 RESTCONF with CBOR-YANG 3 COMI with string identifiers 4 COMI with SIDs Are 2 and 3 the same? Do we have to write up something for RESTCONF over CoAP? (There might also be NETCONF with CBOR-YANG, which doesn=E2=80=99t quite = fit into the above hierarchy.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jul 22 07:02:37 2017 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 1CE6D131B9A for ; Sat, 22 Jul 2017 07:02:35 -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, RP_MATCHES_RCVD=-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 zJkSzSnhZFdQ for ; Sat, 22 Jul 2017 07:02:33 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E3F129AC4 for ; Sat, 22 Jul 2017 07:02:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 526836E2; Sat, 22 Jul 2017 16:02:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id yL3AQkdRRl_o; Sat, 22 Jul 2017 16:02:26 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 22 Jul 2017 16:02:32 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BAF9200AA; Sat, 22 Jul 2017 16:02:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oJaQaLW2CD3O; Sat, 22 Jul 2017 16:02:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B824200A8; Sat, 22 Jul 2017 16:02:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 30FE73FF983D; Sat, 22 Jul 2017 16:02:30 +0200 (CEST) Date: Sat, 22 Jul 2017 16:02:30 +0200 From: Juergen Schoenwaelder To: Carsten Bormann Cc: Michel Veillette , Core Message-ID: <20170722140230.GA22751@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Carsten Bormann , Michel Veillette , Core References: <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> <20170722120258.GA22600@elstar.local> <9BC4E6D5-EB85-474F-A52B-BC170A962FC5@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <9BC4E6D5-EB85-474F-A52B-BC170A962FC5@tzi.org> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 14:02:35 -0000 On Sat, Jul 22, 2017 at 03:37:33PM +0200, Carsten Bormann wrote: > > Anyway, I do not want to prevent people from getting experience with > > this as long as there is a way to use YANG-CBOR without SID. Make SID > > an additional optimization. If you want to require SID for CoMI, fine. > > Then in the worst case CoMI goes with the fate of SIDs. > > Sounds good to me. > > So we would have the following levels of optimization: > > 1 RESTCONF with JSON-YANG > 2 RESTCONF with CBOR-YANG Option #2 makes sense to investigate, i.e., to find out how much efficiency gain there is. Someone would need to implement both and provide hard numbers. I would expect a certain gain on the encoding/decoding side but then one needs to lock at the whole picture. But I think this is a reasonable experiment to make. Volunteers? > 3 COMI with string identifiers > 4 COMI with SIDs Up to COMI people to decide, perhaps #4 is sufficient if COMI's scope is restricted to very constrained devices or boxes using highly limited links and we do not need #3. All depends on what is the real target for COMI. > (There might also be NETCONF with CBOR-YANG, which doesn’t quite fit > into the above hierarchy.) NETCONF has no way to negotiate different content encodings, NETCONF is pretty much hard wired to use XML since the whole protocol is encoded in XML. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Jul 22 10:53:35 2017 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 B9BE3131C27 for ; Sat, 22 Jul 2017 10:53:33 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filament-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 Na_vvsxsBJvs for ; Sat, 22 Jul 2017 10:53:32 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 DBA46131C15 for ; Sat, 22 Jul 2017 10:53:31 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id j32so10999580iod.0 for ; Sat, 22 Jul 2017 10:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=IJ9mcBxQus1r2/vwMs9CWoAQfbsZdgk2BpR6vN0aM7c=; b=wGFRp9QzVeHpzfGBwgtVxH/+zQMJPV4T36yf4Cr94aC8U+KQFRai+XVTvPhwG6LtTe cj/HoapYd9EjPI4/ivE8x42DdNZ1ro/Ys+0dDTrC2J2DB0Z4F8bRe7zJOGFegV1iBNJQ pfeQUhqS33hw6kQaVtTtgSGRxBriGQAGcCtKI9oOFArmNvvFYCDSJVVHdusxLdnHyX+J fg3t6ipGMglMvinLfFa7yT+DSa33ixUEl0G6YIAR7qLC7sFVF3GGxhe5KyMID2t5Og+e MLCJhkbVKoFdoNZo4ULnTY1azKHAvgUCiMTmy+rQp5TUqzJ3kX4V6wHIlQ29cGDbx9ND Kpbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IJ9mcBxQus1r2/vwMs9CWoAQfbsZdgk2BpR6vN0aM7c=; b=X/Yl40JvamVDmX2HIEqOLvC2Uu99vnQ94HpSMhNhr66En2MwW0+OiV1ejjI9B1qmej lS7xGcUQvnd+k7kWLq2ZI7IpNsqNztpieIj3azXNAGYpn7jkpwdHOqiiNN8QpTWLOvps FUm2s3UZLFUVrEsBlyouDKfIvqskkMspRtvALvkq8M+H1cm6E5sZE+0oS/lMjU+so7MJ hsPQ11z8EzYIMJ6z/Wvn47KsWFkyHqMu3qvsF7MpmEbSwidyWWlIARIbWbjNbV3vVyOe jlA3mXeRD72MEeJZJIBxkpE3oWoLd3wKC5EYZ5ww3Ex5xg6WpA60vYiX6dZXnJDTiwat BHwA== X-Gm-Message-State: AIVw1123os4tNg3Nt5yvNAdmTToAuoLDfAwfYFRvjTcxnG8dYnoLlU+o 9B8EVOzREqZLxbdh X-Received: by 10.107.200.196 with SMTP id y187mr5155584iof.67.1500746011201; Sat, 22 Jul 2017 10:53:31 -0700 (PDT) Received: from aither.local ([2601:282:4202:67d3:c4a1:825c:dc7e:e0b]) by smtp.gmail.com with ESMTPSA id e11sm1931749ita.36.2017.07.22.10.53.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jul 2017 10:53:29 -0700 (PDT) To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , core References: <988B5CDC-8709-4BF1-AB6F-C5B16D45E563@ericsson.com> From: Peter Saint-Andre - Filament Message-ID: <0fdb5c19-5edb-01e2-d2cc-776f285f6770@filament.com> Date: Sat, 22 Jul 2017 11:53:27 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <988B5CDC-8709-4BF1-AB6F-C5B16D45E563@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [core] "ni" URIs in SenML names (and no "; " in allowed characters) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 22 Jul 2017 17:53:34 -0000 On 7/22/17 7:34 AM, Ari Kernen wrote: > Hi all, > > In the Friday CoRE session we discussed that adding ";" to the > allowed characters of SenML names could be useful for accommodating > for certain kinds of URIs, like "ni". However, as I mentioned during > the meeting, whether the ";" character is safe for names needs to be > checked with experts on the topic. We got now feedback that it is > *not* safe to use that character and should not be included in the > character set. For the edification of working group participants, can you elaborate on what the safety issue is? For instance, does using ';' introduce a security vulnerability in some constrained systems? > Therefore, instead of allowing ";" in names, we could consider > documenting simple translation rule for "ni" URIs: just switch the > ";" into ":". In the ni-URIs the ";" character is used just once: > between base64 encoded hash and the algorithm used to generate the > hash value [1]. And to avoid issues with encoding the authority part, > we could use just the alg-val part of the URI as name. I'm sure we'd all like to avoid yet more bespoke encoding rules. > This could be done in the SenML base spec, or we could leave all such > translation / name-mapping rules for future spec(s) since they are > just a special case for name generation and not a requirement for > SenML as such. I'm perhaps leaning towards the latter option to get > SenML shipped now. Leaving this out of SenML for now makes sense, but (at the risk of sounding like a broken record) I'll reiterate that we need to make it very clear that many URI schemes and URN namespaces can't be used as SenML names because of the restricted character set. Peter -- Peter Saint-Andre https://filament.com/ From nobody Sun Jul 23 11:40:00 2017 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 C0671131692 for ; Sun, 23 Jul 2017 11:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7, 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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBgKBZz1Ex_J for ; Sun, 23 Jul 2017 11:39:55 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B7713170E for ; Sun, 23 Jul 2017 11:39:55 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id c184so8713754wmd.0 for ; Sun, 23 Jul 2017 11:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=pUNZciMihL+KIQ+ziSRGjdAh6F3F4zl3Pgkc/eIysQg=; b=llClmHbWUBGWy2i3Uj4HAoQ8NNyz3Fz1dqIQz20e9suDGnzcnPrvbQ4yaPu73nlJig eO5txKELRqJZ9Jb19oYHzGqSRg22xdCPSGTKywq4UcNo/sX1FA6j2SrUGXBqfv29tzk6 k/EzCzkS7Iy19S/gkAIL9BBX3Mb0S+9LRHW8n1qpKOK76NJjyjEiYNV8gh4GR28Piixv TwUEHknKB2nJW1RlBQRHi574uwlTZjqJ4niGaR0ZGmjtUQvqNSfSTQMH1EGBjSLnOkA5 l3pwzqIAcGEpxam97pG9a92hMv4A9tdBcpzVsyUn8uSH5AArI8cGqCxFhU1Ybzypffjr HB7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=pUNZciMihL+KIQ+ziSRGjdAh6F3F4zl3Pgkc/eIysQg=; b=rqPsrQLCElxjR/KBsLQwKef1u9N7S+QemS6+YDtQhQfxsHIep1LI35HxqPAXJnQI7i Fjj+ekB2P0DoFQbcQxPgeTOPHbOowVxv1FC+S8kqIr1aBeS+V8bZ+WAingwjWJzEoydw SJI3mRJ+8gbrH8/4wYUpGKE4eVjHGmQySmbR0KyMx4obIs3BzN83e6ueJPTe0uIzDuCt nqaN5cafqr+YdJgWYe+GQtl9/uh2F3ESg2ruigh4FOldk89Skt8Zun31/qsrKCh5CciI z7QsoUXUyRNFLcm40wqW0tooYNdHtdD+1BZOQDffuWjQRMKvK9DEzPr4AABJ8JmdjQCF jMpg== X-Gm-Message-State: AIVw113ODp5fjmP6a2Cg0cELgqSpaUjv3rT91ecBDoFrnQQPtpqq/g+T y3Ep2bpXlYhGACDJOEP6X0JSToy/KkjH X-Received: by 10.28.199.207 with SMTP id x198mr3139954wmf.156.1500835193790; Sun, 23 Jul 2017 11:39:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Sun, 23 Jul 2017 11:39:53 -0700 (PDT) In-Reply-To: <20170722140230.GA22751@elstar.local> References: <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> <20170722120258.GA22600@elstar.local> <9BC4E6D5-EB85-474F-A52B-BC170A962FC5@tzi.org> <20170722140230.GA22751@elstar.local> From: Andy Bierman Date: Sun, 23 Jul 2017 11:39:53 -0700 Message-ID: To: Juergen Schoenwaelder , Carsten Bormann , Michel Veillette , Core Content-Type: multipart/alternative; boundary="94eb2c0d818097bae00555006c5b" Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jul 2017 18:39:58 -0000 --94eb2c0d818097bae00555006c5b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 22, 2017 at 7:02 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sat, Jul 22, 2017 at 03:37:33PM +0200, Carsten Bormann wrote: > > > > Anyway, I do not want to prevent people from getting experience with > > > this as long as there is a way to use YANG-CBOR without SID. Make SID > > > an additional optimization. If you want to require SID for CoMI, fine= . > > > Then in the worst case CoMI goes with the fate of SIDs. > > > > Sounds good to me. > > > > So we would have the following levels of optimization: > > > > 1 RESTCONF with JSON-YANG > > 2 RESTCONF with CBOR-YANG > > Option #2 makes sense to investigate, i.e., to find out how much > efficiency gain there is. Someone would need to implement both and > provide hard numbers. I would expect a certain gain on the > encoding/decoding side but then one needs to lock at the whole > picture. But I think this is a reasonable experiment to > make. Volunteers? > Isn't CBOR-YANG covered by changes to the current document? IMO, the following protocol-independent media types should be defined: (2) application/yang-data+cbor : exact same identifier and instance value mappings as XML and JSON versions of yang-data. (4) application/yang-data+cbor.sid : identifier and instance value mappings according to SID registry Efficiency in system design is not limited to the protocol. Designers of YANG modules for constrained devices can use numeric types over string types and increase the efficiency of the CBOR encoding. The main use-case for CBOR for RESTCONF right now is pushing lots of operational state telemetry data off of routers. I can imagine routers using application/yang-data+cbor.sid a little at a time, for spot solutions. Some might want to see the technology mature before putting it in production networks. > > 3 COMI with string identifiers > > 4 COMI with SIDs > > Up to COMI people to decide, perhaps #4 is sufficient if COMI's scope > is restricted to very constrained devices or boxes using highly > limited links and we do not need #3. All depends on what is the real > target for COMI. > > > (There might also be NETCONF with CBOR-YANG, which doesn=E2=80=99t quit= e fit > > into the above hierarchy.) > > NETCONF has no way to negotiate different content encodings, NETCONF > is pretty much hard wired to use XML since the whole protocol is > encoded in XML. > > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --94eb2c0d818097bae00555006c5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 22, 2017 at 7:02 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Jul 22, 2017 at 03:37:33PM +0200, Carsten Bo= rmann wrote:

> > Anyway, I do not want to prevent people from getting experience w= ith
> > this as long as there is a way to use YANG-CBOR without SID. Make= SID
> > an additional optimization. If you want to require SID for CoMI, = fine.
> > Then in the worst case CoMI goes with the fate of SIDs.
>
> Sounds good to me.
>
> So we would have the following levels of optimization:
>
> 1 RESTCONF with JSON-YANG
> 2 RESTCONF with CBOR-YANG

Option #2 makes sense to investigate, i.e., to find out how much
efficiency gain there is. Someone would need to implement both and
provide hard numbers. I would expect a certain gain on the
encoding/decoding side but then one needs to lock at the whole
picture. But I think this is a reasonable experiment to
make. Volunteers?


Isn= 9;t CBOR-YANG covered by changes to the current document?

IMO, the following protocol-independent media types should be defin= ed:

(2)
=C2=A0 application/yang-data+cbo= r : exact same identifier and instance value mappings as XML and JSON versi= ons of yang-data.

(4)
=C2=A0 application= /yang-data+cbor.sid : identifier and instance value mappings according to S= ID registry


Efficiency in system de= sign is not limited to the protocol.
Designers of YANG modules fo= r constrained devices can use numeric types over string types
and= increase the efficiency of the CBOR encoding.

The= main use-case for CBOR for RESTCONF right now is pushing lots of operation= al state telemetry data
off of routers. I can imagine routers usi= ng application/yang-data+cbor.sid a little at a time, for spot solutions.
Some might want to see the technology mature before putting it in = production networks.




> 3 COMI with string identifiers
> 4 COMI with SIDs

Up to COMI people to decide, perhaps #4 is sufficient if COMI's scope is restricted to very constrained devices or boxes using highly
limited links and we do not need #3. All depends on what is the real
target for COMI.

> (There might also be NETCONF with CBOR-YANG, which doesn=E2=80=99t qui= te fit
> into the above hierarchy.)

NETCONF has no way to negotiate different content encodings, NETCONF
is pretty much hard wired to use XML since the whole protocol is
encoded in XML.

/js



Andy
=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--94eb2c0d818097bae00555006c5b-- From nobody Sun Jul 23 23:42:55 2017 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 0DCA912EC55 for ; Sun, 23 Jul 2017 23:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 SGUrgo_BDen6 for ; Sun, 23 Jul 2017 23:42:52 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63308129461 for ; Sun, 23 Jul 2017 23:42:52 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:213]) by smtp-cloud2.xs4all.net with ESMTP id oWin1v00M4R9iYA01WinFP; Mon, 24 Jul 2017 08:42:50 +0200 Received: from 2001:983:a264:1:bd90:ff6f:ffe3:73b1 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 24 Jul 2017 08:42:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 24 Jul 2017 08:42:47 +0200 From: peter van der Stok To: Andy Bierman Cc: Juergen Schoenwaelder , Carsten Bormann , Michel Veillette , Core Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> <20170722120258.GA22600@elstar.local> <9BC4E6D5-EB85-474F-A52B-BC170A962FC5@tzi.org> <20170722140230.GA22751@elstar.local> Message-ID: <74bbae503e0cfb3d689ea2a737a5e7f4@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 06:42:55 -0000 For case 3, CoMI with string identifiers, I recommend to send hashes and fall back to strings when a clash occurs. Strings are only used for clashing names, all others are sent as hashes. For an installation with 1000 names and 30 bit hash, the clash probability is less than 5*10^-4. With little extra code, string identifiers are only necessary when 3 or more names clash to the same hash value. The probability of such a clash with 30 bit hash and 1000 names is less than 5*10^-8. For comparison, the probability that a given flight will crash is 10^-7. Peter Andy Bierman schreef op 2017-07-23 20:39: > On Sat, Jul 22, 2017 at 7:02 AM, Juergen Schoenwaelder > wrote: > >> On Sat, Jul 22, 2017 at 03:37:33PM +0200, Carsten Bormann wrote: >> >>>> Anyway, I do not want to prevent people from getting experience >> with >>>> this as long as there is a way to use YANG-CBOR without SID. >> Make SID >>>> an additional optimization. If you want to require SID for CoMI, >> fine. >>>> Then in the worst case CoMI goes with the fate of SIDs. >>> >>> Sounds good to me. >>> >>> So we would have the following levels of optimization: >>> >>> 1 RESTCONF with JSON-YANG >>> 2 RESTCONF with CBOR-YANG >> >> Option #2 makes sense to investigate, i.e., to find out how much >> efficiency gain there is. Someone would need to implement both and >> provide hard numbers. I would expect a certain gain on the >> encoding/decoding side but then one needs to lock at the whole >> picture. But I think this is a reasonable experiment to >> make. Volunteers? > > Isn't CBOR-YANG covered by changes to the current document? > > IMO, the following protocol-independent media types should be defined: > > (2) > application/yang-data+cbor : exact same identifier and instance > value mappings as XML and JSON versions of yang-data. > > (4) > application/yang-data+cbor.sid : identifier and instance value > mappings according to SID registry > > Efficiency in system design is not limited to the protocol. > Designers of YANG modules for constrained devices can use numeric > types over string types > and increase the efficiency of the CBOR encoding. > > The main use-case for CBOR for RESTCONF right now is pushing lots of > operational state telemetry data > off of routers. I can imagine routers using > application/yang-data+cbor.sid a little at a time, for spot solutions. > Some might want to see the technology mature before putting it in > production networks. > >>> 3 COMI with string identifiers >>> 4 COMI with SIDs >> >> Up to COMI people to decide, perhaps #4 is sufficient if COMI's >> scope >> is restricted to very constrained devices or boxes using highly >> limited links and we do not need #3. All depends on what is the real >> target for COMI. >> >>> (There might also be NETCONF with CBOR-YANG, which doesn’t quite >> fit >>> into the above hierarchy.) >> >> NETCONF has no way to negotiate different content encodings, NETCONF >> is pretty much hard wired to use XML since the whole protocol is >> encoded in XML. >> >> /js > > Andy > >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> Fax: +49 421 200 3103 > [1]> >> >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core [2] > > > > Links: > ------ > [1] http://www.jacobs-university.de/ > [2] https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 24 01:19:39 2017 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 59B38131C2D for ; Mon, 24 Jul 2017 01:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dXE6emFeiIOu for ; Mon, 24 Jul 2017 01:19:36 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 34816131C20 for ; Mon, 24 Jul 2017 01:19:36 -0700 (PDT) X-AuditID: c1b4fb2d-857ff70000005f66-ea-5975ad96010e Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5A.B2.24422.69DA5795; Mon, 24 Jul 2017 10:19:34 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Mon, 24 Jul 2017 10:19:33 +0200 From: =?utf-8?B?QXJpIEtlcsOkbmVu?= To: Peter Saint-Andre - Filament , Cullen Jennings CC: core Thread-Topic: [core] "ni" URIs in SenML names (and no "; " in allowed characters) Thread-Index: AQHTAxNvNd3n8hvej0+iE5sUhxOGGqJig6yA Date: Mon, 24 Jul 2017 08:19:33 +0000 Message-ID: <3D8076B6-615F-4A86-89A4-539DCBC1BBB2@ericsson.com> References: <988B5CDC-8709-4BF1-AB6F-C5B16D45E563@ericsson.com> <0fdb5c19-5edb-01e2-d2cc-776f285f6770@filament.com> In-Reply-To: <0fdb5c19-5edb-01e2-d2cc-776f285f6770@filament.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/signed; boundary="Apple-Mail=_84D00848-5365-4FCF-9C63-FB6810059D27"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2K7hO60taWRBuv7xC32vV3PbPFh/Q9G i9lngh2YPS5tms3usWTJTyaPy+c/MgYwR3HZpKTmZJalFunbJXBlzLofVDDBqWLGkVa2BsaT Nl2MnBwSAiYSx+bMZ+li5OIQEjjCKHHyyF0oZzGjxKkz65hBqtgEbCWetO5jBbFFBCIk/q2d BBZnFpCQOLvyMFhcWCBIovv/LHaImmCJhycfMEHYRhJL/pwAi7MIqErcmbQWrJdXwF7i6Ldf jCC2kECpxMz3S8FqOAUcJL43TAKbySggJvH91BomiF3iEreezGeCuFpE4uHF02wQtqjEy8f/ WCFsJYlFtz8zgTzALDCFUeLCvS+sEMsEJU7OfMIygVFkFpJZs5DVzUJSB1GkLbFs4WtmCFtT Yn/3cqi4qcTrox8ZIWxriRm/DrJB2IoSU7ofsi9g5FjFKFqcWlycm25krJdalJlcXJyfp5eX WrKJERiFB7f81t3BuPq14yFGAQ5GJR7emBWlkUKsiWXFlbmHGFWA5jzasPoCoxRLXn5eqpII 74IioDRvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeh30XIoQE0hNLUrNTUwtSi2CyTBycUg2M3PtW ipRt5A83jF5zXnlm1ckPk7nm9S6Zw1hwpfzd2akvw/u9Mz7yCymKLNoSx+Hn99w/VylMYOt2 abEKv5IthveFypf2/7+f/CRG+tatyHmThRsWb+3V+XI1s/PiSmt5ZqWLYn1FT9tM7huYPo5R mf0302rdrsiS2FXlT6215k68vYa5/IeXEktxRqKhFnNRcSIAPsn2usoCAAA= Archived-At: Subject: Re: [core] "ni" URIs in SenML names (and no "; " in allowed characters) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 08:19:38 -0000 --Apple-Mail=_84D00848-5365-4FCF-9C63-FB6810059D27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Jul 2017, at 20.53, Peter Saint-Andre - Filament = wrote: >=20 > On 7/22/17 7:34 AM, Ari Ker=C3=A4nen wrote: >> Hi all, >>=20 >> In the Friday CoRE session we discussed that adding ";" to the >> allowed characters of SenML names could be useful for accommodating >> for certain kinds of URIs, like "ni". However, as I mentioned during >> the meeting, whether the ";" character is safe for names needs to be >> checked with experts on the topic. We got now feedback that it is >> *not* safe to use that character and should not be included in the >> character set. >=20 > For the edification of working group participants, can you elaborate = on > what the safety issue is? For instance, does using ';' introduce a > security vulnerability in some constrained systems? Apparently it's more of a problem for the back-end systems, but I'll let = Cullen elaborate on the details since he raised the concerns on this. >> Therefore, instead of allowing ";" in names, we could consider >> documenting simple translation rule for "ni" URIs: just switch the >> ";" into ":". In the ni-URIs the ";" character is used just once: >> between base64 encoded hash and the algorithm used to generate the >> hash value [1]. And to avoid issues with encoding the authority part, >> we could use just the alg-val part of the URI as name. >=20 > I'm sure we'd all like to avoid yet more bespoke encoding rules. That would be nice. In case of "ni" URIs I don't think the translation = rule is a big issue, but in general the restricted character set does = restrict the usability of URIs as names. However, having such capability = is not one of the design goals of SenML, but just the other way around: = being able to use names *in* URIs.=20 >> This could be done in the SenML base spec, or we could leave all such >> translation / name-mapping rules for future spec(s) since they are >> just a special case for name generation and not a requirement for >> SenML as such. I'm perhaps leaning towards the latter option to get >> SenML shipped now. >=20 > Leaving this out of SenML for now makes sense, but (at the risk of > sounding like a broken record) I'll reiterate that we need to make it > very clear that many URI schemes and URN namespaces can't be used as > SenML names because of the restricted character set. Yes, I'm planning to incorporate the text you proposed for the updated = revision to address this. All, please comment if you think that's a bad = idea. It's not a technical change, just clarification of existing rules. Cheers, Ari --Apple-Mail=_84D00848-5365-4FCF-9C63-FB6810059D27 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMqDCCBeow ggPSoAMCAQICEQD6DAOc/5f0WLIscub/Ets/MA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIwMjE0 NTY0MloXDTE3MTIwMjE0NTY0MVowZTERMA8GA1UECgwIRXJpY3Nzb24xFTATBgNVBAMMDEFyaSBL ZXLDpG5lbjEnMCUGCSqGSIb3DQEJARYYYXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tMRAwDgYDVQQF EwdlYXJpa2VyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiQ6/yW4ZyfTOP25xgQsm LuLOe1Dzz6aA5qv8aa+X7zADW1TNPsHlRyEjN25OenU73pSPMM/we06WGetED9lwO6WYSXEW69zN H7shEv7E3oWFkZxLemb/lB6ldVNRc3fmPc8AIvbJmb1O/w1h68pcsMG/zCTDHEp8K9QwyCP2WXBU cBcZ3n67FuSWcxhJLTOScxMiXgbzMy5358ZUVGZwSpo1h6OvjWNMxhP2r9zvVU+rVinsILqwB3Ii 6gSuMheq3n3xNnvpPhj5nDg6HgHU2W/NrE/KoYpRhoxyS/9MgYIXSyHKau4mo0hHAgj0NDwzk45O Yc/pB1keer7g+qT5EwIDAQABo4IBvjCCAbowSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50 cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEE djB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2 Mi5jZXIwIwYDVR0RBBwwGoEYYXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYM KwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxp YXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU Tt7OuiPseKi8/pwwc54KqU7l+uAwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwDgYD VR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBWKYJqheGSHGZGS7Y7pHYHUI9cMUYHmhgI oLqqWcbkeGDqvHsSqYACAOZtxWfonBglWNg2Gp8Mz/ufiCo747KQ+YW9yfn2NXoHVYHKuZLtgwxt kXidHad/VxQJLDRCfGeTv0BxF8uF+05hWpgKx1iRB5HevdF+qb55HcCVw/k5yFK+ZeNnI4FJChD4 NIPtioHadTRnaBWwrbsK1LWaQYLtFRFUH6uaqHSDQF6nIjdwtKn94MLt270IsQj72qvDOHk3XWtw 7p+W0m0Dy6WbSMNysNEah9gp0fPs8hbirK5yqOEp+ug9If2KFZHgKCwJZkhh/3WIFiFZasV2UfN9 Ngx41llsZe28CjA5w97qtnZ86DaTvE5k3NDv5UahBR2bxDznviZFjwhUPSmYXJfanKHW1SopWPmI Z3Ye9zvFSUbYNeTUsxTbjYkuz45BrkzWISv23s7YDNwx/L37QLb0AoNjuq2EoU9dUTIiI5+2giIa ZKiS5bQYl92gG0+hV14u5hLWzfN7QyqdiM5+Nm3KjiXZPW/+ThD/DTDxlyJVTWWP8hb7poSystU+ xqPK0EXtjgfg+jMRFaR0hmdlCMnMjFdlaT8lTKW3DPP78+sQz2svn/JcBY3ETPdJSwSYeEQAjbNG GvJ3DxmGNC5xXoAT6wa80BfNlD7LZEcf4stD9udmrzCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6 cPR8wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVowOjER MA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4Gnl17DJhklko XOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWXhPTdNzrB3zs5cJO7 sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZabrGh9OxQHC4iBHk zD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtVaqitBl0oAJiJyeBm vEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldVJtMwDYXpyFMGAijT 6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDH SBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvw hkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsu REnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3I T7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEB BH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsG AQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25l cmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8C AwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEu Y29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEu Y29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1UdIwQY MBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3PZBCsmGb cSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n65c5oN+l2JDU uzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+xhsfysYiIl4ORzE3T peppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy04/RnoylxSenxADi1 tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEueSRNASLfpFwyRmzm iuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWXI0g6SgdDObU0GEHj u0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBji J/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyG EyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7G eSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGCApkwggKVAgEBME8w OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Eg djICEQD6DAOc/5f0WLIscub/Ets/MAkGBSsOAwIaBQCgggEfMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDcyNDA4MjAxNVowIwYJKoZIhvcNAQkEMRYEFLA8rpXi UBBHYnBpsqtieVobRGGIMF4GCSsGAQQBgjcQBDFRME8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQD6DAOc/5f0WLIscub/Ets/MGAG CyqGSIb3DQEJEAILMVGgTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIRAPoMA5z/l/RYsixy5v8S2z8wDQYJKoZIhvcNAQEBBQAEggEA HCXwIRDBLGxXPXaFpFKUEIXISpl7cJLeIy/oF1SDbkqvXbVPw9+G6Trtvqeuvpyernn3wH5xSUmC 7qUiUBiGCIULsr0kF2SRf00YZWZyinatRKPIHS9/MAGvS2G0Av+N8AxvvlJqsf84T4SWWnW44sHC AlpLIQPbiGE9Zqmo8I3Y7eBydSyVvvb26LGs1WCc3f+uSjg4yCP691J9WOjKNcv1qmuAggTXrp7W rN3yCObAt4pPO5Afpiefwbo3GwIIIwbB5Y+8mAStxOE81848CZVkwkYU2UDh5VTtCNu791JA0OZz qVpb5i51nP+0X2tQG3n4gHX4QWzcUpZldl/uCAAAAAAAAA== --Apple-Mail=_84D00848-5365-4FCF-9C63-FB6810059D27-- From nobody Mon Jul 24 01:29:30 2017 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 E02E1131C32; Mon, 24 Jul 2017 01:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 tadDG1FLj9D0; Mon, 24 Jul 2017 01:29:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1518A131C31; Mon, 24 Jul 2017 01:29:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRW43440; Mon, 24 Jul 2017 08:29:19 +0000 (GMT) Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 24 Jul 2017 09:29:17 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.23]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0301.000; Mon, 24 Jul 2017 13:59:09 +0530 From: Raja ashok To: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= CC: "core@ietf.org" , "draft-ietf-core-object-security@ietf.org" Thread-Topic: Doubts in draft-ietf-core-object-security Thread-Index: AdL71RHIJFGFQkrRQUCixg0rsoEXNAG4KoyAAGdOnFA= Date: Mon, 24 Jul 2017 08:29:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.121] Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2300FD3BLREML503MBXchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5975AFE2.0014, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.9.23, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a4721b037aec73495ecaf89e5be277f5 Archived-At: Subject: Re: [core] Doubts in draft-ietf-core-object-security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 08:29:28 -0000 --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2300FD3BLREML503MBXchi_ Content-Type: multipart/alternative; boundary="_000_FDFEA8C9B9B6BD4685DCC959079C81F5E2300FD3BLREML503MBXchi_" --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E2300FD3BLREML503MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR8O2cmFuLA0KDQpUaGFua3MgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbnMuDQoNCkkgYWdyZWUg d2l0aCB5b3VyIHBvaW50LCBzYW1lIHNlc3Npb24ga2V5IGNhbiBiZSB1c2VkIGZvciBsYXJnZSBu dW1iZXIgb2YgbWVzc2FnZXMgdGlsbCB0aGUgbm9uY2Ugb2YgQUVBRCBvdmVyZmxvd3MuIEJ1dCBh cyBwZXIgbXkga25vd2xlZGdlIGEgc2FtZSBzZXNzaW9uIGtleSAoMTZieXRlKSBzaG91bGQgbm90 IGJlIHVzZWQgZm9yIG1vcmUgdGhhbiBmZXcgZGF5cyg1IHRvIDEwIGRheXMpLiBCZWNhdXNlIGl0 IGNhbiBiZSBicnV0ZSBmb3JjZWQuIFNvIEkgYW0gdGhpbmtpbmcgbGlrZSwgd2Ugc2hvdWxkIGNv bnNpZGVyIG9mIHBlcmlvZGljYWxseSBkZXJpdmluZyBzZXNzaW9uIGtleXMgZnJvbSBzYW1lIG1h c3RlciBzZWNyZXQgdXNpbmcgZGlmZmVyZW50IHJhbmRvbSBudW1iZXJzIChtYXN0ZXIgc2FsdCku DQoNCkFuZCBhbHNvIGN1cnJlbnRseSBpbiBPU0NvQVAsIHRvIGhhbmRsZSByZWJvb3Qgc2NlbmFy aW8sIG5vZGUgc2hvdWxkIHBlcmlvZGljYWxseSB1cGRhdGVzIChjdXJyZW50IHNlcXVlbmNlIG51 bWJlciArIG4pIHRvIHBlcnNpc3RlbnQgbWVtb3J5LiBJIGZlZWwgd2UgY2FuIGF2b2lkIHRoaXMg d3JpdGUgb24gcGVyc2lzdGVudCBtZW1vcnksIGlmIHdlIGRvIHJhbmRvbSBudW1iZXIgZXhjaGFu Z2UgYmVmb3JlIGRlcml2aW5nIHNlc3Npb24ga2V5cy4gSSBtZWFuLCBhIHJlYm9vdGVkIGNsaWVu dCBjYW4gaW5pdGlhdGUgYSByZXF1ZXN0IHRvIGRlcml2ZSBuZXcgc2Vzc2lvbiBrZXkgKG5lZWQg dG8gY29uc2lkZXIgRG9TIGF0dGFjayBoZXJlKS4gU28gd2UgY2FuIHN0b3JlIG9ubHkgbWFzdGVy IHNlY3JldCBpbiBwZXJzaXN0ZW50IG1lbW9yeS4NCg0KUGxlYXNlIGNsYXJpZnkgbWUgaWYgbXkg dW5kZXJzdGFuZGluZyBpcyB3cm9uZy4NCg0KUmVnYXJkcywNCkFzaG9rDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpbQ29tcGFueV9sb2dvXQ0KDQpSYWphIEFzaG9rIFYgSw0K SHVhd2VpIFRlY2hub2xvZ2llcw0KQmFuZ2Fsb3JlLCBJbmRpYQ0KaHR0cDovL3d3dy5odWF3ZWku Y29tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K5pys6YKu5Lu25Y+K5YW26ZmE 5Lu25ZCr5pyJ5Y2O5Li65YWs5Y+455qE5L+d5a+G5L+h5oGv77yM5LuF6ZmQ5LqO5Y+R6YCB57uZ 5LiK6Z2i5Zyw5Z2A5Lit5YiX5Ye655qE5Liq5Lq65oiW576k57uE44CC56aBDQrmraLku7vkvZXl hbbku5bkurrku6Xku7vkvZXlvaLlvI/kvb/nlKjvvIjljIXmi6zkvYbkuI3pmZDkuo7lhajpg6jm iJbpg6jliIblnLDms4TpnLLjgIHlpI3liLbjgIHmiJbmlaPlj5HvvInmnKzpgq7ku7bkuK0NCuea hOS/oeaBr+OAguWmguaenOaCqOmUmeaUtuS6huacrOmCruS7tu+8jOivt+aCqOeri+WNs+eUteiv neaIlumCruS7tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZpOacrOmCruS7tu+8gQ0KVGhpcyBlLW1h aWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBm cm9tIEhVQVdFSSwgd2hpY2gNCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50 aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGlt aXRlZCB0bywgdG90YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBk aXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGll bnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkg YW5kIGRlbGV0ZSBpdCENCg0KRnJvbTogR8O2cmFuIFNlbGFuZGVyIFttYWlsdG86Z29yYW4uc2Vs YW5kZXJAZXJpY3Nzb24uY29tXQ0KU2VudDogMjIgSnVseSAyMDE3IDEyOjEzDQpUbzogUmFqYSBh c2hvaw0KQ2M6IGNvcmVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHlA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBEb3VidHMgaW4gZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1z ZWN1cml0eQ0KDQpIaSBBc2hvaywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQpXaGF0 IGFtb3VudCBvZiBtZXNzYWdlIGRhdGEgZG8geW91IGVudmlzaW9uIGR1cmluZyB0aGUgbGlmZXRp bWUgb2YgdGhlIGRldmljZT8gVGhlIHNhbWUga2V5IGNhbiBiZSB1c2VkIGZvciBhIGxhcmdlIG51 bWJlciBvZiBtZXNzYWdlcyAodGhlIG51bWJlciBkZXBlbmRpbmcgb24gdGhlIEFFQUQgYWxnb3Jp dGhtKSBhbmQgdGhlcmUgaXMgaW4gcHJpbmNpcGxlIG5vIHJlYXNvbiB0byBjaGFuZ2Uga2V5IGJl Zm9yZSB0aGF0LiBBbmQgYWZ0ZXIgdGhhdCB5b3Ugd291bGQgcHJvYmFibHkgd2FudCB0byBhbnl3 YXkgbWFrZSBhIERpZmZpZS1IZWxsbWFuIGtleSBleGNoYW5nZSBzaW5jZSB0aGUgZW50cm9weSBv ZiB0aGUgbWFzdGVyIHNlY3JldCBpcyB3b3JuIG91dC4NCg0KSW4gcHJpbmNpcGxlIGl0IGlzIHBv c3NpYmxlIHRvIGhhdmUgYSBuZXcgbWFzdGVyIHNhbHQgc2VlZGVkIGJ5IChzb21ldGhpbmcgcmFu ZG9tIGtub3duIHRvKSBjbGllbnQgYW5kIHNlcnZlciBhbmQgZGVyaXZlIGEgbmV3IHNlc3Npb24g a2V5LCBidXQgZm9yIHRoZSByZWFzb25zIGFib3ZlIHdlIGRpZCBub3Qgc3BlY2lmeSB0aGF0LiBB bm90aGVyIG9wdGlvbiBpcyB0byB1c2UgT1NDT0FQIHdpdGggc29tZSBvdGhlciBrZXkgZXhjaGFu Z2UgcHJvdG9jb2wgd2hpY2ggc3VwcG9ydHMga2V5IHJvbGxvdmVyLg0KDQpQbGVhc2UgbGV0IG1l IGtub3cgbW9yZSBhYm91dCB0aGUgdXNlIGNhc2UgaWYgdGhpcyBkb2VzbuKAmXQgYW5zd2VyIHRo ZSBxdWVzdGlvbi4NCg0KVGhhbmtzDQpHw7ZyYW4NCg0KRnJvbTogUmFqYSBhc2hvayA8cmFqYS5h c2hva0BodWF3ZWkuY29tPG1haWx0bzpyYWphLmFzaG9rQGh1YXdlaS5jb20+Pg0KRGF0ZTogVGh1 cnNkYXkgMTMgSnVseSAyMDE3IGF0IDE0OjM5DQpUbzogR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5z ZWxhbmRlckBlcmljc3Nvbi5jb208bWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4+ LCAiZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZzxtYWlsdG86ZHJhZnQt aWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLWNvcmUtb2Jq ZWN0LXNlY3VyaXR5QGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3Vy aXR5QGlldGYub3JnPj4NCkNjOiAiY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9yZz4i IDxjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3JnPj4NClN1YmplY3Q6IERvdWJ0cyBp biBkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5DQoNCkhpIEdvZXJhbiBTZWxhbmRlciwN Cg0KSSBoYXZlIGdvbmUgdGhyb3VnaCB0aGUgT1NDT0FQIGFuZCBFREhPQyBkcmFmdHMuIEFuZCBJ IGFtIGhhdmluZyBmZXcgZG91YnRzIGluIGl0LiBQbGVhc2UgcHJvdmlkZSB5b3VyIGNvbW1lbnRz IG9uIGl0Lg0KDQpUaGlzIHNwZWNpZmljYXRpb24gbWFrZXMgaGFuZHNoYWtlKEVESE9DKSBmb3Ig ZGVyaXZpbmcgbWFzdGVyIHNlY3JldCBhcyBvcHRpb25hbC4gQW5kIGFsc28gYSBjb25zdHJhaW50 IG5vZGUgY2FuIHNraXAgaGFuZHNoYWtlIGFuZCBlc3RhYmxpc2ggYSBzZWN1cmUgY2hhbm5lbCBp ZiBtYXN0ZXIgc2VjcmV0IGlzIHByZWNvbmZpZ3VyZWQuDQoNClRoaXMgbWF5IG1ha2UgYSBjb25z dHJhaW50IG5vZGUgdG8gdXNlIHNhbWUgc2Vzc2lvbiBrZXlzIChzZW5kZXIgYW5kIHJlY2VpdmVy IGtleSkgZm9yIGxvbmdlciBkdXJhdGlvbiwgaWYgc2VxdWVuY2UgbnVtYmVyIGlzIG5vdCBleGhh dXN0ZWQuIE9ubHkgc29sdXRpb24gZm9yIHJlbmV3aW5nIHNlc3Npb24ga2V5IGlzIHRvIG5lZ290 aWF0ZSBuZXcgbWFzdGVyIHNlY3JldCBieSB1c2luZyBFREhPQy4gQnV0IEVESE9DIHN1cHBvcnRz IG9ubHkgUFNLX0VDREhFIGFuZCBFQ0RTQV9FQ0RIRSBtZWNoYW5pc20uIEhlcmUgSSBmZWVsIHdl IGFyZSBtaXNzaW5nIFBTSyB3aXRob3V0IChFQylESEUgbWVjaGFuaXNtIGZvciBlc3RhYmxpc2hp bmcgc2VjdXJlIGNoYW5uZWwuIEkgbWVhbiB3ZSBhcmUgbWlzc2luZyBUTFNfUFNLX1dJVEhfQUVT XzEyOF9DQ01fOCBraW5kIG9mIG1lY2hhbmlzbS4NCg0KSW4gRFRMUywgVExTX1BTS19XSVRIX0FF U18xMjhfQ0NNXzggdXNlcyBzYW1lIFBTSyBldmVyeSB0aW1lIGZvciBkZXJpdmluZyBzZXNzaW9u IGtleXMsIGFuZCBpdCBkb2VzbuKAmXQgc3VwcG9ydCBQRlMuIEJ1dCB0aGUgc2Vzc2lvbiBrZXkg ZGVyaXZlZCBpcyBkaWZmZXJlbnQgZXZlcnkgdGltZSB3aXRoIHRoZSBoZWxwIG9mIGNsaWVudCBh bmQgc2VydmVyIHJhbmRvbS4NCg0KU28gSSBmZWVsIHdlIGNhbiBjb25zaWRlciBvZiBleGNoYW5n aW5nIHJhbmRvbSBudW1iZXIgYWxzbyBhbG9uZyB3aXRoIEtJRCBhbmQgUGFydGlhbCBJViBpbiB0 aGUgMXN0IFJlcXVlc3QgYW5kIFJlc3BvbnNlLiBUbyBhY2hpZXZlIFRMU19QU0tfV0lUSF9BRVNf MTI4X0NDTV84IGtpbmQgb2YgbWVjaGFuaXNtIGluIE9TQ29BUCB3aXRob3V0IEVDREhFIGV4Y2hh bmdlLiBGb3IgdGhpcyBhbnl3YXkgd2UgaGF2ZSB0byBjb25zaWRlciBtdWx0aXBsZSBmYWN0b3Jz IGxpa2UgcmVwbGF5IGF0dGFjaywgRG9TIGF0dGFjayAoY2xpZW50IGluaXRpYXRpbmcga2V5IGRl cml2YXRpb24gZm9yIGVhY2ggcmVxdWVzdCksIGNsaWVudCByZWJvb3QgY2FzZSBldGMuDQoNClJl Z2FyZHMsDQpBc2hvaw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KW0NvbXBh bnlfbG9nb10NCg0KUmFqYSBBc2hvayBWIEsNCkh1YXdlaSBUZWNobm9sb2dpZXMNCkJhbmdhbG9y ZSwgSW5kaWENCmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4uuWFrOWPuOeahOS/neWv huS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4reWIl+WHuueahOS4quS6 uuaIlue+pOe7hOOAguemgQ0K5q2i5Lu75L2V5YW25LuW5Lq65Lul5Lu75L2V5b2i5byP5L2/55So 77yI5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo5YiG5Zyw5rOE6Zyy44CB5aSN5Yi244CB 5oiW5pWj5Y+R77yJ5pys6YKu5Lu25LitDQrnmoTkv6Hmga/jgILlpoLmnpzmgqjplJnmlLbkuobm nKzpgq7ku7bvvIzor7fmgqjnq4vljbPnlLXor53miJbpgq7ku7bpgJrnn6Xlj5Hku7bkurrlubbl iKDpmaTmnKzpgq7ku7bvvIENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFp biBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQppcyBpbnRlbmRl ZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBh Ym92ZS4gQW55IHVzZSBvZiB0aGUNCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55 IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwNCmRp c2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhl ciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSBy ZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkN CnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCg== --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E2300FD3BLREML503MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrljY7mlofnu4bpu5E7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0Fj ZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjIwNTAiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5IaSBHw7ZyYW4sPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRo YW5rcyBmb3IgeW91ciBjbGFyaWZpY2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCB5b3VyIHBvaW50LCBzYW1lIHNlc3Npb24ga2V5IGNhbiBi ZSB1c2VkIGZvciBsYXJnZSBudW1iZXIgb2YgbWVzc2FnZXMgdGlsbCB0aGUgbm9uY2Ugb2YgQUVB RCBvdmVyZmxvd3MuIEJ1dCBhcyBwZXIgbXkga25vd2xlZGdlIGEgc2FtZSBzZXNzaW9uIGtleSAo MTZieXRlKSBzaG91bGQgbm90IGJlIHVzZWQgZm9yIG1vcmUgdGhhbiBmZXcgZGF5cyg1DQogdG8g MTAgZGF5cykuIEJlY2F1c2UgaXQgY2FuIGJlIGJydXRlIGZvcmNlZC4gU28gSSBhbSB0aGlua2lu ZyBsaWtlLCB3ZSBzaG91bGQgY29uc2lkZXIgb2YgcGVyaW9kaWNhbGx5IGRlcml2aW5nIHNlc3Np b24ga2V5cyBmcm9tIHNhbWUgbWFzdGVyIHNlY3JldCB1c2luZyBkaWZmZXJlbnQgcmFuZG9tIG51 bWJlcnMgKG1hc3RlciBzYWx0KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PkFuZCBhbHNvIGN1cnJlbnRseSBpbiBPU0NvQVAsIHRvIGhhbmRsZSByZWJvb3Qgc2NlbmFyaW8s IG5vZGUgc2hvdWxkIHBlcmlvZGljYWxseSB1cGRhdGVzIChjdXJyZW50IHNlcXVlbmNlIG51bWJl ciAmIzQzOyBuKSB0byBwZXJzaXN0ZW50IG1lbW9yeS4gSSBmZWVsIHdlIGNhbiBhdm9pZCB0aGlz IHdyaXRlIG9uIHBlcnNpc3RlbnQgbWVtb3J5LCBpZiB3ZSBkbyByYW5kb20NCiBudW1iZXIgZXhj aGFuZ2UgYmVmb3JlIGRlcml2aW5nIHNlc3Npb24ga2V5cy4gSSBtZWFuLCBhIHJlYm9vdGVkIGNs aWVudCBjYW4gaW5pdGlhdGUgYSByZXF1ZXN0IHRvIGRlcml2ZSBuZXcgc2Vzc2lvbiBrZXkgKG5l ZWQgdG8gY29uc2lkZXIgRG9TIGF0dGFjayBoZXJlKS4gU28gd2UgY2FuIHN0b3JlIG9ubHkgbWFz dGVyIHNlY3JldCBpbiBwZXJzaXN0ZW50IG1lbW9yeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlBsZWFzZSBjbGFyaWZ5IG1lIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgd3Jv bmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5Bc2hvazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCjxociBzaXplPSIy IiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48IS0tW2lmIGd0ZSB2bWwgMV0+PHY6c2hhcGV0eXBlIGlkPSJfeDAwMDBfdDc1 IiBjb29yZHNpemU9IjIxNjAwLDIxNjAwIiBvOnNwdD0iNzUiIG86cHJlZmVycmVsYXRpdmU9InQi IHBhdGg9Im1ANEA1bEA0QDExQDlAMTFAOUA1eGUiIGZpbGxlZD0iZiIgc3Ryb2tlZD0iZiI+DQo8 djpzdHJva2Ugam9pbnN0eWxlPSJtaXRlciIgLz4NCjx2OmZvcm11bGFzPg0KPHY6ZiBlcW49Imlm IGxpbmVEcmF3biBwaXhlbExpbmVXaWR0aCAwIiAvPg0KPHY6ZiBlcW49InN1bSBAMCAxIDAiIC8+ DQo8djpmIGVxbj0ic3VtIDAgMCBAMSIgLz4NCjx2OmYgZXFuPSJwcm9kIEAyIDEgMiIgLz4NCjx2 OmYgZXFuPSJwcm9kIEAzIDIxNjAwIHBpeGVsV2lkdGgiIC8+DQo8djpmIGVxbj0icHJvZCBAMyAy MTYwMCBwaXhlbEhlaWdodCIgLz4NCjx2OmYgZXFuPSJzdW0gQDAgMCAxIiAvPg0KPHY6ZiBlcW49 InByb2QgQDYgMSAyIiAvPg0KPHY6ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4ZWxXaWR0aCIgLz4N Cjx2OmYgZXFuPSJzdW0gQDggMjE2MDAgMCIgLz4NCjx2OmYgZXFuPSJwcm9kIEA3IDIxNjAwIHBp eGVsSGVpZ2h0IiAvPg0KPHY6ZiBlcW49InN1bSBAMTAgMjE2MDAgMCIgLz4NCjwvdjpmb3JtdWxh cz4NCjx2OnBhdGggbzpleHRydXNpb25vaz0iZiIgZ3JhZGllbnRzaGFwZW9rPSJ0IiBvOmNvbm5l Y3R0eXBlPSJyZWN0IiAvPg0KPG86bG9jayB2OmV4dD0iZWRpdCIgYXNwZWN0cmF0aW89InQiIC8+ DQo8L3Y6c2hhcGV0eXBlPjx2OnNoYXBlIGlkPSJyaWRJbWciIG86c3BpZD0iX3gwMDAwX3MxMDI3 IiB0eXBlPSIjX3gwMDAwX3Q3NSIgYWx0PSJDb21wYW55X2xvZ28iIHN0eWxlPSdwb3NpdGlvbjph YnNvbHV0ZTttYXJnaW4tbGVmdDowO21hcmdpbi10b3A6MDt3aWR0aDo3Ni41cHQ7aGVpZ2h0OjI0 cHQ7ei1pbmRleDoyO3Zpc2liaWxpdHk6dmlzaWJsZTttc28td3JhcC1zdHlsZTpzcXVhcmU7bXNv LXdyYXAtZGlzdGFuY2UtbGVmdDowO21zby13cmFwLWRpc3RhbmNlLXRvcDowO21zby13cmFwLWRp c3RhbmNlLXJpZ2h0OjA7bXNvLXdyYXAtZGlzdGFuY2UtYm90dG9tOjA7bXNvLXBvc2l0aW9uLWhv cml6b250YWw6bGVmdDttc28tcG9zaXRpb24taG9yaXpvbnRhbC1yZWxhdGl2ZTp0ZXh0O21zby1w b3NpdGlvbi12ZXJ0aWNhbDphYnNvbHV0ZTttc28tcG9zaXRpb24tdmVydGljYWwtcmVsYXRpdmU6 bGluZScgbzphbGxvd292ZXJsYXA9ImYiPg0KPHY6aW1hZ2VkYXRhIHNyYz0iY2lkOmltYWdlMDAx LmpwZ0AwMUQzMDQ4NS4wNDE3QjNBMCIgbzpocmVmPSJmaWxlOi8vL0M6XFVzZXJzXHIwMDkwMjcz NlxBcHBsaWNhdGlvbiUyMERhdGFcTWljcm9zb2Z0XFNpZ25hdHVyZXNcY29tcGFueV9sb2dvLmpw ZyIgLz4NCjx3OndyYXAgdHlwZT0ic3F1YXJlIiBhbmNob3J5PSJsaW5lIi8+DQo8L3Y6c2hhcGU+ PCFbZW5kaWZdLS0+PCFbaWYgIXZtbF0+PGltZyB3aWR0aD0iMTAyIiBoZWlnaHQ9IjMyIiBzcmM9 ImNpZDppbWFnZTAwMS5qcGdAMDFEMzA0ODUuMDQxN0IzQTAiIGFsaWduPSJsZWZ0IiBhbHQ9IkNv bXBhbnlfbG9nbyIgdjpzaGFwZXM9InJpZEltZyI+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM1OTU5NTki PlJhamEgQXNob2sgViBLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y OiM1OTU5NTkiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzU5NTk1OSI+SHVhd2Vp IFRlY2hub2xvZ2llczxicj4NCkJhbmdhbG9yZSwgSW5kaWE8YnI+DQpodHRwOi8vd3d3Lmh1YXdl aS5jb20gPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjojMUY0OTdEIj4NCjxociBzaXplPSIy IiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTrlrovkvZM7Y29sb3I6Z3JheSI+5pys6YKu5Lu25Y+K5YW26ZmE5Lu25ZCr5pyJ5Y2O 5Li65YWs5Y+455qE5L+d5a+G5L+h5oGv77yM5LuF6ZmQ5LqO5Y+R6YCB57uZ5LiK6Z2i5Zyw5Z2A 5Lit5YiX5Ye655qE5Liq5Lq65oiW576k57uE44CC56aBPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk65Y2O5paH57uG6buRO2NvbG9yOmdyYXkiPjxicj4NCjwv c3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWls eTrlrovkvZM7Y29sb3I6Z3JheSI+5q2i5Lu75L2V5YW25LuW5Lq65Lul5Lu75L2V5b2i5byP5L2/ 55So77yI5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo5YiG5Zyw5rOE6Zyy44CB5aSN5Yi2 44CB5oiW5pWj5Y+R77yJ5pys6YKu5Lu25LitPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk65Y2O5paH57uG6buRO2NvbG9yOmdyYXkiPjxicj4NCjwvc3Bhbj48 c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTrlrovk vZM7Y29sb3I6Z3JheSI+55qE5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM 6K+35oKo56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu 5Lu277yBPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk65Y2O 5paH57uG6buRO2NvbG9yOmdyYXkiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6Z3JheSI+VGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNv bmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2gNCjxicj4NCmlzIGludGVu ZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVk IGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KPGJyPg0KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVp biBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFy dGlhbA0KPGJyPg0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBi eSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIDxicj4NCnJlY2lwaWVudChzKSBpcyBw cm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGJ5DQo8YnI+DQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQg ZGVsZXRlIGl0ITwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g R8O2cmFuIFNlbGFuZGVyIFttYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IDIyIEp1bHkgMjAxNyAxMjoxMzxicj4NCjxiPlRvOjwvYj4gUmFqYSBh c2hvazxicj4NCjxiPkNjOjwvYj4gY29yZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jb3JlLW9iamVj dC1zZWN1cml0eUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogRG91YnRzIGluIGRy YWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6YmxhY2siPkhpIEFzaG9rLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+V2hhdCBhbW91bnQgb2YgbWVzc2FnZSBkYXRhIGRvIHlvdSBlbnZpc2lv biBkdXJpbmcgdGhlIGxpZmV0aW1lIG9mIHRoZSBkZXZpY2U/IFRoZSBzYW1lIGtleSBjYW4gYmUg dXNlZCBmb3IgYSBsYXJnZSBudW1iZXIgb2YgbWVzc2FnZXMgKHRoZSBudW1iZXIgZGVwZW5kaW5n IG9uIHRoZSBBRUFEIGFsZ29yaXRobSkgYW5kIHRoZXJlIGlzDQogaW4gcHJpbmNpcGxlIG5vIHJl YXNvbiB0byBjaGFuZ2Uga2V5IGJlZm9yZSB0aGF0LiBBbmQgYWZ0ZXIgdGhhdCB5b3Ugd291bGQg cHJvYmFibHkgd2FudCB0byBhbnl3YXkgbWFrZSBhIERpZmZpZS1IZWxsbWFuIGtleSBleGNoYW5n ZSBzaW5jZSB0aGUgZW50cm9weSBvZiB0aGUgbWFzdGVyIHNlY3JldCBpcyB3b3JuIG91dC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkluIHByaW5jaXBsZSBpdCBpcyBw b3NzaWJsZSB0byBoYXZlIGEgbmV3IG1hc3RlciBzYWx0IHNlZWRlZCBieSAoc29tZXRoaW5nIHJh bmRvbSBrbm93biB0bykgY2xpZW50IGFuZCBzZXJ2ZXIgYW5kIGRlcml2ZSBhIG5ldyBzZXNzaW9u IGtleSwgYnV0IGZvciB0aGUgcmVhc29ucyBhYm92ZSB3ZSBkaWQgbm90IHNwZWNpZnkgdGhhdC4g QW5vdGhlcg0KIG9wdGlvbiBpcyB0byB1c2UgT1NDT0FQIHdpdGggc29tZSBvdGhlciBrZXkgZXhj aGFuZ2UgcHJvdG9jb2wgd2hpY2ggc3VwcG9ydHMga2V5IHJvbGxvdmVyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+UGxlYXNlIGxldCBtZSBrbm93IG1vcmUgYWJvdXQg dGhlIHVzZSBjYXNlIGlmIHRoaXMgZG9lc27igJl0IGFuc3dlciB0aGUgcXVlc3Rpb24uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+R8O2cmFuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+UmFqYSBhc2hvayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhamEuYXNob2tAaHVh d2VpLmNvbSI+cmFqYS5hc2hva0BodWF3ZWkuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ VGh1cnNkYXkgMTMgSnVseSAyMDE3IGF0IDE0OjM5PGJyPg0KPGI+VG86IDwvYj5Hw7ZyYW4gU2Vs YW5kZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20iPmdv cmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86 ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1jb3Jl LW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnIj5kcmFmdC1pZXRmLWNvcmUt b2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90Ozxh IGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5Eb3VidHMgaW4gZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0 eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowY20iIGlkPSJNQUNfT1VUTE9PS19B VFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSBHb2VyYW4gU2VsYW5kZXIsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgaGF2ZSBnb25lIHRocm91Z2ggdGhlIE9TQ09BUCBh bmQgRURIT0MgZHJhZnRzLiBBbmQgSSBhbSBoYXZpbmcgZmV3IGRvdWJ0cyBpbiBpdC4gUGxlYXNl IHByb3ZpZGUgeW91ciBjb21tZW50cyBvbiBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+VGhpcyBzcGVjaWZpY2F0aW9uIG1ha2VzIGhhbmRzaGFrZShFREhPQykgZm9yIGRlcml2 aW5nIG1hc3RlciBzZWNyZXQgYXMgb3B0aW9uYWwuIEFuZCBhbHNvIGEgY29uc3RyYWludCBub2Rl IGNhbiBza2lwIGhhbmRzaGFrZSBhbmQgZXN0YWJsaXNoIGEgc2VjdXJlIGNoYW5uZWwgaWYgbWFz dGVyIHNlY3JldCBpcyBwcmVjb25maWd1cmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5UaGlzIG1heSBtYWtlIGEgY29uc3RyYWludCBub2RlIHRvIHVzZSBzYW1lIHNlc3Npb24g a2V5cyAoc2VuZGVyIGFuZCByZWNlaXZlciBrZXkpIGZvciBsb25nZXIgZHVyYXRpb24sIGlmIHNl cXVlbmNlIG51bWJlciBpcyBub3QgZXhoYXVzdGVkLiBPbmx5IHNvbHV0aW9uIGZvciByZW5ld2lu ZyBzZXNzaW9uIGtleSBpcyB0byBuZWdvdGlhdGUgbmV3IG1hc3RlciBzZWNyZXQNCiBieSB1c2lu ZyBFREhPQy4gQnV0IEVESE9DIHN1cHBvcnRzIG9ubHkgUFNLX0VDREhFIGFuZCBFQ0RTQV9FQ0RI RSBtZWNoYW5pc20uIEhlcmUgSSBmZWVsIHdlIGFyZSBtaXNzaW5nIFBTSyB3aXRob3V0IChFQylE SEUgbWVjaGFuaXNtIGZvciBlc3RhYmxpc2hpbmcgc2VjdXJlIGNoYW5uZWwuIEkgbWVhbiB3ZSBh cmUgbWlzc2luZyBUTFNfUFNLX1dJVEhfQUVTXzEyOF9DQ01fOCBraW5kIG9mIG1lY2hhbmlzbS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW4gRFRMUywgVExTX1BTS19XSVRIX0FF U18xMjhfQ0NNXzggdXNlcyBzYW1lIFBTSyBldmVyeSB0aW1lIGZvciBkZXJpdmluZyBzZXNzaW9u IGtleXMsIGFuZCBpdCBkb2VzbuKAmXQgc3VwcG9ydCBQRlMuIEJ1dCB0aGUgc2Vzc2lvbiBrZXkg ZGVyaXZlZCBpcyBkaWZmZXJlbnQgZXZlcnkgdGltZSB3aXRoIHRoZSBoZWxwIG9mIGNsaWVudCBh bmQgc2VydmVyIHJhbmRvbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U28gSSBm ZWVsIHdlIGNhbiBjb25zaWRlciBvZiBleGNoYW5naW5nIHJhbmRvbSBudW1iZXIgYWxzbyBhbG9u ZyB3aXRoIEtJRCBhbmQgUGFydGlhbCBJViBpbiB0aGUgMTxzdXA+c3Q8L3N1cD4gUmVxdWVzdCBh bmQgUmVzcG9uc2UuIFRvIGFjaGlldmUgVExTX1BTS19XSVRIX0FFU18xMjhfQ0NNXzgga2luZCBv ZiBtZWNoYW5pc20gaW4gT1NDb0FQIHdpdGhvdXQgRUNESEUNCiBleGNoYW5nZS4gRm9yIHRoaXMg YW55d2F5IHdlIGhhdmUgdG8gY29uc2lkZXIgbXVsdGlwbGUgZmFjdG9ycyBsaWtlIHJlcGxheSBh dHRhY2ssIERvUyBhdHRhY2sgKGNsaWVudCBpbml0aWF0aW5nIGtleSBkZXJpdmF0aW9uIGZvciBl YWNoIHJlcXVlc3QpLCBjbGllbnQgcmVib290IGNhc2UgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QXNob2s8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZSBp ZD0iX3gwMDAwX3MxMDI2IiB0eXBlPSIjX3gwMDAwX3Q3NSIgYWx0PSJDb21wYW55X2xvZ28iIHN0 eWxlPSdwb3NpdGlvbjphYnNvbHV0ZTttYXJnaW4tbGVmdDowO21hcmdpbi10b3A6MDt3aWR0aDo3 Ni41cHQ7aGVpZ2h0OjI0cHQ7ei1pbmRleDoxO21zby13cmFwLWRpc3RhbmNlLWxlZnQ6MDttc28t d3JhcC1kaXN0YW5jZS1yaWdodDowO21zby1wb3NpdGlvbi1ob3Jpem9udGFsOmxlZnQ7bXNvLXBv c2l0aW9uLXZlcnRpY2FsLXJlbGF0aXZlOmxpbmUnIG86YWxsb3dvdmVybGFwPSJmIj4NCjx2Omlt YWdlZGF0YSBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFEMzA0ODUuMDQxN0IzQTAiIG86dGl0bGU9 ImltYWdlMDAxIiAvPg0KPHc6d3JhcCB0eXBlPSJzcXVhcmUiLz4NCjwvdjpzaGFwZT48IVtlbmRp Zl0tLT48IVtpZiAhdm1sXT48aW1nIHdpZHRoPSIxMDIiIGhlaWdodD0iMzIiIHNyYz0iY2lkOmlt YWdlMDAxLmpwZ0AwMUQzMDQ4NS4wNDE3QjNBMCIgYWxpZ249ImxlZnQiIGFsdD0iQ29tcGFueV9s b2dvIiB2OnNoYXBlcz0iX3gwMDAwX3MxMDI2Ij48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM1OTU5NTkiPlJh amEgQXNob2sgViBLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiM1 OTU5NTkiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzU5NTk1OSI+SHVhd2VpIFRl Y2hub2xvZ2llczxicj4NCkJhbmdhbG9yZSwgSW5kaWE8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3 Lmh1YXdlaS5jb20iPmh0dHA6Ly93d3cuaHVhd2VpLmNvbTwvYT4gPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+DQo8aHIg c2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmdyYXkiPuacrOmCruS7tuWPiuWFtumZhOS7tuWQ q+acieWNjuS4uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumd ouWcsOWdgOS4reWIl+WHuueahOS4quS6uuaIlue+pOe7hOOAguemgTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTtjb2xvcjpncmF5Ij48 YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk65a6L5L2TO2NvbG9yOmdyYXkiPuatouS7u+S9leWFtuS7luS6uuS7peS7u+S9leW9 ouW8j+S9v+eUqO+8iOWMheaLrOS9huS4jemZkOS6juWFqOmDqOaIlumDqOWIhuWcsOazhOmcsuOA geWkjeWItuOAgeaIluaVo+WPke+8ieacrOmCruS7tuS4rTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTtjb2xvcjpncmF5Ij48YnI+DQo8 L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p bHk65a6L5L2TO2NvbG9yOmdyYXkiPueahOS/oeaBr+OAguWmguaenOaCqOmUmeaUtuS6huacrOmC ruS7tu+8jOivt+aCqOeri+WNs+eUteivneaIlumCruS7tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZ pOacrOmCruS7tu+8gTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OuWNjuaWh+e7hum7kTtjb2xvcjpncmF5Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmdyYXkiPlRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29u dGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQo8YnI+DQpp cyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlz IGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCjxicj4NCmluZm9ybWF0aW9uIGNvbnRhaW5l ZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFs IG9yIHBhcnRpYWwNCjxicj4NCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5h dGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCA8YnI+DQpyZWNpcGllbnQo cykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KPGJyPg0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRl bHkgYW5kIGRlbGV0ZSBpdCE8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E2300FD3BLREML503MBXchi_-- --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2300FD3BLREML503MBXchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Mon, 24 Jul 2017 08:29:08 GMT"; modification-date="Mon, 24 Jul 2017 08:29:08 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E2300FD3BLREML503MBXchi_-- From nobody Mon Jul 24 01:55:45 2017 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 C429A12EACC for ; Mon, 24 Jul 2017 01:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 3SecWFvmzhoS for ; Mon, 24 Jul 2017 01:55:41 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5DDC129ACD for ; Mon, 24 Jul 2017 01:55:40 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:65dd:b049:5cc5:86db] (unknown [IPv6:2001:660:7301:3728:65dd:b049:5cc5:86db]) (Authenticated sender: alex@ackl.io) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id A4BBC1720E0; Mon, 24 Jul 2017 10:55:37 +0200 (CEST) From: Alexander Pelov Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_498985C0-50D5-4C08-9C3A-33DE96749F77" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 24 Jul 2017 10:55:36 +0200 In-Reply-To: <74bbae503e0cfb3d689ea2a737a5e7f4@xs4all.nl> Cc: Andy Bierman , Core To: consultancy@vanderstok.org References: <85B187B2-04DF-4C6B-A36C-FCC7FC2D3B79@tzi.org> <20170722120258.GA22600@elstar.local> <9BC4E6D5-EB85-474F-A52B-BC170A962FC5@tzi.org> <20170722140230.GA22751@elstar.local> <74bbae503e0cfb3d689ea2a737a5e7f4@xs4all.nl> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 08:55:44 -0000 --Apple-Mail=_498985C0-50D5-4C08-9C3A-33DE96749F77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, Section "4.2.2. Member names as keys" of draft-ietf-core-yang-cbor-04 = describes how you achieve what you want in your demand. I think there is no point in continuing the discussion of should we = include something that is already there. You can start using it as it is = today. Also, we will be doing an interop event by the end of August. Please, = make sure to participate to this event, as without running code, a = specification serves no useful purpose. Alexander > Le 24 juil. 2017 =C3=A0 08:42, peter van der Stok = a =C3=A9crit : >=20 > For case 3, CoMI with string identifiers, I recommend to send hashes = and fall back to strings when a clash occurs. > Strings are only used for clashing names, all others are sent as = hashes. > For an installation with 1000 names and 30 bit hash, the clash = probability is less than 5*10^-4. > With little extra code, string identifiers are only necessary when 3 = or more names clash to the same hash value. > The probability of such a clash with 30 bit hash and 1000 names is = less than 5*10^-8. > For comparison, the probability that a given flight will crash is = 10^-7. >=20 > Peter >=20 > Andy Bierman schreef op 2017-07-23 20:39: >> On Sat, Jul 22, 2017 at 7:02 AM, Juergen Schoenwaelder >> wrote: >>> On Sat, Jul 22, 2017 at 03:37:33PM +0200, Carsten Bormann wrote: >>>>> Anyway, I do not want to prevent people from getting experience >>> with >>>>> this as long as there is a way to use YANG-CBOR without SID. >>> Make SID >>>>> an additional optimization. If you want to require SID for CoMI, >>> fine. >>>>> Then in the worst case CoMI goes with the fate of SIDs. >>>> Sounds good to me. >>>> So we would have the following levels of optimization: >>>> 1 RESTCONF with JSON-YANG >>>> 2 RESTCONF with CBOR-YANG >>> Option #2 makes sense to investigate, i.e., to find out how much >>> efficiency gain there is. Someone would need to implement both and >>> provide hard numbers. I would expect a certain gain on the >>> encoding/decoding side but then one needs to lock at the whole >>> picture. But I think this is a reasonable experiment to >>> make. Volunteers? >> Isn't CBOR-YANG covered by changes to the current document? >> IMO, the following protocol-independent media types should be = defined: >> (2) >> application/yang-data+cbor : exact same identifier and instance >> value mappings as XML and JSON versions of yang-data. >> (4) >> application/yang-data+cbor.sid : identifier and instance value >> mappings according to SID registry >> Efficiency in system design is not limited to the protocol. >> Designers of YANG modules for constrained devices can use numeric >> types over string types >> and increase the efficiency of the CBOR encoding. >> The main use-case for CBOR for RESTCONF right now is pushing lots of >> operational state telemetry data >> off of routers. I can imagine routers using >> application/yang-data+cbor.sid a little at a time, for spot = solutions. >> Some might want to see the technology mature before putting it in >> production networks. >>>> 3 COMI with string identifiers >>>> 4 COMI with SIDs >>> Up to COMI people to decide, perhaps #4 is sufficient if COMI's >>> scope >>> is restricted to very constrained devices or boxes using highly >>> limited links and we do not need #3. All depends on what is the real >>> target for COMI. >>>> (There might also be NETCONF with CBOR-YANG, which doesn=E2=80=99t = quite >>> fit >>>> into the above hierarchy.) >>> NETCONF has no way to negotiate different content encodings, NETCONF >>> is pretty much hard wired to use XML since the whole protocol is >>> encoded in XML. >>> /js >> Andy >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >>> Germany >>> Fax: +49 421 200 3103 >> [1]> >>> _______________________________________________ >>> core mailing list >>> core@ietf.org >>> https://www.ietf.org/mailman/listinfo/core = [2] >> Links: >> ------ >> [1] http://www.jacobs-university.de/ = >> [2] https://www.ietf.org/mailman/listinfo/core = >> _______________________________________________ >> core mailing list >> core@ietf.org >> https://www.ietf.org/mailman/listinfo/core = >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core = --Apple-Mail=_498985C0-50D5-4C08-9C3A-33DE96749F77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear all,

Section "4.2.2. Member names as keys" = of draft-ietf-core-yang-cbor-04 describes how you achieve what you = want in your demand.

I think there is no point in continuing the discussion of = should we include something that is already there. You can start using = it as it is today.

Also, we will be doing an interop event by the end of August. = Please, make sure to participate to this event, as without running code, = a specification serves no useful purpose.

Alexander




Le 24 juil. 2017 =C3=A0 08:42, peter van der = Stok <stokcons@xs4all.nl> a =C3=A9crit :

For case 3, CoMI with string = identifiers, I recommend to send hashes and fall back to strings when a = clash occurs.
Strings are only used for clashing names, = all others are sent as hashes.
For an installation with 1000 = names and 30 bit hash, the clash probability is less than = 5*10^-4.
With little extra code, string = identifiers are only necessary when 3 or more names clash to the same = hash value.
The probability of such a clash with 30 = bit hash and 1000 names is less than 5*10^-8.
For comparison, the probability that a given = flight will crash is 10^-7.

Peter

Andy Bierman schreef op 2017-07-23 = 20:39:
On Sat, Jul 22, 2017 at 7:02 AM, Juergen Schoenwaelder
<j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Jul 22, 2017 at = 03:37:33PM +0200, Carsten Bormann wrote:
Anyway, I = do not want to prevent people from getting experience
with
this as = long as there is a way to use YANG-CBOR without SID.
Make SID
an = additional optimization. If you want to require SID for CoMI,
fine.
Then in = the worst case CoMI goes with the fate of SIDs.
Sounds good to me.
So we would = have the following levels of optimization:
1 RESTCONF with = JSON-YANG
2 RESTCONF with CBOR-YANG
Option #2 makes sense to investigate, i.e., to = find out how much
efficiency gain there is. Someone would = need to implement both and
provide hard numbers. I would = expect a certain gain on the
encoding/decoding side but = then one needs to lock at the whole
picture. But I think = this is a reasonable experiment to
make. Volunteers?
Isn't CBOR-YANG covered by changes to the = current document?
IMO, the following protocol-independent = media types should be defined:
(2)
 application/yang-data+cbor : exact same identifier and = instance
value mappings as XML and JSON versions of = yang-data.
(4)
 application/yang-data+cbor.sid : identifier and = instance value
mappings according to SID registry
Efficiency in system design is not limited to the = protocol.
Designers of YANG modules for constrained = devices can use numeric
types over string types
and increase the efficiency of the CBOR encoding.
The main use-case for CBOR for RESTCONF right now is pushing = lots of
operational state telemetry data
off = of routers. I can imagine routers using
application/yang-data+cbor.sid a little at a time, for spot = solutions.
Some might want to see the technology mature = before putting it in
production networks.
3 COMI with string identifiers
4 COMI with = SIDs
Up to COMI people to decide, perhaps #4 = is sufficient if COMI's
scope
is restricted = to very constrained devices or boxes using highly
limited = links and we do not need #3. All depends on what is the real
target for COMI.
(There might also be NETCONF with CBOR-YANG, which doesn=E2=80=99= t quite
fit
into the above hierarchy.)
NETCONF has no way to negotiate different = content encodings, NETCONF
is pretty much hard wired to = use XML since the whole protocol is
encoded in XML.
/js
Andy
--
Juergen Schoenwaelder =           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587 =         Campus Ring 1 | 28759 = Bremen |
Germany
Fax:   +49 421 = 200 3103         <http://www.jacobs-university.de/
[1]>
_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core [2]
Links:
------
[1] http://www.jacobs-university.de/
[2] https://www.ietf.org/mailman/listinfo/core
_______________________________________________
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

= --Apple-Mail=_498985C0-50D5-4C08-9C3A-33DE96749F77-- From nobody Mon Jul 24 02:18:37 2017 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 D8A0C129ACD for ; Mon, 24 Jul 2017 02:18:35 -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, RP_MATCHES_RCVD=-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 YI8TyGjS26pF for ; Mon, 24 Jul 2017 02:18:33 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55F3126DEE for ; Mon, 24 Jul 2017 02:18:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 10CD8F39; Mon, 24 Jul 2017 11:18:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id TpPwdb_lj22c; Mon, 24 Jul 2017 11:18:31 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 24 Jul 2017 11:18:31 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6634200AA; Mon, 24 Jul 2017 11:18:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Gzd8UDuTqfFO; Mon, 24 Jul 2017 11:18:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD845200A8; Mon, 24 Jul 2017 11:18:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 18FA73FFAA0F; Mon, 24 Jul 2017 11:18:29 +0200 (CEST) Date: Mon, 24 Jul 2017 11:18:29 +0200 From: Juergen Schoenwaelder To: Alexander Pelov Cc: Core Message-ID: <20170724091829.GA23635@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Alexander Pelov , Core References: <20170722120258.GA22600@elstar.local> <9BC4E6D5-EB85-474F-A52B-BC170A962FC5@tzi.org> <20170722140230.GA22751@elstar.local> <74bbae503e0cfb3d689ea2a737a5e7f4@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 09:18:36 -0000 On Mon, Jul 24, 2017 at 10:55:36AM +0200, Alexander Pelov wrote: > Dear all, > > Section "4.2.2. Member names as keys" of draft-ietf-core-yang-cbor-04 describes how you achieve what you want in your demand. > > > I think there is no point in continuing the discussion of should we include something that is already there. You can start using it as it is today. > There need to be different media types and it needs to be clear what is required to implement in which situation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 24 02:31:10 2017 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 ACB1E131BF8 for ; Mon, 24 Jul 2017 02:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 oPmwayciYLB6 for ; Mon, 24 Jul 2017 02:31:06 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F91B12EC4B for ; Mon, 24 Jul 2017 02:31:06 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:65dd:b049:5cc5:86db] (unknown [IPv6:2001:660:7301:3728:65dd:b049:5cc5:86db]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 4615FC5A51; Mon, 24 Jul 2017 11:31:04 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Alexander Pelov In-Reply-To: <20170724091829.GA23635@elstar.local> Date: Mon, 24 Jul 2017 11:31:03 +0200 Cc: Core Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170722120258.GA22600@elstar.local> <9BC4E6D5-EB85-474F-A52B-BC170A962FC5@tzi.org> <20170722140230.GA22751@elstar.local> <74bbae503e0cfb3d689ea2a737a5e7f4@xs4all.nl> <20170724091829.GA23635@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 09:31:07 -0000 Dear Juergen, The Content Format is out of scope for YANG-CBOR. It is only pertinent = for CoMI.=20 Alexander > Le 24 juil. 2017 =C3=A0 11:18, Juergen Schoenwaelder = a =C3=A9crit : >=20 > On Mon, Jul 24, 2017 at 10:55:36AM +0200, Alexander Pelov wrote: >> Dear all, >>=20 >> Section "4.2.2. Member names as keys" of draft-ietf-core-yang-cbor-04 = describes how you achieve what you want in your demand. >>=20 >>=20 >> I think there is no point in continuing the discussion of should we = include something that is already there. You can start using it as it is = today. >>=20 >=20 > There need to be different media types and it needs to be clear what > is required to implement in which situation. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Mon Jul 24 03:00:44 2017 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 1E67C131BBE for ; Mon, 24 Jul 2017 03:00:43 -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, RP_MATCHES_RCVD=-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 sKhJL27xtYU2 for ; Mon, 24 Jul 2017 03:00:41 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73044120721 for ; Mon, 24 Jul 2017 03:00:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 434B3F4C; Mon, 24 Jul 2017 12:00:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 36tqQ2bW0rTx; Mon, 24 Jul 2017 12:00:39 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 24 Jul 2017 12:00:40 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23AFE200AD; Mon, 24 Jul 2017 12:00:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tzH_OKunjQ14; Mon, 24 Jul 2017 12:00:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0F53200A8; Mon, 24 Jul 2017 12:00:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0DB833FFAAC9; Mon, 24 Jul 2017 12:00:38 +0200 (CEST) Date: Mon, 24 Jul 2017 12:00:37 +0200 From: Juergen Schoenwaelder To: Alexander Pelov Cc: Core Message-ID: <20170724100037.GA23746@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Alexander Pelov , Core References: <20170722120258.GA22600@elstar.local> <9BC4E6D5-EB85-474F-A52B-BC170A962FC5@tzi.org> <20170722140230.GA22751@elstar.local> <74bbae503e0cfb3d689ea2a737a5e7f4@xs4all.nl> <20170724091829.GA23635@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 10:00:43 -0000 Dear Alexander, I think people what to implement YANG-CBOR without having to implement the SID part. If the document makes it clear that this is possible without breaking conformance, I think everybody is fine. /js On Mon, Jul 24, 2017 at 11:31:03AM +0200, Alexander Pelov wrote: > Dear Juergen, > > The Content Format is out of scope for YANG-CBOR. It is only pertinent for CoMI. > > Alexander > > > > Le 24 juil. 2017 11:18, Juergen Schoenwaelder a crit : > > > > On Mon, Jul 24, 2017 at 10:55:36AM +0200, Alexander Pelov wrote: > >> Dear all, > >> > >> Section "4.2.2. Member names as keys" of draft-ietf-core-yang-cbor-04 describes how you achieve what you want in your demand. > >> > >> > >> I think there is no point in continuing the discussion of should we include something that is already there. You can start using it as it is today. > >> > > > > There need to be different media types and it needs to be clear what > > is required to implement in which situation. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 24 03:02:40 2017 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 984E7131BC8 for ; Mon, 24 Jul 2017 03:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 LPV6X-3PWzmZ for ; Mon, 24 Jul 2017 03:02:37 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D52120721 for ; Mon, 24 Jul 2017 03:02:36 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:65dd:b049:5cc5:86db] (unknown [IPv6:2001:660:7301:3728:65dd:b049:5cc5:86db]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 0327EC5A6C; Mon, 24 Jul 2017 12:02:34 +0200 (CEST) From: Alexander Pelov Message-Id: <1A9412FE-F663-479B-AC0C-4286B146B74D@ackl.io> Content-Type: multipart/alternative; boundary="Apple-Mail=_EDF79979-9367-40AE-A3FF-A4E2A53116CA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 24 Jul 2017 12:02:28 +0200 In-Reply-To: <20170724100037.GA23746@elstar.local> Cc: Core To: Juergen Schoenwaelder References: <20170722120258.GA22600@elstar.local> <9BC4E6D5-EB85-474F-A52B-BC170A962FC5@tzi.org> <20170722140230.GA22751@elstar.local> <74bbae503e0cfb3d689ea2a737a5e7f4@xs4all.nl> <20170724091829.GA23635@elstar.local> <20170724100037.GA23746@elstar.local> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 10:02:38 -0000 --Apple-Mail=_EDF79979-9367-40AE-A3FF-A4E2A53116CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Juergen, Sounds perfectly reasonable! Thanks for pointing it out - and you are = right about it. It is already in the text, but I=E2=80=99m taking note that we should = make it more explicit and maybe add a sentence to underline it in the = introduction / abstract. Does that sound OK ? Alexander > Le 24 juil. 2017 =C3=A0 12:00, Juergen Schoenwaelder = a =C3=A9crit : >=20 > Dear Alexander, >=20 > I think people what to implement YANG-CBOR without having to implement > the SID part. If the document makes it clear that this is possible > without breaking conformance, I think everybody is fine. >=20 > /js >=20 > On Mon, Jul 24, 2017 at 11:31:03AM +0200, Alexander Pelov wrote: >> Dear Juergen, >>=20 >> The Content Format is out of scope for YANG-CBOR. It is only = pertinent for CoMI.=20 >>=20 >> Alexander >>=20 >>=20 >>> Le 24 juil. 2017 =C3=A0 11:18, Juergen Schoenwaelder = a =C3=A9crit : >>>=20 >>> On Mon, Jul 24, 2017 at 10:55:36AM +0200, Alexander Pelov wrote: >>>> Dear all, >>>>=20 >>>> Section "4.2.2. Member names as keys" of = draft-ietf-core-yang-cbor-04 describes how you achieve what you want in = your demand. >>>>=20 >>>>=20 >>>> I think there is no point in continuing the discussion of should we = include something that is already there. You can start using it as it is = today. >>>>=20 >>>=20 >>> There need to be different media types and it needs to be clear what >>> is required to implement in which situation. >>>=20 >>> /js >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --Apple-Mail=_EDF79979-9367-40AE-A3FF-A4E2A53116CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Juergen,

Sounds perfectly reasonable! Thanks for pointing it out - and = you are right about it.

It is already in the text, but I=E2=80=99m taking note that = we should make it more explicit and maybe add a sentence to underline it = in the introduction / abstract.

Does that sound OK ?

Alexander


Le = 24 juil. 2017 =C3=A0 12:00, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> a =C3=A9crit = :

Dear Alexander,
I think people what to implement YANG-CBOR = without having to implement
the SID part. If the document = makes it clear that this is possible
without breaking conformance, I = think everybody is fine.

/js

On Mon, Jul 24, 2017 at 11:31:03AM +0200, = Alexander Pelov wrote:
Dear Juergen,

The Content Format is out of scope for = YANG-CBOR. It is only pertinent for CoMI. 

Alexander


Le 24 juil. 2017 =C3=A0 = 11:18, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> a =C3=A9crit = :

On Mon, Jul 24, 2017 at 10:55:36AM +0200, = Alexander Pelov wrote:
Dear all,

Section "4.2.2. Member = names as keys" of draft-ietf-core-yang-cbor-04 describes how you achieve = what you want in your demand.


I think there is no point in continuing the discussion of = should we include something that is already there. You can start using = it as it is today.


There need to be different media types and it needs to be = clear what
is required to implement in which situation.

/js

-- 
Juergen = Schoenwaelder =           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587 =         Campus Ring 1 | 28759 = Bremen | Germany
Fax:   +49 421 200 3103 =         <http://www.jacobs-university.de/>


-- 
Juergen Schoenwaelder =           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587 =         Campus Ring 1 | 28759 = Bremen | Germany
Fax:   +49 421 200 3103 =         <http://www.jacobs-university.de/>

= --Apple-Mail=_EDF79979-9367-40AE-A3FF-A4E2A53116CA-- From nobody Mon Jul 24 03:13:05 2017 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 BCF21131BC8 for ; Mon, 24 Jul 2017 03:13:03 -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, RP_MATCHES_RCVD=-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 lqNWphyIOa3E for ; Mon, 24 Jul 2017 03:13:02 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77566127201 for ; Mon, 24 Jul 2017 03:13:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 41361360; Mon, 24 Jul 2017 12:13:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id fYQ3XhvHhHlr; Mon, 24 Jul 2017 12:13:00 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 24 Jul 2017 12:13:01 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 22490200A8; Mon, 24 Jul 2017 12:13:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7Aw600-GEsvP; Mon, 24 Jul 2017 12:13:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9CADE200AD; Mon, 24 Jul 2017 12:13:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 79B283FFAB82; Mon, 24 Jul 2017 12:13:00 +0200 (CEST) Date: Mon, 24 Jul 2017 12:13:00 +0200 From: Juergen Schoenwaelder To: Alexander Pelov Cc: Core Message-ID: <20170724101300.GA23787@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Alexander Pelov , Core References: <20170722120258.GA22600@elstar.local> <9BC4E6D5-EB85-474F-A52B-BC170A962FC5@tzi.org> <20170722140230.GA22751@elstar.local> <74bbae503e0cfb3d689ea2a737a5e7f4@xs4all.nl> <20170724091829.GA23635@elstar.local> <20170724100037.GA23746@elstar.local> <1A9412FE-F663-479B-AC0C-4286B146B74D@ackl.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <1A9412FE-F663-479B-AC0C-4286B146B74D@ackl.io> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 10:13:04 -0000 On Mon, Jul 24, 2017 at 12:02:28PM +0200, Alexander Pelov wrote: > Dear Juergen, > > Sounds perfectly reasonable! Thanks for pointing it out - and you are right about it. > > It is already in the text, but I’m taking note that we should make it more explicit and maybe add a sentence to underline it in the introduction / abstract. > > Does that sound OK ? Yes /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 24 05:30:43 2017 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 8E8ED131CD3 for ; Mon, 24 Jul 2017 05:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 4ZKuFpRs-30s for ; Mon, 24 Jul 2017 05:30:39 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61325129A96 for ; Mon, 24 Jul 2017 05:30:39 -0700 (PDT) Received: from [IPv6:2001:660:7301:3728:65dd:b049:5cc5:86db] (unknown [IPv6:2001:660:7301:3728:65dd:b049:5cc5:86db]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 3FA3AA8115; Mon, 24 Jul 2017 14:30:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Alexander Pelov In-Reply-To: <20170724101300.GA23787@elstar.local> Date: Mon, 24 Jul 2017 14:30:36 +0200 Cc: Core Content-Transfer-Encoding: quoted-printable Message-Id: <7F2A81DA-8174-4F1E-A2E1-F78F332714AA@ackl.io> References: <20170722120258.GA22600@elstar.local> <9BC4E6D5-EB85-474F-A52B-BC170A962FC5@tzi.org> <20170722140230.GA22751@elstar.local> <74bbae503e0cfb3d689ea2a737a5e7f4@xs4all.nl> <20170724091829.GA23635@elstar.local> <20170724100037.GA23746@elstar.local> <1A9412FE-F663-479B-AC0C-4286B146B74D@ackl.io> <20170724101300.GA23787@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] yang cbor encoding without SID X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 12:30:42 -0000 Ok, great - we=E2=80=99ll include it in the next version. Thanks a lot, Juergen !=20 Alexander > Le 24 juil. 2017 =C3=A0 12:13, Juergen Schoenwaelder = a =C3=A9crit : >=20 > On Mon, Jul 24, 2017 at 12:02:28PM +0200, Alexander Pelov wrote: >> Dear Juergen, >>=20 >> Sounds perfectly reasonable! Thanks for pointing it out - and you are = right about it. >>=20 >> It is already in the text, but I=E2=80=99m taking note that we should = make it more explicit and maybe add a sentence to underline it in the = introduction / abstract. >>=20 >> Does that sound OK ? >=20 > Yes >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Mon Jul 24 05:31:46 2017 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 DE1B6131CD5 for ; Mon, 24 Jul 2017 05:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 c3ptphrHetco for ; Mon, 24 Jul 2017 05:31:43 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DD3131CDE for ; Mon, 24 Jul 2017 05:31:43 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1500899480; h=from:subject:to:date:message-id; bh=SxeSfmBQQJzryH6MSIGWSiBSDkM+pTm3AD/kPw7yR1Q=; b=PY7vhRlVq6pyHc2PntKUb7O+mTHueINVoEBAXzXEawm0Jc0sOou7YTKb1UMNBj2s+0g5+OYbjIO 9k6ZFnsYXD/siG4wFHNaBpiMUXPIp2eJaGNJwC6LC/0Ucv4GD0c99aLGAI4UQYF8n8+5AmNmAwj5u 5EaLUXEKDzjrljJJSh3VD+fOk2Z44YFpkyP2Zi8qNcwpBtChs293fNDhc/6iagwu4kR0SxyE4laSg fa//vYRtJww8BKiDmD47SUQ9RXo3pL/s9cv37WdnCUI/nWzk/OQFu8jGNIDgtC6aLur26/L5ZPiOT otfZ7CXhejhKwx3C26lg7liKrh20dVAyEpuQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Jul 2017 05:31:20 -0700 Received: from Hebrews (88.128.80.153) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Jul 2017 05:31:17 -0700 From: Jim Schaad To: Date: Mon, 24 Jul 2017 14:31:37 +0200 Message-ID: <000201d30478$cd0b8ff0$6722afd0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMEdnvOkg5RLpB4Q1WQbmY/3o58ZQ== X-Originating-IP: [88.128.80.153] Archived-At: Subject: [core] Questions on RFC 8075 - http to CoAP mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 12:31:45 -0000 Following a number of discussions at the F2F meeting, I decided that I really needed to look at the proxy code that I inherited/stole and see if what it does matches what was documented. At this point in time I am still trying to trudge through the code (and I don't really expect any help there), however I have come up with a number of comments/questions that I would like to see if there are answers to. 1. Is there any real difference between the default mapping of section 5.3 and the simple form mapping of section 5.4.1 where the template is {+tu}. I cannot see what the difference would be and am currently planning to implement just section 5.4 and ignore section 5.3 2. In looking at example #2 of section 5.4.2.1, I think I got misled based on the example. Is there any reason why => https://p.example.com/hc/?s=coap&hp=s.example.com&p=/light Is not a valid result? That is why can I not omit the "&q=" if there is nothing there. 3. I am not sure what the correct story would be for dealing with the following GET coap://10.10.80.200/resource HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0) Host: 10.10.80.200 Proxy-Connection: Keep-Alive I generated that based on an ftp over http example, so it could easily be completely strange and illegal. However, what would this mean and is there a reason it was not covered? RFC 8132 --- PATCH/FETCH This document did not define any text to help me do this mapping. This applies both to the methods and to the error codes. From the text it appears that FETCH is a new concept while PATCH and iPATCH are/might have some support from HTTP and thus can be directly translated. However, trying to find all of the errors and documents on this is somewhat painful and if the section on how to do it and what the error matching is would be helpful both now and in the next version of the docment. Jim From nobody Mon Jul 24 06:52:12 2017 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 E3C62131771; Mon, 24 Jul 2017 06:52:09 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=augustcellars.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 6DkGk5t7d5If; Mon, 24 Jul 2017 06:52:07 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B88131D16; Mon, 24 Jul 2017 06:52:06 -0700 (PDT) Content-Type: multipart/related; boundary="----=_NextPart_000_000B_01D30494.CB81D1F0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1500904304; h=from:subject:to:date:message-id; bh=Qe9Md5kNj4TpdxSt6iw/phKtJAy+kAg99BVQCWJJVro=; b=eJlvHNbjqc0hQRNd1WuQegGBNiE/5H8jytFszZ3egXgznIVhxvgUnPO2J2DA9zrgYE8MUYqajiW aEYhG2wptOLRWreJOX4dMkqtGH6fzog5DoObZaj3brmVQ+8zC1mza8pmCwQqw2c629btnYtxXoOwg tGww3gb1vGKuRBNsSpdfJKXk1sHhIzWZFxAOQj8k4K7heJVLnoGwFGSAxa3vV/P9Q+t6AVy77Jr5U ysIx4LIb6fqWnI7Y718OrZKvDJ4TW+6GxDHRhHSVKFQI8rF3UBqrMm++2IVAcuix1NXEJEveGEo0W M7RgA2WmTOB02ao6eBP2XkVjLlJZ+yIynLaw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Jul 2017 06:51:43 -0700 Received: from Hebrews (88.128.80.153) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Jul 2017 06:51:39 -0700 From: Jim Schaad To: 'Raja ashok' , =?utf-8?Q?'G=C3=B6ran_Selander'?= CC: , References: In-Reply-To: Date: Mon, 24 Jul 2017 15:51:59 +0200 Message-ID: <000a01d30484$07f55870$17e00950$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF9aXKxXeprvkCCJedHdDeYKlJgYQJTOnbiAKgtTTii9lipUA== X-Originating-IP: [88.128.80.153] Archived-At: Subject: Re: [core] Doubts in draft-ietf-core-object-security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 13:52:10 -0000 ------=_NextPart_000_000B_01D30494.CB81D1F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01D30494.CB81D1F0" ------=_NextPart_001_000C_01D30494.CB81D1F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: core [mailto:core-bounces@ietf.org] On Behalf Of Raja ashok Sent: Monday, July 24, 2017 10:29 AM To: G=C3=B6ran Selander Cc: draft-ietf-core-object-security@ietf.org; core@ietf.org Subject: Re: [core] Doubts in draft-ietf-core-object-security =20 Hi G=C3=B6ran, =20 Thanks for your clarifications. =20 I agree with your point, same session key can be used for large number = of messages till the nonce of AEAD overflows. But as per my knowledge a = same session key (16byte) should not be used for more than few days(5 to = 10 days). Because it can be brute forced. So I am thinking like, we = should consider of periodically deriving session keys from same master = secret using different random numbers (master salt). =20 [JLS] If you have a method to do this then you would be doing something = that I have no idea how to do. Brute forcing a 128-bit key is currently = thought to be a fairly lengthy exercise. And simply bumping up to a = 256-bit key would be a way to make that nearly impossible without = breaking AES in it=E2=80=99s entirety. =20 =20 And also currently in OSCoAP, to handle reboot scenario, node should = periodically updates (current sequence number + n) to persistent memory. = I feel we can avoid this write on persistent memory, if we do random = number exchange before deriving session keys. I mean, a rebooted client = can initiate a request to derive new session key (need to consider DoS = attack here). So we can store only master secret in persistent memory. =20 [JLS] I am not sure which I think would be more expensive. An occasional = write to persistent memory (on the order of a couple of hundred messages = sent) or at least one round trip of transmission costs. However, if = that is what you want to do then that is the purpose of the EDHOC draft. = This does have a feature that what you are asking for does not have, = but would probably be the right answer. =20 Jim =20 =20 Please clarify me if my understanding is wrong. =20 Regards, Ashok =20 _____ =20 Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com=20 _____ =20 =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=E6= =9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4=BF= =A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB=99= =E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84=E4= =B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81 =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB=E4= =BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4=BD= =86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88=86= =E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96=E6= =95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E6= =94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=AB= =8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=A5= =E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE=E4= =BB=B6=EF=BC=81 This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 From: G=C3=B6ran Selander [mailto:goran.selander@ericsson.com]=20 Sent: 22 July 2017 12:13 To: Raja ashok Cc: core@ietf.org ; = draft-ietf-core-object-security@ietf.org = =20 Subject: Re: Doubts in draft-ietf-core-object-security =20 Hi Ashok, =20 Thanks for your comments. =20 What amount of message data do you envision during the lifetime of the = device? The same key can be used for a large number of messages (the = number depending on the AEAD algorithm) and there is in principle no = reason to change key before that. And after that you would probably want = to anyway make a Diffie-Hellman key exchange since the entropy of the = master secret is worn out. =20 In principle it is possible to have a new master salt seeded by = (something random known to) client and server and derive a new session = key, but for the reasons above we did not specify that. Another option = is to use OSCOAP with some other key exchange protocol which supports = key rollover. =20 Please let me know more about the use case if this doesn=E2=80=99t = answer the question. =20 Thanks G=C3=B6ran =20 From: Raja ashok > Date: Thursday 13 July 2017 at 14:39 To: G=C3=B6ran Selander >, = "draft-ietf-core-object-security@ietf.org = " = > Cc: "core@ietf.org " > Subject: Doubts in draft-ietf-core-object-security =20 Hi Goeran Selander, =20 I have gone through the OSCOAP and EDHOC drafts. And I am having few = doubts in it. Please provide your comments on it. =20 This specification makes handshake(EDHOC) for deriving master secret as = optional. And also a constraint node can skip handshake and establish a = secure channel if master secret is preconfigured. =20 This may make a constraint node to use same session keys (sender and = receiver key) for longer duration, if sequence number is not exhausted. = Only solution for renewing session key is to negotiate new master secret = by using EDHOC. But EDHOC supports only PSK_ECDHE and ECDSA_ECDHE = mechanism. Here I feel we are missing PSK without (EC)DHE mechanism for = establishing secure channel. I mean we are missing = TLS_PSK_WITH_AES_128_CCM_8 kind of mechanism. =20 In DTLS, TLS_PSK_WITH_AES_128_CCM_8 uses same PSK every time for = deriving session keys, and it doesn=E2=80=99t support PFS. But the = session key derived is different every time with the help of client and = server random. =20 So I feel we can consider of exchanging random number also along with = KID and Partial IV in the 1st Request and Response. To achieve = TLS_PSK_WITH_AES_128_CCM_8 kind of mechanism in OSCoAP without ECDHE = exchange. For this anyway we have to consider multiple factors like = replay attack, DoS attack (client initiating key derivation for each = request), client reboot case etc. =20 Regards, Ashok =20 _____ =20 Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com=20 _____ =20 =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=E6= =9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4=BF= =A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB=99= =E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84=E4= =B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81 =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB=E4= =BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4=BD= =86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88=86= =E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96=E6= =95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E6= =94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=AB= =8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=A5= =E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE=E4= =BB=B6=EF=BC=81 This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ------=_NextPart_001_000C_01D30494.CB81D1F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: core = [mailto:core-bounces@ietf.org] On Behalf Of Raja = ashok
Sent: Monday, July 24, 2017 10:29 AM
To: = G=C3=B6ran Selander <goran.selander@ericsson.com>
Cc: = draft-ietf-core-object-security@ietf.org; = core@ietf.org
Subject: Re: [core] Doubts in = draft-ietf-core-object-security

 

Hi G=C3=B6ran,

 

Thanks for your = clarifications.

 

I agree with your point, = same session key can be used for large number of messages till the nonce = of AEAD overflows. But as per my knowledge a same session key (16byte) = should not be used for more than few days(5 to 10 days). Because it can = be brute forced. So I am thinking like, we should consider of = periodically deriving session keys from same master secret using = different random numbers (master salt).

 

[JLS] If you = have a method to do this then you would be doing something that I have = no idea how to do.=C2=A0 Brute forcing a 128-bit key is currently = thought to be a fairly lengthy exercise.=C2=A0 And simply bumping up to = a 256-bit key would be a way to make that nearly impossible without = breaking AES in it=E2=80=99s entirety.=C2=A0

 

And also currently in = OSCoAP, to handle reboot scenario, node should periodically updates = (current sequence number + n) to persistent memory. I feel we can avoid = this write on persistent memory, if we do random number exchange before = deriving session keys. I mean, a rebooted client can initiate a request = to derive new session key (need to consider DoS attack here). So we can = store only master secret in persistent memory.

 

[JLS] I am = not sure which I think would be more expensive. An occasional write to = persistent memory (on the order of a couple of hundred messages sent) or = at least one round trip of transmission costs.=C2=A0 However, if that is = what you want to do then that is the purpose of the EDHOC draft. = =C2=A0This does have a feature that what you are asking for does not = have, but would probably be the right answer.

 

Jim

 

 

Please clarify me if my = understanding is wrong.

 

Regards,

Ashok

 

3D"Company_logo"

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com =

=E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6= =E5=90=AB=E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5= =AF=86=E4=BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80= =81=E7=BB=99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA= =E7=9A=84=E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81<= /span>
=E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5= =E4=BB=BB=E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6= =8B=AC=E4=BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83= =A8=E5=88=86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81= =E6=88=96=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD<= /span>
=E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8= =E9=94=99=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6= =82=A8=E7=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80= =9A=E7=9F=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC= =E9=82=AE=E4=BB=B6=EF=BC=81
This = e-mail and its attachments contain confidential information from HUAWEI, = which
is intended only for the person or entity whose address is = listed above. Any use of the
information contained herein in any way = (including, but not limited to, total or partial
disclosure, = reproduction, or dissemination) by persons other than the intended =
recipient(s) is prohibited. If you receive this e-mail in error, = please notify the sender by
phone or email immediately and delete = it!

 

From: = G=C3=B6ran Selander [mailto:goran.selander@ericsso= n.com]
Sent: 22 July 2017 12:13
To: Raja = ashok
Cc: core@ietf.org; = draft-ietf-core-= object-security@ietf.org
Subject: Re: Doubts in = draft-ietf-core-object-security

 

Hi = Ashok,

 

=

Thanks for your = comments.

 

=

What amount of message data do = you envision during the lifetime of the device? The same key can be used = for a large number of messages (the number depending on the AEAD = algorithm) and there is in principle no reason to change key before = that. And after that you would probably want to anyway make a = Diffie-Hellman key exchange since the entropy of the master secret is = worn out.

 

=

In principle it is possible to = have a new master salt seeded by (something random known to) client and = server and derive a new session key, but for the reasons above we did = not specify that. Another option is to use OSCOAP with some other key = exchange protocol which supports key = rollover.

 

=

Please let me know more about the = use case if this doesn=E2=80=99t answer the = question.

 

=

Thanks

=

G=C3=B6ran

 

=

From: = Raja ashok <raja.ashok@huawei.com>
Date: Thursday 13 July 2017 at 14:39
To: G=C3=B6ran = Selander <goran.selander@ericsson.com>, "draft-ietf-core-= object-security@ietf.org" <draft-ietf-core-= object-security@ietf.org>
Cc: "core@ietf.org" <core@ietf.org>
Subject: = Doubts in = draft-ietf-core-object-security

 

=

Hi Goeran = Selander,

 

I have gone through the = OSCOAP and EDHOC drafts. And I am having few doubts in it. Please = provide your comments on it.

 

This specification makes = handshake(EDHOC) for deriving master secret as optional. And also a = constraint node can skip handshake and establish a secure channel if = master secret is preconfigured.

 

This may make a constraint = node to use same session keys (sender and receiver key) for longer = duration, if sequence number is not exhausted. Only solution for = renewing session key is to negotiate new master secret by using EDHOC. = But EDHOC supports only PSK_ECDHE and ECDSA_ECDHE mechanism. Here I feel = we are missing PSK without (EC)DHE mechanism for establishing secure = channel. I mean we are missing TLS_PSK_WITH_AES_128_CCM_8 kind of = mechanism.

 

In DTLS, = TLS_PSK_WITH_AES_128_CCM_8 uses same PSK every time for deriving session = keys, and it doesn=E2=80=99t support PFS. But the session key derived is = different every time with the help of client and server = random.

 

So I feel we can consider = of exchanging random number also along with KID and Partial IV in the = 1st Request and Response. To achieve = TLS_PSK_WITH_AES_128_CCM_8 kind of mechanism in OSCoAP without ECDHE = exchange. For this anyway we have to consider multiple factors like = replay attack, DoS attack (client initiating key derivation for each = request), client reboot case etc.

 

Regards,

Ashok

 

3D"Company_logo"

Raja = Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

=E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6= =E5=90=AB=E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5= =AF=86=E4=BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80= =81=E7=BB=99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA= =E7=9A=84=E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81<= /span>
=E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5= =E4=BB=BB=E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6= =8B=AC=E4=BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83= =A8=E5=88=86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81= =E6=88=96=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD<= /span>
=E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8= =E9=94=99=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6= =82=A8=E7=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80= =9A=E7=9F=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC= =E9=82=AE=E4=BB=B6=EF=BC=81
This = e-mail and its attachments contain confidential information from HUAWEI, = which
is intended only for the person or entity whose address is = listed above. Any use of the
information contained herein in any way = (including, but not limited to, total or partial
disclosure, = reproduction, or dissemination) by persons other than the intended =
recipient(s) is prohibited. If you receive this e-mail in error, = please notify the sender by
phone or email immediately and delete = it!

 

------=_NextPart_001_000C_01D30494.CB81D1F0-- ------=_NextPart_000_000B_01D30494.CB81D1F0 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------=_NextPart_000_000B_01D30494.CB81D1F0-- From nobody Mon Jul 24 07:25:11 2017 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 493A3131D2C for ; Mon, 24 Jul 2017 07:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_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=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHdOoG9o6UAu for ; Mon, 24 Jul 2017 07:25:08 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3D8131D1E for ; Mon, 24 Jul 2017 07:25:08 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id c184so33192871wmd.0 for ; Mon, 24 Jul 2017 07:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=mrZxUxcc+Icciv342gAobwY3np66wWmY9cUnFqkWDt8=; b=o5uFwgxy2WORCtk8TJQpt9qAjOsX6kegbdtPPtfl2RkKm5hZhBpV3C/sqpzbuTqrag Soib619Bfv25dOXO/Of3hXl/z14lAOyzxtrgoAhHmDX0EDt616ugTPBzY79FJBjmMc6H eUGV4hE2vQK/X1d/FLwCd8VrRE9cCWddh42mqf0MUIyNx3XffiopJHevG6tPUkLBuyCO mx5Cdcy3zBGXJPWB3jdUnBUZqeghCQXlfcb7TKlMClxu+Ghb5bJjHS3X9GKjytCfmh+s MUSkpc0pIa5XWsd+i+oNpv4l0UrVFMXRAD+pMzManbRhX5OHwJJubl34LlLlNbE5ELpP XMeQ== 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=mrZxUxcc+Icciv342gAobwY3np66wWmY9cUnFqkWDt8=; b=UOHhcDiQZSfC832DBfyyHZWMQBH2Fh6C1gH4jcSp+l03eKOKOubQDHLSZXEeBzIjrj 052NP0XLM2MfFcQ2YEE9DpRPsA0EgV9ikgrniXO57qwEne3C7JYctXqfP0K+Up+su/Jm W0rMqhLw3/RFKFFnj9dGelDbv1qh2IzylGiTfGOsPUHQRDg1otrQ3GZNooFOUb434Ai8 MbbT+kWUdqr284tbBWGoNAqxBpxha/URUnHLeUtNdMgTujTQ7CE6QKIgR6tQL1u+XrrL ilbEhoIQUAqj9lG+gtHusrStln5de+0gg5t4KjvnKPy4+zA61igrXPNcqPXEfIFO2mgL Tjqw== X-Gm-Message-State: AIVw112OKCroJhuM+UTHA5wV9PJ0i9au40QuAskvuoNW6xaGmA0RPB3X iwyUnwXD8Zsrb8uH9G83kUXoDOKL5b27 X-Received: by 10.28.32.81 with SMTP id g78mr4754540wmg.59.1500906306571; Mon, 24 Jul 2017 07:25:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.152.196 with HTTP; Mon, 24 Jul 2017 07:25:05 -0700 (PDT) From: Andy Bierman Date: Mon, 24 Jul 2017 07:25:05 -0700 Message-ID: To: Core Content-Type: multipart/alternative; boundary="001a113c89de3edf4d055510fb33" Archived-At: Subject: [core] YANG modules for Class 1 devices? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 24 Jul 2017 14:25:10 -0000 --001a113c89de3edf4d055510fb33 Content-Type: text/plain; charset="UTF-8" Hi, Are there any real YANG modules for use on Class 1 constrained devices at this time? It might be useful to see examples of such modules and their corresponding SID files. thanks, Andy --001a113c89de3edf4d055510fb33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Are there any real YANG modules for= use on Class 1 constrained devices at this time?
It might be use= ful to see examples of such modules and their corresponding SID files.


thanks,
Andy

--001a113c89de3edf4d055510fb33-- From nobody Mon Jul 24 23:18:31 2017 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 C346B1200F3; Mon, 24 Jul 2017 23:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj3UfvPKB4zz; Mon, 24 Jul 2017 23:18:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1E4126B7E; Mon, 24 Jul 2017 23:18:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRY38475; Tue, 25 Jul 2017 06:18:20 +0000 (GMT) Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 25 Jul 2017 07:17:43 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.23]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0301.000; Tue, 25 Jul 2017 11:47:32 +0530 From: Raja ashok To: Jim Schaad , =?utf-8?B?J0fDtnJhbiBTZWxhbmRlcic=?= CC: "draft-ietf-core-object-security@ietf.org" , "core@ietf.org" Thread-Topic: [core] Doubts in draft-ietf-core-object-security Thread-Index: AdL71RHIJFGFQkrRQUCixg0rsoEXNAG4KoyAAGdOnFAAAL04gAAtgqng Date: Tue, 25 Jul 2017 06:17:32 +0000 Message-ID: References: <000a01d30484$07f55870$17e00950$@augustcellars.com> In-Reply-To: <000a01d30484$07f55870$17e00950$@augustcellars.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.121] Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E23013E0BLREML503MBXchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.5976E2AE.0027, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.9.23, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 32ff62353201d421cab1a4721d4739dc Archived-At: Subject: Re: [core] Doubts in draft-ietf-core-object-security X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 06:18:29 -0000 --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E23013E0BLREML503MBXchi_ Content-Type: multipart/alternative; boundary="_000_FDFEA8C9B9B6BD4685DCC959079C81F5E23013E0BLREML503MBXchi_" --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E23013E0BLREML503MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmltLA0KDQpQbGVhc2UgZmluZCBteSBpbmxpbmVkIGNvbW1lbnRzLg0KDQpSZWdhcmRzLA0K QXNob2sNCg0KRnJvbTogSmltIFNjaGFhZCBbbWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb21d DQpTZW50OiAyNCBKdWx5IDIwMTcgMTk6MjINClRvOiBSYWphIGFzaG9rOyAnR8O2cmFuIFNlbGFu ZGVyJw0KQ2M6IGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc7IGNvcmVA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbY29yZV0gRG91YnRzIGluIGRyYWZ0LWlldGYtY29yZS1v YmplY3Qtc2VjdXJpdHkNCg0KDQoNCkZyb206IGNvcmUgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBSYWphIGFzaG9rDQpTZW50OiBNb25kYXksIEp1bHkgMjQsIDIw MTcgMTA6MjkgQU0NClRvOiBHw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29u LmNvbTxtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPj4NCkNjOiBkcmFmdC1pZXRm LWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNvcmUtb2Jq ZWN0LXNlY3VyaXR5QGlldGYub3JnPjsgY29yZUBpZXRmLm9yZzxtYWlsdG86Y29yZUBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbY29yZV0gRG91YnRzIGluIGRyYWZ0LWlldGYtY29yZS1vYmplY3Qt c2VjdXJpdHkNCg0KSGkgR8O2cmFuLA0KDQpUaGFua3MgZm9yIHlvdXIgY2xhcmlmaWNhdGlvbnMu DQoNCkkgYWdyZWUgd2l0aCB5b3VyIHBvaW50LCBzYW1lIHNlc3Npb24ga2V5IGNhbiBiZSB1c2Vk IGZvciBsYXJnZSBudW1iZXIgb2YgbWVzc2FnZXMgdGlsbCB0aGUgbm9uY2Ugb2YgQUVBRCBvdmVy Zmxvd3MuIEJ1dCBhcyBwZXIgbXkga25vd2xlZGdlIGEgc2FtZSBzZXNzaW9uIGtleSAoMTZieXRl KSBzaG91bGQgbm90IGJlIHVzZWQgZm9yIG1vcmUgdGhhbiBmZXcgZGF5cyg1IHRvIDEwIGRheXMp LiBCZWNhdXNlIGl0IGNhbiBiZSBicnV0ZSBmb3JjZWQuIFNvIEkgYW0gdGhpbmtpbmcgbGlrZSwg d2Ugc2hvdWxkIGNvbnNpZGVyIG9mIHBlcmlvZGljYWxseSBkZXJpdmluZyBzZXNzaW9uIGtleXMg ZnJvbSBzYW1lIG1hc3RlciBzZWNyZXQgdXNpbmcgZGlmZmVyZW50IHJhbmRvbSBudW1iZXJzICht YXN0ZXIgc2FsdCkuDQoNCltKTFNdIElmIHlvdSBoYXZlIGEgbWV0aG9kIHRvIGRvIHRoaXMgdGhl biB5b3Ugd291bGQgYmUgZG9pbmcgc29tZXRoaW5nIHRoYXQgSSBoYXZlIG5vIGlkZWEgaG93IHRv IGRvLiAgQnJ1dGUgZm9yY2luZyBhIDEyOC1iaXQga2V5IGlzIGN1cnJlbnRseSB0aG91Z2h0IHRv IGJlIGEgZmFpcmx5IGxlbmd0aHkgZXhlcmNpc2UuICBBbmQgc2ltcGx5IGJ1bXBpbmcgdXAgdG8g YSAyNTYtYml0IGtleSB3b3VsZCBiZSBhIHdheSB0byBtYWtlIHRoYXQgbmVhcmx5IGltcG9zc2li bGUgd2l0aG91dCBicmVha2luZyBBRVMgaW4gaXTigJlzIGVudGlyZXR5Lg0KDQoNCkFuZCBhbHNv IGN1cnJlbnRseSBpbiBPU0NvQVAsIHRvIGhhbmRsZSByZWJvb3Qgc2NlbmFyaW8sIG5vZGUgc2hv dWxkIHBlcmlvZGljYWxseSB1cGRhdGVzIChjdXJyZW50IHNlcXVlbmNlIG51bWJlciArIG4pIHRv IHBlcnNpc3RlbnQgbWVtb3J5LiBJIGZlZWwgd2UgY2FuIGF2b2lkIHRoaXMgd3JpdGUgb24gcGVy c2lzdGVudCBtZW1vcnksIGlmIHdlIGRvIHJhbmRvbSBudW1iZXIgZXhjaGFuZ2UgYmVmb3JlIGRl cml2aW5nIHNlc3Npb24ga2V5cy4gSSBtZWFuLCBhIHJlYm9vdGVkIGNsaWVudCBjYW4gaW5pdGlh dGUgYSByZXF1ZXN0IHRvIGRlcml2ZSBuZXcgc2Vzc2lvbiBrZXkgKG5lZWQgdG8gY29uc2lkZXIg RG9TIGF0dGFjayBoZXJlKS4gU28gd2UgY2FuIHN0b3JlIG9ubHkgbWFzdGVyIHNlY3JldCBpbiBw ZXJzaXN0ZW50IG1lbW9yeS4NCg0KW0pMU10gSSBhbSBub3Qgc3VyZSB3aGljaCBJIHRoaW5rIHdv dWxkIGJlIG1vcmUgZXhwZW5zaXZlLiBBbiBvY2Nhc2lvbmFsIHdyaXRlIHRvIHBlcnNpc3RlbnQg bWVtb3J5IChvbiB0aGUgb3JkZXIgb2YgYSBjb3VwbGUgb2YgaHVuZHJlZCBtZXNzYWdlcyBzZW50 KSBvciBhdCBsZWFzdCBvbmUgcm91bmQgdHJpcCBvZiB0cmFuc21pc3Npb24gY29zdHMuICBIb3dl dmVyLCBpZiB0aGF0IGlzIHdoYXQgeW91IHdhbnQgdG8gZG8gdGhlbiB0aGF0IGlzIHRoZSBwdXJw b3NlIG9mIHRoZSBFREhPQyBkcmFmdC4gIFRoaXMgZG9lcyBoYXZlIGEgZmVhdHVyZSB0aGF0IHdo YXQgeW91IGFyZSBhc2tpbmcgZm9yIGRvZXMgbm90IGhhdmUsIGJ1dCB3b3VsZCBwcm9iYWJseSBi ZSB0aGUgcmlnaHQgYW5zd2VyLg0KW0FzaG9rXSBJIGZlZWwgdGhlcmUgbWlnaHQgYmUgc29tZSBj YXNlLCB3aGVyZSBvY2Nhc2lvbmFsIHdyaXRlIHRvIHBlcnNpc3RlbnQgbWVtb3J5IG9mIHNlbnNv ciBub2RlIGlzIGV4cGVuc2l2ZSB0aGFuIDFSVFQgY29zdC4gSSB1bmRlcnN0b29kIHRoYXQgRURI T0MgKHdpdGggUFNLIG9yIFg1MDkpIGhlbHBzIHRvIGRlcml2ZSBuZXcgbWFzdGVyIHNlY3JldCwg YnV0IEVDREhFIGJhc2VkIGtleSBleGNoYW5nZSBpcyBtYW5kYXRvcnkgaGVyZS4gU28gdGhhdCBJ IHRob3VnaHQgb2YgY29uc2lkZXJpbmcgdGhlIGNhc2Ugb2YgZGVyaXZpbmcgbmV3IHNlc3Npb24g a2V5IChvciBtYXN0ZXIgc2VjcmV0KSB3aXRoIFBTSyBhbmQgcmFuZG9tIG5vbmNlICh3aXRob3V0 IEVDSERFKS4NCg0KSmltDQoNCg0KUGxlYXNlIGNsYXJpZnkgbWUgaWYgbXkgdW5kZXJzdGFuZGlu ZyBpcyB3cm9uZy4NCg0KUmVnYXJkcywNCkFzaG9rDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpbQ29tcGFueV9sb2dvXQ0KDQpSYWphIEFzaG9rIFYgSw0KSHVhd2VpIFRlY2hu b2xvZ2llcw0KQmFuZ2Fsb3JlLCBJbmRpYQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0K5pys6YKu5Lu25Y+K5YW26ZmE5Lu25ZCr5pyJ5Y2O 5Li65YWs5Y+455qE5L+d5a+G5L+h5oGv77yM5LuF6ZmQ5LqO5Y+R6YCB57uZ5LiK6Z2i5Zyw5Z2A 5Lit5YiX5Ye655qE5Liq5Lq65oiW576k57uE44CC56aBDQrmraLku7vkvZXlhbbku5bkurrku6Xk u7vkvZXlvaLlvI/kvb/nlKjvvIjljIXmi6zkvYbkuI3pmZDkuo7lhajpg6jmiJbpg6jliIblnLDm s4TpnLLjgIHlpI3liLbjgIHmiJbmlaPlj5HvvInmnKzpgq7ku7bkuK0NCueahOS/oeaBr+OAguWm guaenOaCqOmUmeaUtuS6huacrOmCruS7tu+8jOivt+aCqOeri+WNs+eUteivneaIlumCruS7tumA muefpeWPkeS7tuS6uuW5tuWIoOmZpOacrOmCruS7tu+8gQ0KVGhpcyBlLW1haWwgYW5kIGl0cyBh dHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwg d2hpY2gNCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFk ZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFp bmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90 YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9u KSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGllbnQocykgaXMgcHJv aGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBieQ0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBp dCENCg0KRnJvbTogR8O2cmFuIFNlbGFuZGVyIFttYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nz b24uY29tXQ0KU2VudDogMjIgSnVseSAyMDE3IDEyOjEzDQpUbzogUmFqYSBhc2hvaw0KQ2M6IGNv cmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNvcmUtb2JqZWN0 LXNlY3VyaXR5QGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5 QGlldGYub3JnPg0KU3ViamVjdDogUmU6IERvdWJ0cyBpbiBkcmFmdC1pZXRmLWNvcmUtb2JqZWN0 LXNlY3VyaXR5DQoNCkhpIEFzaG9rLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQoNCldo YXQgYW1vdW50IG9mIG1lc3NhZ2UgZGF0YSBkbyB5b3UgZW52aXNpb24gZHVyaW5nIHRoZSBsaWZl dGltZSBvZiB0aGUgZGV2aWNlPyBUaGUgc2FtZSBrZXkgY2FuIGJlIHVzZWQgZm9yIGEgbGFyZ2Ug bnVtYmVyIG9mIG1lc3NhZ2VzICh0aGUgbnVtYmVyIGRlcGVuZGluZyBvbiB0aGUgQUVBRCBhbGdv cml0aG0pIGFuZCB0aGVyZSBpcyBpbiBwcmluY2lwbGUgbm8gcmVhc29uIHRvIGNoYW5nZSBrZXkg YmVmb3JlIHRoYXQuIEFuZCBhZnRlciB0aGF0IHlvdSB3b3VsZCBwcm9iYWJseSB3YW50IHRvIGFu eXdheSBtYWtlIGEgRGlmZmllLUhlbGxtYW4ga2V5IGV4Y2hhbmdlIHNpbmNlIHRoZSBlbnRyb3B5 IG9mIHRoZSBtYXN0ZXIgc2VjcmV0IGlzIHdvcm4gb3V0Lg0KDQpJbiBwcmluY2lwbGUgaXQgaXMg cG9zc2libGUgdG8gaGF2ZSBhIG5ldyBtYXN0ZXIgc2FsdCBzZWVkZWQgYnkgKHNvbWV0aGluZyBy YW5kb20ga25vd24gdG8pIGNsaWVudCBhbmQgc2VydmVyIGFuZCBkZXJpdmUgYSBuZXcgc2Vzc2lv biBrZXksIGJ1dCBmb3IgdGhlIHJlYXNvbnMgYWJvdmUgd2UgZGlkIG5vdCBzcGVjaWZ5IHRoYXQu IEFub3RoZXIgb3B0aW9uIGlzIHRvIHVzZSBPU0NPQVAgd2l0aCBzb21lIG90aGVyIGtleSBleGNo YW5nZSBwcm90b2NvbCB3aGljaCBzdXBwb3J0cyBrZXkgcm9sbG92ZXIuDQoNClBsZWFzZSBsZXQg bWUga25vdyBtb3JlIGFib3V0IHRoZSB1c2UgY2FzZSBpZiB0aGlzIGRvZXNu4oCZdCBhbnN3ZXIg dGhlIHF1ZXN0aW9uLg0KDQpUaGFua3MNCkfDtnJhbg0KDQpGcm9tOiBSYWphIGFzaG9rIDxyYWph LmFzaG9rQGh1YXdlaS5jb208bWFpbHRvOnJhamEuYXNob2tAaHVhd2VpLmNvbT4+DQpEYXRlOiBU aHVyc2RheSAxMyBKdWx5IDIwMTcgYXQgMTQ6MzkNClRvOiBHw7ZyYW4gU2VsYW5kZXIgPGdvcmFu LnNlbGFuZGVyQGVyaWNzc29uLmNvbTxtYWlsdG86Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29t Pj4sICJkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPG1haWx0bzpkcmFm dC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPiIgPGRyYWZ0LWlldGYtY29yZS1v YmplY3Qtc2VjdXJpdHlAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2Vj dXJpdHlAaWV0Zi5vcmc+Pg0KQ2M6ICJjb3JlQGlldGYub3JnPG1haWx0bzpjb3JlQGlldGYub3Jn PiIgPGNvcmVAaWV0Zi5vcmc8bWFpbHRvOmNvcmVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogRG91YnRz IGluIGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHkNCg0KSGkgR29lcmFuIFNlbGFuZGVy LA0KDQpJIGhhdmUgZ29uZSB0aHJvdWdoIHRoZSBPU0NPQVAgYW5kIEVESE9DIGRyYWZ0cy4gQW5k IEkgYW0gaGF2aW5nIGZldyBkb3VidHMgaW4gaXQuIFBsZWFzZSBwcm92aWRlIHlvdXIgY29tbWVu dHMgb24gaXQuDQoNClRoaXMgc3BlY2lmaWNhdGlvbiBtYWtlcyBoYW5kc2hha2UoRURIT0MpIGZv ciBkZXJpdmluZyBtYXN0ZXIgc2VjcmV0IGFzIG9wdGlvbmFsLiBBbmQgYWxzbyBhIGNvbnN0cmFp bnQgbm9kZSBjYW4gc2tpcCBoYW5kc2hha2UgYW5kIGVzdGFibGlzaCBhIHNlY3VyZSBjaGFubmVs IGlmIG1hc3RlciBzZWNyZXQgaXMgcHJlY29uZmlndXJlZC4NCg0KVGhpcyBtYXkgbWFrZSBhIGNv bnN0cmFpbnQgbm9kZSB0byB1c2Ugc2FtZSBzZXNzaW9uIGtleXMgKHNlbmRlciBhbmQgcmVjZWl2 ZXIga2V5KSBmb3IgbG9uZ2VyIGR1cmF0aW9uLCBpZiBzZXF1ZW5jZSBudW1iZXIgaXMgbm90IGV4 aGF1c3RlZC4gT25seSBzb2x1dGlvbiBmb3IgcmVuZXdpbmcgc2Vzc2lvbiBrZXkgaXMgdG8gbmVn b3RpYXRlIG5ldyBtYXN0ZXIgc2VjcmV0IGJ5IHVzaW5nIEVESE9DLiBCdXQgRURIT0Mgc3VwcG9y dHMgb25seSBQU0tfRUNESEUgYW5kIEVDRFNBX0VDREhFIG1lY2hhbmlzbS4gSGVyZSBJIGZlZWwg d2UgYXJlIG1pc3NpbmcgUFNLIHdpdGhvdXQgKEVDKURIRSBtZWNoYW5pc20gZm9yIGVzdGFibGlz aGluZyBzZWN1cmUgY2hhbm5lbC4gSSBtZWFuIHdlIGFyZSBtaXNzaW5nIFRMU19QU0tfV0lUSF9B RVNfMTI4X0NDTV84IGtpbmQgb2YgbWVjaGFuaXNtLg0KDQpJbiBEVExTLCBUTFNfUFNLX1dJVEhf QUVTXzEyOF9DQ01fOCB1c2VzIHNhbWUgUFNLIGV2ZXJ5IHRpbWUgZm9yIGRlcml2aW5nIHNlc3Np b24ga2V5cywgYW5kIGl0IGRvZXNu4oCZdCBzdXBwb3J0IFBGUy4gQnV0IHRoZSBzZXNzaW9uIGtl eSBkZXJpdmVkIGlzIGRpZmZlcmVudCBldmVyeSB0aW1lIHdpdGggdGhlIGhlbHAgb2YgY2xpZW50 IGFuZCBzZXJ2ZXIgcmFuZG9tLg0KDQpTbyBJIGZlZWwgd2UgY2FuIGNvbnNpZGVyIG9mIGV4Y2hh bmdpbmcgcmFuZG9tIG51bWJlciBhbHNvIGFsb25nIHdpdGggS0lEIGFuZCBQYXJ0aWFsIElWIGlu IHRoZSAxc3QgUmVxdWVzdCBhbmQgUmVzcG9uc2UuIFRvIGFjaGlldmUgVExTX1BTS19XSVRIX0FF U18xMjhfQ0NNXzgga2luZCBvZiBtZWNoYW5pc20gaW4gT1NDb0FQIHdpdGhvdXQgRUNESEUgZXhj aGFuZ2UuIEZvciB0aGlzIGFueXdheSB3ZSBoYXZlIHRvIGNvbnNpZGVyIG11bHRpcGxlIGZhY3Rv cnMgbGlrZSByZXBsYXkgYXR0YWNrLCBEb1MgYXR0YWNrIChjbGllbnQgaW5pdGlhdGluZyBrZXkg ZGVyaXZhdGlvbiBmb3IgZWFjaCByZXF1ZXN0KSwgY2xpZW50IHJlYm9vdCBjYXNlIGV0Yy4NCg0K UmVnYXJkcywNCkFzaG9rDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpbQ29t cGFueV9sb2dvXQ0KDQpSYWphIEFzaG9rIFYgSw0KSHVhd2VpIFRlY2hub2xvZ2llcw0KQmFuZ2Fs b3JlLCBJbmRpYQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0K5pys6YKu5Lu25Y+K5YW26ZmE5Lu25ZCr5pyJ5Y2O5Li65YWs5Y+455qE5L+d 5a+G5L+h5oGv77yM5LuF6ZmQ5LqO5Y+R6YCB57uZ5LiK6Z2i5Zyw5Z2A5Lit5YiX5Ye655qE5Liq 5Lq65oiW576k57uE44CC56aBDQrmraLku7vkvZXlhbbku5bkurrku6Xku7vkvZXlvaLlvI/kvb/n lKjvvIjljIXmi6zkvYbkuI3pmZDkuo7lhajpg6jmiJbpg6jliIblnLDms4TpnLLjgIHlpI3liLbj gIHmiJbmlaPlj5HvvInmnKzpgq7ku7bkuK0NCueahOS/oeaBr+OAguWmguaenOaCqOmUmeaUtuS6 huacrOmCruS7tu+8jOivt+aCqOeri+WNs+eUteivneaIlumCruS7tumAmuefpeWPkeS7tuS6uuW5 tuWIoOmZpOacrOmCruS7tu+8gQ0KVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250 YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hpY2gNCmlzIGludGVu ZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVk IGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBh bnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbA0K ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90 aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91 IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBi eQ0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0K --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E23013E0BLREML503MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrljY7mlofnu4bpu5E7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0Fj ZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjgiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBK aW0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5QbGVhc2UgZmluZCBteSBp bmxpbmVkIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+QXNob2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKaW0gU2NoYWFkIFttYWlsdG86aWV0ZkBh dWd1c3RjZWxsYXJzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNCBKdWx5IDIwMTcgMTk6MjI8 YnI+DQo8Yj5Ubzo8L2I+IFJhamEgYXNob2s7ICdHw7ZyYW4gU2VsYW5kZXInPGJyPg0KPGI+Q2M6 PC9iPiBkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnOyBjb3JlQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbY29yZV0gRG91YnRzIGluIGRyYWZ0LWlldGYt Y29yZS1vYmplY3Qtc2VjdXJpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBjb3JlIFs8YSBocmVmPSJtYWlsdG86Y29y ZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+UmFqYSBhc2hvazxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1 bHkgMjQsIDIwMTcgMTA6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+IEfDtnJhbiBTZWxhbmRlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbSI+Z29yYW4uc2VsYW5k ZXJAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnIj5kcmFmdC1pZXRmLWNvcmUt b2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYu b3JnIj5jb3JlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2NvcmVdIERv dWJ0cyBpbiBkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgR8O2 cmFuLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgY2xhcmlm aWNhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGFncmVlIHdp dGggeW91ciBwb2ludCwgc2FtZSBzZXNzaW9uIGtleSBjYW4gYmUgdXNlZCBmb3IgbGFyZ2UgbnVt YmVyIG9mIG1lc3NhZ2VzIHRpbGwgdGhlIG5vbmNlIG9mIEFFQUQgb3ZlcmZsb3dzLiBCdXQgYXMg cGVyIG15IGtub3dsZWRnZSBhIHNhbWUgc2Vzc2lvbiBrZXkgKDE2Ynl0ZSkgc2hvdWxkIG5vdCBi ZSB1c2VkIGZvciBtb3JlIHRoYW4gZmV3IGRheXMoNQ0KIHRvIDEwIGRheXMpLiBCZWNhdXNlIGl0 IGNhbiBiZSBicnV0ZSBmb3JjZWQuIFNvIEkgYW0gdGhpbmtpbmcgbGlrZSwgd2Ugc2hvdWxkIGNv bnNpZGVyIG9mIHBlcmlvZGljYWxseSBkZXJpdmluZyBzZXNzaW9uIGtleXMgZnJvbSBzYW1lIG1h c3RlciBzZWNyZXQgdXNpbmcgZGlmZmVyZW50IHJhbmRvbSBudW1iZXJzIChtYXN0ZXIgc2FsdCku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bSkxTXSBJZiB5b3UgaGF2ZSBhIG1ldGhv ZCB0byBkbyB0aGlzIHRoZW4geW91IHdvdWxkIGJlIGRvaW5nIHNvbWV0aGluZyB0aGF0IEkgaGF2 ZSBubyBpZGVhIGhvdyB0byBkby4mbmJzcDsgQnJ1dGUgZm9yY2luZyBhIDEyOC1iaXQga2V5IGlz IGN1cnJlbnRseSB0aG91Z2h0IHRvIGJlIGEgZmFpcmx5IGxlbmd0aHkgZXhlcmNpc2UuJm5ic3A7 IEFuZCBzaW1wbHkgYnVtcGluZyB1cCB0byBhIDI1Ni1iaXQga2V5IHdvdWxkIGJlIGENCiB3YXkg dG8gbWFrZSB0aGF0IG5lYXJseSBpbXBvc3NpYmxlIHdpdGhvdXQgYnJlYWtpbmcgQUVTIGluIGl0 4oCZcyBlbnRpcmV0eS4mbmJzcDsgPG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkFuZCBhbHNvIGN1cnJlbnRseSBpbiBPU0NvQVAsIHRvIGhhbmRs ZSByZWJvb3Qgc2NlbmFyaW8sIG5vZGUgc2hvdWxkIHBlcmlvZGljYWxseSB1cGRhdGVzIChjdXJy ZW50IHNlcXVlbmNlIG51bWJlciAmIzQzOyBuKSB0byBwZXJzaXN0ZW50IG1lbW9yeS4gSSBmZWVs IHdlIGNhbiBhdm9pZCB0aGlzIHdyaXRlIG9uIHBlcnNpc3RlbnQgbWVtb3J5LCBpZiB3ZSBkbyBy YW5kb20NCiBudW1iZXIgZXhjaGFuZ2UgYmVmb3JlIGRlcml2aW5nIHNlc3Npb24ga2V5cy4gSSBt ZWFuLCBhIHJlYm9vdGVkIGNsaWVudCBjYW4gaW5pdGlhdGUgYSByZXF1ZXN0IHRvIGRlcml2ZSBu ZXcgc2Vzc2lvbiBrZXkgKG5lZWQgdG8gY29uc2lkZXIgRG9TIGF0dGFjayBoZXJlKS4gU28gd2Ug Y2FuIHN0b3JlIG9ubHkgbWFzdGVyIHNlY3JldCBpbiBwZXJzaXN0ZW50IG1lbW9yeS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltKTFNdIEkgYW0gbm90IHN1cmUgd2hpY2ggSSB0aGlu ayB3b3VsZCBiZSBtb3JlIGV4cGVuc2l2ZS4gQW4gb2NjYXNpb25hbCB3cml0ZSB0byBwZXJzaXN0 ZW50IG1lbW9yeSAob24gdGhlIG9yZGVyIG9mIGEgY291cGxlIG9mIGh1bmRyZWQgbWVzc2FnZXMg c2VudCkgb3IgYXQgbGVhc3Qgb25lIHJvdW5kIHRyaXAgb2YgdHJhbnNtaXNzaW9uIGNvc3RzLiZu YnNwOyBIb3dldmVyLCBpZiB0aGF0IGlzIHdoYXQgeW91IHdhbnQNCiB0byBkbyB0aGVuIHRoYXQg aXMgdGhlIHB1cnBvc2Ugb2YgdGhlIEVESE9DIGRyYWZ0LiAmbmJzcDtUaGlzIGRvZXMgaGF2ZSBh IGZlYXR1cmUgdGhhdCB3aGF0IHlvdSBhcmUgYXNraW5nIGZvciBkb2VzIG5vdCBoYXZlLCBidXQg d291bGQgcHJvYmFibHkgYmUgdGhlIHJpZ2h0IGFuc3dlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bQXNob2tdIEkgZmVl bCB0aGVyZSBtaWdodCBiZSBzb21lIGNhc2UsIHdoZXJlIG9jY2FzaW9uYWwgd3JpdGUgdG8gcGVy c2lzdGVudCBtZW1vcnkgb2Ygc2Vuc29yIG5vZGUgaXMgZXhwZW5zaXZlIHRoYW4gMVJUVCBjb3N0 LiBJIHVuZGVyc3Rvb2QgdGhhdCBFREhPQyAod2l0aCBQU0sgb3IgWDUwOSkgaGVscHMgdG8gZGVy aXZlIG5ldyBtYXN0ZXIgc2VjcmV0LCBidXQNCiBFQ0RIRSBiYXNlZCBrZXkgZXhjaGFuZ2UgaXMg bWFuZGF0b3J5IGhlcmUuIFNvIHRoYXQgSSB0aG91Z2h0IG9mIGNvbnNpZGVyaW5nIHRoZSBjYXNl IG9mIGRlcml2aW5nIG5ldyBzZXNzaW9uIGtleSAob3IgbWFzdGVyIHNlY3JldCkgd2l0aCBQU0sg YW5kIHJhbmRvbSBub25jZSAod2l0aG91dCBFQ0hERSkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5KaW08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5QbGVhc2UgY2xhcmlmeSBtZSBpZiBteSB1bmRl cnN0YW5kaW5nIGlzIHdyb25nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXNob2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PCEtLVtpZiBndGUgdm1sIDFdPjx2OnNoYXBldHlw ZSBpZD0iX3gwMDAwX3Q3NSIgY29vcmRzaXplPSIyMTYwMCwyMTYwMCIgbzpzcHQ9Ijc1IiBvOnBy ZWZlcnJlbGF0aXZlPSJ0IiBwYXRoPSJtQDRANWxANEAxMUA5QDExQDlANXhlIiBmaWxsZWQ9ImYi IHN0cm9rZWQ9ImYiPg0KPHY6c3Ryb2tlIGpvaW5zdHlsZT0ibWl0ZXIiIC8+DQo8djpmb3JtdWxh cz4NCjx2OmYgZXFuPSJpZiBsaW5lRHJhd24gcGl4ZWxMaW5lV2lkdGggMCIgLz4NCjx2OmYgZXFu PSJzdW0gQDAgMSAwIiAvPg0KPHY6ZiBlcW49InN1bSAwIDAgQDEiIC8+DQo8djpmIGVxbj0icHJv ZCBAMiAxIDIiIC8+DQo8djpmIGVxbj0icHJvZCBAMyAyMTYwMCBwaXhlbFdpZHRoIiAvPg0KPHY6 ZiBlcW49InByb2QgQDMgMjE2MDAgcGl4ZWxIZWlnaHQiIC8+DQo8djpmIGVxbj0ic3VtIEAwIDAg MSIgLz4NCjx2OmYgZXFuPSJwcm9kIEA2IDEgMiIgLz4NCjx2OmYgZXFuPSJwcm9kIEA3IDIxNjAw IHBpeGVsV2lkdGgiIC8+DQo8djpmIGVxbj0ic3VtIEA4IDIxNjAwIDAiIC8+DQo8djpmIGVxbj0i cHJvZCBANyAyMTYwMCBwaXhlbEhlaWdodCIgLz4NCjx2OmYgZXFuPSJzdW0gQDEwIDIxNjAwIDAi IC8+DQo8L3Y6Zm9ybXVsYXM+DQo8djpwYXRoIG86ZXh0cnVzaW9ub2s9ImYiIGdyYWRpZW50c2hh cGVvaz0idCIgbzpjb25uZWN0dHlwZT0icmVjdCIgLz4NCjxvOmxvY2sgdjpleHQ9ImVkaXQiIGFz cGVjdHJhdGlvPSJ0IiAvPg0KPC92OnNoYXBldHlwZT48djpzaGFwZSBpZD0icmlkSW1nIiBvOnNw aWQ9Il94MDAwMF9zMTAyNyIgdHlwZT0iI194MDAwMF90NzUiIGFsdD0iQ29tcGFueV9sb2dvIiBz dHlsZT0ncG9zaXRpb246YWJzb2x1dGU7bWFyZ2luLWxlZnQ6MDttYXJnaW4tdG9wOjA7d2lkdGg6 NzYuNXB0O2hlaWdodDoyNHB0O3otaW5kZXg6MjUxNjU4MjQwO3Zpc2liaWxpdHk6dmlzaWJsZTtt c28td3JhcC1zdHlsZTpzcXVhcmU7bXNvLXdyYXAtZGlzdGFuY2UtbGVmdDowO21zby13cmFwLWRp c3RhbmNlLXRvcDowO21zby13cmFwLWRpc3RhbmNlLXJpZ2h0OjA7bXNvLXdyYXAtZGlzdGFuY2Ut Ym90dG9tOjA7bXNvLXBvc2l0aW9uLWhvcml6b250YWw6bGVmdDttc28tcG9zaXRpb24taG9yaXpv bnRhbC1yZWxhdGl2ZTp0ZXh0O21zby1wb3NpdGlvbi12ZXJ0aWNhbDphYnNvbHV0ZTttc28tcG9z aXRpb24tdmVydGljYWwtcmVsYXRpdmU6bGluZScgbzphbGxvd292ZXJsYXA9ImYiPg0KPHY6aW1h Z2VkYXRhIHNyYz0iY2lkOmltYWdlMDAxLmpwZ0AwMUQzMDUzQS44NjJBNTY4MCIgbzp0aXRsZT0i Y29tcGFueV9sb2dvIiAvPg0KPHc6d3JhcCB0eXBlPSJzcXVhcmUiLz4NCjwvdjpzaGFwZT48IVtl bmRpZl0tLT48IVtpZiAhdm1sXT48aW1nIHdpZHRoPSIxMDIiIGhlaWdodD0iMzIiIHNyYz0iY2lk OmltYWdlMDAxLmpwZ0AwMUQzMDUzQS44NjJBNTY4MCIgYWxpZ249ImxlZnQiIGFsdD0iQ29tcGFu eV9sb2dvIiB2OnNoYXBlcz0icmlkSW1nIj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzU5NTk1OSI+UmFq YSBBc2hvayBWIEs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzU5 NTk1OSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNTk1OTU5Ij5IdWF3ZWkgVGVj aG5vbG9naWVzPGJyPg0KQmFuZ2Fsb3JlLCBJbmRpYTxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cu aHVhd2VpLmNvbSI+aHR0cDovL3d3dy5odWF3ZWkuY29tPC9hPiA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFs aWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L 5L2TO2NvbG9yOiMxRjQ5N0QiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2Vu dGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlpI LUNOIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpncmF5 Ij7mnKzpgq7ku7blj4rlhbbpmYTku7blkKvmnInljY7kuLrlhazlj7jnmoTkv53lr4bkv6Hmga/v vIzku4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrkurrmiJbnvqTn u4TjgILnpoE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTrl jY7mlofnu4bpu5E7Y29sb3I6Z3JheSI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpncmF5Ij7mraLk u7vkvZXlhbbku5bkurrku6Xku7vkvZXlvaLlvI/kvb/nlKjvvIjljIXmi6zkvYbkuI3pmZDkuo7l hajpg6jmiJbpg6jliIblnLDms4TpnLLjgIHlpI3liLbjgIHmiJbmlaPlj5HvvInmnKzpgq7ku7bk uK08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTrljY7mlofn u4bpu5E7Y29sb3I6Z3JheSI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpncmF5Ij7nmoTkv6Hmga/j gILlpoLmnpzmgqjplJnmlLbkuobmnKzpgq7ku7bvvIzor7fmgqjnq4vljbPnlLXor53miJbpgq7k u7bpgJrnn6Xlj5Hku7bkurrlubbliKDpmaTmnKzpgq7ku7bvvIE8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTrljY7mlofnu4bpu5E7Y29sb3I6Z3JheSI+PGJy Pg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpncmF5Ij5UaGlzIGUtbWFp bCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZy b20gSFVBV0VJLCB3aGljaA0KPGJyPg0KaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBv ciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlDQo8 YnI+DQppbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywg YnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsDQo8YnI+DQpkaXNjbG9zdXJlLCBy ZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUg aW50ZW5kZWQgPGJyPg0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZl IHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkNCjxicj4N CnBob25lIG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBHw7ZyYW4gU2VsYW5kZXIgWzxhIGhyZWY9 Im1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nvbi5jb20iPm1haWx0bzpnb3Jhbi5zZWxhbmRl ckBlcmljc3Nvbi5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIyIEp1bHkgMjAxNyAxMjox Mzxicj4NCjxiPlRvOjwvYj4gUmFqYSBhc2hvazxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJh ZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZyI+DQpkcmFmdC1pZXRmLWNvcmUt b2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogRG91 YnRzIGluIGRyYWZ0LWlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPkhpIEFzaG9rLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+V2hhdCBhbW91bnQgb2YgbWVzc2FnZSBkYXRhIGRvIHlv dSBlbnZpc2lvbiBkdXJpbmcgdGhlIGxpZmV0aW1lIG9mIHRoZSBkZXZpY2U/IFRoZSBzYW1lIGtl eSBjYW4gYmUgdXNlZCBmb3IgYSBsYXJnZSBudW1iZXIgb2YgbWVzc2FnZXMgKHRoZSBudW1iZXIg ZGVwZW5kaW5nIG9uIHRoZSBBRUFEIGFsZ29yaXRobSkgYW5kIHRoZXJlIGlzDQogaW4gcHJpbmNp cGxlIG5vIHJlYXNvbiB0byBjaGFuZ2Uga2V5IGJlZm9yZSB0aGF0LiBBbmQgYWZ0ZXIgdGhhdCB5 b3Ugd291bGQgcHJvYmFibHkgd2FudCB0byBhbnl3YXkgbWFrZSBhIERpZmZpZS1IZWxsbWFuIGtl eSBleGNoYW5nZSBzaW5jZSB0aGUgZW50cm9weSBvZiB0aGUgbWFzdGVyIHNlY3JldCBpcyB3b3Ju IG91dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkluIHByaW5jaXBs ZSBpdCBpcyBwb3NzaWJsZSB0byBoYXZlIGEgbmV3IG1hc3RlciBzYWx0IHNlZWRlZCBieSAoc29t ZXRoaW5nIHJhbmRvbSBrbm93biB0bykgY2xpZW50IGFuZCBzZXJ2ZXIgYW5kIGRlcml2ZSBhIG5l dyBzZXNzaW9uIGtleSwgYnV0IGZvciB0aGUgcmVhc29ucyBhYm92ZSB3ZSBkaWQgbm90IHNwZWNp ZnkgdGhhdC4gQW5vdGhlcg0KIG9wdGlvbiBpcyB0byB1c2UgT1NDT0FQIHdpdGggc29tZSBvdGhl ciBrZXkgZXhjaGFuZ2UgcHJvdG9jb2wgd2hpY2ggc3VwcG9ydHMga2V5IHJvbGxvdmVyLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+UGxlYXNlIGxldCBtZSBrbm93IG1v cmUgYWJvdXQgdGhlIHVzZSBjYXNlIGlmIHRoaXMgZG9lc27igJl0IGFuc3dlciB0aGUgcXVlc3Rp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5UaGFua3M8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+R8O2cmFuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+UmFqYSBhc2hvayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhamEu YXNob2tAaHVhd2VpLmNvbSI+cmFqYS5hc2hva0BodWF3ZWkuY29tPC9hPiZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+VGh1cnNkYXkgMTMgSnVseSAyMDE3IGF0IDE0OjM5PGJyPg0KPGI+VG86IDwvYj5H w7ZyYW4gU2VsYW5kZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3Jhbi5zZWxhbmRlckBlcmljc3Nv bi5jb20iPmdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZyI+ZHJhZnQt aWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpkcmFmdC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnIj5kcmFmdC1p ZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9i PiZxdW90OzxhIGhyZWY9Im1haWx0bzpjb3JlQGlldGYub3JnIj5jb3JlQGlldGYub3JnPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvcmVAaWV0Zi5vcmciPmNvcmVAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5Eb3VidHMgaW4gZHJhZnQtaWV0Zi1jb3JlLW9iamVj dC1zZWN1cml0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0IiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+SGkgR29lcmFuIFNlbGFuZGVyLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5JIGhhdmUgZ29uZSB0aHJvdWdoIHRoZSBPU0NPQVAgYW5kIEVESE9DIGRy YWZ0cy4gQW5kIEkgYW0gaGF2aW5nIGZldyBkb3VidHMgaW4gaXQuIFBsZWFzZSBwcm92aWRlIHlv dXIgY29tbWVudHMgb24gaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoaXMg c3BlY2lmaWNhdGlvbiBtYWtlcyBoYW5kc2hha2UoRURIT0MpIGZvciBkZXJpdmluZyBtYXN0ZXIg c2VjcmV0IGFzIG9wdGlvbmFsLiBBbmQgYWxzbyBhIGNvbnN0cmFpbnQgbm9kZSBjYW4gc2tpcCBo YW5kc2hha2UgYW5kIGVzdGFibGlzaCBhIHNlY3VyZSBjaGFubmVsIGlmIG1hc3RlciBzZWNyZXQg aXMgcHJlY29uZmlndXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhpcyBt YXkgbWFrZSBhIGNvbnN0cmFpbnQgbm9kZSB0byB1c2Ugc2FtZSBzZXNzaW9uIGtleXMgKHNlbmRl ciBhbmQgcmVjZWl2ZXIga2V5KSBmb3IgbG9uZ2VyIGR1cmF0aW9uLCBpZiBzZXF1ZW5jZSBudW1i ZXIgaXMgbm90IGV4aGF1c3RlZC4gT25seSBzb2x1dGlvbiBmb3IgcmVuZXdpbmcgc2Vzc2lvbiBr ZXkgaXMgdG8gbmVnb3RpYXRlIG5ldyBtYXN0ZXIgc2VjcmV0DQogYnkgdXNpbmcgRURIT0MuIEJ1 dCBFREhPQyBzdXBwb3J0cyBvbmx5IFBTS19FQ0RIRSBhbmQgRUNEU0FfRUNESEUgbWVjaGFuaXNt LiBIZXJlIEkgZmVlbCB3ZSBhcmUgbWlzc2luZyBQU0sgd2l0aG91dCAoRUMpREhFIG1lY2hhbmlz bSBmb3IgZXN0YWJsaXNoaW5nIHNlY3VyZSBjaGFubmVsLiBJIG1lYW4gd2UgYXJlIG1pc3Npbmcg VExTX1BTS19XSVRIX0FFU18xMjhfQ0NNXzgga2luZCBvZiBtZWNoYW5pc20uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkluIERUTFMsIFRMU19QU0tfV0lUSF9BRVNfMTI4X0NDTV84 IHVzZXMgc2FtZSBQU0sgZXZlcnkgdGltZSBmb3IgZGVyaXZpbmcgc2Vzc2lvbiBrZXlzLCBhbmQg aXQgZG9lc27igJl0IHN1cHBvcnQgUEZTLiBCdXQgdGhlIHNlc3Npb24ga2V5IGRlcml2ZWQgaXMg ZGlmZmVyZW50IGV2ZXJ5IHRpbWUgd2l0aCB0aGUgaGVscCBvZiBjbGllbnQgYW5kIHNlcnZlciBy YW5kb20uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNvIEkgZmVlbCB3ZSBjYW4g Y29uc2lkZXIgb2YgZXhjaGFuZ2luZyByYW5kb20gbnVtYmVyIGFsc28gYWxvbmcgd2l0aCBLSUQg YW5kIFBhcnRpYWwgSVYgaW4gdGhlIDE8c3VwPnN0PC9zdXA+IFJlcXVlc3QgYW5kIFJlc3BvbnNl LiBUbyBhY2hpZXZlIFRMU19QU0tfV0lUSF9BRVNfMTI4X0NDTV84IGtpbmQgb2YgbWVjaGFuaXNt IGluIE9TQ29BUCB3aXRob3V0IEVDREhFDQogZXhjaGFuZ2UuIEZvciB0aGlzIGFueXdheSB3ZSBo YXZlIHRvIGNvbnNpZGVyIG11bHRpcGxlIGZhY3RvcnMgbGlrZSByZXBsYXkgYXR0YWNrLCBEb1Mg YXR0YWNrIChjbGllbnQgaW5pdGlhdGluZyBrZXkgZGVyaXZhdGlvbiBmb3IgZWFjaCByZXF1ZXN0 KSwgY2xpZW50IHJlYm9vdCBjYXNlIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFzaG9rPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCjxociBz aXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48IS0tW2lmIGd0ZSB2bWwgMV0+PHY6c2hhcGUgaWQ9Il94MDAwMF9z MTAyNiIgdHlwZT0iI194MDAwMF90NzUiIGFsdD0iQ29tcGFueV9sb2dvIiBzdHlsZT0ncG9zaXRp b246YWJzb2x1dGU7bWFyZ2luLWxlZnQ6MDttYXJnaW4tdG9wOjA7d2lkdGg6NzYuNXB0O2hlaWdo dDoyNHB0O3otaW5kZXg6MjUxNjU3MjE2O21zby13cmFwLWRpc3RhbmNlLWxlZnQ6MDttc28td3Jh cC1kaXN0YW5jZS1yaWdodDowO21zby1wb3NpdGlvbi1ob3Jpem9udGFsOmxlZnQ7bXNvLXBvc2l0 aW9uLXZlcnRpY2FsLXJlbGF0aXZlOmxpbmUnIG86YWxsb3dvdmVybGFwPSJmIj4NCjx2OmltYWdl ZGF0YSBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFEMzA1M0EuODYyQTU2ODAiIG86dGl0bGU9Imlt YWdlMDAxIiAvPg0KPHc6d3JhcCB0eXBlPSJzcXVhcmUiLz4NCjwvdjpzaGFwZT48IVtlbmRpZl0t LT48IVtpZiAhdm1sXT48aW1nIHdpZHRoPSIxMDIiIGhlaWdodD0iMzIiIHNyYz0iY2lkOmltYWdl MDAxLmpwZ0AwMUQzMDUzQS44NjJBNTY4MCIgYWxpZ249ImxlZnQiIGFsdD0iQ29tcGFueV9sb2dv IiB2OnNoYXBlcz0iX3gwMDAwX3MxMDI2Ij48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM1OTU5NTkiPlJhamEg QXNob2sgViBLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiM1OTU5 NTkiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzU5NTk1OSI+SHVhd2VpIFRlY2hu b2xvZ2llczxicj4NCkJhbmdhbG9yZSwgSW5kaWE8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3Lmh1 YXdlaS5jb20iPmh0dHA6Ly93d3cuaHVhd2VpLmNvbTwvYT4gPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFs IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+DQo8aHIgc2l6 ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmdyYXkiPuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+ac ieWNjuS4uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWc sOWdgOS4reWIl+WHuueahOS4quS6uuaIlue+pOe7hOOAguemgTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTtjb2xvcjpncmF5Ij48YnI+ DQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk65a6L5L2TO2NvbG9yOmdyYXkiPuatouS7u+S9leWFtuS7luS6uuS7peS7u+S9leW9ouW8 j+S9v+eUqO+8iOWMheaLrOS9huS4jemZkOS6juWFqOmDqOaIlumDqOWIhuWcsOazhOmcsuOAgeWk jeWItuOAgeaIluaVo+WPke+8ieacrOmCruS7tuS4rTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OuWNjuaWh+e7hum7kTtjb2xvcjpncmF5Ij48YnI+DQo8L3Nw YW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6 5a6L5L2TO2NvbG9yOmdyYXkiPueahOS/oeaBr+OAguWmguaenOaCqOmUmeaUtuS6huacrOmCruS7 tu+8jOivt+aCqOeri+WNs+eUteivneaIlumCruS7tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZpOac rOmCruS7tu+8gTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5 OuWNjuaWh+e7hum7kTtjb2xvcjpncmF5Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmdyYXkiPlRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFp biBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoDQo8YnI+DQppcyBp bnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxp c3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGUNCjxicj4NCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBo ZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9y IHBhcnRpYWwNCjxicj4NCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlv bikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCA8YnI+DQpyZWNpcGllbnQocykg aXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBieQ0KPGJyPg0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkg YW5kIGRlbGV0ZSBpdCE8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E23013E0BLREML503MBXchi_-- --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E23013E0BLREML503MBXchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Tue, 25 Jul 2017 06:17:32 GMT"; modification-date="Tue, 25 Jul 2017 06:17:32 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E23013E0BLREML503MBXchi_-- From nobody Tue Jul 25 11:12:25 2017 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 A891B131E88 for ; Tue, 25 Jul 2017 11:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 0RuRw42ZsSRE for ; Tue, 25 Jul 2017 11:12:22 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCFA131E82 for ; Tue, 25 Jul 2017 11:12:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1501006318; h=from:subject:to:date:message-id; bh=YSEjp1Cs1R4XmirbggTvHHAlOnL9erpU+XmeDnf3lQs=; b=WS+mrYDUJIumlAos9vA2Zn6W4llWs8Ms41JhqncjTyoe8Vx4oq4wFcGnAjJbwQ8r61xlTv47OJd 2KQ2H2DrWiz0eGNcMn2q4m7UbcEiqpIZsHFhR55v7fde5vABAI/7L1Cfy+DMpP75VJn/FQxQYvZO6 KCKo636T9HNgtuzYpiC9ecDlgqruCOR6p7edVzrUgJK3NhiDNID++23EgP0nSqJ+RG8DVJUBRtJVA MBtViO4GpWfJ8JjIiRIzB73n/R14lh0HZ2AZU7fnKCsykz/iSv3TWdcEA2momKJk+ywPWvws3WGsv BgbjtjGU3kgWhdulp4OxhBn/uDJDU4vsiUpA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 25 Jul 2017 11:11:57 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 25 Jul 2017 11:11:53 -0700 From: Jim Schaad To: References: <000201d30478$cd0b8ff0$6722afd0$@augustcellars.com> <4ee5c6916963ee6abe77f1ed8bfeba65@xs4all.nl> In-Reply-To: <4ee5c6916963ee6abe77f1ed8bfeba65@xs4all.nl> Date: Tue, 25 Jul 2017 11:12:06 -0700 Message-ID: <00e801d30571$8891b490$99b51db0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE6YmOpEFIo78lLLrQIo3NMZ87nrgDNwVrPo4+tdAA= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] Questions on RFC 8075 - http to CoAP mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 25 Jul 2017 18:12:24 -0000 Off list I was asked to be more detailed about what my thinking was related to the patch drafts As of today I think that the following would be true: For an http->coap proxy: PATCH maps to PATCH without any changes (just like POST maps to POST). iPATCH and FETCH do not have any mapping as they are not defined for HTTP. 4.09 Conflict maps to 4.09 4.22 Unpossessable Entity maps to 4.09 For a coap->http proxy: PATCH map to PATCH without any changes iPATCH maps to PATCH FETCH fails as no mapping exists - Error of 4.05 Method Not Allowed Same error mapping Does that sound correct? Jim > RFC 8132 --- PATCH/FETCH > > This document did not define any text to help me do this mapping. > This applies both to the methods and to the error codes. From the > text it appears that FETCH is a new concept while PATCH and iPATCH > are/might have some support from HTTP and thus can be directly > translated. However, trying to find all of the errors and documents > on this is somewhat painful and if the section on how to do it and > what the error matching is would be helpful both now and in the next > version of the docment. > From nobody Wed Jul 26 00:47:34 2017 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 6DD621200FC for ; Wed, 26 Jul 2017 00:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 SAlel7ZN6jm9 for ; Wed, 26 Jul 2017 00:47:30 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865B612EA95 for ; Wed, 26 Jul 2017 00:47:30 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:195]) by smtp-cloud3.xs4all.net with ESMTP id pKnU1v00526ABXz01KnUtr; Wed, 26 Jul 2017 09:47:28 +0200 Received: from 2001:983:a264:1:3496:acfe:1e22:f993 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 26 Jul 2017 09:47:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 26 Jul 2017 09:47:28 +0200 From: peter van der Stok To: Jim Schaad Cc: core@ietf.org Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <00e801d30571$8891b490$99b51db0$@augustcellars.com> References: <000201d30478$cd0b8ff0$6722afd0$@augustcellars.com> <4ee5c6916963ee6abe77f1ed8bfeba65@xs4all.nl> <00e801d30571$8891b490$99b51db0$@augustcellars.com> Message-ID: <79d0680908fc702392e33c7060282c5d@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: Re: [core] Questions on RFC 8075 - http to CoAP mapping X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 07:47:33 -0000 Hi Jim, The analysis below looks correct to me. All error mappings follow the standard mapping Two exceptions, coap Patch explicitly returns 4.13 and 5.03, not mentioned by http Patch at first sight, but they can be converted to http 413 and 503 as they are very standard error codes. Advertising as specified for http patch is not specified for coap patch I don't think that mapping of caching behavior of patch is more complex than for other methods. does that help? Peter Jim Schaad schreef op 2017-07-25 20:12: > Off list I was asked to be more detailed about what my thinking was > related > to the patch drafts > > As of today I think that the following would be true: > > For an http->coap proxy: > > PATCH maps to PATCH without any changes (just like POST maps to POST). > iPATCH and FETCH do not have any mapping as they are not defined for > HTTP. > > 4.09 Conflict maps to 4.09 > 4.22 Unpossessable Entity maps to 4.09 > > > For a coap->http proxy: > > PATCH map to PATCH without any changes > iPATCH maps to PATCH > FETCH fails as no mapping exists - Error of 4.05 Method Not Allowed > > Same error mapping > > Does that sound correct? > > Jim > >> RFC 8132 --- PATCH/FETCH >> >> This document did not define any text to help me do this mapping. >> This applies both to the methods and to the error codes. From the >> text it appears that FETCH is a new concept while PATCH and iPATCH >> are/might have some support from HTTP and thus can be directly >> translated. However, trying to find all of the errors and documents >> on this is somewhat painful and if the section on how to do it and >> what the error matching is would be helpful both now and in the next >> version of the docment. >> > > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From nobody Wed Jul 26 03:49:51 2017 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 008BB131FE8 for ; Wed, 26 Jul 2017 03:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 OtUoPh0wcLXI for ; Wed, 26 Jul 2017 03:49:47 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9AC126DEE for ; Wed, 26 Jul 2017 03:49:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1501066165; h=from:subject:to:date:message-id; bh=ybQDCMDxRmO94M8X/f3VF/t+Kd1OvzAXdo/vTpzVYJg=; b=QqN/N/Xwkvr022sszpIv0yhvYt+udla0Gq8HyBZKV1kocuRqgckGu1eSpB54O9BWamXdqNifJGf /QGeiif5R+cfL/pMSI+ruJXEDInhbt63ssB1hepEgY4cZcpJZj2imTujZljeGStwpwDejPKiuU3qF h47mZqXdn4QBJvqXaGxY2RwhnC3xLNiam6V+IMFLbNpTtD/pC92PU3qwZuGMGmxM6lV37UvlVxYug 5GZff9OnlxKQMSfvEHqOyuQfXr0sl1XgeWQzVxO34UpRhS34BuWf5DEbRzxV3gql2nhrQiRhw6NXA HkRzglw9SFg99LpWIeK5pw93PNC5VJdc9k/Q== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Jul 2017 03:49:24 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Jul 2017 03:49:22 -0700 From: Jim Schaad To: Date: Wed, 26 Jul 2017 03:49:36 -0700 Message-ID: <015601d305fc$e18f9fe0$a4aedfa0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdMF+54HCIx1ItTCTFGRX6Gh0iCKrg== X-Originating-IP: [24.21.96.37] Archived-At: Subject: [core] How to proxy coap->http X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 10:49:49 -0000 I started to do something that I thought was reasonable and have just been told that what I wanted to do is apparently not legal according to the current specification. As I think it is totally reasonable, I want to verify that it is both reasonable and not permitted. And then maybe start a discussion about if it should be permitted. It may be this was discussed before I came into the group so a pointer to mailing list discussion would be apricated as well. The following is considered to be a valid URL when doing an HTTP to CoAP proxy http://example.com/http2coap/coap:://coap.example.com/hello >From this, I made the assumption that the reverse URL would be equally acceptable. That is coap://proxy.example.com/coap2http/http://hello.example.com/hello When encoding this, you would end up with GET coap://proxy.example.com/coap2http Proxy-Uri: http://hello.example.com/hello However, RFC 7252 in section 5.10.2 appears to state that one cannot have both a Proxy-Uri and a Uri-Path in the same message and be a legal message. 1) Am I correct this would be a reasonable thing to do - that is allow the proxy server to be a resource (and thus potentially supporting multiple proxies on a single server with different security requirements). 2) Am I correct that this is not something that is currently a legal thing to do? 3) Is there a reason why this is not supported. I do not believe that this maps to anything like an http CONNECT as there is no session that is established. It would map much closer to something that is just transforming the request and responses. Jim From nobody Wed Jul 26 05:03:03 2017 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 6A622131C60 for ; Wed, 26 Jul 2017 05:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5] 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 7b5tWwl7kaJ4 for ; Wed, 26 Jul 2017 05:02:59 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 67D2C126E3A for ; Wed, 26 Jul 2017 05:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6QC2tm0006249 for ; Wed, 26 Jul 2017 14:02:55 +0200 (CEST) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xHYdq0kMCzDLcy for ; Wed, 26 Jul 2017 14:02:55 +0200 (CEST) Received: by mail-io0-f172.google.com with SMTP id m88so58097414iod.2 for ; Wed, 26 Jul 2017 05:02:55 -0700 (PDT) X-Gm-Message-State: AIVw112TXkReBUyVCI2TRib4tZQpJCfC4Tx4B0KoTqGImsys2sp/QEMC F50YQbhPa8rb7Vm2oY8e2KhoNL4aHg== X-Received: by 10.107.11.209 with SMTP id 78mr650463iol.222.1501070573736; Wed, 26 Jul 2017 05:02:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.115.220 with HTTP; Wed, 26 Jul 2017 05:02:12 -0700 (PDT) In-Reply-To: <015601d305fc$e18f9fe0$a4aedfa0$@augustcellars.com> References: <015601d305fc$e18f9fe0$a4aedfa0$@augustcellars.com> From: Klaus Hartke Date: Wed, 26 Jul 2017 14:02:12 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Jim Schaad Cc: "core@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [core] How to proxy coap->http X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 12:03:02 -0000 Hi Jim! Jim Schaad wrote: > The following is considered to be a valid URL when doing an HTTP to CoAP > proxy > > http://example.com/http2coap/coap:://coap.example.com/hello (This would be encoded as:) GET /http2coap/coap:://coap.example.com/hello HTTP/1.1 Host: example.com > >From this, I made the assumption that the reverse URL would be equally > acceptable. That is > > coap://proxy.example.com/coap2http/http://hello.example.com/hello > > When encoding this, you would end up with > > GET coap://proxy.example.com/coap2http > Proxy-Uri: http://hello.example.com/hello (With the current rules, it would be encoded as:) method: GET uri-host: "proxy.example.com" uri-path: "coap2http" uri-path: "http:" uri-path: "" uri-path: "hello.example.com" uri-path: "hello" > However, RFC 7252 in section 5.10.2 appears to state that one cannot have > both a Proxy-Uri and a Uri-Path in the same message and be a legal message. When sending a request to a proxy, both CoAP and HTTP allow a client specify an absolute-URI. In CoAP it is possible that this is an http:// URI, but in HTTP putting a coap:// URI in the request-line works only theoretically. Works: method: GET proxy-uri: "http://hello.example.com/hello" Works in theory but not in practice: GET coap://coap.example.com/hello HTTP/1.1 So in HTTP you need some workaround to submit a CoAP URI to a proxy. Of course, you could apply the same workaround to CoAP, but the intention was to keep it simple and have the workaround be the exception, not the norm. > 1) Am I correct this would be a reasonable thing to do - that is allow the > proxy server to be a resource (and thus potentially supporting multiple > proxies on a single server with different security requirements). I can imagine that it would be reasonable to have proxies on a single server with different security requirements, but currently in both the CoAP architecture and HTTP architecture a proxy is a host and not a resource (with the exception of the HTTP-to-CoAP workaround). I would prefer to keep it this way. Can you tell more about the use case? > 2) Am I correct that this is not something that is currently a legal thing > to do? Yes, Proxy-URI and URI-* options are currently mutually exclusive. > 3) Is there a reason why this is not supported. I do not believe that this > maps to anything like an http CONNECT as there is no session that is > established. It would map much closer to something that is just > transforming the request and responses. See above. Klaus From nobody Wed Jul 26 05:12:22 2017 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 EEDEA131D25 for ; Wed, 26 Jul 2017 05:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 ps312anUPmXL for ; Wed, 26 Jul 2017 05:12:18 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64FC124E15 for ; Wed, 26 Jul 2017 05:12:17 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1501071117; h=from:subject:to:date:message-id; bh=hvPeFdE88dxBhGX37rl0A9xnZKCdOrIFKMfwO+riYCk=; b=K8ZJKZpFIZRPi4k9Mrf5SBXO+Dbb72/AxQiB5WyG3xpOlxqiySrRoiMs1Xam7leY4maggHLfrzP FbASP6IFWu2Oo1KG16ForCF195QrBjgY29hxrReThwAFPqQ5OS4SfJ4bUdnlRTPcVeI3LhbECyxQh DVZPVqY9XHP9puaGQvQodwFYcZsvrE/3uxtuYda4Z3Srbl1iG6PVZB2NpDeGufHr06tZeNm2ROa2e uOoCXx3KhFc2Q37eeW3Mp3anlOiuOLmdhPkGblpZ1riTrR3iEZzegE4279wcU1Y/OSCl6xDeHt+wO eQNbrd1LmzIwwmDRDmSqQPC2wOXxt5LaM4ng== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Jul 2017 05:11:57 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Jul 2017 05:11:54 -0700 From: Jim Schaad To: 'Klaus Hartke' CC: References: <015601d305fc$e18f9fe0$a4aedfa0$@augustcellars.com> In-Reply-To: Date: Wed, 26 Jul 2017 05:12:09 -0700 Message-ID: <016701d30608$6968feb0$3c3afc10$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHZYAK3M2Tdx3FSlHVEjICsWicFZQGd6NTPokxhPZA= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] How to proxy coap->http X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 12:12:20 -0000 Thanks for the response. The encoding that you have below using a = schema as a Uri-Path element would never have occurred to me. I will = need to cogitate. Jim -----Original Message----- From: Klaus Hartke [mailto:hartke@tzi.org]=20 Sent: Wednesday, July 26, 2017 5:02 AM To: Jim Schaad Cc: core@ietf.org WG Subject: Re: [core] How to proxy coap->http Hi Jim! Jim Schaad wrote: > The following is considered to be a valid URL when doing an HTTP to=20 > CoAP proxy > > http://example.com/http2coap/coap:://coap.example.com/hello (This would be encoded as:) GET /http2coap/coap:://coap.example.com/hello HTTP/1.1 Host: example.com > >From this, I made the assumption that the reverse URL would be=20 > >equally > acceptable. That is > > coap://proxy.example.com/coap2http/http://hello.example.com/hello > > When encoding this, you would end up with > > GET coap://proxy.example.com/coap2http > Proxy-Uri: http://hello.example.com/hello (With the current rules, it would be encoded as:) method: GET uri-host: "proxy.example.com" uri-path: "coap2http" uri-path: "http:" uri-path: "" uri-path: "hello.example.com" uri-path: "hello" > However, RFC 7252 in section 5.10.2 appears to state that one cannot=20 > have both a Proxy-Uri and a Uri-Path in the same message and be a = legal message. When sending a request to a proxy, both CoAP and HTTP allow a client = specify an absolute-URI. In CoAP it is possible that this is an http:// = URI, but in HTTP putting a coap:// URI in the request-line works only = theoretically. Works: method: GET proxy-uri: "http://hello.example.com/hello" Works in theory but not in practice: GET coap://coap.example.com/hello HTTP/1.1 So in HTTP you need some workaround to submit a CoAP URI to a proxy. Of course, you could apply the same workaround to CoAP, but the = intention was to keep it simple and have the workaround be the = exception, not the norm. > 1) Am I correct this would be a reasonable thing to do - that is=20 > allow the proxy server to be a resource (and thus potentially=20 > supporting multiple proxies on a single server with different security = requirements). I can imagine that it would be reasonable to have proxies on a single = server with different security requirements, but currently in both the = CoAP architecture and HTTP architecture a proxy is a host and not a = resource (with the exception of the HTTP-to-CoAP workaround). I would = prefer to keep it this way. Can you tell more about the use case? > 2) Am I correct that this is not something that is currently a legal=20 > thing to do? Yes, Proxy-URI and URI-* options are currently mutually exclusive. > 3) Is there a reason why this is not supported. I do not believe that = > this maps to anything like an http CONNECT as there is no session that = > is established. It would map much closer to something that is just=20 > transforming the request and responses. See above. Klaus From nobody Wed Jul 26 13:41:36 2017 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 970001315FF for ; Wed, 26 Jul 2017 13:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=augustcellars.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 PLja8nE05hTG for ; Wed, 26 Jul 2017 13:41:33 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C00126D46 for ; Wed, 26 Jul 2017 13:41:33 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1501101671; h=from:subject:to:date:message-id; bh=ZZN5hjUSP40rd6aZ8CguQNcdThe06HZ+0o48avm5lBU=; b=AcEq7LjPaWduDDVxbzAuV0S/U8aYaf+4k6aYErf6Mdi3nb95KiAK8FaGaqzWj0JKwr5L07XbU7P 6iU3IXmu4clvw+4TmGam+pymoJDPuEoaI/GbHeKuu4YW1E5SKJ1NocEhHhYM67DV9tdg4FrOT1uR9 BwXCj9YjXHFu+BUM07LPF4J+JjburVX6FgKNCmma8gyEiM27R01Ipn/I9hsD51FfUMnUONfhbJxAY oN23kIULmGqMhWVgQbdCDaxJHgRtMgk3gFjCLeCymhhdu1k7pYRo5pAaTYkSTGdNjc+M7cgnKgi33 dpXZ8gzCp41k+ZoVxRcj7Uam/8mJhq2c59jQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Jul 2017 13:41:11 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 26 Jul 2017 13:40:47 -0700 From: Jim Schaad To: 'Klaus Hartke' CC: References: <015601d305fc$e18f9fe0$a4aedfa0$@augustcellars.com> In-Reply-To: Date: Wed, 26 Jul 2017 13:41:03 -0700 Message-ID: <01a701d3064f$80fd66f0$82f834d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHZYAK3M2Tdx3FSlHVEjICsWicFZQGd6NTPokzCN+A= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [core] How to proxy coap->http X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 20:41:36 -0000 > -----Original Message----- > From: Klaus Hartke [mailto:hartke@tzi.org] > Sent: Wednesday, July 26, 2017 5:02 AM > To: Jim Schaad > Cc: core@ietf.org WG > Subject: Re: [core] How to proxy coap->http >=20 > Hi Jim! >=20 > Jim Schaad wrote: > > The following is considered to be a valid URL when doing an HTTP to > > CoAP proxy > > > > http://example.com/http2coap/coap:://coap.example.com/hello >=20 > (This would be encoded as:) >=20 > GET /http2coap/coap:://coap.example.com/hello HTTP/1.1 > Host: example.com >=20 > > >From this, I made the assumption that the reverse URL would be > > >equally > > acceptable. That is > > > > coap://proxy.example.com/coap2http/http://hello.example.com/hello > > > > When encoding this, you would end up with > > > > GET coap://proxy.example.com/coap2http > > Proxy-Uri: http://hello.example.com/hello >=20 > (With the current rules, it would be encoded as:) >=20 > method: GET > uri-host: "proxy.example.com" > uri-path: "coap2http" > uri-path: "http:" > uri-path: "" > uri-path: "hello.example.com" > uri-path: "hello" I recognize that with the encoding that I had above it would be a = different world and not the current rules. I understand how the current = rules would reach the encoding that you provided. >=20 > > However, RFC 7252 in section 5.10.2 appears to state that one cannot > > have both a Proxy-Uri and a Uri-Path in the same message and be a = legal > message. >=20 > When sending a request to a proxy, both CoAP and HTTP allow a client = specify > an absolute-URI. In CoAP it is possible that this is an http:// URI, = but in HTTP > putting a coap:// URI in the request-line works only theoretically. >=20 > Works: >=20 > method: GET > proxy-uri: "http://hello.example.com/hello" >=20 > Works in theory but not in practice: >=20 > GET coap://coap.example.com/hello HTTP/1.1 So, the only real reason that I can see for this not working is the fact = that one cannot write a PAC file that would provide a proxy mapping and = expect any current browser to make the function call. As an aside, I do = not know if the url passed into the function FindProxyForURL would = actually include the schema or not, however I am sure that Firefox today = would probably not make the function call for a coap schema. >=20 > So in HTTP you need some workaround to submit a CoAP URI to a proxy. > Of course, you could apply the same workaround to CoAP, but the = intention > was to keep it simple and have the workaround be the exception, not = the > norm. >=20 > > 1) Am I correct this would be a reasonable thing to do - that is > > allow the proxy server to be a resource (and thus potentially > > supporting multiple proxies on a single server with different = security > requirements). >=20 > I can imagine that it would be reasonable to have proxies on a single = server > with different security requirements, but currently in both the CoAP > architecture and HTTP architecture a proxy is a host and not a = resource (with > the exception of the HTTP-to-CoAP workaround). I would prefer to keep = it this > way. Can you tell more about the use case? I don't currently have a use case that I can give at this point in time = because I don't have a real world problem to solve. I am looking at = getting the code working with my code base and am looking for the = "easiest" way to do this with my current code base. I do have a couple of things that will affect how the proxy server is = going to operate. Since I want to have the ability to support running = coaps from the client to the proxy server, I fully expect that the = well-known points associated with the ACE framework document are going = to need to be supported. This means that the proxy server is not just = an implementation that is going to absorb everything at the root point, = but will have other resources besides the proxy one sitting at the root. = From my point of view it seems odd that this is the way things are = going to be laid out with root being the proxy server and other = resources existing. I would not expect a proxy server to support OSCOAP = as that is designed for end-to-end security, DTLS is going to be needed = which means that key configuration is going to be needed. =20 I am not sure how security would be setup to allow access control for = OSCOAP as it would imply some type of double encryption, but it would be = easy to do for dtls and do enforcement on the host and port of the = "final" destination point. Jim >=20 > > 2) Am I correct that this is not something that is currently a legal > > thing to do? >=20 > Yes, Proxy-URI and URI-* options are currently mutually exclusive. >=20 > > 3) Is there a reason why this is not supported. I do not believe = that > > this maps to anything like an http CONNECT as there is no session = that > > is established. It would map much closer to something that is just > > transforming the request and responses. >=20 > See above. >=20 > Klaus From nobody Thu Jul 27 16:07:28 2017 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 8FFE112EC14 for ; Thu, 27 Jul 2017 16:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 NSwJZgNb624X for ; Thu, 27 Jul 2017 16:07:25 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30129.outbound.protection.outlook.com [40.107.3.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE8712EC05 for ; Thu, 27 Jul 2017 16:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=93XsjDQigDOoEPOPbyPP7MT+lmGuj50JVfQMXVYHjes=; b=I8lkdhw77M9y3pqIYMxGHo0d9JsBfVA+yhRl6de/momYJcL5kanMwb4Y4RXW5pxVE7fbVIb4AcQDMwnjah1fYs0P4bwxt+cnhujuXCRfkCUCKaX03TjpyG/sPduvchUCgNkTNNJ1w5377gj3mgMKGXZSSFzGHuOr9tPqSyQSmJE= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB3072.eurprd07.prod.outlook.com (10.175.242.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Thu, 27 Jul 2017 23:07:21 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::d0a5:5d5d:c414:4b10]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::d0a5:5d5d:c414:4b10%14]) with mapi id 15.01.1304.021; Thu, 27 Jul 2017 23:07:21 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Jim Schaad , "core@ietf.org" Thread-Topic: [core] How to proxy coap->http Thread-Index: AdMF+54HCIx1ItTCTFGRX6Gh0iCKrgBOdp0A Date: Thu, 27 Jul 2017 23:07:20 +0000 Message-ID: <63BDBF2C-42CC-4B96-AEE1-6D5640B4CBD0@nokia.com> References: <015601d305fc$e18f9fe0$a4aedfa0$@augustcellars.com> In-Reply-To: <015601d305fc$e18f9fe0$a4aedfa0$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [109.170.183.119] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3072; 7:i8kRG2oIRrv/x12c8bX5epg4uq6Sy7AoZ9O8ZcIRpJrZaHt4QidkCKRDuGqMcTD+wnaLqf2gzK9bu8RFmCoeYH7CWlD/CFyKAwSn5a9ZNomKhtZ+bKqdusFPuL8QoCkeNiFuNNia9kBc7XxCAYT6JPAOOS0wZwJrAQAZjRfXrnfdwkMkr+bzuQd3Q9jO+u3TQVPqzOKO/U5kApcTWWSbDR21yn1K0KGreCpWde2eBtknKeouUcGYzLBAGV6XPsNYbQS+wLZ4na6Eeyn3gY5yM+znsUhTBwg9tGIJbQoQt7KfLqSJNdyluBj95f+DxW0Ope6TdNHS8UjKOa8MsCYq7Z/VUutRVRugBQZF0bYj8LwT0M097OMqCnpLZuPcjAwjVd34d5qXisw9xb0pH4eI/b53I7p9B5NzvpRUBtNrkNsY3io9D/UkfYhMi5n97VLD/0NZR7PcIvO/jaP0ksJwMEZwPrAZEl3PuR9/97nLB37/8hOR3Ipvoo7FskBJy8FmG8oukZ7A7VI3KUckr4PIXtlnspE4+nJZaIEVDAFnAqY/PPKSr6T6CJgbRf7LcP/tkTq3iZbDtzvuO63wcg4v8bmH8l/+IPjW/RNHiXLfrlrSS6YUdFspk17IeoO+DpEraFKoiHvjChNj42f1tVeXY7T+CAR3BGCXWi0mgGGly6lnP1JG9dYefWBkIKHcnAv3u/OlxemvNeD7HvobN4QCZAtXwvXJRUBk4MTHkKd7cbMNBa5N+S8OmhDPnK4x3kOsNG5WFjt0LoCStloqw98PzP+CTcTCduC7RAptjkKqrzk= x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39410400002)(39400400002)(39850400002)(39450400003)(39840400002)(24454002)(199003)(189002)(2501003)(25786009)(3846002)(6116002)(36756003)(305945005)(102836003)(105586002)(66066001)(6436002)(2900100001)(33656002)(2950100002)(2906002)(6246003)(189998001)(38730400002)(53936002)(107886003)(3280700002)(6512007)(3660700001)(82746002)(99286003)(6306002)(86362001)(106356001)(6486002)(4001350100001)(5250100002)(6506006)(229853002)(68736007)(4326008)(83716003)(101416001)(966005)(8676002)(14454004)(81166006)(8936002)(53546010)(50986999)(81156014)(7736002)(5660300001)(478600001)(83506001)(97736004)(54356999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3072; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 7e69e8d4-5a11-46fe-958a-08d4d5443c42 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254116)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR07MB3072; x-ms-traffictypediagnostic: VI1PR07MB3072: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB3072; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB3072; x-forefront-prvs: 03818C953D received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2017 23:07:20.9696 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3072 Archived-At: Subject: Re: [core] How to proxy coap->http X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 27 Jul 2017 23:07:28 -0000 SGkgSmltLA0KDQpPbiAyNC8wNy8yMDE3LCAxMzozMSwgImNvcmUgb24gYmVoYWxmIG9mIEppbSBT Y2hhYWQiIDxjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGlldGZAYXVndXN0Y2Vs bGFycy5jb20+IHdyb3RlOg0KPiBGb2xsb3dpbmcgYSBudW1iZXIgb2YgZGlzY3Vzc2lvbnMgYXQg dGhlIEYyRiBtZWV0aW5nLCBJIGRlY2lkZWQgdGhhdCBJDQo+IHJlYWxseSBuZWVkZWQgdG8gbG9v ayBhdCB0aGUgcHJveHkgY29kZSB0aGF0IEkgaW5oZXJpdGVkL3N0b2xlIGFuZCBzZWUNCj4gaWYg d2hhdCBpdCBkb2VzIG1hdGNoZXMgd2hhdCB3YXMgZG9jdW1lbnRlZC4gIEF0IHRoaXMgcG9pbnQg aW4gdGltZSBJDQo+IGFtIHN0aWxsIHRyeWluZyB0byB0cnVkZ2UgdGhyb3VnaCB0aGUgY29kZSAo YW5kIEkgZG9uJ3QgcmVhbGx5IGV4cGVjdA0KPiBhbnkgaGVscCB0aGVyZSksIGhvd2V2ZXIgSSBo YXZlIGNvbWUgdXAgd2l0aCBhIG51bWJlciBvZg0KPiBjb21tZW50cy9xdWVzdGlvbnMgdGhhdCBJ IHdvdWxkIGxpa2UgdG8gc2VlIGlmIHRoZXJlIGFyZSBhbnN3ZXJzIHRvLg0KPiANCj4gMS4gIElz IHRoZXJlIGFueSByZWFsIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgZGVmYXVsdCBtYXBwaW5nIG9m DQo+IHNlY3Rpb24gNS4zIGFuZCB0aGUgc2ltcGxlIGZvcm0gbWFwcGluZyBvZiBzZWN0aW9uIDUu NC4xIHdoZXJlIHRoZQ0KPiB0ZW1wbGF0ZSBpcyB7K3R1fS4gIEkgY2Fubm90IHNlZSB3aGF0IHRo ZSBkaWZmZXJlbmNlIHdvdWxkIGJlIGFuZCBhbQ0KPiBjdXJyZW50bHkgcGxhbm5pbmcgdG8gaW1w bGVtZW50IGp1c3Qgc2VjdGlvbiA1LjQgYW5kIGlnbm9yZSBzZWN0aW9uDQo+IDUuMw0KDQpJdCBp cyBzbGlnaHRseSBkaWZmZXJlbnQuICBCdXQgYmVjYXVzZSA1LjQuMSBpcyBhIHN1cGVyc2V0IG9m IDUuMywgaWYNCnlvdSBpbXBsZW1lbnQgNS40LjEgeW91IGRvbid0IG5lZWQgdG8gY2FyZSBhYm91 dCA1LjMuDQoNCj4gMi4gIEluIGxvb2tpbmcgYXQgZXhhbXBsZSAjMiBvZiBzZWN0aW9uIDUuNC4y LjEsIEkgdGhpbmsgSSBnb3QgbWlzbGVkDQo+IGJhc2VkIG9uIHRoZSBleGFtcGxlLiAgSXMgdGhl cmUgYW55IHJlYXNvbiB3aHkNCj4gDQo+ID0+IGh0dHBzOi8vcC5leGFtcGxlLmNvbS9oYy8/cz1j b2FwJmhwPXMuZXhhbXBsZS5jb20mcD0vbGlnaHQNCj4gDQo+IElzIG5vdCBhIHZhbGlkIHJlc3Vs dD8gIFRoYXQgaXMgd2h5IGNhbiBJIG5vdCBvbWl0IHRoZSAiJnE9IiBpZiB0aGVyZQ0KPiBpcyBu b3RoaW5nIHRoZXJlLg0KDQpJdCBpcyBjZXJ0YWlubHkgYSB2YWxpZCBVUkksIGJ1dCBpdCBpcyBu b3QgYSB2YWxpZCBvdXRwdXQgb2YgdGhlIFVSSQ0KdGVtcGxhdGUgaW5zdGFudGlhdGlvbiBiZWNh dXNlIHRoZSB0ZW1wbGF0ZSBzcGVjaWZpZXMgJyZxPScgYXMgYQ0KbGl0ZXJhbCwgdGhlcmVmb3Jl ICcmcT0nIHNob3VsZCBiZSBzZXJpYWxpc2VkIGV2ZW4gaWYgdGhlIHF1ZXJ5IHBhcnQgb2YNCnRo ZSBUYXJnZXQgQ29BUCBVUkkgaXMgbWlzc2luZy4NCg0KPiAzLiAgSSBhbSBub3Qgc3VyZSB3aGF0 IHRoZSBjb3JyZWN0IHN0b3J5IHdvdWxkIGJlIGZvciBkZWFsaW5nIHdpdGggdGhlDQo+IGZvbGxv d2luZw0KPiANCj4gR0VUIGNvYXA6Ly8xMC4xMC44MC4yMDAvcmVzb3VyY2UgSFRUUC8xLjENCj4g VXNlci1BZ2VudDogTW96aWxsYS80LjAgKGNvbXBhdGlibGU7IE1TSUUgOC4wKQ0KPiBIb3N0OiAx MC4xMC44MC4yMDANCj4gUHJveHktQ29ubmVjdGlvbjogS2VlcC1BbGl2ZSAgDQo+IA0KPiBJIGdl bmVyYXRlZCB0aGF0IGJhc2VkIG9uIGFuIGZ0cCBvdmVyIGh0dHAgZXhhbXBsZSwgc28gaXQgY291 bGQgZWFzaWx5DQo+IGJlIGNvbXBsZXRlbHkgc3RyYW5nZSBhbmQgaWxsZWdhbC4gIEhvd2V2ZXIs IHdoYXQgd291bGQgdGhpcyBtZWFuIGFuZA0KPiBpcyB0aGVyZSBhIHJlYXNvbiBpdCB3YXMgbm90 IGNvdmVyZWQ/DQoNClRoZSByZXF1ZXN0IGlzIHZhbGlkLCBzbyBpZiB0aGUgSEMgcHJveHkgcmVj ZWl2ZXMgaXQsIGl0IHNob3VsZCBmb3J3YXJkDQppdCB0byB0aGUgQ29BUCBub2RlIChpZiBhbGxv d2VkIGJ5IHBvbGljeSkuICBUaGUgcmVhc29uIHdoeSBVUkktbWFwcGluZw0KZXhpc3RzIGluIHRo ZSBmaXJzdCBwbGFjZSB0aG91Z2ggLSBhcyBkaXNjdXNzZWQgYXQgdGhlIGJlZ2lubmluZyBvZg0K c2VjdGlvbiA1IC0gaXMgdGhhdCB1c2VyIGFnZW50cyBkb24ndCBsaWtlIGdlbmVyYXRpbmcgY29h cChzKSBVUkkgaW4NCmFic29sdXRlLWZvcm0uDQoNCj4gUkZDIDgxMzIgLS0tIFBBVENIL0ZFVENI DQo+IA0KPiBUaGlzIGRvY3VtZW50IGRpZCBub3QgZGVmaW5lIGFueSB0ZXh0IHRvIGhlbHAgbWUg ZG8gdGhpcyBtYXBwaW5nLg0KPiBUaGlzIGFwcGxpZXMgYm90aCB0byB0aGUgbWV0aG9kcyBhbmQg dG8gdGhlIGVycm9yIGNvZGVzLiAgRnJvbSB0aGUNCj4gdGV4dCBpdCBhcHBlYXJzIHRoYXQgRkVU Q0ggaXMgYSBuZXcgY29uY2VwdCB3aGlsZSBQQVRDSCBhbmQgaVBBVENIDQo+IGFyZS9taWdodCBo YXZlIHNvbWUgc3VwcG9ydCBmcm9tIEhUVFAgYW5kIHRodXMgY2FuIGJlIGRpcmVjdGx5DQo+IHRy YW5zbGF0ZWQuICBIb3dldmVyLCB0cnlpbmcgdG8gZmluZCBhbGwgb2YgdGhlIGVycm9ycyBhbmQg ZG9jdW1lbnRzDQo+IG9uIHRoaXMgaXMgc29tZXdoYXQgcGFpbmZ1bCBhbmQgaWYgdGhlIHNlY3Rp b24gb24gaG93IHRvIGRvIGl0IGFuZA0KPiB3aGF0IHRoZSBlcnJvciBtYXRjaGluZyBpcyB3b3Vs ZCBiZSBoZWxwZnVsIGJvdGggbm93IGFuZCBpbiB0aGUgbmV4dA0KPiB2ZXJzaW9uIG9mIHRoZSBk b2NtZW50Lg0KDQpJIGFncmVlIHdpdGggeW91Lg0KDQpDaGVlcnMsIHQNCg0K From nobody Fri Jul 28 04:38:08 2017 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 1E1B01322D4 for ; Fri, 28 Jul 2017 04:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 h1xFijCwEuL9 for ; Fri, 28 Jul 2017 04:38:03 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255941322CE for ; Fri, 28 Jul 2017 04:38:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=oXoYzHiIZURhJ6PIsv2DVFPdJXJ1pIqbwyReMNalHhEJz8jvVUnkW8wW7AwNZaqRolagp0Avpwy/ARnRZAyO/QKurS9wpw61LLvGVwtqQw2EjazVb1JIi6dIsYcpZpn9MgXhR6em7Ry1EYxu5xWhSmwxG/kiQQD+FBGmrtb/lq0=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 28147 invoked from network); 28 Jul 2017 13:38:01 +0200 Received: from pd9e11f5a.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.31.90) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 28 Jul 2017 13:38:01 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <2CD73E04-4287-45A1-A83C-CA4CD976A0B5@tzi.org> Date: Fri, 28 Jul 2017 13:38:00 +0200 Cc: core-chairs@ietf.org, Adam Roach , The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <25FE644D-155A-44AE-A565-DC16FCADC76E@kuehlewind.net> References: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> <4DD370D3-62A2-460C-9D3F-0B96EA1A94F6@tzi.org> <2CD73E04-4287-45A1-A83C-CA4CD976A0B5@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170728113801.28138.67437@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?core-coap-tcp-tls-08=3A_=28with_DISCUSS=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jul 2017 11:38:06 -0000 Hi Carsten, I checked the latest version of the draft and I don=E2=80=99t really see = my other discuss points addressed (points 2 and 3 mainly about = connection handling and timing). Can you please explain how this is = addressed?=20 Related to some previous comments you provided: some of these points = might be addressed by an application on top of coap, however, this draft = should a) indicate that the application has to care about it, b) provide = recommendation what to do under which considerations, and c) potentially = even provide default parameters where possible. Thanks, Mirja > Am 10.05.2017 um 21:05 schrieb Carsten Bormann : >=20 > On May 10, 2017, at 18:49, Mirja K=C3=BChlewind = wrote: >>=20 >> You cannot use TCP without it reliability features. Having additional = reliability in the higher layer simply means the reliability is not = used. >=20 > =E2=80=A6 or that the features are suddenly viewed as conveying = application (or even end-to-end) reliability. > Much safer to remove them. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Fri Jul 28 05:37:09 2017 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 A7DC7131F7F; Fri, 28 Jul 2017 05:37:08 -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 2VSF8ibLr6JN; Fri, 28 Jul 2017 05:37:04 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 8B902131C28; Fri, 28 Jul 2017 05:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v6SCb0Ml013945; Fri, 28 Jul 2017 14:37:00 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xJpJD2phJzDKx4; Fri, 28 Jul 2017 14:37:00 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <25FE644D-155A-44AE-A565-DC16FCADC76E@kuehlewind.net> Date: Fri, 28 Jul 2017 14:36:59 +0200 Cc: core-chairs@ietf.org, Adam Roach , The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org X-Mao-Original-Outgoing-Id: 522938219.139926-3d02fdc1c9263f839ea7f101d74d2593 Content-Transfer-Encoding: quoted-printable Message-Id: <8A324329-D5AA-4B52-820F-80FB538765F6@tzi.org> References: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> <4DD370D3-62A2-460C-9D3F-0B96EA1A94F6@tzi.org> <2CD73E04-4287-45A1-A83C-CA4CD976A0B5@tzi.org> <25FE644D-155A-44AE-A565-DC16FCADC76E@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?core-coap-tcp-tls-08=3A_=28with_DISCUSS=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jul 2017 12:37:09 -0000 Hi Mirja, thank you for looking at the document again, and for clarifying that you = do expect some changes in the text and not just the email comments we = made. Just to gauge the level of detail you expect here: One plan would be to = appropriate some text from section 6 of RFC 7230, which might include = phrases such as "It is beyond the scope of this specification to = describe =E2=80=9C and "Implementations ought to anticipate the need to = recover from asynchronous close events.=E2=80=9D =20 I don=E2=80=99t think it is the intention of the WG to prescribe = specific timing or other parameters related to connection management; = e.g., we have learned from RFC 2616 that standardizing a specific number = for the limit to simultaneous connections (end of section 8.1.4 there) = can be a mistake; this was not repeated in RFC 7230 (replacement text: = "A client ought to limit the number of simultaneous open connections = that it maintains to a given server.=E2=80=9D =E2=80=94 no specific = number given, and non-RFC2119 =E2=80=9Cought to=E2=80=9D language). I expect we will have text for this in the next version -10 shortly. Gr=C3=BC=C3=9Fe, Carsten > On Jul 28, 2017, at 13:38, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Carsten, >=20 > I checked the latest version of the draft and I don=E2=80=99t really = see my other discuss points addressed (points 2 and 3 mainly about = connection handling and timing). Can you please explain how this is = addressed?=20 >=20 > Related to some previous comments you provided: some of these points = might be addressed by an application on top of coap, however, this draft = should a) indicate that the application has to care about it, b) provide = recommendation what to do under which considerations, and c) potentially = even provide default parameters where possible. >=20 > Thanks, > Mirja >=20 >=20 >> Am 10.05.2017 um 21:05 schrieb Carsten Bormann : >>=20 >> On May 10, 2017, at 18:49, Mirja K=C3=BChlewind = wrote: >>>=20 >>> You cannot use TCP without it reliability features. Having = additional reliability in the higher layer simply means the reliability = is not used. >>=20 >> =E2=80=A6 or that the features are suddenly viewed as conveying = application (or even end-to-end) reliability. >> Much safer to remove them. >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >=20 >=20 >=20 From nobody Fri Jul 28 06:22:28 2017 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 73B42132000 for ; Fri, 28 Jul 2017 06:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 2Yt-34peLtKp for ; Fri, 28 Jul 2017 06:22:25 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B30131C90 for ; Fri, 28 Jul 2017 06:22:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=CHXBhxoSRyybzcOU0xGzerpqV8DAclfG8jmSHBzZq3MM5+a08BL3D7D0m0+mdr/Jtpv+bfUVHCCvvSPnkdGEFHZ4ORICD9+N1ibsH4Oaf1YXljS2OfNxEn3iqBBPLk/4qE8+DpdlOYL9/uv1/YRsIedRjc2UHagnANb6TjiQyg8=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 5282 invoked from network); 28 Jul 2017 15:15:42 +0200 Received: from pd9e11f5a.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.31.90) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 28 Jul 2017 15:15:42 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <8A324329-D5AA-4B52-820F-80FB538765F6@tzi.org> Date: Fri, 28 Jul 2017 15:15:41 +0200 Cc: core-chairs@ietf.org, Adam Roach , The IESG , core@ietf.org, draft-ietf-core-coap-tcp-tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <732F90E8-E28C-46E5-93B1-0CD7302BB809@kuehlewind.net> References: <149442363148.22664.577627584227036852.idtracker@ietfa.amsl.com> <799244C3-CD27-4F46-B5E3-E24457BC7F4B@tzi.org> <4DD370D3-62A2-460C-9D3F-0B96EA1A94F6@tzi.org> <2CD73E04-4287-45A1-A83C-CA4CD976A0B5@tzi.org> <25FE644D-155A-44AE-A565-DC16FCADC76E@kuehlewind.net> <8A324329-D5AA-4B52-820F-80FB538765F6@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170728131542.5273.35285@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [core] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?core-coap-tcp-tls-08=3A_=28with_DISCUSS=29?= X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jul 2017 13:22:26 -0000 Hi Carsten again, thanks! Actually my discuss point 3 is not an application requirement = but a protocol mechanism and in this case at least recommended numbers = make sense, where a number can depend on e.g. the RTT. Will wait for the update! Mirja > Am 28.07.2017 um 14:36 schrieb Carsten Bormann : >=20 > Hi Mirja, >=20 > thank you for looking at the document again, and for clarifying that = you do expect some changes in the text and not just the email comments = we made. >=20 > Just to gauge the level of detail you expect here: One plan would be = to appropriate some text from section 6 of RFC 7230, which might include = phrases such as "It is beyond the scope of this specification to = describe =E2=80=9C and "Implementations ought to anticipate the need to = recover from asynchronous close events.=E2=80=9D =20 >=20 > I don=E2=80=99t think it is the intention of the WG to prescribe = specific timing or other parameters related to connection management; = e.g., we have learned from RFC 2616 that standardizing a specific number = for the limit to simultaneous connections (end of section 8.1.4 there) = can be a mistake; this was not repeated in RFC 7230 (replacement text: = "A client ought to limit the number of simultaneous open connections = that it maintains to a given server.=E2=80=9D =E2=80=94 no specific = number given, and non-RFC2119 =E2=80=9Cought to=E2=80=9D language). >=20 > I expect we will have text for this in the next version -10 shortly. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On Jul 28, 2017, at 13:38, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Hi Carsten, >>=20 >> I checked the latest version of the draft and I don=E2=80=99t really = see my other discuss points addressed (points 2 and 3 mainly about = connection handling and timing). Can you please explain how this is = addressed?=20 >>=20 >> Related to some previous comments you provided: some of these points = might be addressed by an application on top of coap, however, this draft = should a) indicate that the application has to care about it, b) provide = recommendation what to do under which considerations, and c) potentially = even provide default parameters where possible. >>=20 >> Thanks, >> Mirja >>=20 >>=20 >>> Am 10.05.2017 um 21:05 schrieb Carsten Bormann : >>>=20 >>> On May 10, 2017, at 18:49, Mirja K=C3=BChlewind = wrote: >>>>=20 >>>> You cannot use TCP without it reliability features. Having = additional reliability in the higher layer simply means the reliability = is not used. >>>=20 >>> =E2=80=A6 or that the features are suddenly viewed as conveying = application (or even end-to-end) reliability. >>> Much safer to remove them. >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>=20 >>=20 >>=20 >=20 From nobody Fri Jul 28 14:04:32 2017 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 625D51270B4 for ; Fri, 28 Jul 2017 14:04:30 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 LOjULuUD6k-t for ; Fri, 28 Jul 2017 14:04:27 -0700 (PDT) Received: from smtp93.ord1d.emailsrvr.com (smtp93.ord1d.emailsrvr.com [184.106.54.93]) (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 BD2D11243F6 for ; Fri, 28 Jul 2017 14:04:27 -0700 (PDT) Received: from smtp12.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp12.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 12B08E0088; Fri, 28 Jul 2017 17:04:27 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp12.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A4444E006E; Fri, 28 Jul 2017 17:04:26 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Fri, 28 Jul 2017 17:04:27 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <3D8076B6-615F-4A86-89A4-539DCBC1BBB2@ericsson.com> Date: Fri, 28 Jul 2017 15:04:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8BF7198C-8D5D-42DA-8AC4-9295C753689B@iii.ca> References: <988B5CDC-8709-4BF1-AB6F-C5B16D45E563@ericsson.com> <0fdb5c19-5edb-01e2-d2cc-776f285f6770@filament.com> <3D8076B6-615F-4A86-89A4-539DCBC1BBB2@ericsson.com> To: core X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [core] "ni" URIs in SenML names (and no "; " in allowed characters) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.22 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, 28 Jul 2017 21:04:30 -0000 TL;DR What I suggest we do in this case is add text to the draft which says = something along lines of: When encoding a "Named Information" URI into a SenML name, it is = RECOMMENDED that the ';' between the digest algorithm and digest value = be converted to a '.'=20 ------------------------------------ If you want the longer version .....=20 People in the core WG often think about what SenML means to implement on = the constrained device side and that is important ... but equally = important is the servers that can receive data from millions of devices = and process it in a cost effective way. Right now they check the data = once when it comes in to ensure it meets the required syntax then on all = the internal systems, they do not have to constantly check if the data = is safe for the things it is used for. One of the big concerns is = database attacks best is summarized by https://xkcd.com/327/ If the = database does not allow one to safely use character X and character X is = allowed in a senml name, then the needs to be escaped everywhere it is = used. It is preferable to have a very reduced set of charter so they = don't have to be escaped.=20 Similarly, senml name are often used in query parameters in a HTTP URL.=20= It is impossible to define a syntax for names that can both be used as a = URL and can be used as a segment of a URL with no escaping. Early on we = choose to have the SenML names be such that we could use them as parts = or URLs. This means we end up needing some amount of encoding or = escaping when we try and fit a full URL into a name.=20 Changing to allow "/" was a huge change at this late stage but no one = could com up with a concrete security vulnerability it intruded to = existing systems. However, introducing ";" would definitely introduce = security venerability to running code so at the same time that the input = check was removed to allow ";", every place that used the name would = have to check and or escape the use of ";" to make it safe. This slows = down the code raising costs and introduces more bugs and security = vulnerabilities.=20 Every version of the draft since = https://tools.ietf.org/html/draft-jennings-senml-00 published in June = 2010 has had the roughly the word This restricted character set was chosen so that these names can be directly used as in other types of URI including segments of an HTTP path with no special encoding and can be directly used in many databases and analytic systems. The most resent version added "/" which is likely to be highly = inoperable given it was added in 2017. But I do not think we can ask = people with high speed deployed server software to add ";" at this = point. The gains of adding this do not offset the spend and security = concerns of just using simple names that do not require escaping.=20 To get to the specific of the NI URI and the ";" that is causing = problems ... the text after it is constrained o the base64 URL alphabet = (which is fine in name) and the text before is the hash algorithm and = will mostly likely be letters, number and minus sign. I think using the = "." instead of a ";" would be totally safe from a parsing point of view = here in that anything parsing this that needed to fine the end of the = algorithm and start of base64 hash could safely assume that the "." was = the separator of the two. Alternatively just the hash could be used with = for the name with the algorithm carried in meta data about the sensor. = I agree with peters point about avoid bespoke encoding rules but given = the lack of clear use case for using NI names here at all, perhaps it = might be better to ask even if using hash based names, why use a URL = syntax for them.=20 Anyways, we can define names such that they can be use in URI with no = escaping, or they can be URI with no escaping, but we can't get both at = the same time. We decide to allow them to used in URI and I think that = is the right decision.=20 PS ... Sorry about the top posting... some guy called Peter once told me=20= :) A: Because it messes up the order in which people normally read text. Q: Why is top-posting so bad? A: Top-posting. Q: What is the most annoying behavior on email discussion lists? > On Jul 24, 2017, at 2:19 AM, Ari Ker=C3=A4nen = wrote: >=20 >=20 >> On 22 Jul 2017, at 20.53, Peter Saint-Andre - Filament = wrote: >>=20 >> On 7/22/17 7:34 AM, Ari Ker=C3=A4nen wrote: >>> Hi all, >>>=20 >>> In the Friday CoRE session we discussed that adding ";" to the >>> allowed characters of SenML names could be useful for accommodating >>> for certain kinds of URIs, like "ni". However, as I mentioned during >>> the meeting, whether the ";" character is safe for names needs to be >>> checked with experts on the topic. We got now feedback that it is >>> *not* safe to use that character and should not be included in the >>> character set. >>=20 >> For the edification of working group participants, can you elaborate = on >> what the safety issue is? For instance, does using ';' introduce a >> security vulnerability in some constrained systems? >=20 > Apparently it's more of a problem for the back-end systems, but I'll = let Cullen elaborate on the details since he raised the concerns on = this. >=20 >>> Therefore, instead of allowing ";" in names, we could consider >>> documenting simple translation rule for "ni" URIs: just switch the >>> ";" into ":". In the ni-URIs the ";" character is used just once: >>> between base64 encoded hash and the algorithm used to generate the >>> hash value [1]. And to avoid issues with encoding the authority = part, >>> we could use just the alg-val part of the URI as name. >>=20 >> I'm sure we'd all like to avoid yet more bespoke encoding rules. >=20 > That would be nice. In case of "ni" URIs I don't think the translation = rule is a big issue, but in general the restricted character set does = restrict the usability of URIs as names. However, having such capability = is not one of the design goals of SenML, but just the other way around: = being able to use names *in* URIs.=20 >=20 >>> This could be done in the SenML base spec, or we could leave all = such >>> translation / name-mapping rules for future spec(s) since they are >>> just a special case for name generation and not a requirement for >>> SenML as such. I'm perhaps leaning towards the latter option to get >>> SenML shipped now. >>=20 >> Leaving this out of SenML for now makes sense, but (at the risk of >> sounding like a broken record) I'll reiterate that we need to make it >> very clear that many URI schemes and URN namespaces can't be used as >> SenML names because of the restricted character set. >=20 > Yes, I'm planning to incorporate the text you proposed for the updated = revision to address this. All, please comment if you think that's a bad = idea. It's not a technical change, just clarification of existing rules. >=20 >=20 > Cheers, > Ari >=20